敏捷开发_你如何理解敏捷开发？

对比敏捷方法与工程方法之间的差异，能帮助我们更好地理解【敏捷开发】：

敏捷型方法是“面向人的”而非“面向过程的”。
工程型方法的目标是定义一个过程，不管什么人使用这个过程，都能得到大致相同的结果；而敏捷型方法则认为，没有任何过程能代替开发组的技能，过程所起的作用是对开发组的工作提供支持。

作为雪鸟会议最重要的产物，“敏捷软件开发宣言”(Manifesto for Agile Software Development，常被称为“敏捷宣言”)从一开始就建立在对比的基础上。

让我们追根溯源，从源头理解【敏捷开发】

敏捷宣言的全文如下：

显然，这里的四个“高于”，以及“更好的软件开发方法”，对比的参照物都是传统的软件工程方法。

敏捷在中国传播的过程中，第二组对比“工作的软件高于详尽的文档”效果最直观，也最容易被接纳。

很多企业长期苦于软件质量不佳、交付进度无法保障、客户需求把握不准等问题，而传统的软件工程方法要求的文档对于这些问题帮助往往并不明显。

然而一旦在项目进展过程中能获得可工作的软件，尤其是，如果用可工作的软件向客户征求反馈，那么客户改变或增加需求的可能性就会不可避免地提高。

客户经常自己并不完全清楚软件应该具备什么功能以及应该如何运作。当他们看到并试用真实的软件时，模糊的想法会变得更加清晰，新的想法会被催生出来，他们就会要求改变或增加需求。

这些变化对于软件本身是好事，但对于开发软件的企业则未必，因为变化几乎必然会带来工作量的增加。

敏捷宣言的起草者们清晰地认识到了这个问题，他们倡导的价值观是避免以甲方乙方的姿态抠合同细节和纠结于复杂的变更管理流程，建立包含技术和业务的一体团队，超越单个项目、单个合同的极限，在长期的合作中建立共赢关系。这就是“客户合作高于合同谈判”的含义。

同时，开发软件的团队自身需要构建的能力也有所不同。传统软件工程以严格遵循预定计划为目标，由此延伸出了一整套能力、实践和工具。一旦认识到需求的变化是常态而非异常，计划的频繁调整也就不可避免，此时传统软件工程的能力、实践和工具反而可能成为阻碍。

以项目管理中常用的工具甘特图为例，其中的计划排期做得越细密，需求变化时调整起来就会越麻烦。因此，如果软件团队希望在可工作的软件基础上与客户建立合作而非谈判的关系，就必须具备快速调整响应变化的能力。敏捷宣言的第四组对比“响应变化高于遵循计划”，很大程度上是对软件团队的能力要求。

在敏捷宣言的起草者们看来，这种响应变化的能力固然可以借助合适的流程和工具有所加强，但最重要的还是一线软件开发者自身的能力和意愿。团队的能力最终取决于团队中每个人的能力以及人与人之间丰富而微妙的互动，流程和工具只能辅助，无法替代优秀的个人与默契的团队。

“个体和互动高于流程和工具”这一组价值观对比或许是敏捷宣言中最不直观、最难理解的一组，却也是敏捷的倡导者们认同最深、时时念兹在兹的一组。

内容摘自《敏捷中国史话》，作者 @熊节

《敏捷中国史话》用生动、翔实的语言，辅以情景描述，循序渐进地讲解了敏捷软件开发在中国的发展历程。从敏捷的发展背景，到世纪之交的中国软件业的发展状况、敏捷的传入、敏捷的低谷以及敏捷实践者为敏捷发展所做的艰苦奋斗，还介绍了敏捷在通信行业和互联网企业的实施状况、敏捷软件开发的发展和Scrum的流行。

本书既适合广大的敏捷方法的爱好者阅读，也适合对软件开发方法发展历程和对中国敏捷技术普及历史感兴趣的人员阅读。