十三 敏捷转型的约定

搞敏捷,你我要有个约定,请不要忽悠我。

我可以理解为了让敏捷推广的难度降低,我们把敏捷实践暂时从编码开始。但请一定明确,在需求的迭代中若没有需求分析的阶段,之后做的所有敏捷实践都是未得本质的活动,我们的最终目标是要从需求分析开始进行敏捷实践,因为需求分析才是敏捷的开始。

敏捷最大的优势,也是可直接体察的价值—通过持续集成和自动化测试,最大限度地得到一个趋向于无缺陷的软件,但往往被忽略的是,这个倾向于无缺陷软件的前提是它必然是一个被期待的软件。如果不,那么所有我们为质量做出的努力都是在用一件绝对正确的事情验证一件绝对错误的事情。

现实并不能让人满意,注重价值的敏捷,在很多情况被简单误解为一种信息验证器,而不是价值。各种看板、Story拆分、任务划分、验收条件等等这些应该成为价值验证的有力工具,被我们当作验证设计文档里面的文字转化成可用的代码,但对于它是不是被需要,我们并不关注。

那些隐藏在200页设计说明书里面的需求,那些淹没在文字里的细节和那些没能够达成共识的设计,因为这个复杂的文档,和它之前那长达数个月内经历的多次评审,变得理所当然的准确无误。人们永远倾向于相信复杂的东西,那么需要让人相信和确认便是让你所描述的东西趋于复杂。当认为有时开发团队的人太固执于实现细节的时候,你其实并没有太多硬性的责任让需求转化为可用的软件,你更多的时候,只是尽义务地等待那些刚进入团队不久的新人,羞涩地向你提出本该你主动解释清楚的问题,而你的工作,应该在那部巨大需求设计文档的最后一个句号后基本完毕。

我们期待敏捷是银弹。面对那些把折叠床放在桌下的“康夫”,我们何尝不想希望自己手中那个所谓“敏捷”的东西,真是机器猫二次元袋中万能的道具。但其实,真的不是。我不止一次地害怕,未来的某天,善良的“康夫”会对这个也许并没有那么有效的东西失去信心。我害怕我们一直坚持在做的,那些正确的实践,到最后都变成没有错误的无价值品,那么敏捷的精神在哪里,真正的价值驱动体现在哪里?

应该承认的是,一些改变正在发生。我们尝试把逐渐与交付团队独立的系统专家推倒另外一个高度,把和团队紧密合作的模块设计师尽量推向客户,初衷在于避免需求人员和设计人员之间沟通时产生的损耗,让需求收集、分析和设计集中在一个团队完成,并期待这个团队能够和交付团队紧密合作。这一初衷也完全符合“让分析人员和开发人员在一起”的敏捷基本准入条件。

虽然前期的设计阶段仍然没有在开发阶段中进行迭代式分析,但至少我们有一些可以对交付负责,和交付团队在一起的人,通过他们和系统专家以及客户的沟通,为开发团队澄清需求。虽然在这个过程中有太多太多的不明确和关于设计和实现的争执,但是至少,在需要的时候,他们会耐心地和开发人员在一起,努力把需求实现做到尽量不失真的标准。

但是,请至少让他们大部分时间和团队在一起!如果一个80个人的团队,只有一个分析人员进行需求的澄清,绝大部分依靠文档传递需求信息,寄希望于开发团队能够根据文档的信息实现需求真正描述的功能,真正失真后又必须等待到上线时才能发现,若管理一个天才团队,我尚未有足够信心,对一般水平的开发团队而言,真的不是拆分Story,每日晨会,故事墙能够解决的问题。当我被问道:“请问如何拆分Story才是正确的?”,但上下文是分析人员基本不在团队内,需要由开发人员尝试理解设计文档并写用户故事(目的是证明开发人员自己明白所做功能的业务价值),这样的问题,我确实无法回答,因为我怎样的回答,放在这个上下文里,都是没有实际意义的。

敏捷是一个太容易被误解成工具集合的概念,认为它是一套方法论指导下的工具集合,使用其中某一部分的工具便能达到预期的效果,但是实际上,敏捷中的所有实践都是这个方法论体系中不可缺少的东西。

我明白,学习敏捷需要阶段,但第一课应该学到的是,如果开始敏捷,请答应我在不远的未来实现两件事,第一分析人员会跟开发团队大部分时间在一起;第二敏捷实践必须从需求分析的敏捷实践开始。不然,我们所有的实践都是,得其形骸,不得精要。