传统的软件开发是瀑布式的，它提倡设定计划，遵循计划，循序渐进的实施，其中一部分的重要产出就是大量完备的文档。ide
可是敏捷宣言中明确的指出：工做的软件高于详尽的文档！这并非说，敏捷中文档不重要，但在敏捷中有哪些文档呢？只记录结果文档。测试
这又是问什么呢？这就要与敏捷宣言中的另外一句话：响应变化高于遵循计划，一块儿结合着看！spa
进行过敏捷的团队都了解用户故事，用户故事是在迭代计划中团队承诺的 feature，并会对用户故事进行故事拆分和工时评估。而且，Scrum 迭代规定 Sprint 冲刺中不要打断或更改团队冲刺的故事。设计
可是，大多数团队在进行中很快就变成是小迭代中的小瀑布！团队在计划会议中被要求完成多少个故事，大多数状况缺乏前期调研和整理，任务拆分不是按照过程拆分（调研、设计、开发、测试），就是纵向拆分（页面开发、逻辑层开发、接口开发）等。基本感受就是要完成这些故事，了解个大基本，不少细节还要到迭代中进行梳理和整理。orm
这时，若是你面临的第一个问题就是，如何保证在迭代内完成承诺的用户故事？接口
若是你是这样作的：为了保证完成，开始制定计划时间表和里程碑，为了在开始在迭代前梳理清楚需求，要求有 PRD，并在迭代中规定不要轻易改变迭代内容等，那么，你就真的将敏捷变成了小瀑布了。也许你会说，故事拆分就是为了定义边界，让咱们知道在迭代中作什么故事。还有燃尽图，就是要按照计划的速度进行开发。开发
这样作，你就真的理解错了敏捷的含义！你作的就真的不是敏捷！文档
计划会议当然重要，咱们花费大量的时间进行故事评估、任务拆分。目的是什么，快速迭代！这没有问题，但同时还有重要的一条，敏捷是快速响应变化高于遵循变化。回到根本，为何要快速迭代，就是由于需求变化的太快。变化快到你刚刚评估完毕一个用户故事，下一刻它有了变化。这时，难道你还要固守什么迭代不要被打破或更改的规则么？部署
团队承诺、响应变化。就是由于这一点，在敏捷中工做的软件高于详尽的文档，而且敏捷中少有过程文档，任何产品或故事都是以结果为导向的。面对变化，敏捷是响应变化，而不是追踪变化。get
敏捷团队的 wiki 中只有最终的结果文档，而且每每是开发完成以后补的。这时，你也许会疑惑，那故事评估和任务拆分，以及燃尽图统计还有什么意义？若是故事拆分的任务没有任何工做的指导性，那还有必要拆分么？
回答这个问题，就要说下团队。在敏捷中，团队的积极性和自主性显得格外重要，以及相互信任。害群之马必定要从团队 T 除。
故事是如何进入到迭代中的？故事是产品细粒度划分以后，按照优先级，被团队评估和初步拆分任务以后放入迭代的。这就是计划会议，其目的只有一个，统一愿景！其他全部的都是为了帮助完成目标的实践！
你会问，团队承诺、响应变化，咱们如何确信团队能完成迭代中的内容？随时可能变得需求和设计，时刻在变的计划，在没有完成以前又没有任何文档，如何保证团队能完成？就只凭团队承诺？对！就是相信！若是是你是领导者，你惟一能作的相信团队，要作的就是保护团队！
也能够说，敏捷就是如此激励团队的！相信团队，让团队发挥力量解决问题，他们能搞定！你不用干涉他们！因此，这也就是为何说，敏捷中，领导只须要关注看板上空闲的任务，而不是空闲的人。
可是，你如何作到这点，如何激励团队，这在之后我们会继续讨论！
因此，至此来回答前面的问题：计划会议、故事评估、任务拆分、站立会议、回顾会议、演示会议，全部的一切，都是为了让团队高效服务的！
但是，你还会问！若是团队没有实现承诺怎么办？首先，你要看，团队是否真的有没有尽心尽力。若是有，你就要看看迭代的任务是什么缘由，是故事太多，是干扰太多，仍是什么问题。若是不是，你就要看看团队出了什么问题，如何能激发团队的积极性。而这些你均可以在团队的 Retro 上与团队一块儿讨论。
总之，若是团队每天加班都没有完成，那真的团队承诺的太多了。遇到这个问题，要说的就是，敏捷提倡工做效率，而不是靠时间堆出来的虚假繁忙和过分劳累！
让咱们在回顾一下 Scrum 的由来：在橄榄球冲刺以前，教练指挥部署战术、制定计划，可是一旦开始以后，就是要靠团队随机应变，尽最大的努力完成目标，并不断地总结每一次成功和失败。
用最后一句话进行总结：敏捷让团队只作最有价值的！
ps. 你在决定让团队作一件事时，首先想一想，这事情真的会给团队产生价值么？团队会真的执行么？若是拿不定主意，就让团队来决定吧！
—————————— 本文同步发布于 ZHANGSR 个人我的博客 ——————————