精益Scrum
使用精益思想来考虑和解决Scrum所暴露的问题通常会收获高回报，并且这是持续贯彻实施持续改善文化的一个好方法。Scrum团队仍在学习如何将精益应用到Scrum中，但是许多实践已经变得越来越受欢迎，因为它们已经证明了这些实践使得Scrum团队的工作更加有效。
有许多常见的实践和技术在知识工作中直接支持精益原则。这些技术的可以用下面的角度来审视它们是如何在Scrum团队中得以实现的。
以下当然不是一个详尽的技术列表，只是一些Scrum团队可能会使用精益从业者常见的技术进行改善的简单例子。此外，每项技术可以应用在许多方面，这里只描述了少量的精益技术。Scrum团队可能在不同的场景中使用这些改善技术，这与在文档中描述的情况有所不同。
消除浪费
也许最根本的精益实践是消除浪费。精益认为浪费任何不需要产生期望的结果。软件开发中常见的浪费包括：
1、软件中存在不被使用的代码或者功能
2、导致重新开发的缺陷
3、延迟或者需要花费时间等待的事情
4、从一个人、团队或者业务流程移交到另一个人、团队或者业务流程
5、高度详细的需求
6、不充分的需求
7、缓慢的或者低效的沟通
一些浪费根本无法避免，甚至是必要的。例如，在最严格的定义中，需求文档也是浪费。一个代表需求的索引卡根本没有交付给客户，因此索引卡就是浪费。需求卡本身不是产品功能，它代表了创建功能的工作和必须完成的工作内容。需求卡的存在是为了帮助开发人员思考并跟踪他们的工作。虽然大多数团队认为这是必要的做法，它很容易被认定为浪费。
虽然一些浪费是必要的，但是这些内容可以被减少、优化，甚至是被删除。在软件开发价值流中的一些浪费，如等待太长，检查代码，很容易识别和消除。在软件开发团队发现其他浪费，如开发的最初阶段在开发之前需要创建大量文档，这种状况是需要作为一种认识并需要花费大量的精力和时间从根本上得到改变。
Scrum Master开会讨论指导他们的团队获得更高的生产效率和质量。一个Scrum Master建议使用像在精益思维中的消除浪费。Scrum Master们同意尝试这个想法，开始寻找浪费的例子，并将它们分类为两个列表来表示：哪些是可以立即消除和哪些需要一些时间来管理。
第一个列表包含那些由Scrum Master自己或开发团队就可以消除的浪费，而不需要任何许可或等待。另一个列表标记为“Waste Backlog”，需要团队同意才能够标记为浪费，并且需要大量的时间或精力来改变。以下是两个列表的例子：
| 可以立刻消除的浪费 | 存在浪费的Backlog |
|---|---|
| 一些构建过程使用手工方式来执行并且为此需要专门进行维护。 | 对所有的功能在编码之前先创建UML模型。 |
| WEB站点的打包使用手工方式进行。使用自动化工具来实现。 | 由于办公室布局的限制，需要同一开发小组的成员需要在办公室之间进行小型的、随机的讨论。 |
| 开发者使用共享的开发数据库并且因为数据的经常变化而影响开发进度。改变开发模型，让每一个开发者使用独立的开发数据库。 | 在可能的情况下使用自动安装工具以便在运营是不需要人工部署。 |
| 测试者直到功能存在时在开始编写测试用例。对测试专家而言鼓励和倡导测试优先实践。 | 缺陷跟踪报告中的很多字段虽然是必填项，但是很少使用。可以节省为填写这些字段所花费的时间。 |
使用这些列表内容，Scrum Master向各自的Scrum团队提出可立即改善的行动建议。虽然Scrum Master教导他们的团队获得更高的质量水准，Scrum团队的自组织性质需要团队自身的价值改变，并且需要创建一个可以改善的计划。
Sprint回顾会议是一个专门的讨论会，在Sprint回顾会议上，团队可以分享改进的想法并且制定有效的行动计划。有效的Sprint回顾会议往往可以制定改善计划，并且支持持续改进的文化。在Sprint Backlog中最终消除和改善需要Scrum团队进行一些额外的工作。这是Scrum Master的职责，当然这一职责还包括改善Scrum的使用和鼓励在整个组织中使用敏捷方法的能力。
连载（二）