敏捷开发没你想的那么简单（上）
没用过敏捷的人，包括我在内，都会“看轻”敏捷 —— 无非是一种新的开发流程，只要翻翻书，记熟那些个会议和流程，就可以开始了。
结果就是，在开始实施后，要么执行不下去，哀叹自己的团队不适合敏捷；要么没有达到预期的效果，唱衰敏捷，嚷嚷着敏捷没用。
要想顺利的使
用敏捷
，首先
得搞清楚
什么是敏捷
。
要想说清楚什么是敏捷，直接给出定义，不够接地气，帮助有限。因此我要找了个参照物，好让你比对着看。
找谁参照呢？自然是人人熟知的瀑布模型（我不信你做软件开发没经历过瀑布模型）。
瀑布模型是 1970 年，Winston Royce 博士借鉴了其他工程领域的思想，比如建筑工程，提出的。所以瀑布模型适合
确定性高的项目。
但这种模式用到软件开发上
，就有点“水土不服”了，到如今 VUCA（易变、不确定、复杂和模糊）的时代，尤为明显：
-
-
-
不能很好的管控风险，最后一次性的交付往往达不到客户的要求
为了解决这些问题，一群聪明人于 2001 年在美国犹他州发布了“敏捷宣言”，其中倡导了 5 点
价值观：
-
-
-
-
-
这些价值观乍一看很好理解，但常常被过分解读，造成了很多误解。
比如，敏捷不用写文档，错，敏捷需要写
必要的文档
；
又比如，敏捷就是开发快，错，敏捷提高的是
响应速度
。
所以为了能让价值观更具体，需要原则来做指导，宋宁在文中总结了 12 条
原则：
-
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
-
即使到了开发的后期，也欢迎改变需求。
敏捷过程利用变化来为客户创造竞争优势。
-
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
-
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
-
围绕被激励起来的个体来构建项目。
给他们提供所需的环境和支持，并且信任他们能够完成工作。
-
在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
-
-
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
-
-
简单 —— 使未完成的工作最大化的艺术 —— 是根本的。
-
-
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
价值观和原则都是在天上的东西，最后还需要
方法帮其落地。说到方法，不得不提
敏捷最大的“冤案”之一 —— “
敏捷就是 Scrum，Scrum 就是敏捷”。
事实上，Scrum 根本代表不了敏捷。打个比喻，价值是爸爸，原则是妈妈，Scrum 是他们的孩子，它还有好多兄弟姐妹，比如极限编程、水晶方法等等。
今天的分享就到这里，下次会分享下半部分，一些关于具体的实操，谢谢阅读。
标签:
