[个人心得][案例]敏捷中还需不需要进行需求审批及变更管理

1. 背景

1.1 个人背景

笔者没系统学习过敏捷管理，之前只是在所处团队中跟随使用，因此并没有思考过各个行为背后的原因。为什么现在要做敏捷管理的心得记录，是因为新被指派到管理一个敏捷项目的团队，成熟度几乎为0，百废待兴。看到各种问题（因为之前在敏捷团队中工作过，所以感觉非常不对劲），然后才去思考敏捷各个方法的实践，这个系列的文章，纯粹针对各个问题进行拆招，并无一定的顺序。

1.2 团队背景

80%的团队成员入职不到3个月，大多数没有敏捷项目经验，或者是伪敏捷经验，虽有其形但不知所以然。

团队没有有经验的Scrum Master，目前的Scrum Master是之前的BA临时担任。

Product Owner都在国外，并且隶属于业务团第，具有流利英语交流能力的只有BA，开发成员基本只能进行书面交流而不能进行口语交流。

2. 团队之前的做法及遇到问题

2.1 之前怎么做

团队有使用backlog的概念，BA会提前将所有的story提前录入到backlog里面，进行前期梳理。与Product Owner把story确定之后，会针对某个story进行审批，然后会进行sprint开发。

2.2 遇到的问题

因为时差问题，以及团队中只有BA能流畅与Product Owner沟通，导致Story的审批比较慢，经常是Sprint要开始了，当前Sprint的Story还没审批，导致Sprint中的Story无法开工，有时候Product Owner放了几天假找不到人，团队就不知道怎么做

2.3 对策及遇到的新问题

因为Story审批不及时而影响到Sprint的开发，团队尝试过取消Story审批这个步骤，到Sprint开始的时候，如果来得及审批，就按照之前的做法；如果来不及审批的，按照优先级也将重要的Story放到Sprint里开始开发。

然而，这样导致出现了2个新的问题：

1. 开始了Sprint之后，Product Owner发现Story里面的逻辑错了，要求把里面的逻辑改正，这导致前期估算不准，有可能导致原先计划的功能无法在本Sprint完成，需要推迟到下一个Sprint里。
2. 这个是极个别的例子，其中一个敏捷团队，正好处于把产品部署到一个新国家的时期，其中这个新的国家用户在UAT阶段提出了一个需要变更的要点，否则不审批在这个国家上线，开发团队在没有通知我及Product Owner的情况下，将这个需求作为紧急需求指定进行开发，做了三四天发现赶不及原定的上线时间，汇报到我这里，才发现有这个紧急需求。（之后是叫停了这个需求的）

3. 问题分析及应对

3.1 问题分析

因为原公司原团队是从瀑布模式转变而来，对项目的开发理念仍然是以需求审批和变更为前提。对需求的变更仍然定的比较死，导致无法在敏捷中快速进行迭代开发。

而一旦放松，又会导致从一个极端走向另外一个极端，原先的极端是完全控制，需要Product Owner审批之后才能开始开发；后来的极端是完全放开审批，由敏捷团队自行根据优先级进行排序。

这说明无论是任何的流程或方法，都必须要有一定的弹性，不可以限制得太死，也不可放的太松。抓得太紧导致推进困难，放的太松容易混乱。

3.2 敏捷宣言及考虑思路

在敏捷宣言中，有一条是：
响应变化 高于 遵循计划
但从案例中可以看到，随时的响应任何变化不是一件好事，但从例子中可以看到，既不能A，也不能B。那么如何在中间获得取舍呢？

那么就要解决2个问题：

1. 如果PO对backlog进行最后审批之前，有可能导致审批的需求不充足，令到开发团队迟迟无法开始下一个sprint。
2. 如果不需要对backlog进行审批，团队自由选择，会导致做一些PO不愿意看到的事情。

PO为什么迟迟不愿意审批，因为PO属于业务部门，大部分情况下，业务部门对IT的要求都是：既要，也要，还要，但你不能不经我同意随便做…。这里涉及到对业务部门进行敏捷培训，达成共识，这个属于后话，因为本公司中，确实是IT先行转变成敏捷，而业务部门仍然以年度预算及目标为导向，相信这也是大部分公司的问题。这个另外开一篇文章进行描述。

思路：那么在这种情况下，如果假设审批的story为100%完成，那么，backlog中必定存在分析到90%，80%, 60%的story，既然PO不愿意担负审批未完成的story的责任，而作为IT管理者必须合理利用团队资源（否则团队成员就没有任务安排，导致公司资源浪费），可以从story的完成度上做文章。

3.3 应对策略

问题的分析与思路都弄清楚，接下来的应对策略就比较简单了，目前给到团队的规则是：

1. 如果sprint开始之前，已经有充足的完成度为100%的story，那么团队可以按照正常的敏捷方式运作
2. 如果sprint开始之前，没有足够的完成度为100%的story，那么SM需要和BA沟通，明确剩余的80%以上的story是否足够，并且要预演剩下的story是否能在下一个周期形成足够的80% story，如果可以，项目状态仍然是green的。
3. 如果第二条中，BA预见到下一个周期无法形成足够的80%，需要向项目经理汇报，项目经理与PO及业务上级进行沟通，看是否需要推进项目优先级，让PO更多时间侧重于本项目，或者业务能接受80%完成度以下的story进入开发，导致改错成本增加。
4. 如果前面都无法达成共识，作为团队管理的我可以提前将资源释放到其他的敏捷团队。

4 总结

团队管理，项目管理并不是非黑即白，敏捷也并不是只有一种方式，因为团队中PO并不属于IT团队，隶属于业务部门，本案例应该会是常见情况。团队规则的制定，也要根据实际情况考虑。如有其他的不同案例，欢迎留言讨论。