软件开发中的11个系统思维定律

英文原文:11 Laws of The System Thinking in Software Development

  “我会更加努力地工作” —— 一匹名叫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. 把系统看做一个整体,并且视其为其他系统的一部分。

  系统思维方面有很多挑战,通过获取并且利用有关系统工作方式的知识,我们可以战胜其中的很多挑战。但是,大部分严峻挑战是我们人类与之相冲突的本性。我们的激情、感情以及本能可以轻易改变我们理智、条理分明的思维方式。掌握系统思维方式的第一步就是要学习如何跟自己合作

时间: 2024-10-13 11:45:31

软件开发中的11个系统思维定律的相关文章

软件开发中的工作事务与微技能分级评估

工作三四年后,是否感觉自己开始做一些没有提升的事情?是否在做一些低水平重复建设的事情呢? 通过对软件开发中的工作事务与微技能进行评估和分级,可以清晰地理解自己的工作构成.评估自己的当前水平.定位下一步发展的方向和思路. 难度系数 *** 1 1.  完成初级的页面测试: 2.  编写简单非专业的文档: 3.  能够理解基本业务: 4.  日常普通的交流: 难度系数 *** 2 1.  完成一个简单的脚本实现临时需求, 15-20 min: 2.  完成一个函数或方法的单测, 5-15 min ;

对软件开发中uml建模的理解和图形整理(一)

由于uml(统一建模语言)在开发中经常会用到,特别是在软件开发中的OOAD阶段,因此要理解和使用uml显得尤为重要.在uml开始之前,咱先回顾一个OOAD.OOP的主要特征. OOAD:根据面向对象的方法学来对软件系统进行分析和设计的过程.它包括OOA 分析阶段和OOD设计阶段.其中分析阶段主要解决"What to do?"的问题,而设计阶段主要解决"How to do?"的问题.具体来说就是:在OOA分析阶段咱要做的主要工作就是建立对业务问题域的视图(建立模型).

软件开发中,什么是模块化开发?

软件产品可以被看作是由一系列具有特定功能的组件组成,作为一个完整的系统也可以被分解成一系列功能模块,这些模块之间的相互作用就形成了系统的所有功能. 所谓模块是指可组成系统的.具有某种确定独立功能的半自律性的子系统,可以通过标准的界面和其他同样的子系统按照一定的规则相互联系而构成的更加复杂的系统.每个模块的研发和改进都独立于其他模块的研发和改进,每个模块所特有的信息处理过程都被包含在模块的内部,如同一个"黑箱",但是有一个或数个通用的标准界面与系统或其他模块相互连接. 在软件的模块化开发

软件开发中的自测及C代码示例

在软件开发中,程序自测是一个永远都绕不开的话题.很多开发人员以写出有难度的代码为荣,但却不重视对自己编写的代码进行测试,这导致了最终到达客户手中的产品质量不高,bug频发,损害了公司的形象.对于一个开发人员来说,我们应该将开发和自测置于同等重要的地位,我们花在自测上的时间要不比开发少.能否对自己编写的代码进行充分的自测也是检验一个开发人员水平高低的标准之一. 自测方法 根据所编写的程序的特点,自测方法大致有如下几种: 第一种,利用模拟工具进行自测.这种方法适用于需要其他模块(尚不具备)发过来的消

基于git的软件开发中并行工程管理以及版本控制系统概要

并行工程师什么,这里就不再解释(不懂请百度),实际上,在软件开发过程中,涉及到多人合作的以项目小组形式完成开发的软件(这里指广义上)或多或少都使用了并行工程的概念,在正式的项目开发中,项目小组成员总是分工合作每人完成一部分,然后再合并起来,而且,在实际应用中,尽管使用的是瀑布模型完成开发,但总是所有项目小组成员同时开始完成自己的部分,这,其实已经是并行工程了,我们可以自豪的宣布:我们在开发过程中使用了并行 工程这种高大上的玩意来提高开发速度,所以,老板你得给我们涨工资! 很简单吧,看起来好简单的

软件开发中 常见英文文档 缩写(转)

软件开发中常见英文缩写和各类软件开发文档的英文缩写: 英文简写 文档名称 MRD market requirement document (市场需求文档) PRD product requirement document (产品需求文档) SOW 工作任务说明书 PHB Process Handbook (项目过程手册) EST Estimation Sheet (估计记录) PPL Project Plan (项目计划) CMP Software Management Plan( 配置管理计划

现代软件开发中现代软件工程的合理运用

进入新时期以来,我国的社会经济水平与科学技术发展水平都上升到了一个新的高度,不论是在社会生产中还是在日常生活中,计算机信息技术都得到了普遍的运用.而计算机信息技术主要是在软件的支持下进行系统运行的现代科学技术,在现代软件开发中,现代软件的整体特点与结构都会对现代软件工程在其中的应用产生重大的影响,因此,必须要采用最合适的软件工程方法,让现代软件工程在现代软件开发中得到更加合理的应用.

移动视频会议软件开发中应该注意的问题

在当前移动互联网迅速发展之下,智能手机的年增长量远大于PC的增长量,而移动终端相应的种类及软件数量都在迅速增加,因此大部分的PC应用软件都能在移动终端上找到类似的软件,甚至很多公司的PC软件都移植到移动终端上,移动终端软件已经能与PC软件平分秋色.作为企业级的高端应用——视频会议软件,和大多数的软件一样,在移动终端都有了相应的应用软件.在手机.平板.甚至在智能电视上进行视频会议已经不是新鲜事.那我们怎样才能在移动终端上开发出类似PC上的视频会议软件呢?我们应该注意些什么问题呢? 首先我们要把移动

彼之蜜糖,吾之砒霜——聊聊软件开发中的最佳实践

"描述一个事物,唯有一个名词定义它的概念,唯有一个动词揭露它的行为,唯有一个形容词表现它的特征.要做的,就是用心去寻找那个名词.那个动词.那个形容词--" -- 福楼拜 (Gustave Flaubert) 我想讲个故事. 很久很久以前(一般讲故事都是这样开头吧), 两个老工程师在一起聊天,谈各自生涯中最自豪的工程.其中一个先讲述了他的杰作: " 我们建造的桥,横跨一个峡谷,峡谷很宽很深.我们花了两年时间研究地质,选择材料.聘请了最好的工程师团队来设计方案,而这又花了五年时间