解读敏捷 之 响应变化高于遵循计划
您目前处于:敏捷  2015年04月10日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


本文受原创保护,未经作者授权,禁止转载。 linkedkeeper.com (文/张松然)