1.4 更好的协作

实例化需求说明的另一个重要好处是能够使得不同的软件开发活动在短迭代周期里更好地协作。根据我的经验和本书中的案例研究,对很多团队来说,采用Scrum最大的绊脚石就是无法彻底完成迭代里的任务。很多团队还坚持“老旧的”理念:先完成开发,然后完成测试,最终修饰润色后发布。这会滋生一种错觉,以为开发是分阶段完成的;而事实上,开发的完成是需要后续的测试和修复的。在Scrum进度板上,“done”列代表开发人员觉得有些事情已经完成,“done-done”列意味着测试人员赞同任务已经完成,等等之类(甚至有人说他们采用了“done-done-done”列)。我们的工作往往会落入这种模式,同时测试的结果影响到下一个周期,这会造成很大的变数并使得交付过程变得更难预测。

实例化需求说明解决了这个问题。本书所介绍的实践让团队清晰地定义一个可以普遍理解和客观衡量的目标。因此,很多团队发现他们的分析、开发和测试活动变得可以更好地协作了。

uSwitch是一个成功改善协作的例子——它是英国最繁忙的网站中的一个。从前,uSwitch很难知道某个功能何时可以完成,因此他们在2008年实施了实例化需求说明。该网站的一位开发人员Stephen Lloyd说:“过去,我们将完成的工作交给QA部门,而他们很快会告诉说我们忘记了测试某个场景,这给我们造成了很多问题。”通过实施实例化需求说明,他们克服了这个问题。Lloyd说他们现在更好地整合成了一个团队,并且对业务需求有了更好的理解。过程的改变还提高了软件的质量。该网站的另一名开发人员Hemal Kuntawala则这么说:

我们整个网站的错误率显著地下降了,修复问题也比以前快很多。如果在线的网站确实出现了问题,我们通常能够在几个小时内修复,而此前需要几天甚至几周。

Beazley是一家专业保险公司,他们的团队也经历了协作改善的过程。他们在美国的业务分析师和在英国的开发人员、测试人员一起工作。他们实施实例化需求说明主要是为了确保软件能够在迭代结束时完成。Ian Cooper是Beazley一个开发团队的队长,他说:

我们一直都写单元测试,但问题是当中有一条鸿沟——这些测试可以告诉我们软件是否工作,却没有告诉我们它是否是客户所需的。过去我们甚至没有让测试人员在(开发的)同一个周期内进行测试。他们(测试人员)会把前一轮迭代的信息反馈到当前的迭代里。不过现在已经没有这种情况了。我们对验收有了更清晰的认识。

AdScale.de是一个在线广告市场,他们在新西兰的团队有类似的经历。在项目启动两年之后,日益复杂的用户界面和系统集成使得代码库变得非常大,仅仅使用单元测试已经无法有效地进行管理。开发人员认为事情已经完成了,于是继续去做其他事情,然而在测试人员评审后,开发人员却不得不进行返工。因为测试和开发之间的脱节,找到问题所在需要花费很长的时间。前面几轮迭代的问题影响了后面的迭代,扰乱了开发的流程。在实施实例化需求说明后,开发和测试的协作更紧密了。Clare McLennan是这个项目的开发/测试人员,她说:

即时反馈减少了发布过程的很多压力。以前,开发人员对我们感到沮丧,因为他们的功能无法发布。同时我们也对他们很无语,因为他们没有修复问题,导致我们无法测试他们的功能。我们在等他们而他们也在等我们。现在这个问题已经不存在了,因为全部测试一次只需一个小时。前一轮迭代完成的功能不会被退回而放到下一轮迭代里。

实例化需求说明使得团队可以用一种清晰、客观和可衡量的方式定义预期的功能。它还能加速反馈、改善开发流程,并防止中断计划好的工作。

目录