网站建设公司网站,百度知道答题赚钱,手机网站怎么做沉浸式,新式装修“我会更加努力地工作”——一匹名叫Boxer的马#xff08;出自乔治奥威尔的《动物农庄》#xff09; 彼得圣吉在其著作《第五项修炼》中提到的系统思维定律同样适用于软件开发。 1. 今日的问题源于昨日的解决方案#xff08;Today’s problems come from yesterday’s sol… “我会更加努力地工作”——一匹名叫Boxer的马出自乔治·奥威尔的《动物农庄》 彼得·圣吉在其著作《第五项修炼》中提到的系统思维定律同样适用于软件开发。 1. 今日的问题源于昨日的解决方案Today’s problems come from yesterday’s solutions 当解决问题时我们会感到很高兴。我们经常不考虑后果。令人感到意外的是我们提出的解决方案可能会产生反作用并带来新问题。     作为对取得巨大成功的团队的奖励公司决定为团队中的少数骨干成员发放奖金并晋升职位。团队中的其他成员会感到不公平并且会丧失积极性。最终使团队成员之间的关系更加紧张后续项目也就很难再取得成功。     项目经理频繁要求开发者修复一个新的软件Bug或者处理客户的紧急需求而开发者尽力满足这些要求。但是过于频繁地分散精力会妨碍他们完成迭代过程中的主要任务。因此项目进展很慢。 2. 用力越大系统的反作用力也越大The harder you push, the harder the system pushes back 当事情的进展结果并非如我们所愿时我们会固执地坚持自己的方法。我们没有时间来停下来思维并寻找更好的替代方案而是“义无反顾”地向前冲。有时候虽然解决了问题但往往又发现深陷于其他问题之中。     当一个系统远未完成时经理通常会不断催促员工加班加点地工作并且要求按时完成。系统bug数量的持续增加及整体质量的急剧下降导致更多的延误。因此需要做更多的工作来部署软件系统。     为了满足新系统的要求开发者勇敢的对原有的系统架构进行扩展但死板陈旧的方法已经不能满足这些新需求。他们忙于做这件事以至于没有时间停下来仔细分析并且改变方法从而导致系统质量下降。 3. 福兮祸之所伏Behavior grows better before it grows worse 短期的解决方案会给我们带来短暂的休息和状况的暂时改善但是不会从根本上解决问题。这些问题终究会使情况变得更糟。     公司为顾客提供丰厚的优惠并投入巨资宣传让很多人购买软件 。但是顾客购买之后很不满意因为软件无法使用也不可靠。     如果开发小组能够按时完成系统开发管理层承诺如果开发团队能够按时完成系统开发公司会提供巨额的奖金。一个团队开始努力的工作但很快他们就意识到这是不可能实现的。于是开发者变得悲观并丧失动力。 4. 最容易出去的方法往往会导致返回来The easy way out usually leads back in 在生活中学到的一些解决方案能够帮助我们轻易地并且更早的地获得成功。我们总是试图把它们强加到任何情形上而忽略了特殊的背景以及相关人员。     开发者还没有准备好接受结对编程或者测试驱动开发这样的实践时敏捷教练强行实现完全的极限编程。这会给任何敏捷方法带来压力、冲突以及负面影响。     开发者把设计模式应用到任何地方这是徒劳的而且这会让系统变得复杂。 5. 治疗带来的结果可能会比疾病导致后果更严重The cure can be worse than the disease 有些熟知的方法可能会更危险比如在编程的时候喝啤酒来减轻不切实际的任务期限带来的压力。     由于不信任全职开发者一家公司雇佣了大量的承包商来开发核心功能。结果系统不具有概念完整性自己公司的开发者看不懂并且无法做出修改。所以公司员工也不了解相关领域的知识、解释以及概念。     开发者会走捷径拷贝相似功能的代码来赶进度并且争取尽快发行第一个版本。他们一开始进展迅速但是代码最终会变成大泥球比喻系统结构不清晰。 6. 欲速则不达Faster is slower 当我们看到成功的曙光我们会全力以赴不再小心谨慎。然而最优增长速率通常会比可能的最快增长速率要慢得多。     经理们往往为已经成功的项目增加很多人手但总体进展就会变慢因为交流所用的花费增加以及团队成员之间失去默契。     在没有对代码进行合理重构及改善的情况下开发者快速的为系统添加新的功能会使系统变得难懂而且难以修改。 7. 在时间和空间上因果并不密切相关Cause and effect are not closely related in time and space 我们善于为出现的困难寻找原因即使这些原因很牵强并且远非是真正的根本原因。     为了按时完成系统开发团队不再接受来自客户的需求改变。因此客户对发行的软件不满意。     实时系统历经坎坷之后管理层迫使开发者同意并且在给系统做出任何修改之前撰写详细的技术说明。结果开发者失去了为系统做出任何改进的动力并且开始拖延。 8. 微小的改变可以产生明显的效果但这种杠杆效应最大的地方往往也最不明显Small changes can produce big results-but the areas of highest leverage are often the least obvious 像改变公司政策、愿景或者广告用语这样显而易见并且关系重大的解决方案往往不起作用。相反小而普通但持续的改变却会带来大不相同的效果。     发者每天都与客户进行交流并且做出大部分决定。因此能够更好地理解客户的需求、做出更好的决定并且给出最优的解决方案。     开发者为系统的每项功能设计自动化单元测试。因此设计更灵活、人们更自信、系统在每此修改之后都能得到完全的测试。 9. 鱼与熊掌可以兼得但不是同时兼得You can have your cake and eat it too – but not at once 我们经常会面对刻板的“非此即彼”选择。如果我们改变一下自己的观点及系统规则这些选择有时并不会使我们进退两难。     经验丰富的项目经理知道增加系统特性的数量与削减时间和开支不可兼得。然而如果我们完善一下想法、寻找合适的人才并且避免过度开发这也是可能做到的。     开发者认为他们应该要么采用事务脚本要么采用域模型体系架构模式。然而复合域中的高性能解决方案可以将两者结合以得到最佳性能。 10. 把一头大象分两半不会得到两头大象Dividing an elephant in half does not produce two small elephants 无法整体了解系统往往会做出次优决定。     项目经理往往通过生成的代码量和迭代过程中实现的功能数来评估开发者。而开发者往往会生成大量无用代码。     管理层承诺每发现一处系统bug测试者将得到5美元。测试者对跟开发者合作不再感兴趣并且不再试图消除产生bug的根本因素。团队之间良好而且高效的关系不复存在。 11. 无可非议There is no blame 我们喜欢归咎于客观条件或对别人指指点点甚至对此深信不疑。但是我们自己以及问题的原因都是系统的一部分。     今天早上团队没有发布系统完全是乔的过错。即使项目经理亲切地为其提供了免费的啤酒、T恤以及披萨他也没能在一晚上的时间内修复所有的缺陷。     人们不会使用一个公司优秀的Web 2.0社会化应用用户喜欢简单实用的东西并且不会感激你辛勤工作的成果。 以上11条系统思维定律表明我们提出的所有解决方案都会产生一定的后果有时非常严重并出乎意料。我们周围的系统本就那样我们不应苛责它们而是要从中学习。要掌握系统思维方式并控制这些系统我们需要做到如下几点     1. 要明白我们是在跟什么样的系统打交道是人或是软件     2. 有意识地学习相互关系、因果链     3. 把系统看做一个整体并且视其为其他系统的一部分。 系统思维方面有很多挑战通过获取并且利用有关系统工作方式的知识我们可以战胜其中的很多挑战。但是大部分严峻挑战是我们人类与之相冲突的本性。我们的激情、感情以及本能可以轻易改变我们理智、条理分明的思维方式。掌握系统思维方式的第一步就是要学习如何跟自己合作。 后话 在软件开发过程中你有或缺乏哪些系统思维的使用经验 编者注原文作者Andriy Solovey从事软件开发已有15年做过开发人员、软件经理和系统架构师。关注构建优质、可靠和可用的软件。《如何使用搜索技巧来成为一名高效的程序员》就是他所写。 原文链接http://www.jobbole.com/entry.php/394-软件开发中的11个系统思维定律转载于:https://www.cnblogs.com/MSRA_SE_TEAM/archive/2010/12/18/1909855.html