事实1:敏捷并不完美,敏捷一直在发展。敏捷宣言是2001年时17位为软件开发专家根据亲身实践和帮助他人实践,是对过去软件开发良好做法的总结,就如何更好地开发软件达成的共识。敏捷宣言选用“揭示/寻找(uncovering)”一词表明作者并没有所有的答案,其作用之一是让人们更加认真仔细的思考如何开发软件,寻找更好的软件开发方法。另外,就范围而言并没有覆盖软件开发的所有方面,比如敏捷没有涉及用户体验设计。另外,敏捷运动都没有与文化概念(无论在组织层面还是在国家层面上的文化)以及文化与实践之间的微妙互动(这是情景中不可或缺的一部分)完全融为一体。毫无疑问,敏捷一直处于演进之中,近年Kanban的出现很好地反映了这一点。敏捷是不完美的,同时,敏捷还将继续演进。
迷思2:敏捷是银弹。
事实2:敏捷不是银弹。敏捷只是接受常识*,提醒我们构建软件的是人。敏捷接受软件交付过程中固有的复杂性和不确定性。敏捷并不完美敏捷项目和其他项目一样同样会失败,只是相对使用传统软件开发方法而言有更高的成功率。另外,软件企业在变化,问题在变化,技术在变化,单纯地依靠任何一种管理和技术都不可能解决问题,也没有哪个方法可以直接套用。理论带来的是5%的启发或者灵感,95%的是针对软件企业实际的探索,留给了软件企业自己。敏捷也不例外,敏捷不是终点,只是敏捷是一个很好的起点和路标。
迷思3:敏捷过程。
事实3:很多人来敏捷寻找“敏捷过程”,将“敏捷看作价值观和文化”的更为宽泛视角来看敏捷或许能够更好地理解敏捷。倘若在敏捷宣言发布后的10年后的2011年还将敏捷落点在“过程”上,不能不说让我感到遗憾?!像Scrum、XP等涉及的过程只是起点,不是终点,也就是说单单一个“守”是不够的。另外,人们一直在说“敏捷过程”,但是实际上,不论是正式的还是在人们头脑中所默许的描述,过程本身都不是敏捷的。人可以敏捷,团队或者组织也可以敏捷。成为敏捷,而不是做敏捷。
迷思4:敏捷团队没有文档。
事实4:这是很典型地对敏捷宣言的误读或是误解。敏捷团队并不意味着不写文档,更确切地说敏捷团队没有写任何不必要的文档,对待文档像其他交付物一样,只是更喜欢面对面的沟通。敏捷并不否认文档的作用,与之同理,敏捷认同过程和工具、合同谈判和计划的价值,只是认为人及其交互、可工作的软件、响应变化更有价值。
迷思5:敏捷是反对规划的。
事实5:敏捷不反对规划,需要的是敏捷地去做估计与规划,发生变化时必须专业地判断回到原有的计划还是创建一个新计划哪一个更合适。另外,敏捷意味着“关注当前的现实”,敏捷规划是多层次的,更为宽泛(比如,每个季度的发布规划、每2周的迭代规划、每天的站立会议),使用不同的工具,比如使用燃尽图而不是用甘特图来可视化计划,让利益攸关者尽早地知道问题,更好地响应变化。
迷思6:敏捷反对合同。
事实6:洽谈协议,签订合同或者内部项目章程,并不是坏事,但仅有这些是不够的。客户需要的是满足他们需求的软件。客户和开发团队合作是最好的解决方案,合同提供了边界条件,通过不断协调,开发团队理解真正需求,并交付客户需要的软件。
迷思7:敏捷无纪律。
事实7:纪律提供了团队做不喜欢却又不能不做事情的能力,敏捷是讲究纪律的,其中XP尤其如此,比如,必须测试,必须反馈,必须定期交付,必须更新计划。
迷思8:敏捷反对架构。
事实8:架构在敏捷项目中和其他软件项目中一样重要。只是反对大规模预先设计(BDUF,Big Design Up Front),通过不同的手法(比如简单设计、测试驱动、持续集成和重构等)进行演进设计,实质上意味着系统设计随着系统实现而成长。在编写代码之前有进行设计的必要。其中一些设计工作在编写任何代码之前,但大多数设计则出现在针对特定任务的阶段过程中编写代码之前。在预构(Prefactoring)和重构(Refacroring)之间有一种新的平衡。敏捷强调设计简单、清晰并且易于重构。一个优秀的架构对于团队的所有的人都是简单并易于理解的。
迷思9:敏捷反对方法学,敏捷以“传统”为敌,以“PMP、CMMI与IPD”为敌。
事实9:敏捷不反对方法学,相反试图为方法学正名而努力。敏捷反对以文档驱动的重型软件开发方法,提供另外的选择,希望能恢复一种平衡,敏捷宣言的价值比较描述是其表现形式反映了这一点。真正拥护敏捷者并不会禁止或不提倡从其他阵营中汲取营养,敏捷的目的之一是促使人们认真仔细地思考如何更好地开发软件。
迷思10:敏捷团队反对管理。
事实10:管理仍然重要,管理的职责仍需承担,只是敏捷倡导创建自组织团队,敏捷反对“命令-控制”的管理方式,偏好“领导-协作”的管理方式。敏捷团队有权进行设计、计划和执行任务,并监督和管理自己的工作过程和进度,在健全的自组织团队中,团队成员共同承担领导角色,对工作成果共担职责。
迷思11:敏捷对人员要求高,适合于有经验有能力的高级技术人员组成的团队。
事实11:试想一下“使用非敏捷过程就能避免使用任何有有能力有经验的人”吗?事实上,同样的一批人应用敏捷比使用其他方法更有可能成功。根据经验,在敏捷项目中,通常初学者与有经验者之比在3:1到5:1之间。
迷思12:敏捷只能应用于小团队,敏捷无法扩展。
事实12:敏捷是可以扩展的,但敏捷扩展像其他软件实践一样,没有那么简单,没那么好。敏捷起初起源于小团队,许多敏捷实践都在团队层次上自然形成,但经过多年发展之后,有不少人对敏捷价值观、原则和实践在大团队中加以应用,更确切地说进行了试验,说明敏捷可以扩展至大团队,获得了一些成功经验。我认为与其,考虑如何往上扩展,不如尝试如何往下缩减,即大团队做减法,围绕人和工作系统(环境),以产出价值来衡量,去除不合理的部分。
迷思13:敏捷倡导的增量迭代开发就是微型瀑布(分析-设计-编码-测试)的叠加。
事实13:事实是分析、测试、编码和设计在开发过程中是持续的活动,每个迭代都产生的可工作软件。如图所示。
迷思14:敏捷是关于软件开发,不影响其他。
事实14:敏捷是一套面向商业竞争成功的适应能力和响应能力的价值观和原则。敏捷包含的概念和实践方法在挑战传统的组织假定,往往会导致组织变革。比如,敏捷倡导的自组织和跨专业/功能的团队就是高冲击力的代表;更小频繁发布软件成为有效时,企业不得不处理如何最大化其市场影响的问题;“在整个项目过程中,业务人员和开发者必须每天一起工作。”对产品营销和产品管理也会产生影响,通常需要新的资源和组织结构,如对产品经理的要求会更高,产品设计可能会与研发部门、市场部门并列。
迷思15:敏捷不过是经验之谈、观点或“信仰”,无法评估其是否合理。
事实15:不少敏捷方法明确提出其背后的科学理论依据,比如自适应软件开发的理论是复杂自适应理论,Scrum的理论依据是控制论,Crystal的理论依据是博弈论,精益软件开发的理论依据是排队论和系统论。应用排队论、控制论、信息论和博弈论等正式模型来评估采用敏捷的工作系统,证明其确实可以产生优秀绩效。
*敏捷背后的四个假定或接受的四个事实:
1. 客户不完全知道自己的需要。通常,在项目开始之前搜集完所有需求是不可能的。
2. 开发团队不完全知道如何构建软件。通常,在项目开始之前完全确定技术解决方案是不可能的。
3. 需要和构建会发生变化。唯一不变的是变化。
4. 在现实中,永远有比你时间和金钱所允许做的事更多。