敏捷开发没你想的那么简单（上）

Posted 2021-04-25 SingleTalk

没用过敏捷的人，包括我在内，都会“看轻”敏捷 —— 无非是一种新的开发流程，只要翻翻书，记熟那些个会议和流程，就可以开始了。

殊不知，这只是照猫画虎，不得要领。

结果就是，在开始实施后，要么执行不下去，哀叹自己的团队不适合敏捷；要么没有达到预期的效果，唱衰敏捷，嚷嚷着敏捷没用。

这些都是因为对敏捷的理解太片面造成的。

要想顺利的使 用敏捷 ，首先 得搞清楚 什么是敏捷 。

要想说清楚什么是敏捷，直接给出定义，不够接地气，帮助有限。因此我要找了个参照物，好让你比对着看。

找谁参照呢？自然是人人熟知的瀑布模型（我不信你做软件开发没经历过瀑布模型）。

瀑布模型是 1970 年，Winston Royce 博士借鉴了其他工程领域的思想，比如建筑工程，提出的。所以瀑布模型适合 确定性高的项目。

但这种模式用到软件开发上 ，就有点“水土不服”了，到如今 VUCA（易变、不确定、复杂和模糊）的时代，尤为明显：

• 研发周期太长，导致研发跟不上业务发展的节奏
• 研发不能很好的响应需求变化，导致客户满意度低
• 不能很好的管控风险，最后一次性的交付往往达不到客户的要求

为了解决这些问题，一群聪明人于 2001 年在美国犹他州发布了“敏捷宣言”，其中倡导了 5 点 价值观：

1. 个体和交互胜过过程和工具
2. 可以工作的软件胜过面面俱到的文档
3. 客户合作胜过合同谈判
4. 响应变化胜过遵循计划
5. 虽然右项有价值，但我们更重视左项

这些价值观乍一看很好理解，但常常被过分解读，造成了很多误解。 比如，敏捷不用写文档，错，敏捷需要写 必要的文档 ； 又比如，敏捷就是开发快，错，敏捷提高的是 响应速度 。

所以为了能让价值观更具体，需要原则来做指导，宋宁在文中总结了 12 条 原则：

1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2. 即使到了开发的后期，也欢迎改变需求。 敏捷过程利用变化来为客户创造竞争优势。
3. 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕被激励起来的个体来构建项目。 给他们提供所需的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
7. 工作的软件是首要的进度度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
10. 简单 —— 使未完成的工作最大化的艺术 —— 是根本的。
11. 最好的构架、需求和设计出自于自组织的团队。
12. 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

价值观和原则都是在天上的东西，最后还需要 方法帮其落地。说到方法，不得不提 敏捷最大的“冤案”之一 —— “ 敏捷就是 Scrum，Scrum 就是敏捷”。

事实上，Scrum 根本代表不了敏捷。打个比喻，价值是爸爸，原则是妈妈，Scrum 是他们的孩子，它还有好多兄弟姐妹，比如极限编程、水晶方法等等。

最后搬出宋宁老师总结的敏捷公式：

敏捷 = 价值观 + 原则 + 方法

记住这个公式，就从大局上把握了敏捷的精髓。

今天的分享就到这里，下次会分享下半部分，一些关于具体的实操，谢谢阅读。