精益Scrum（七）

构筑完整性

许多软件技术大师关注于在软件开发过程中构建完整性。软件设计模式，测试先行开发技术，重构和结对编程等都试图在开发软件时就提高软件的质量。在构建软件的过程中尽早的提高软件质量而不是依赖于事后质量检查和“测试质量”来保证。

场景

一个开发团队已经具有了测试先行的开发技术，并成功地在开发过程中由开发人员创建的单元测试中成功地使用了假设……/当什么时候…… /然后……的表达式。

假设……/当……/然后……接受标准格式
当……<某些行动发生了>
然后……<这就是结果>

该团队拥有良好的可读性单元测试套件，开发人员依靠自动化测试工具来指导他们的设计和测试代码。

虽然这种方法在单元测试级别上工作，但开发团队的测试专家仍然使用微软Word文档来创建功能测试的接受标准。在编码和完成功能后，它们进行手工验证。因为这些测试没有运行，直到程序员认为一个功能完成后，大量的缺陷被测试专家发现。这会导致在Sprint评审会议之前，Sprint中的返工，有时也会导致功能没有开发完成。

精益方法

在讨论Sprint回顾的验收标准工作流程时，开发团队决定尝试以下内容：
1、测试专家不是使用Microsoft的Word文档来创建验收测试的规则，而是使用还没有进行内部实施的自动化测试的情况。
2、在每天早晨5点至下午3点运行新的自动化测试，并且产生测试通过或失败的测试报告。通常最新创建的测试会执行失败。
3、当开发者选择一个新功能开发时，开发者从实现功能的验收测试开始工作。
4、开发者在与创建测试用例的测试者协同工作时，可以改善测试用例，但是要符合测试的原本意图。
5、直到测试通过所有的功能才算完成。
6、在Sprint结束时所有的测试必须通过。

当使用这种方法经历了几个Sprint迭代之后，缺陷和返工工作减少了。开发团队通过每天两次运行的自动化测试来监控更新报告，从而发现那些成功和失败的测试用例被当作一种趋势。团队使用每一个运行的自动化测试来获取更新的报告。

开发团队发现他们在每日站会中使用回顾报告的价值大于使用典型的燃尽图。Scrum Master确认这张新的燃尽图能够在Sprint Backlog的重要部分实施。

Scrum指南指出Sprint Backlog是在一个Spring迭代中经过挑选的一组Product Backlog条目，加上一个交付这些Product Backlog的计划。对于开发团队，该计划现在是从失败的验收测试中和通过趋于执行通过和执行失败测试的次数的追踪来逐步完成过程的。与在Sprint Backlog中的任务一样，测试可以在整个Spring中添加、删除或修改，或者在Spring中进行修正。创建一个给定的测试往往会导致执行相应的功能多达几天。

现在使用实际的自动化测试作为功能回归的需求和机制意味着测试是必须的。这也使得Sprint的工作被看作是使自动化测试通过的一个进展。这个测试优先的开发技术重新定义了团队使用Scrum的方式，并将需求验证注入到创建过程本身，从而将完整性建立到产品中。

广受欢迎的Scrum框架的许多方面都是支持精益原则的。就像Scrum团队的成熟和改善中，Scrum团队经常发现为迭代和增量开发寻找更多价值的精益思想是更加有效的工具。

虽然具体的技术可能会来来往往，但是通过不断关注改善来保持健康的软件开发团队是至关重要的。Scrum框架具有足够的灵活性来适应精益改善方法，例如使用看板来发现改善内容。透过精益思想的镜头来审视Scrum往往会产生更高的质量，更好的生产率，并且减少浪费。

深思熟虑地优化一个Scrum团队的行动可能会是非常复杂地行为。当寻找改善的方法时，不要让最求足够的完美成为敌人。与客户关注的交付高质量的、可工作的软件价值相比完善的Scrum远远地不重要，所以首先关注那些能够真正提高产品质量的事情。

连载（七）