关于敏捷开发的思考

我们无需完全100%去套用一些管理方法，重要的是“实用”，舍弃一些无关的框架。例如关于敏捷开发：

• 团队跨语言、时差无法高效实时沟通就一定不能启用敏捷开发模式吗？
• “敏捷开发”就一定不能写PRD吗？

肯定不是这样的，重要的是我们要理解这些管理方法背后的底层逻辑，理解透彻后，我们在里面找到我们自己业务团队所在的一个平衡点。

个人认为，相比瀑布研发，敏捷开发的核心特点是：

• 小步快跑，迭代思维
• 灵活，调头成本低
• 让产品、研发、测试各个团队，形成交叉循环
• 流程链上能够闭环，行程一轮又一轮的冲刺（Sprint），就像摇起来发动机，甚至可以反向推动业务
• 研发透明度高，避免黑盒现象

而这里面有几个关键点：

• 需求的解构能力（Break Down），把一个大的需求分解成不同阶段，一方面可以降低研发负载，另一方面可以得到运营数据的反馈来优化。同理，Jira中的Epic-User Story-Task就是同样的底层逻辑。
• 需求的整体规划思维，敏捷开发另一个现象就是，产品经理被业务团队Push下，造成系统不断的碎片化,最后就像一个补丁做出来的衣服，缺少整体的规划。我们进行定期的需求路径规划探讨也是很有必要的
• 每个冲刺的时间的管理能力，一个高性能的发动机，需要各个单位的精密配合，火花塞、供油、活塞、齿轮都需要能协同好，那么这里的进度管理与纠偏就至关重要。每日的例会（Scrum Meeting），燃尽图（Burn Down Chart）的主要价值也在于此。
• 每个冲刺（Sprint）的复盘会是最重要的事情，往往也是最容易忽略的，或者敷衍的。能让大家跳出“担责任”的思想包袱，积极主动发现问题，提出优化方案更应该受到鼓励。
• 责任到人，比如，明确Scrum Master，日例会的组织、复盘会的组织、时间的纠偏等，有些时候，该作的决策，责任人就一定要果断
• 更多时候,我们会发现实操过程中不是流程的设计问题，更多的是团队对流程的底层理解不到位，动作变形了。

那么回到跨国团队这个大前提，敏捷开发，对于敏捷高效的沟通要求是非常高的，这也正是跨国的最大挑战。那么怎么办？我们一定要“敏捷开发”吗？不一定，重要的不是这个名头，而是这个模式背后优秀的价值，回到这个出发点再看，问题就会容易很多，挑战点就可以迁移了。

例如，我们可以把口头的高效沟通方式，通过文字和原型（简化版PRD）来表达即可，大家会觉得这失去了敏捷的高效，其实不然，事后我们依然会发现，高效、有序的敏捷冲刺模式所带来的效率提升，依旧远大于做PRD和原型所牺牲的时间，远大于无序的管理所浪费的时间。

以上也是这段时间的一些思考，希望大家一起探讨指导。