传统的软件开发是瀑布式的，它提倡设定计划，遵循计划，按部就班的实施，其中一部分的重要产出就是大量完备的文档。

但是敏捷宣言中明确的指出：工作的软件高于详尽的文档！这并不是说，敏捷中文档不重要，但在敏捷中有哪些文档呢？只记录结果文档。

这又是问什么呢？这就要与敏捷宣言中的另一句话：响应变化高于遵循计划，一起结合着看！

进行过敏捷的团队都了解用户故事，用户故事是在迭代计划中团队承诺的 feature，并会对用户故事进行故事拆分和工时评估。并且，Scrum 迭代规定 Sprint 冲刺中不要打断或更改团队冲刺的故事。

但是，大多数团队在进行中很快就变成是小迭代中的小瀑布！团队在计划会议中被要求完成多少个故事，大多数情况缺少前期调研和整理，任务拆分不是按照过程拆分（调研、设计、开发、测试），就是纵向拆分（页面开发、逻辑层开发、接口开发）等。基本感觉就是要完成这些故事，了解个大基本，很多细节还要到迭代中进行梳理和整理。

这时，如果你面临的第一个问题就是，如何保证在迭代内完成承诺的用户故事？

如果你是这样做的：为了保证完成，开始制定计划时间表和里程碑，为了在开始在迭代前梳理清楚需求，要求有 PRD，并在迭代中规定不要轻易改变迭代内容等，那么，你就真的将敏捷变成了小瀑布了。也许你会说，故事拆分就是为了定义边界，让我们知道在迭代中做什么故事。还有燃尽图，就是要按照计划的速度进行开发。

这样做，你就真的理解错了敏捷的含义！你做的就真的不是敏捷！

计划会议固然重要，我们花费大量的时间进行故事评估、任务拆分。目的是什么，快速迭代！这没有问题，但同时还有重要的一条，敏捷是快速响应变化高于遵循变化。回到根本，为什么要快速迭代，就是因为需求变化的太快。变化快到你刚刚评估完毕一个用户故事，下一刻它有了变化。这时，难道你还要固守什么迭代不要被打破或更改的规则么？

团队承诺、响应变化。就是因为这一点，在敏捷中工作的软件高于详尽的文档，并且敏捷中少有过程文档，任何产品或故事都是以结果为导向的。面对变化，敏捷是响应变化，而不是追踪变化。

敏捷团队的 wiki 中只有最终的结果文档，并且往往是开发完成之后补的。这时，你也许会疑惑，那故事评估和任务拆分，以及燃尽图统计还有什么意义？如果故事拆分的任务没有任何工作的指导性，那还有必要拆分么？

回答这个问题，就要说下团队。在敏捷中，团队的积极性和自主性显得格外重要，以及相互信任。害群之马一定要从团队 T 除。

故事是如何进入到迭代中的？故事是产品细粒度划分之后，按照优先级，被团队评估和初步拆分任务之后放入迭代的。这就是计划会议，其目的只有一个，统一愿景！其余所有的都是为了帮助完成目标的实践！

你会问，团队承诺、响应变化，我们如何确信团队能完成迭代中的内容？随时可能变得需求和设计，时刻在变的计划，在没有完成之前又没有任何文档，如何保证团队能完成？就只凭团队承诺？对！就是相信！如果是你是领导者，你唯一能做的相信团队，要做的就是保护团队！

也可以说，敏捷就是如此激励团队的！相信团队，让团队发挥力量解决问题，他们能搞定！你不用干涉他们！所以，这也就是为什么说，敏捷中，领导只需要关注看板上空闲的任务，而不是空闲的人。

但是，你如何做到这点，如何激励团队，这在以后咱们会继续讨论！

所以，至此来回答前面的问题：计划会议、故事评估、任务拆分、站立会议、回顾会议、演示会议，所有的一切，都是为了让团队高效服务的！

可是，你还会问！如果团队没有实现承诺怎么办？首先，你要看，团队是否真的有没有全力以赴。如果有，你就要看看迭代的任务是什么原因，是故事太多，是干扰太多，还是什么问题。如果不是，你就要看看团队出了什么问题，如何能激发团队的积极性。而这些你都可以在团队的 Retro 上与团队一起讨论。

总之，如果团队天天加班都没有完成，那真的团队承诺的太多了。遇到这个问题，要说的就是，敏捷提倡工作效率，而不是靠时间堆出来的虚假繁忙和过渡劳累！

让我们在回顾一下 Scrum 的由来：在橄榄球冲刺之前，教练指挥部署战术、制定计划，但是一旦开始之后，就是要靠团队随机应变，尽最大的努力完成目标，并不断地总结每一次成功和失败。

用最后一句话进行总结：敏捷让团队只做最有价值的！

ps. 你在决定让团队做一件事时，首先想想，这事情真的会给团队产生价值么？团队会真的执行么？如果拿不定主意，就让团队来决定吧！

本文受原创保护，未经作者授权，禁止转载。 linkedkeeper.com (文／张松然)  ©著作权归作者所有