PMI-ACP敏捷项目管理辅导：敏捷开发之4句敏捷宣言

PMI-ACP敏捷项⽬管理辅导：敏捷开发之4句敏捷宣⾔

敏捷ACP,如果说之前还是⼀个陌⽣的名词，那么在互联⽹⼤⾏其道的今天，您⼀定不陌⽣了。

了解敏捷，那么敏捷宣⾔就是我们必须⾸先要了解的。若不了解，你都不好意思说你了解敏捷…

敏捷宣⾔

个体和交互 胜过 过程与⼯具

可⼯作的软件 胜过 ⾯⾯俱到的⽂档

客户协作 胜过 合同谈判

响应变化 胜过 遵循计划

这4句黄⾦宣⾔，是在2001年由17位世界轻量级⽅法学家在犹他州的⼀个雪鸟滑雪场提出的，虽然只有4句话，但字字千⾦，也是敏捷的精髓所在！

在做咨询的过程与开发、项⽬管理⼈员交流过程中，我发现⼤家对敏捷都有所了解，但是能说出上述4句真⾔的⼈，寥寥⽆⼏。可能⼤家⼤概知道是什么个意

思，但不能⽤最精简的⽂字表达。正好此部分也是PMI-ACP敏捷项⽬管理认证中必考的内容，所以，建议⼤家记住这4句话。

在和⼀些⼈员交流中，我发现⼤家都知道敏捷，但是能说出这个简单的敏捷宣⾔的并不多，即使现在知道，过不了多久也就忘记了。因为这个⼜不需要考试，谁

吃的没事去死记硬背这些话呢，公司也不会因为我们知道这个⽽涨⼯资。⽽我们⼜知道，这其实是敏捷开发的精髓，最好需要通过⾃⼰的思考形成⾃⼰的理解来

记住这四句话。

下⾯我将与⼤家⼀起分享我对这4句宣⾔的理解，希望各位都有所收获，欢迎拍砖及点评。

在分享之前先看下瀑布和敏捷的区别 ，在我的⼀张ACP培训的课件⾥，我有⼀张他们直接的区别，如下图：

传统的瀑布式开发属于计划驱动型，前期需求调研完毕后，签订合同，然后项⽬组指定详细的计划并严格按照计划执⾏，在详尽的过程和纷杂的⼯具⽀持下，通

过⽂⼭会海似的⽂档来定义永不变更的需求，若时间不够，增加⼈员或减少质量来缓解压⼒。

⽽敏捷的模式是计划驱动型，通过⾃组织的团队在每个固定的迭代周期内不断交付有价值的功能来完成产品的开发，达到项⽬的最⼤化价值。

从上图三⾓形的变化可以看出他们的驱动⼒不同，关注点不同。⽽价值驱动的敏捷开发模式，更贴近现实，往往都是资源、时间确定，需求是随时变更的。

1、个体和交互胜过过程与⼯具

⼈的因素才是管理中最重要的因⼦，⽅法和⼯具，都是为了更好的达成做事的⽬的，是死的，⼈是活的。如果团队中没有优秀的成员，再强⼤的⼯具、过程都是

摆设。敏捷团队提倡跨功能的团队成员，他们是⼀个⾃组织的团队，⼀起⼯作，⾯对⾯的交流，⼀起做计划，⼀起探讨问题所在及解决⽅案。通过这种⾃组织的

团队，可以⾃发的解决开发过程中遇到的各种问题。虽然说个体和交互更重要⼀些，并不是说过程和⼯具就不需要了。合适的⼯具对于成功来说也是⾮常重要

的。⽐如我们的IDE、版本控制系统、⾃动化测试的⼯具等等，对于团队的开发者来说这些都可以⼤⼤提升⼯作效率，但我们不能夸⼤⼯具在整个过程中的作

⽤。记住⼯具是死的，⼈是活的，⼯具只是⼈的奴⾪⽽已。

2、可⼯作的软件 胜过 ⾯⾯俱到的⽂档

对于⼀个开发⼈员来说，最烦的可能就是写⼤量的⽂档了，想想我们的项⽬，有多少⽂档写了后从来没⼈看的？有多少项⽬⽂档和最终的实施是谬之千⾥的？有

多少⽂档和代码是时区同步，造成弥天⼤谎的？⽽这些⽂档对⽤户来说，是他们最关⼼的吗？

客户需要的是⼀个能够跑起来的软件，能够解决实际问题的软件，通过频繁的交付有价值的可以⼯作的软件，不仅可以更频繁的搜集产品和开发过程的反馈，还

可以保证项⽬团队始终处理的都是最具价值的功能。提供的是⼀种检视与调整的契机。

虽然我们说可⼯作的软件更好，但并不是说不要⽂档。在开发过程组都需要跟我们的⼲系⼈交流，也需要⼀些报告，⼀些简短的需求⽂档，⼀些核⼼的⾼层次的

需求，⼀些结构⽅⾯的⽂档等。最重要的是⾯对⾯的交流，⼯作在⼀起，传授知识。

3、客户协作 胜过 合同谈判

告诉开发团队想要的东西，然后去休个假，期望回来之后就有⼀个满意的系统，那是做梦。让我们回到合作的本源：软件开发的终极⽬标是什么？就是提供给客

户满意的软件，达成双⽅的共赢。只有客户才清楚你的产品是否是满意的，敏捷开发提倡客户与devteam⼀起⼯作，及时反馈。通过快递的迭代，可以提早暴露

出问题和发现客户的需求，从⽽避免后期变更造成的巨⼤影响。

4、响应变化 胜过 遵循计划

计划赶不上变化，⽽团队的应变能⼒，常常决定着⼀个软件项⽬的成败。

在敏捷中，我们的每个sprint周期都不会长，⽽且也不会指定长时间的复杂计划。

⾸先，事业环境因素很可能会变化，这会引起需求的变动。其次，客户往往是看到系统后，才会发现哪些是他们不需要的，从⽽改变需求。最后，即使我们知道

了详细的需求，⽽且坚信他们不会在改变，但我们仍然不能很好的估算项⽬的进度和开发时间。

我常发现有些项⽬经理致⼒于做出⼀张精美的⽢特图，然后彩打出来贴在项⽬组的⼀⾯墙上，领导视察的时候，指着这张蓝图说：我们的规划是什么，我们的进

度怎么样怎么了…然并卵！因为这张图早已经不能反馈出现在的状态了！⼲系⼈可能有了新的认识，某些任务可能已经不在需要，也可能新增了⼀些任务到图

中。简⾔之，计划的变更，不仅仅是⽇期的延长，还有可能是逻辑关系的变化。

敏捷项⽬⾸先承认需求的不确定性，所以不会制定很长时间的复杂计划，常规的做法是：为了接下来的⼀周做详细的计划，为2个⽉后做粗略的计划。通过迭代

开发，每次迭代都是基于上⼀个迭代基础之上，通过不断的响应变化来消除过程的不确定性。许多项⽬管理⽅法是：规划规划再规划，然后调整，再规划，最后

执⾏，实在执⾏不下去了，跑路跳槽了……

⽽敏捷开发⽅法是：规划、执⾏、检视、调整，往复循环的过程。

我的观点

其实这⼏句敏捷宣⾔，想表达的⽆⾮是：

通过⾃组织的团队与客户达成紧密的合作，通过快速迭代，响应变化，并提供最有价值的可⼯作的软件