一个“敏捷”项目复盘的思考

本周被邀请和一个“敏捷”项目团队进行了一次复盘。项目负责人希望能够对一期中的一些问题做一下梳理。“敏捷”二字加了引号是因为这个项目只是披着敏捷外壳，客户要求按照迭代交付功能，并用 story point 进行结算。但是实际团队并没有按照敏捷的方式来执行，在复盘中我感觉有不少情况对很多团队也是有借鉴意义的，所以在这里总结并分享一下，希望对小伙伴们有帮助。

项目背景

一个信息系统。项目分为两期，一期是替换已有系统，二期对新系统进行升级，增加新功能。项目一共有两个研发团队，每个团队包含开发和测试人员，差不多 20 多人。两个团队一起接近 50 人的规模。大部分是刚入职半年的新员工。一期预估 6 个 sprint，每个 sprint 1 个月的时间，sprint 结束给客户进行 demo 并进行 UAT。每个 sprint 预计要完成 1000 story point 的任务。1 story point=1 man day。

问题与思考

1. 项目交付的时间节点固定，交付工作量巨大，不可能完成的任务。

一个迭代 1000 个 man day 的工作量。如果从简单数学计算看，10000 man day 的工作量，两个一共 50 人的团队。那么 20 天左右可以完成。以一个月 21 天工作日来看差不多。但是当前项目团队是新组建的，同时人员能力也都比较初级。项目投标时期的估算工作量大多采用中等能力人员的平均水平。而现在团队大多是低于中等能力。这么看明显会存在完成不了 sprint 的风险。

思考

1. 项目投标期间的工作量评估一般很粗略，甚至为了赢得合同而故意低估。这样的结果是项目团队在交付期会面临很大的压力。

2. 作为项目负责人，可以在项目第一次迭代或者第二次迭代期间拿到团队实际交付能力，也就是交付速率。基于数据，调整后续战术，例如争取和客户商议调整迭代工作量，或者增加迭代数量等。

3. 如果无法和客户协商调整工作量或者交付时间，那么项目负责人就需要尝试在团队内部进行调整。例如增加团队人员。或者调整团队人员级别的配比等方式增加团队吞吐量。

2. 迭代后的 Demo 以及 UAT 的反馈只增不减。

客户在看到实际的软件后，会有很多反馈。这些反馈该如何应对？这个团队的做法是尽可能添加到下一个迭代中，而不减少下次迭代的 1000 points 的任务。这样的结果是永远都增加任务，永远都完成不了。同时也会导致团队的压力越来越大。而质量也会越来越差。超负荷工作换来的是低质量的交付与客户的不信任。团队士气也被打击。

思考

1. 我们一直在保证的工作量真的是客户在意的功能吗？真的是必做的吗？如果不是，那么我们为什么不尝试和客户商议，将一些不是必须的功能暂时推迟，这样可以减少团队的工作量，同时也可以留出时间来提高当前的交付质量。

2. 用户的反馈是否都存在优先级？哪些是看到演示功能后涌现的新的改进，哪些是需求理解偏差导致的 bug？和客户对齐项目目标之后，是否可以重新调整迭代内容和优先级？而不是一味的增加工作量。

3. 通过高质量的交付以及和客户对齐项目目标，换取客户的信任。还记得敏捷宣言中的那句话吗“客户的合作高于合同谈判”。对客户有价值的交付，才是我们的目标。做完了所有合同的功能，可能并不是客户真正需要的。这能算项目成功吗？

3. 两个团队迭代时间不同步，有部分重叠，交付内容互相影响。

两个团队的迭代时间不同步，团队领导希望在为期一个月的迭代中，一半迭代之后大部分开发任务应该可以完成，那么可以保留一个团队在当次迭代进行 bug 修复等收尾工作，另一个团队可以提前下一个迭代。但是实际情况也正是因为两个团队的迭代时间有部分重叠，导致两个团队的工作互相影响。一个团队的代码提交影响另一个团队的代码提交。导致 bug 数量无法控制。

思考

1. 能够在一个迭代半程撤出一个团队提前进行下一个迭代的想法是很有创造性的，前提是迭代前半程交付的质量足够好。这也体现了“单件流”的思想。如果实际情况无法做到，那么就应该先保证当次迭代的内容高质量的交付，避免后续修复 bug 带来的额外工作量。

2. 由于两个团队进行开发的工作在后期变成一个团队来维护。一方面存在知识负载，一个团队无法了解另一个团队的业务逻辑，导致修改代码时出现问题的几率变大。另一方面，两个团队开发的工作被一个团队进行维护，工作量也是存在很大风险的。

3. 两个团队的迭代时间应该同步，代码提交与合并都在一个迭代中。避免彼此影响。

4. 开发不看需求也不和测试人员交流，做错后，由 QA 发现 bug 后，才重新梳理业务逻辑。

开发人员在开始开发前不看需求，也不和测试人员交流。直接开始开发。导致开发的功能和需求不符。最后 QA 发现问题，开发人员才重新梳理业务逻辑。这样的结果是浪费了很多时间，同时也增加了 QA 的工作量。

思考

1. 开发与测试人员可以结对来进行需求梳理。避免开发的功能和需求不符。

2. 应用 ATDD 的方式，需求梳理之后形成 AC。开发人员根据 AC 进行开发，测试人员根据 AC 进行验证。这样可以避免开发的功能和需求不符。

3. 团队还可以通过 AC 和 PO 或者 BA 进行 confirm。避免开发的功能和需求不符。

5. 项目经常出现修改一处 bug，发生更多 bug 的情况。

这是个经典的问题。开发人员无法保证修改一个 bug 后不会引入更多的 bug。如果全部交给 QA 来发现，那么 QA 的工作量会很大。同时也会影响项目的进度。毕竟发现问题已经在后期，修复问题的时间也会增加。

思考

1. 工程实践在这里只有一条。通过自动化测试来保证尽可能覆盖更多的业务场景。一旦发现问题，尽早通知研发团队修复。

2. 自动化测试对团队要求很高，同时也会增加团队工作量。针对测试金字塔三层中的三种测试方式，性价比最高的是中间层接口/服务测试。

3. 越早构建自动化测试的安全网，越能够在项目后期得到好处。

总结

1. 如果真的希望跑敏捷项目，无论是客户自己还是承包商，都需要知道，敏捷团队的素质和能力是关键。

2. 下图可以看到，Bug 的引入高峰是在编码期间，而发现是在偏后期功能测试阶段。修复成本越往后越高。所以想办法将功能质量提前将会获得更好的效果，甚至节约成本。这也是测试左移的思想来源之一。

1. 
   

2. 与客户合作的目标是可工作的软件，解决客户的实际问题。尽可能尝试获得客户的信任，通过让客户相信我们所有的目标都是交付对他们有价值的功能，从而让客户掌控节奏，看到团队交付的效果，客户控制并缩小需求范围。

3. 开发和 QA 之间对需求的商讨，团队和 BA/PO 的需求对齐。都是高效团队合作的关键。

4. 敏捷工程实践中针对自动化测试的实践，是避免后期修复成本的关键。也是保证团队交付质量的关键。

践行敏捷实践，让工作去繁从简。欢迎在留言区留言，交流落地经验。

【欢迎关注我的博客】