我们必要要用敏捷开发吗？

继续我今年的更新系列。前面花了几篇文章讲述了产品视角的重要性以及对产品经理能力的一些要求。今天开始写敏捷开发相关的文章。先来抛一个问题，我们是否必须要用敏捷开发呢？

答案当然是不是必须的。敏捷开发不是银弹，有很多的问题是敏捷开发解决不了的，也有很多的公司现状不适合敏捷开发的推广。敏捷开发也不是唯一可行的方法，有很多团队用瀑布也可以做得很好，也有很牛掰的程序员自己一个人撸产品，战斗力超表。所以从这两个角度来讲，敏捷开发并不是必须要用的。

但是我还是推荐大家来实行敏捷开发。一方面是因为竞争环境的变化，敏捷开发已经形成主流的研发模式，你喜欢也罢，不喜欢也罢，都需要面对。另外一方面来讲是因为敏捷开发确实可以解决问题，善加利用，可以有效提高团队的产出。今天想和大家就这一点来分享下我的观点。

首先来看看我们研发的日常吧。

如果您是一位项目经理，不知道有没有经历过这样的场景？

• 一头是老板，一头是团队，既要对老板负责，又要对团队负责，两头都不讨好；
• 项目马上就结束了，但还有很多功能没有实现，还有一堆Bug没有解决；
• 团队里面总是有那么一两个刺头；
• 资源总是那么紧张；
• 产品经理又变更需求了；
• ……

如果您是一位研发人员，不知道您是否有这样的感觉呢？

• 天啊，需求又变更了；
• 今天晚上又要加班了，唉，老婆又要抱怨了（对了，还有很多没有对象）；
• 我想学点新东西，没时间啊；
• 测试的人也太bt了，老挑我毛病；
• 项目经理啥都不懂，在那儿装；
• 填完日报填周报，有啥用；
• 饭碗都要被人工智能抢走了；
• ……

如果您是一位产品经理，您是否经常有这样的感觉呢？

• 为什么开发连这么简单的功能都做不出来；
• 为什么我的需求开发和测试都理解偏差了呢；
• 为什么上线会出那么多的Bug；
• 为什么开发做出来的东西和我预期的总是有很大差距；
• 为什么我要的东西总是会延期；
• ……

如果您是一位测试人员，您是不是经常这样吐槽呢？

• 天啊，明天就上线了，开发还没有提交测试呢；
• 天啊，开发的Bug也太多了；
• 天啊，我还有那么多测试用例没有跑呢；
• 天啊，测试需求又变更了，之前写的用例白写了；
• 天啊，我1个人对付5个开发；
• 天啊，线上又出Bug了，又要挨训了；
• 天啊，我还要负责过程改进，还要监督流程；
• ......

站在老板的角度，站在客户的角度，我们可以继续列很多的问题。这也许就是现在每个团队真实的写照。那么是什么原因导致了这些问题呢？可以从很多角度来分析，比如需求梳理不够清楚、流程不规范、研发人员能力需要提升等等。但如果让我用一个字来总结的话，我会用“乱”来总结。

首先很多公司的战略不够清晰。大多数团队做战略是靠老板的经验和直觉（俗称拍脑袋）。而很多时候的经验和直觉不过是跟风、追求热点而已。这就导致了公司缺少长期主义，缺少战略定力。这种混乱会导致产研团队缺乏明确的目标，无所适从，对自己所做的东西也缺少认同感和成就感。

其次很多公司的组织结构不合理，部门墙严重。每个部门有自己的考核指标和利益诉求，就会出现各种的推诿。遇到功劳就抢，遇到责任就推。部门和部门之间互相看不顺眼。这种情况下面就不要指望跨部门之间协作效率了。

从产品层面来讲的话，需求往往理不清楚，导致大家理解不一致，变更也比较频繁。前面我也写了若干文章来分析产品经理的重要性以及对产品经理能力的要求。产品经理是整个研发的起点，需求如果都理不清楚，后面的开发和测试就不要指望有好的结果了。当然需求能否理得清楚和公司的战略也有直接联系。

从代码角度来讲，往往缺乏有效的架构设计和工程管理，代码一点点地坏掉。一个程序员能够把自己维护的代码按照目录、文件分离清楚，把每一个类抽象好，把每一个方法定义清楚，就是很不错的程序员了（其实这是基本要求）。但这样的程序员也是凤毛麟角的了。

从流程规范上来讲，也乱就一个字。有很多公司的流程规范过于繁杂，导致无法执行，纸上一套，执行一套。有得公司的流程则不完善，甚至是没有。项目管理基本靠聊天、靠开会、靠写文档（这是国内某知名聊天软件所推的项目管理方案，只不过是聊天聊得更好、会开得更好、文档写得更好，但骨子的问题没有解决）。产品研发是非常需要协作的，需要有完善的流程规范才能保证项目的顺利进展。

继续列举下去的话，还会有很多可以吐槽的地方。那么我们来看敏捷开发是如何解决这些问题呢？如果用一个字来概括，我会用“拆”来总结。
 

首先将复杂的产品拆分成一个个的小版本。一件事情我可能很难一下子想清楚，那我就先通过一些小版本来获得市场的反馈以及团队对这件事情更深入的认知。以前做瀑布开发，会先花大量的时间来讨论需求，讨论清楚了再开发。但现在的系统越来复杂，团队很难一下子把事情想清楚，再加上外在的环境天天在变。比如现在GPT出来之后，各种应用日新月异的发展。敏捷开发解决这个问题的思路就是通过小版本迭代快速地获得反馈，及时进行调整。这样可以将产品逐渐梳理清楚。同时也可以辅助战略的制定和调整。开源软件社区里经常说的一句话就是“Release Early，Release Offen”，说得也是这个道理。

其次将团队拆分一个个的敏捷开发小组，培养大家的自我管理的能力。软件研发我认为是很矛盾的一件事情。一方面从业人员都是业内最优秀的一波人，但同时软件研发的标准化程度却很低，对协同的要求又是高需求。传统的金字塔式的结构其实是效仿了工程类项目管理的管理方式，不适合研发项目管理这种场景。所以就需要想办法激发大家的主观能动性，发挥每一个个体的价值。真正意义上的自组织比较难，但可以朝着这个方向努力，逐渐培养大家的自我管理能力。原来主要是项目经理来负责整个项目的进展，现在是整个团队来一起负责，效果肯定就不一样了。如果一个公司的每一个小组都是比较敏捷的，那么整个公司的研发也不会太差。

再次通过快速迭代的方式建立起整个公司的协作节奏。节奏可以产生美，产生信任。建立在信任基础上的协作效率就会更高。以前的时候做一个大瀑布，销售、市场很长时间拿不到产品，也不知道研发到什么程度了，所以销售是天生不信任研发的。聪明一点的、强势一点的销售，就会搬个小板凳做在研发旁边，抓人来干活。敏捷开发通过快速迭代或者看板方法来快速响应来自方方面面的诉求，提高交付的速率来建立跟各个干系人之间的信任关系。这种节奏建立起来之后，整个公司就可以按照一种频率来进行运转，协作效率就可以保证。

敏捷开发还会通过持续的改进来优化流程。流程的优化是无止境的，敏捷团队会通过回顾会议、日常的沟通等方式来不断的优化自己的流程。相比较于传统的方式，由一个过程改进部门出台流程规范，然后让大家来执行，无疑这种持续改进的效果会更好。俗话说一口吃不了胖子，流程的优化改进也应当逐步来完善。

敏捷开发还有极限编程、DevOps等一系列手段来保证代码始终处于良好的状态。敏捷开发快速迭代的特性要求研发团队需要能够快速响应。所以极限编程里面会强调简单设计、重构、好的架构设计来自自组织的团队等等。换句话讲，和传统瀑布式的开发相比，敏捷团队更强调通过持续的重构、集体所有权、简单设计等一系列的实践来保证代码的质量。这是敏捷团队勇气和信心的来源，相信团队可以通过重构来应对未来的挑战和变化。DevOps工具的完善也为开发团队提供了更有效、更及时的反馈，加速代码流动的速度。

总结来讲，敏捷开发就是通过将研发过程中的各个环节进行不断的细分来解决各种问题：

• 将复杂的产品分解为一个个版本和一个个的用户故事；
• 将金字塔式的团队分解为一个个的敏捷团队；
• 将过程的改进分解为一点一点的改善；
• 将长期的研发过程分解为一次次的冲刺；
• 将长期的战斗分解为一次次的小胜利；
• ……

当然我不是做学术研究，这么说并不是很严谨，但可以让我们对敏捷开发的运作模式有一个直观的理解。理解之后我们就可以更容易接纳并执行敏捷开发。

分之而后明之，明之而后有序，有序则治也。