ASK MO第43期 | 产品成功，是敏捷教练的价值体现吗？

Teambition就可以满足你说的上述情况：

1. 在项目周报里面，我们就可以看到，完成任务数量，逾期任务数量，新建任务数量。这样实际任务偏差就可一目了然。

2. 项目的评审，比如对一个汇报性文件的评审，我们可以把这个文件放在Teambition的文档里面，这样，高层就可以对这个文件发起评审，评审记录也会被每个人看到，不用担心同步问题了。

3. 交接文档方面，我们建议用Teambition的Thoughts工具，他就相当于一个私有的WiKi，你可以把相关的项目文档，技术沉淀，个人的经验知识全放在上面，可以作为团队和公司的资产使用，非常方便。

Teambition是个很不错的工具，产品能力非常突出，我下次要做个几个工具横向对比的视频，敬请期待。

上期已经说过，敏捷教练和健身教练没有本质的区别，教练只是把他的一些经验和方法教给你，督促你完成，但是本质上还是得你来完成才行。

教练的价值就是，没有他，你只能用自己的方式去练习。不是标准的玩法，很难做到和一线大厂对标。因为你都不知道一线大厂实际他怎么玩的。

产品成功，和相当多和因素有关——战略，资源，产品，执行，团队。任何一个因素有问题，产品都难以成功。和教练的方法也有关系，但主要还是自身勤于练习，善于总结和提升。

敏捷没有最佳实践，只有最合适的实践。

你所描述的，是不是团队已经发生的问题，还是你自己想的优缺点，实际上并没有问题发生？

莫老师的建议是，如果没有发生问题，就按现有的模式走下去，如果出现了问题，可以在团队发现了问题之后，再进行复盘，看是在哪个环节出问题了，根本原因是什么？我们要怎么做才能规避后续再出此问题，负责人是谁？什么时间点解决？

回到问题当中来。轮岗是可以的，但是凡事都有个度，太频繁的轮岗的确会造成你说的重新熟悉和产品不清楚资源投入的问题，但把轮岗的周期放长一点就不会了。

另外，前端团队和架构和轮岗没有太多的关系，主要是前端要有一个架构师的角色，他来负责统筹规划前端架构的问题。

迭代周期一定要固定。

我们在转型敏捷的时候，第一步的目标就是要把迭代的节奏固定下来，不管两周还是三周，能固定下来就可以，形成团队节奏再来说提速问题。

如果交付时间到了，还不能交付，就把余下功能放到下个迭代去做就好了？为什么要一起交付？说明需求拆分得不够独立，有很多依赖需求。

所以要解决问题，得把需求拆分得更加独立，颗粒度更加细。

细到什么程度比较好呢？就是5人天的工作量以下。需求拆分是个大版块，就不在这里展开来说了。

需求变更随时都可以，敏捷本来就是要拥抱变化的，在不确定性的商业环境当中找到企业可行的商业模式。

如果降低变更风险的话，做好需求池的管理——用价值模型处理好需求的优先级。把当次迭代的需求严格按照P0到P10的级别划分好优先级，在遇到变更的时候，确认好变更的级别，与在研的优先级进行比较。

变更完成发布后，产品经理要评估实际产生的变更价值，这对建立团队面对变更的信心都是很有帮助的。

总之，我们不要把范围变更看成洪水猛兽，要积极面对变更，评估变更，多做正向影响的范围变更，习惯了之后你们团队的认知会到达一个新高度。