拿看板拯救你——我的“红”项目

拿看板拯救你——我的“红”项目2013-01-17 infoq 译：江辉这篇案例讲述了如何运用看板以及精益开发技术，拯救一个“红”项目。

背景

本文所讲的是一个做了将近一年左右的大型客户端用户开发项目。前前后后，开发团队基本维持在10到15名成员。

在项目开始的时候，团队采用传统的瀑布开发模式。代码开发阶段之前是需求分析阶段，需求分析通常要花上2到3个月而且还会延期。更甚的是在需求分析阶段，项目范围经常变动，往往超出之前客户与开发团队达成的共识。由于客户坚持需要把需求“确定下来”以及开发团队也必须得到客户对需求文档认同的“签署”，这个需求分析的周期花了将近6个月才结束，大致是100%的进度超时。

尽管事实是需求分析阶段已经超过了原定的计划时间，但项目结束的日期并没有因此更改以便符合现实状况。可想而知的结果就是，开发团队被迫在更少的时间内交付更多额外的功能。最终，在开发期限截至时没办法完成，而且由于测试也是草草收场，开发的验证并不充分。

此外，由于项目经理没法管理好客户，保护团队不被客户干扰，整个团队在一种“干扰驱动”的模式下运作。典型的模式是客户向项目经理叫嚣某个质量问题，然后她再把这个信息传达给团队。因此无论哪个危机出现，都无法及时修复。团队没有办法集中在一个问题上，在没有干扰的情况下完成工作。当我空降到这个项目的时候，客户与开发团队的关系非常糟糕，客户拒绝支付。用户也不愿接受已开发的功能、可靠性及性能。项目已经超支几十万美元，计划进度也落后计划几个月。不论是客户还是开发团队，都没法承担这个项目失败的恶果，因此必须做点什么把局面扳回来。

掌控

当你面对这种情况的时候，首先要做的是千万不要惊慌。在这个案例中，客户非常激动并且对团队完全没有信心，客户与团队甚至还相互指责。士气很差并越来越差，原因只是管理层期望团队能够努力工作修复问题。

这个时候，你千万不能火上浇油，一错再错，一意孤行地继续着你的错误。经验表明，对这类情况最佳的方式就是针对数据和事实，而不要带入个人情绪。很重要的是，我们要去挖掘事情起因的根本原因，这样才能发现纠正的方向。但并不需要让团队觉得他们现在所做的每件事情都是错误的，那样做只会让情况更糟。（译注：认同感同样重要，总能有一两件事情团队做得还不错。）

在这个例子中，主要的问题是产品质量很糟糕，已发现的缺陷数也支持这种说法。我们必须让产品成功地交付一些功能，使客户能够使用。而当务之急就是创建一种环境，让团队能够在某个时间段内只集中处理一个问题。

建立质量文化

如果我们反复强调的创建软件的重要性就在于能够正常地工作，并以此作为软件开发的前提，这似乎挺可笑的。但这一点反而是大多数软件项目不断受到挑战的主要方面之一。

在项目的早期，开发团队花了几个月的时间尝试把他们认为的客户想要的需求用文档的形式记录下来。恰恰相反，这导致了一种错误的感觉，让开发团队和客户以为这是他们最终要交付的软件。另外，只有那部分在需求分析阶段跟客户一起需求分析的团队成员才是分析员。直到分析员认为需求分析“完成”了，开发人员才能开始工作。

这引发了之后的一系列现象：

开发人员不得不消化并说明客户的需求，形成作为原子单元的200到300页的文档。

即使在双方“签署”需求文档后，客户还是不断地更改需求。这意味着开发人员的工作持续地被否定和更改。

这导致了开发工期不得不延长到之前计划好的完工日期之后。

测试必须等到所有的开发工作 “完成”后的最后阶段才开始。由于原定的最后期限已过，测试被迫草草收场。

质量不再是检验开发软件是否工作正确的度量，反到成为计算测试人员与开发人员之间用相同方式解释需求的频率的度量。

最终的结果是成百上千的缺陷从开发过程中偷偷潜逃并最终呈现在客户面前。诚然，缺陷是最差的浪费，因为他们是错误需求的已开发状态。这意味着客户花了钱购买开发的软件，然后他们（或团队）不得不消化掉使之正确运行的代价。

很明显，开发团队工作的方式并没有把质量放在首位，事实上，倒是把质量放在了末位。因为分析师、开发人员以及测试人员是被死板地放进项目里，各顾各做着独立的任务。他们从未像整合在一起的机器一样协同工作，他们也没能感受到协作的责任和系统质量的归属感。每当出现问题时，他们就互相指责。简而言之，他们没能创造并接受这样一种质量的文化。

我们决定着手控制质量的最重要的决策就是，要求开发人员在编写代码前首先完成所要开发的工作项的验收测试。这就是人们所说的验收测试驱动开发（Acceptance Test Driven Development或简称ATDD）。有了ATDD，我们从字面上做到了把质量放在首位。

我们运用 ATDD使之适合于这个项目的方法是，我们对每个Backlog里的工作项都要求有相关的验收测试。这样一来，那些没有被代码覆盖的需求就被有效地记录下来。这同样迫使测试人员和开发人员在编码开始之前就在同一起跑线上，有着相同的理解。开发人员的工作主要集中在让那些失败的验收测试通过。必须要澄清的是，测试是基于工作项级别进行开发的，而并不是同一时刻开发一批工作项。

这种方法彻底改变了凭空猜测的工作方式，开发的代码要么正确要么错误。测试要么通过要么失败。就这么简单，是与非，错与对。由于每个开发人员的注意力只集中在某个工作项上，与之前的工作模式去理解整个分析文档相比，一位开发人员在一段时间内所需要理解的验收测试数永远不会太多。验收测试的状态过程有：

失败。由于代码并没有实现功能并通过测试，测试立即失败了。

已开发。让测试通过的代码已经编写。当开发人员实现代码时，他们确认了这个过程状态。

通过。测试人员确认所开发的代码确实通过了测试。

仅仅使用ATDD 方式就已经获得了转变产品质量的正向结果。

在使用ATDD的头8个星期里，我们把一个没有任何测试文档覆盖的文档转变成有着一全套测试以及测试历史记录文档的项目，从而保证了所开发的代码的整体质量。