《SAFe 4.0参考指南：精益软件与系统工程的规模化敏捷框架》一3.7 团队待办事项列表...

本节书摘来自华章出版社《SAFe 4.0参考指南：精益软件与系统工程的规模化敏捷框架》一书中的第3章，第3.7节 作者［美］迪恩·莱芬（DeanLeffingwell），更多章节内容可以访问云栖社区“华章计算机”公众号查看。

3.7　团队待办事项列表

待办事项列表的定义：

1. 隐藏在舒适表面下的大型列表

2. 未完成的任务或未处理资料的聚集

上述第一种待办事项列表的燃尽速度缓慢，而第二种待办事项列表的燃尽速度迅速。

摘要

团队待办事项列表代表了一个团队为提升系统需要做的所有事情的集合，它包含了用户故事和使能故事，其中大部分都来自于项目群待办事项列表，有些则是来自团队自己的具体场景。团队待办事项列表由产品负责人负责，虽然产品负责人是待办事项列表的“责任人”，但这并不意味着只有产品负责人可以创建用户故事，而是需要产品负责人对工作进行优先级排序。

由于用户故事和使能故事都是待办事项列表的一部分，所以通过有效配置资源以确保投资可以在需求冲突中得到平衡，这一点显得尤为重要。资源的配置需要把敏捷发布火车看成一个整体，并根据火车的需要进行协调。

详述

虽然“待办事项列表”看起来是一个简单的概念，然而在其背后却有许多微妙的影响。

待办事项列表需要包含所有要做的事情，如果工作项处于列表中，那么就需要被完成；如果工作项不在列表中，那么就不会被完成。

待办事项列表是一个“希望实现工作项”的列表，而不是一个承诺。工作项可被估算（推荐）也可以不用估算，但无论哪种情况都不会包括承诺该项工作的具体完成时间。

待办事项列表有唯一的责任人——团队的产品负责人。这样可以保护团队免受多方面利益相关者的干扰，因为每一个利益相关者的关注重点都有所不同。

所有的团队成员都可以将自己认为重要的用户故事放入待办事项列表。

待办事项列表包含用户故事、使能故事和“改进故事”，其中“改进故事”是从团队迭代回顾会议的结果中识别出来的改进内容。

团队待办事项列表是一个简单而统一的形式，但也隐藏了敏捷在规模化过程中的复杂性。图3.7-1说明了团队待办事项列表的三个主要来源。

项目群待办事项列表中包括将要实现的特性，通常会计划在敏捷发布火车中进行交付。在PI计划会上，计划在项目群增量（PI）中交付的特性会被分解成故事，并且暂时分配进入团队待办事项列表以便在下一个迭代进行实现。此外，也会计划一些将来需要开展的工作，在这种情况下，团队待办事项列表也可以包含一些尚未拆分成故事的特性。有时需要由多个团队共同交付一个特性，在这种情况下，就需要为相关团队创建相应的工作，然后对其进行估算，并在团队待办事项列表中进行维护。

团队也需要根据自己的实际情况开展工作。除了需要实现那些来自于特性的故事之外，团队也会有一些自己创建的故事，比如新功能、重构、缺陷、研究探针，以及技术债等。这些由团队自己创建的故事也需要加以识别，可以写成使能故事，进行估算，并排序放入待办事项列表中。

敏捷发布火车上的团队并不是孤立存在的，不同团队的待办事项列表中的用户故事可能会相互关联，从而满足利益相关者的目标。这些故事可能会包含对特性、能力甚至史诗故事的研究和估算探针，同时也会反映团队之间的依赖关系，以及对外部的承诺。

通过容量分配优化价值交付和系统健康

与敏捷发布火车一样，每个团队都会面临待办事项列表中内部和外部工作项的平衡问题，内部工作项包括维护、重构、技术债等；外部工作项是指立即能交付价值的新用户故事。“永远保持新功能的开发”在一定程度上比较有效，甚至可以立即满足市场需要，但是这种效果将是短暂的，因为可能会由于沉重的技术债务而影响交付速度。为了避免速度的降低，以及推迟由于技术过时导致的大量系统更换，团队需要持续关注解决方案的技术演进，及时修复缺陷和改进提升，从而保证现有客户的满意度。

产品负责人对于工作项的排序是一件复杂和极具挑战的事，他需要在3种不同类型的工作中进行价值比较：1）缺陷；2）重构、重新设计和技术升级；3）新的用户故事。而且这些工作项按需发生，持续增加。大多数情况下，工作项来自项目群待办事项列表，然后通过容量分配有助于团队形成一种机制，用于明确在给定时间周期内开展哪些类型的活动，如图3.7-2所示。

一旦团队做出决定，他们就可以从每个“切片”中选择最高优先级的工作项，放入迭代中进行实现。对于那些在项目群中已经承诺的故事，在PI计划的时候就已经进行了优先级的排定；但是对于团队自己添加的本地故事，产品负责人需要按照价值/规模大小，或者采用WSJF（加权最短作业优先）进行优先级排序。此外，为了平衡长期的产品健康和价值交付，分配到各个工作项类型的百分比可能会有所不同（例如，在每个PI中都会有所不同）。

待办事项列表梳理

在本节的讨论中，可以看出待办事项列表中的有些故事已经比较完善，并准备就绪可以进行下一步的实现了，这样的故事不会带来太大的风险和意外。因为，整个团队都参与了讨论，大家采取了基于流的方法，通常是每个迭代（或者每周）至少有一个团队对将要实现的故事（有时也会讨论特性）开展一个工作坊，进行讨论、估算，并且建立初步的接收标准。

对于这个会议，业界没有标准的术语，在SAFe 中称为待办事项列表梳理会，但是需要指出的一点是，待办事项列表梳理是一项持续的工作，而不仅仅是一次会议就能解决全部问题的。应用接收测试驱动开发（ATDD）的团队，通常会在前期投入更多的时间用于开发特定的接收测试，有时也会开展一些相关会议，称为规格说明工作坊（specification workshop）。此外，由于多个团队都在做待办事项列表的梳理，可能会出现新的问题、依赖关系和故事。在这种方式中，待办事项列表梳理的流程会有助于把当前计划中存在的问题暴露出来，并升级到敏捷发布火车的同步会议中进行更进一步的讨论。

参考资料

[1]　Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.