中国敏捷实践中的误区（一）敏捷不是银弹

不少公司在尝试实施敏捷开发，敏捷实践在中国越来越流行，但当中敏捷涉及思想和意识上的转变，容易造成各种管理和实践上的差异，笔者常见的有三种情况。

一、小瀑布开发

敏捷当然不是小瀑布开发，很多团队开始四周迭代时，都希望可以逐步改变团队以前的开发习惯，例如：单一功能团队、团队之间交接，然后就会发现团队在这四周内依然像瀑布式开发。

我们都鼓励短迭代，两周比四周能得到更快的反馈，两周迭代比四周迭代更有效打破前面提到的老习惯，而要达到两周迭代，就必需要适当的实践配合，用户故事纵向划分、敏捷建模、测试驱动开发、持续集成、验收测试驱动开发都是有效帮助团队达到短迭代的方法。

而这里又引伸到另一个问题，就是组织能投入多少时间让团队学习这项新技能，从组织的角度去看这些问题，就是这些的回报期要多久，当然，就如丰田公司也是发展了很多年才累积到今天的成果，管理者也需要耐性才可以看到成果，而招聘优秀的开发人员更是非常重要的事情，这也引伸到下一个误区。

二、敏捷开发只是开发团队的事

写程序的是开发人员，实施敏捷时对他们的影响的确会是最大的，但不代表组织里其他角色不会受影响，亦不要以为自己不是开发人员就可以置身事外，这会改变其他员工的配合方式，所以他们的参与都很重要。

以产品管理为例，传统开发基本是顾客与开发团队的博弈，两方为自己的利益在拉锯，而焦点也不在于如何交付价值，而是各种各样的局部优化的行为。而在提倡开发团队与产品管理紧密合作和提高透明度的前提下，打破传统“产品管理VS开发团队”的矛盾以及如何把真正客户和开发团队拉得更近就是真正问题。

同样，大公司有各种各样的政策，有些政策却成为实施敏捷上的障碍，要改变相关政策，一定要跟人事部门做好沟通，也有案例是邀请人事部门的同事接受敏捷组织相关的培训，让他们知道如何更好去配合团队开发的需要。

跟人事管理政策息息相关的还有绩效管理和汇报架构，传统的管理模式下集中管理个人绩效却忽略作为团队的表现，而一个团队内各自有自己的汇报上司，更会令这团队无法做到应有的集中力。在实施敏捷的时候，亦应该检讨组织内影向个人绩效的措施，并加大鼓励团队合作精神，给客户最大的价值。

三、敏捷转型“项目”

“敏捷转型项目”是常听到的词语，这会是什么误区呢？这种说法的误区在于视敏捷转型为有时限和终点的活动，其实不论是敏捷、Scrum或者精益，都提倡持久的改善，通过学习、实践提升团队解决问题能力，简单点就是说：“没有最敏捷，只有更敏捷”。而管理者的角色不是管理转型项目，而是走到现场了解前线工作人员的工作实况，协助消除组织里的阻碍，并提供支持团队所需要的环境、工具、培训等的支持。

敏捷不是银弹，“敏捷”本身是形容词，在敏捷开发中是指能适应变化而作出改变，而且有持续学习的特质，在一些案例中这些意识和观念没有扩展到整个组织里的时候，就会出现一种“做敏捷”的情况，依旧以为敏捷实施只是另一个转型项目，以为敏捷只是另一种开发过程，以为做了书上提到如站立会、写用户故事等等的实践就当是“敏捷了”，以为办公室里加放了状态墙就是实施了“看板”或者“精益”，这些为做而做的事情，如二次世界大战时期太平洋群岛上土人见到飞机和军人所做出的模仿和膜拜行为。对此，笔者的建议是：鼓励组织深入并持续去认识敏捷，了解背后的思想，尝试不同的实践，并多参与社区交流活动。

中国敏捷实践中的误区（二）敏捷不应孤立看待

CargoSmart公司从2008年起，通过引入专业的敏捷开发咨询公司，开始由以往的RUP开发模式（UserCaseBase）向敏捷开发模式（Iteration&Increasement，UserStoryBase）转型，我们的敏捷开发转型，是先由咨询师和一个种子团队（包括BA，QA，SA，Devetc.不同的role）以敏捷软件开发模式一起共同完成一个项目完整的ReleaseLifecycle，然后把这个种子团队的成员分散到不同的开发团队中，由此在整个组织中传播推广敏捷开发的实践。

经过两年多的实践经历，我们有所收获也有经验教训。

以下就分享一些在实践中遇到的问题和我们的认识反思，供大家学习借鉴。

没有分析和设计

敏捷开发强调简单设计，团队每个成员都从接触客户到分析设计，到编码，全部承担。但是实际上团队成员的素质参差不齐，如果只有简单设计、立即编码，而没有后续的持续重构等实践，将导致设计混乱不一致，尤其是对老系统的功能升级，如果Impact分析不够，弱化了分析设计，将导致很多工作在后期频繁变更，使得团队的挫折感增强，产生较多的重复工作和浪费。

必要的系统架构和设计从来都是非常重要的。只是这里的分析设计有别于传统的开发模式，应该应用敏捷的思想，简单设计，持续重构，尽快反馈等。

敏捷拥抱变化，所以变化可以随时随地发生

因为敏捷的导向，可能造成的问题是，前期需求比较随意，对需求质量的控制弱化，需求变更更加频繁。

（1）需求质量的审核，仍然需要改进，需求方向性的错误将导致后续一系列的工作浪费，所以团队内部应该设定里程碑和review标准，从而确保基本的需求质量。

（2）在Iteration里需求尽量不要变更，明确Iteration的边界。否则频繁的变更导致团队没有成就感，方向和目标不明确。

（3）敏捷讲求业务价值导向，有些变更从业务价值上看，可能并非真正需求急切变更。

有些变更通过更好的Impact分析和设计应该也可以避免。BA和SA等不同的角色应该一起配合来做出Impact分析，以供决策。

一些敏捷实践容易实行，一些比较困难。所以割裂敏捷实践的关联，孤立地实践少数的敏捷实践

其实上面的很多问题都是由此导致的，敏捷开发之所以可以替代以往传统开发模式，是因为一组（系列）的开发实践来共同代替以往开发模式。孤立的引入少数实践，通常不能给团队成员感觉有大的改进，从而也放弃对敏捷开发的信心。

例如Stand-upMeeting.这是一个比较容易的实践，但是如果没有背后的需求转化为比较容易衡量的Story-base，没有BA、QA等共同参与基于Story-base去沟通，没有OfflineofMeeting更多的面对面沟通交流，没有大家彼此知道对方的工作内容（CodeOwnership），那么可以设想这种Stand-upmeeting和以往的传统的开发模式，Leader布置任务检查任务进度没有任何区别。

再如简单设计实践，如果没有背后的结对编程、重构等实践，必然导致比较混乱的代码，很难维护的架构，难于扩展，重复实现类似功能等弊端。

再如持续集成（CI），即使这是公认敏捷软件领域内相对没有争议的一个实践，但是如果没有与TDD结合，没有与持续重构，没有与小的Story，快速频繁Deliver等实践结合在一起，并且坚持保持CI的健康，也会让团队成员觉得CI效果不如宣传，从而对敏捷实践等产生质疑。

以上是我们在敏捷开发实践中遇到的几个典型问题，以及部分经验教训的反思总结。

中国敏捷实践中的误区（三）误区和改进

三个主要误区

第一个是重视流程忽视人。敏捷宣言开明宗义指出“人和沟通胜过过程与工具”。但是仍然有很多企业试图通过创造一个完美的流程来实施敏捷。不可否认，合理的流程对于提高团队效率有一定的作用，但是企业真正要从敏捷改进中获益必须落实到人的改变上来。

第二个是重视管理轻视工程。很多团队将敏捷等同于开开站会、做做迭代、搞搞回顾。到头来，一切流于形式。敏捷说到底是对于软件工艺性的认识回归，那么持续集成、自动化测试、设计、重构这些手艺是绕不开的。不从这些根本的手艺上解决问题，各种眼花缭乱的沟通手段实际上徒然增加了团队的成本。
第三个是重视指标轻视过程。很多团队特别是从CMM型组织转向敏捷的团队，热衷于设计所谓的敏捷度量体系。度量应该是帮助团队增强信心和持续改进，指标不应成为目的。我们要关心的不只是站在哪里，更应关心我们将走向哪里。

要解决这些问题没有任何灵丹妙药，从来也不存在一个完美的、放诸四海而皆准的流程。我们在帮助各种企业进行敏捷流程改进的过程中，总结了几种改进模式，这里跟大家分享一下。

五种改进模式

跳跃：团队作为整体从一种实践直接切换到另一个实践方式上。

有些实践我们知道其目标，并且知道这种切换对团队的影响较小，或者不适于采用逐步推行的方案，我们就采用跳跃的方式。

例如，配置管理工具切换。某团队原来使用的配置管理工具是ClearCase，为了享受到SVN的原子提交、低成本分支等好处，我们往往采取跳跃的方式，即整个团队立刻从ClearCase切换到SVN上工作。这是因为配置管理的切换总的来说对于团队的工作方式影响比较可控，而且使用简单。

并行：团队中部分组织或个人使用原有实践，而另一部分切换到另一个实践方式。

有些实践知道其目标，但在整个团队推行可能会对工作方式造成较大影响，或者团队中的某些组织或个人不具备切换到新的实践方式上的条件，我们就采用并行的方式。

例如，项目组持续集成。团队中某个项目组具备较好的持续集成基础，另一些项目组基础较差。如果在整个团队推行持续集成，就可能对团队产生较大的冲击。而且持续集成的具体方案可能需要在一个项目组内试验。这时候，先在一个项目组做起来，然后推广到其他的项目组。

阶石：为了达到一个长远的目标，先实现一个较近的目标。

有些实践有长远的目标，但还看不清达成目标需要的路径，如果知道做某件事情一定有助于达成目标，可以先完成这件事情。例如，单元测试。有时候希望在某些团队中实施单元测试，但缺少合适的测试框架，那么在确定测试框架之前，实际上很难展开后面的工作。这时就可以先全力构建这个测试框架。称这种方式为阶石。

简化：为了达到一个长远的目标，先实现一个较为容易实现的目标，但是这个目标仍然能够给我们带来好处。

有些实践我们有一个长远的目标，但是对于这个长远的目标还不太清楚，或者要达成这个长远目标，要走的路还很长。如果有些做法可以给我们带来一些好处，虽然不如长期目标带来的好处那么大，我们仍然可以先做起来。

系统测试和低成本测试的拉通。系统测试和低成本测试拉通是个长期而艰巨的任务，比如可能需要良好的基础设施的配合。但是我们可以做一些简单的事情来获得相似的好处。

暂停：暂不实施某个实践。

有些实践，团队不具备实施条件，或者对团队的冲击较大，可选择暂不实施。例如TDD。实施TDD需要较高的条件。如果团队不具备这样的条件，贸然推行难度非常大，这个时候常常选择暂停。

上面的5个模式所在维度并不相同。比如，并行是从组织的维度考虑的，而阶石和简化是从目标维度考虑。另外，在不同范围内看，同样的实践也可能属于不同的模式，需注意模式的目的是为帮助参与者清晰把握问题本质，认识解决方案在时间和范围上的局限性。所以把实践与模式绑定的做法也不提倡。

中国敏捷实践中的误区（四）误区常源于主观臆断

自从接触敏捷以来，已经在公司里帮助建立了不少的团队去实施敏捷，也参与了不少社区的交流活动，在这些实践和交流的过程中，感觉对于敏捷，还是有很多不同的理解，其中也包含了不少对于敏捷的误解，在这里和大家一起讨论一下比较常见的几条。

敏捷就是追求速度

一次在和几个朋友聊天的时候，有朋友说最近装了有线数字电视，他觉得开发数字电视频道服务的团队应该是采用了敏捷的团队，因为每隔一段时间，就会有新的功能发布，只是系统不稳定，不得不经常的重新启动机顶盒。

这无疑是个非常有趣的关于敏捷的理解，似乎敏捷就是关注软件功能的投放市场速度，而往往忽略质量。我想这是很多有关敏捷的理解中，比较典型的一种误识。如果我们重读一下敏捷的四句宣言以及12条敏捷原则，应该不难看出，敏捷实际是关注实现客户的价值，而这一价值体现在“可工作的软件”之中，这其实是对质量的要求，它意味着交付的软件是客户需要的并且质量稳定的，是同时对需求质量和开发质量提出要求。另外，因为市场的变化会促使客户重新调整需求，以获取最大的价值，因此敏捷强调“响应变化”，迅速调整策略，以帮助客户迅速对市场变化做出响应。所以，个人的理解，敏捷真正的含义应该是

快速实现客户的价值（可用的软件）；

快速灵活的响应变化。

一个不重视质量，只关注简单堆砌代码的团队，不是真正的敏捷团队。

敏捷项目没有计划

敏捷项目团队确实不会，或者说，很少会在项目之初建立一份类似于WBS任务分解的进度表和甘特图，但敏捷项目依然是有计划的，和传统的进度计划不同，敏捷的计划不是关注在完成项目的一个个活动或者说任务，比如说需求分析、概要设计、详细设计，模块一编码等等，而是关注在客户的需要，关注客户价值的优先级，其计划的对象是用户要求的功能，例如用户故事，计划活动的产出是一个设置了优先级的用户需要的功能列表。敏捷计划分为以下几个层次：

• 愿景–制定产品的长远目标；
• 路线图–制定实现长远目标的分步实施计划；
• 发布–制定一次发布的目标，包含在一个发布中希望交付的需求清单，并设置了优先级；
• 迭代–制定一次迭代的目标，包含了在一个迭代中团队承诺交付的需求清单及为了达成目标而设置的工作任务；
• 每日计划–制定每天的工作目标，包含了团队中每个成员的工作任务。
• 其计划的过程是一个持续的过程，从项目开始时制定产品的愿景，到每个迭代开始时制定迭代计划，敏捷项目的计划不断的细化，不断的根据变化而调整，是Just-In-Time的计划。

敏捷只适用于小型项目和团队

敏捷实践确实很多发源于小型的项目团队，但并不是说敏捷只适合小型项目团队。其实，早期的Scrum项目就已经有在500多人的大型项目中成功实施的案例。可能是由于大多数的敏捷团队一般都希望在5～9人的规模，并且希望团队成员在同一个工作区域，所以很多时候被认为不适合跨地域，跨团队的大型项目的开发。

其实，5～9人的团队规模是一个类似于一个战斗小组的规模，这个团队小组负责完成一个共同的目标。对于一个小型的项目而言，可能只需要一个这样的战斗小组就可以了，而对于一个大型的项目，我们就可以建立多个这样的战斗小组来完成项目目标。在Scrum中，就有Scrum Scaling，通过把一个大型项目团队合理分解为多个小型的Scrum团队，每个团队都负责一个相对独立的模块或者功能，再配合其他的敏捷实践，比如持续集成，Scrum of Scrums等，加强团队之间的协作，从而确保项目的成功。所以，将敏捷实践应用于大型的、复杂的项目是完全可以的。

对于敏捷的误解，常源于主观臆断，而只要真正的尝试和实践过，不断的积累，就能体会其中真味，一己之见，权作抛砖引玉。