本节书摘来自华章出版社《SAFe 4.0参考指南：精益软件与系统工程的规模化敏捷框架》一书中的第3章，第3.10节 作者［美］迪恩·莱芬（DeanLeffingwell），更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.10 迭代执行
没有执行的愿景只是幻觉。
——托马斯·爱迪生
摘要
每个敏捷团队都有一个核心焦点：在短时间盒内开发出一个有效、高质量、可工作、测试过的系统增量。这也是每个精益–敏捷团队、项目群、价值流、投资组合乃至整个企业所面临的根本挑战。如果缺乏有效的迭代执行，即使有完备的准备和计划，也无法实现规模化，解决方案的质量也会受到影响，所有人都会感受到负面的业务影响。
本节将对如何在整个迭代时间盒内进行工作管理提供有效的指导，这些指导对于独立运行的团队或者敏捷发布火车上的团队都适用。
在迭代过程中，团队密切合作，共同定义、构建和测试迭代计划中承诺的故事，并全部展示在团队演示中。团队使用故事、看板和每日站会来跟踪迭代进展和提高价值流。团队在迭代中交付故事，并避免“瀑布”模式，他们会省思实践和挑战，来保证持续增量的小步改进，他们与敏捷发布火车上的其他团队有效合作，通过采用内建质量以保证正确地构建大型系统。这些工作需要花很大精力完成，但是高效的敏捷团队完全能胜任这些工作。?
详述
敏捷团队与传统项目管理和开发模式有所不同，他们得到充分的授权，充满能量和激情，富有使命感和清晰的愿景，从而专注于更快速的价值交付。其核心就是有效地执行每一次迭代。每个团队可能会采用不同的做法，但关注的焦点都是一样的，即通过交付迭代计划中承诺的故事来实现迭代目标。
除了有效的局部迭代执行，敏捷团队有一个更远大的使命，即优化项目群执行。这也是SAFe的四个核心价值观之一。
为实现这个目标，团队在敏捷发布火车的环境中运作，以协调各团队达成一致并实现团队和项目群的PI目标。所有团队都有相同的迭代节奏和时间以保证在进行团队演示和系统演示时，能够同步他们的工作成果以便集成、评估和演示。?
成功迭代执行的关键要素包括：
跟踪迭代进度——使用故事板和看板来跟踪迭代的进度
持续和增量地构建故事——避免“迷你瀑布”，并增量式构建故事
持续沟通——通过团队每日站会进行持续沟通和信息同步
改善流——通过管理在制品，内建质量，持续接收故事来优化流
项目群执行——以敏捷发布火车的模式运作来实现项目群PI目标
跟踪迭代进展
跟踪迭代进展需要对故事、缺陷，以及迭代期间团队的其他活动进行状态的可视化管理。为此，大多数团队会在自己的工作区域或者会议室里，在墙壁上使用大型可视化信息雷达（big visible information radiator，BVIR）。?看板团队使用看板板，ScrumXP团队使用故事板，大致如图3.10-1所示。
使用这个简单的故事板，团队只需要将红标尺移动到当前日期，就能对团队在迭代中的当前状态提供一个简单易懂的可视化评估。（图3.10-1清楚地显示了当前迭代是存在风险的。）团队可以基于这些信息来讨论成功完成迭代所需的工作。如果远程参与者或关键利益相关者需要获取状态信息，团队可以通过网络摄像头、电子邮件或网页进行分享。当然，如果需要进行规模化，几乎所有敏捷团队都能使用敏捷项目管理工具来捕获故事、状态、缺陷、测试用例、估算、实际进展、任务分配、燃尽信息等，而且这些内容都是大型可视化信息雷达的有益补充。
持续沟通
团队协作的关键是具备开放的环境和在同一地点办公。否则，由于问题和假设造成的延迟，将很快导致价值交付的延迟。在最坏的情况下，在不同工作地点的团队可以通过网络摄像头、即时信息和其他协作工具长期保持在线，从而建立一个开放的沟通环境。
每日站会（DSU）
每天，团队成员在同一时间和地点召开会议，通过回答以下问题来协调他们的工作：
我昨天做了什么故事（及其状态）？
我今天能够完成什么故事？
我工作过程中遇到什么困难了吗（我被阻碍了吗）？
每日站会是团队信息同步和自组织的关键。最有效的每日站会，是团队站在标明了当前迭代目标故事状态的BVIR前进行的。每日站会需严格控制在15分钟之内，它不是解决问题的会议，而是一种用来识别问题、依赖关系和沟通的机制，问题可以在每日站会完成之后处理。Scrum Master在“会后处理板”（Meet After Board）上记录需要进一步讨论的问
题，只有与问题有关的成员需要参与“会后处理”会议。无效的每日站会表现有：需要更系统化的方法并陷入深层次的讨论，并且常常需要Scrum Master协调和干预。
注意 虽然每日站会属于Scrum框架，但许多看板团队也在其看板前进行每日站会，来协调工作和检视面临的瓶颈或在制品问题。
改进流程
管理在制品
限制在制品提供了一种策略，可以预防开发中遇到的瓶颈问题，也有助于改进流。同时还能提高团队的专注力，促进信息共享和集体所有权。所有SAFe团队成员都应该对他们的在制品和流有着清晰的理解。
一般来讲，看板小组都会使用限制在制品的方法，ScrumXP团队有时也会采用限制在制品的方法。应用在制品可以是显式的或隐式的——例如，隐式的应用表现在，当团队成员计划自己的工作时，只接受按照其速度预测可完成的故事数量。这种方式强制要求输入的工作（协商的迭代目标和故事）与容量（团队的速度）相匹配。?迭代时间盒也可以限制在制品，它可以在一定时间内防止不受控制的工作蔓延。
ScrumXP团队也可以在他们的故事板上使用显式的限制在制品方法。例如，图3.10-1中如果没有限制在制品，开发人员在完成故事5之后会做什么呢？他们很可能会开始另一个故事的开发。但如果限制“处理中”和“测试”阶段的在制品数量为3，开发人员则可能会去帮助做测试，这样总产出便会增加。要了解更多有关限制在制品的内容，请参阅SAFe原则#6。
内建质量?
敏捷发布火车以最快的、可持续的前置时间来执行和交付新功能。为此，他们必须创造可预测开发速度的高质量系统。SAFe采纳了一系列质量管理方法和工程实践，以致力建立适用于最大型的解决方案的内建质量，例如测试优先、持续集成、重构、结对工作和集体所有权。确保从一开始就保证质量，以便更快、更容易、更低成本地进行价值交付。?
持续接收用户故事
持续地接收故事，可以不断提升流动性。（图3.10-1展示了一个非流动的迭代，团队在6天内只接收了1个故事。）团队成员一旦准备好就可以演示新故事，而不必等待迭代结束时的团队演示。没有被接收的故事则由团队成员进行返工。这样做可以快速有效地解决问题，也会防止其他成员在不可工作的故事之上，继续开发新的故事，还可以防止团队成员在不同的上下文场景中来回切换所带来的开销。
测试自动化
在可能的情况下，尽量将产品负责人和敏捷团队成员描述的系统接收标准，转换成可以反复运行的故事接收测试用例，并随着系统开发进行持续改进以确保测试用例的适用性、一致性。自动化也能实现快速的系统回归测试，强化持续的系统级集成、重构和维护。通常，这些测试使用业务可读性、领域专业性的语言编写，从而可以为系统创建“可自动执行的规范和测试”。?
连续和增量式构建故事?
避免迭代内的“瀑布模式”
团队应该避免将迭代“瀑布”化的趋势，确保以迭代的方式完成“定义–构建–测试”的循环，如图3.10-2所示。
增量式构建故事
图3.10-2 通过跨职能的迭代，避免“迷你瀑布”模式
增量式构建故事可以缩短反馈周期，使得团队能够增量式地对可工作的系统进行持续集成和测试，也可以让敏捷团队成员能够更好地理解相应的功能，实现更频繁的结对开发和集成。团队内外甚至敏捷发布火车团队之间的依赖关系，也可以进行更有效的管理，因为被依赖的团队可以更早地接触新功能。增量式构建故事还有助于减少不确定性，验证架构和设计决策，促进早期学习和知识共享。
专注于项目群执行?
虽然迭代成功很重要，但所有敏捷团队的最终目标是成功实现项目群增量的执行。?为帮助确保团队避免仅仅专注于本地优化而忽视整体优化，SAFe各团队会共同计划、共同集成和演示、共同学习，如图3.10-4所示。
关于各团队共同工作的实践，以及成功实现项目群增量开发的详细内容，可以参考3.2节中的描述。
参考资料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
