详解ACP的敏捷宣言

详解ACP的敏捷宣言

传统的瀑布式开发属于计划驱动型，前期需求调研完毕后，签订合同，然后项目组指定详细的计划并严格按照计划执行，在详尽的过程和纷杂的工具支持下，通过文山会海似的文档来定义永不变更的需求，若时间不够，增加人员或减少质量来缓解压力。
而敏捷的模式是计划驱动型，通过自组织的团队在每个固定的迭代周期内不断交付有价值的功能来完成产品的开发，达到项目的最大化价值。
从上图三角形的变化可以看出他们的驱动力不同，关注点不同。而价值驱动的敏捷开发模式，更贴近现实，往往都是资源、时间确定，需求是随时变更的。

1.个体和交互胜过过程与工具

人的因素才是管理中最重要的因子，方法和工具，都是为了更好的达成做事的目的，是死的，人是活的。如果团队中没有优秀的成员，再强大的工具、过程都是摆设。敏捷团队提倡跨功能的团队成员，他们是一个自组织的团队，一起工作，面对面的交流，一起做计划，一起探讨问题所在及解决方案。通过这种自组织的团队，可以自发的解决开发过程中遇到的各种问题。虽然说个体和交互更重要一些，并不是说过程和工具就不需要了。合适的工具对于成功来说也是非常重要的。比如我们的IDE、版本控制系统、自动化测试的工具等等，对于团队的开发者来说这些都可以大大提升工作效率，但我们不能夸大工具在整个过程中的作用。记住工具是死的，人是活的，工具只是人的奴隶而已。

2.可工作的软件 胜过 面面俱到的文档

对于一个开发人员来说，最烦的可能就是写大量的文档了，想想我们的项目，有多少文档写了后从来没人看的？有多少项目文档和最终的实施是谬之千里的？有多少文档和代码是时区同步，造成弥天大谎的？而这些文档对用户来说，是他们最关心的吗？
客户需要的是一个能够跑起来的软件，能够解决实际问题的软件，通过频繁的交付有价值的可以工作的软件，不仅可以更频繁的搜集产品和开发过程的反馈，还可以保证项目团队始终处理的都是最具价值的功能。提供的是一种检视与调整的契机。
虽然我们说可工作的软件更好，但并不是说不要文档。在开发过程组都需要跟我们的干系人交流，也需要一些报告，一些简短的需求文档，一些核心的高层次的需求，一些结构方面的文档等。最重要的是面对面的交流，工作在一起，传授知识。

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

告诉开发团队想要的东西，然后去休个假，期望回来之后就有一个满意的系统，那是做梦。让我们回到合作的本源：软件开发的终极目标是什么？就是提供给客户满意的软件，达成双方的共赢。只有客户才清楚你的产品是否是满意的，敏捷开发提倡客户与devteam一起工作，及时反馈。通过快递的迭代，可以提早暴露出问题和发现客户的需求，从而避免后期变更造成的巨大影响。

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

计划赶不上变化，而团队的应变能力，常常决定着一个软件项目的成败。
在敏捷中，我们的每个sprint周期都不会长，而且也不会指定长时间的复杂计划。
首先，事业环境因素很可能会变化，这会引起需求的变动。其次，客户往往是看到系统后，才会发现哪些是他们不需要的，从而改变需求。最后，即使我们知道了详细的需求，而且坚信他们不会在改变，但我们仍然不能很好的估算项目的进度和开发时间。

我常发现有些项目经理致力于做出一张精美的甘特图，然后彩打出来贴在项目组的一面墙上，领导视察的时候，指着这张蓝图说：我们的规划是什么，我们的进度怎么样怎么了…然并卵！因为这张图早已经不能反馈出现在的状态了！干系人可能有了新的认识，某些任务可能已经不在需要，也可能新增了一些任务到图中。简言之，计划的变更，不仅仅是日期的延长，还有可能是逻辑关系的变化。

敏捷项目首先承认需求的不确定性，所以不会制定很长时间的复杂计划，常规的做法是：为了接下来的一周做详细的计划，为2个月后做粗略的计划。通过迭代开发，每次迭代都是基于上一个迭代基础之上，通过不断的响应变化来消除过程的不确定性。许多项目管理方法是：规划规划再规划，然后调整，再规划，最后执行，实在执行不下去了，跑路跳槽了……

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