上篇文章 过去一个多月的交付成果总结 提到打脸的事情来了。
1. 团队初期的护航
团队在进入Scrum初期，充满了各种疑虑和不解，为了让团队顺利体验Scrum的世界，我在初期阶段 Sprint 1 Sprint 2 Sprint 3 做了大量的护航工作：
- Scrum的简单宣导。
- 准备基建环境，以及整个适合TDD CI/CD的技术架构。
- 引导团队如何进行需求规划。
- 手把手演示如何编写用户故事，如何编写验收标准。
- 手把手演示如何用TDD方式进行功能开发，以及两轮TDD kata。
- 评审与回顾。
为了避免团队在一开始就遭受挫折，影响团队的信心与士气，Sprint 1 2 3 都在护航下成功完成既定交付。整个过程也存在一些严重的问题：
- 由于项目的特殊性和客观条件，我们没有全职的PO，是有CEO与开发团队共同形成的一个虚拟的PO，CEO兼职提供专业领域的知识和指导产品的规划。
- 团队成员都非常初级，全是应届毕业生，对项目工程缺乏实操经验。
- 团队与虚拟PO在前三个Sprint的故事与验收标准，投入程度不够，一方面是刚进入不熟悉，另一方面是CEO在该阶段有其他非常重要的事务处理。
- 团队成员在Sprint 1是分散远程办公，Sprint 2开始才是部分集中办公。
- 每个Sprint的需求故事，都无法提前准备就绪。
在这种情况下，重复多次向团队警示风险，但都没能受到重视，Sprint是交付了，但是理应还可以做得更好。同时，团队成员也点以为Scrum就是这样的感觉。
2. 引入失败
我希望尽快改变这种情况，但不喜欢强压的方式，反复提醒无效的情况下，放手让团队失败，是一个比较好的方案。
首先，放手让团队失败，并不是说故意设计让团队失败，而是，让团队以他们坚持的方式继续工作，不去干涉、改变他们的行为，他们有可能成功，也有失败，取决于团队自己。
其次，整个过程，并没有增加任何额外的成本，即使Sprint失败，并不意味着零交付。
目的是让整个团队明白现状，我们还没有想象中那么厉害，依然比较初级。
3. 失败
Sprint 4 的最终交付果然是失败，没能100%交付预期的质量和内容。
失败的感觉并不好受，会痛才有效果，也因此能让团队认清自己的现实状况，反省不足地方。
尤其是虚拟PO，明白了对用户故事与验收标准的投入度不够，会导致什么样的结果。
Sprint4 的失败，让团队重新感受压力，反省并承诺在下一个Sprint改进：
- 全团队必须重视用户故事与验收标准的质量。
- PO 加大对用户故事与验收标准的投入度。
- 开发团队重视交付质量，每一个交付都必须亲自在QA环境上通过验收标准，方可视为完成。
- 开发团队改进工作习惯，在一个故事未完成前，不去启动新的故事，避免过多的故事堆积在Doing栏。
- 开发团队提升能力，尽量做到小步快速交付。
- 另一个位专业知识同事(非技术), 贡献一半的时间，做验收测试工作。
4. 转变
Sprint 4 的失败，给整个团队带来压力。Sprint 5 雪上加霜，一个开发成员要去参加一个为期三周封闭的学习会。团队既要补回Sprint4没有交付的东西，又要完成Sprint 5的目标，同时还要面对临时性减员。
在Sprint 5，虚拟PO做到承诺，投入比前几个sprint多，用户故事与验收标准的质量因而得到明显的改进。
团队憋着一股劲前行，到了Sprint 5的交付评审，提前做足了各项准备工作。Sprint5的交付也比前面的几个Sprint有明显改进，PO对结果比较满意，团队本身对交付也充满小自豪。
回顾会上，问团队，是什么让Sprint5有如此交付？团队的回答：
- PO参与度的加大投入。
- 有同事贡献时间做验收测试，对交付质量改进起到非常大的作用。
- 开发团队的上个sprint失败的耻辱感与对本sprint成功的渴望。
- 开发团队能力的持续提升的必然体现。
- 与外部压力关系不大。
Sprint V在减员一人的情况下，一共完成了75个验收标准(AC)，人均 25个AC。
我告诉团队，如果以这个产能数据来看，很厉害了。我之前另一个团队通过一年的时间，才达到 人均25个AC 的产能。但实际上我们的这个产能数据对比，是有一些问题的：
- 这些AC，某种程度上，有Sprint4的基础。
- 我们做的是小程序，并且UI也比较简单，没有太多前端的展示工作。
- 另一个团队，做的是App，同一个故事与AC支持IOS与Android的同时交付，比我们要复杂的多。
- 我们采用的技术栈 Elixir + Phoenix + Functional Programming，令到我们能够专注于业务开发。
- 我们的UI全自动化验收还没有真正实施，这部分省了一部分工作量。另一个团队是已经UI全制动化验收测试。
Sprint V大家做的不错，但我们算是成功吗？
我给大家的评估是：待定，不算成功，也不算失败。
原因是，我们剩有三个故事放在Todo中，没有交付，从这一点上，应当算失败。
但是从团队在减员的情况下的已完成交付质量与工作规模却超过Sprint 4来算，应当算成功。
如果我们接下来的Sprint 6中，完成做到同样规模的等同质量交付，就可以认为 成功。
无需害怕失败，
失败是暂时停止成功。
失败是敏捷团队成长路上的良师益友。
失败也是敏捷教练引导团队的一个重要工具。
害怕失败，不能接受失败，是敏捷最大的障碍之一。
敏捷需要有能接受失败，包容失败的环境。
这里必须感谢团队付出的努力和团队CEO对Sprint4失败的包容与支持。
把团队成长的过程记录下来，也是对团队的一种鼓励。
Sprint 6总结再见。
