完成 - 高绩效敏捷团队的必杀秘笈

导读：敏捷方法已经在软件开发和交付中获得了主导性地位。但即便使用敏捷方法，你是否还在经历着项目延期、质量低下、超出预算等问题？软件开发迭代中总是有这样那样的问题？你是否怀疑敏捷到底能否给你带来期望的成功？近来，在一个有关敏捷中“完成”的在线讲座中，针对当前敏捷实践中存在的问题，Scrum的创始人之一——Jeff Sutherland——总结了敏捷实践中的这些问题的原因，并指出了解决的办法——重新定义“完成”（Definition of Done，DoD）。本文是根据Jeff讲座内容整理而得。

Bad Agile

瀑布开发与敏捷开发的各种利弊对比，已经得到了业界的充分分析，这里就不再赘述。而值得我们警惕的是，敏捷方法中“不敏捷”的实践做法，称之为“Bad Agile”。据可靠业界数据，大约49%的敏捷团队这在经历着“Bad Agile”。

而正是如下这些看似无关紧要却对项目进度和交付伤害极大的错误观念和实践，在消耗着敏捷在人们心中的价值。

• 对《敏捷宣言》的错误理解或者片面理解，导致无法在项目中完全遵循敏捷精神。
• 团队没有在一起工作以在迭代中交付可工作软件。
• 因为软件并不能工作，团队无法在迭代结束时及时响应项目干系人的反馈。
• 大量缺陷（bug）无法在24小时内修复，导致越聚越多，影响交付的软件质量。

为什么软件团队无法按时交付可工作的软件？主要有以下原因：

• “完成”的定义比较糟糕。
• 用户故事并没有Ready。
• 功能失常的领导者。
• 技术债（Technical Debt）。
• 糟糕的教导（Coaching）

下面来具体看看到底发生了什么。

糟糕的DoD定义

1）“完成”的定义并不清晰。由于各个团队成员对“完成”的理解并不一致，而团队又没有坐下来商讨出一个清晰而一致的“完成”定义，大家并不明白“完成”到底对各个角色意味着什么。开发人员可能觉得，写完代码并check-in就算“完成”，而测试人员则认为测试完事才算“完成”，但集成和部署人员则希望功能上线才算“完成”。很明显，如果各个角色并不清楚“完成”对他们和要交付的可工作软件来说意味着什么，那么他们不可能完成客户和产品负责人期望的软件。

2） 缺乏一致的质量标准。如果DoD中不包含什么是“可工作的软件”，那大家对最终结果的认识可能完全不一致。由此，到底什么是高质量，也就无从谈起。没有一致的质量标准，意味着大家对最终交付的软件要达到什么样的质量莫衷一是。另外一个可能造成严重后果的原因可能来自产品负责人（Product Owner）。如果在一个Sprint结束时，Product Owner接受没有真正“完成”的用户故事，那就意味着用户故事的完成也打了折扣。这会让Scrum团队认为，既使在一个迭代中没有完成用户故事也是可以接受的，而以后也可照此办理。

用户故事并没有准备就绪（Ready）

1）用户故事的规模问题。

• 估计用户故事规模（工作量）时使用的基本点（Base Point）并不一致。导致估算出来的用户故事点数对不同的人和不用的用户故事完全没有可参考性。失去故事点的基本价值。
• 在一个迭代中承诺了太大的故事，而不是将大的故事适当合理分解。
• 将太多的用户故事放进一个迭代中。  

2） 用户故事写的太糟糕。

• 由于表达能力、对用户需求的理解等原因，用户故事书写得并不清晰，尤其是验收标准（acceptance criteria）。将这样的用户故事交给团队，团队可能也是一头雾水。
• 没有清晰定义依赖关系。有时候，各个故事之间有一定的内在依赖关系，需要在撰写用户故事时清楚地列出来。

功能失常的团队领导和管理

1）开发人员手中同时在做非常多的事情。由于需要不断地在不同的任务或项目之间来回切换，上下文切换是要消耗开发人员的时间的，团队的效率就会降低。

2）每件事情都是最高优先级。没有区分优先级的用户故事，团队不知道该从哪个下手。所有事情都是最高优先级的结果是，所有事情可能都没法按时完成。

3）完成工作的压力，最终会导致项目延误，并降低交付的质量。压力只能让大家更快地工作，却无法让大家做出更好的软件。

4）缺乏对Scrum的正确理解。误解Scrum和敏捷的很多基本原则和实践，往往在自己项目中会采用一些看似正确的变通措施，最终误入歧途。

5）害怕职责的暴露或者改变。这一条，不多解释。

6）没有采用持续集成，和/或，根本就没有测试。例如：奥巴马医改计划。

技术债（Technical Debt）

软件行业关于“技术债”的讨论可谓数不胜数。

1）未完全完成的Sprint中，某些用户故事“烂尾”，在下一个Sprint中不得不重新规划并完成这些“烂尾”故事。而这可能会造成代码质量下降。

2）遗留代码往往包含了堆积如山的各种技术债，而这会大大降低团队的交付速率（velocity）。很多技术债是由于没有使用持续集成或自动化测试等现代技术而累积下来的。当开发团队出现妄图走捷径、缺乏重构、创造力丧失、消极怠工、工作敷衍草率时，技术债就出现了。

糟糕的教导（Coaching）

1）筒仓式管理（Silo‘s ）和专业化（specialization）拖慢了敏捷团队的前进速度。这方面最好的例子就是专业化的测试团队。

2）开发人员并没有像一个团队一样组织起来工作。他们只有极少的合作，而且没有集群工作。

3）未能使用持续集成，不断出现的问题扼杀了团队前进的速率。团队没有幸福感，没有任何中断模式，不能真正把大家召集在一起，健康地运转Scrum。

4）"假装敏捷"——没有团队协作，没有可工作的软件，没有客户协作，而且对变更没有任何有效的响应。

基于以上Scrum团队中存在的问题，Jeff给出了应对之道：

让事情成功做完的系统方法：

• 使“完成”的定义（DoD）真正起作用。
• 确保产品待办事项（Backlog）准备就绪。
• 培训管理层。
• 实施技术债补救计划
• 提升教导（Coaching）和Scrum Master的地位。

系统化Scrum方法模型如下图所示：

使DoD真正生效

• “完成”的定义中，必须包含集成测试，测试数量必须超过代码容量。
• 测试人员必须是Scrum团队的一员，不要单独分离出测试团队来。
• Sprint中不要承诺太多的用户故事。可以使用某些模式来估计团队在未来Sprint的velocity。比如“昨日天气（Yesterday’s Weather）”模式，“非紧急无中断”模式以及“Scrum紧急事件处理程序”等。
• 使用自动化构建系统来合并新代码与系统已有旧代码——持续集成。
• 系统化地构建自动化验收测试，第一时间预防高优先级缺陷。
• 缺陷修复时间不超过1天。实行“代码每日清理”（Daily Clean Code）。由于大约70%的软件缺陷都是集成缺陷，过后再测将耗费测试人员过多时间。

确保产品待办事项（Backlog）准备就绪。

最近更新的《Scrum指南》[2]包含了“准备就绪”（Ready）的概念。这确保了团队即将使用的Backlog和用户故事是经过了评审，用户故事所表述的需求和价值清晰、明了，团队对故事点的理解一致而可靠。

• 团队可以坐在一起，就“准备就绪的定义”（Definition of Ready, DoR）达成一致。
• 只有经过评审且“准备就绪”的用户故事才能够进入产品待办事项列表（backlog）。
• 对产品待办事项进行精炼，确保用户故事处于“准备就绪”状态。
• 好的“就绪”故事能够是开发团队事半功倍，所以要舍得在用户故事上花时间，以使之真正“就绪”。

下图所示为用户故事的就绪流程：

下图是来自某个Scrum团队的真实案例。在集中精力于用户故事使之“准备就绪”之后，团队的生产率得到了大幅提高。

培训管理层

依赖允许客户——会同供应商或者供货商——决定软件产品最终将是什么样子，敏捷开发的竞争力已经超过了精益制造（lean manufacturing）。对敏捷竞争者来说，定制富有个性的产品的能力只带来很少或者几乎没有任何制造成本上升。但事实上，敏捷确实有所提高，因为敏捷要求在组织、管理哲学和组织运作上做出较大改变。经理们需要接受培训，以了解那些有经验的Agile CXO们如何领导敏捷团队。管理层的职责包括：

• 为敏捷团队提供富有挑战性的目标。
• 创建有效的商业计划或运作环境，比如：建立彼此相互协作的敏捷团队，提供团队运作所需的所有资源。
• 为团队识别并排除障碍。管理层需要了解团队的速率；列出障碍清单以了解是什么因素放慢了团队的速度；消除浪费，要事优先。
• 让产品负责人（Product Owner）对所负责交付的每一个故事点负起职责。
• 让Scrum Master对流程改进和团队的幸福感负起职责。

修复技术债

• 实施缺陷补救计划。通常，80%的缺陷来自于约20%或者更少的代码。针对这部分代码实施有针对性地补救或者更新，可修复绝大多数缺陷。IBM就有一整套完善的确定补救优先级的策略[3]。
• 实施止痛计划。将验收测试系统地构建进整个产品构建系统中，确保最高优先级测试优先运行。
• 缩减债务。团队要为产品负责人构建出适当的业务案例，使之清楚了解在产品开发过程中会有多少个点的技术债，需要多长时间来消除这些技术债。
• 管理层要致力于产品的系统改进。比如降低运营成本，增加销售量等。

用优秀教练增加成功概率

• 雇佣优秀的员工。
• 每个团队都必须有一个敏捷教练。敏捷教练负责在每一个Sprint中至少提出一项流程改进措施。改进产品待办事项列表并持续度量改进效果。教练的指导能够从根本上改善高绩效团队的产出。
• 在教练指导下，所有敏捷团队争取在每个Sprint中实施多次持续部署（continuous deployment）。

敏捷教练可采用如下度量指标来衡量团队的改进效果;

• 缺陷修复时间。如果团队的平均缺陷修复时间（从发现到完成修复）少于24小时，那团队的速率将会加倍。
• 工作群集度度量。 这个指标衡量的是个体和交互产生的绩效有多好。度量公式为： 完成一个用户故事所需要的实际工作量（以小时折算的工作日）/完成所需要的日历时间（日历天数）。如果这个指标超过50%， 团队的工作效率将会再次翻倍。

敏捷教练可以使用如下一些建议[4]来管理和指导敏捷团队：

• 稳定的团队——如何开始？
• 昨日天气——怎么将产品待办事项放入一个Sprint中？
• 代码每日清理——如何才能在Sprint结束时获得一个没有缺陷的产品？
• 群集——怎样让工作快速完成？
• 中断模式——如何处理Sprint期间的干扰？
• 停止前进——如何处理突发事件？
• 让Scrum Scrum起来——如何持续进行改进？
• 幸福指数——如何确保团队不会不堪重负？

结论

Bad Agile往往由以下5个主要因素所致：

• 糟糕的“完成”定义（DoD）
• 用户故事并未就绪
• 领导不善
• 团队技术债
• 无效教练

系统性地聚焦于纠正这些问题将会持续不断地造就高执行力团队，在生产力上提高200%到400%。

如果不能专注于解决这些问题，将会导致大约49%的敏捷团队变为“Bad Agile”，而这又会导致客户不满、收入减少以及股价降低。

参考文献：

[1] 《30天软件开发：告别瀑布拥抱敏捷》，Ken Schwaber，Jeff Sutherland 著；王军，李麟德 译。人民邮电出版社2014年1月出版。

[2] 《Scrum Guide》，http://www.scrumguides.org/。

[3] Mays et al. Experiences in Defect Prevention. IBM Systems Journal 29:1, 1990

[4] Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams 47th Hawaii International Conference on System Sciences (HICSS) By Jeff Sutherland, Neil Harrison, Joel Riddle January 2014.