本节书摘来自华章出版社《SAFe 4.0参考指南：精益软件与系统工程的规模化敏捷框架》一书中的第3章，第3.11节 作者［美］迪恩·莱芬（DeanLeffingwell），更多章节内容可以访问云栖社区“华章计算机”公众号查看。
3.11 团队演示
可工作的软件是进度的首要度量标准。
——敏捷宣言
眼见为实。
——佚名
摘要
在人们真正看到、触碰到最终成果之前，故事或特性都只是一个抽象的概念，所以向客户（或其代理人）演示可运行的、经过测试的系统，是一个具有实质意义和影响深远的时刻。为此，在SAFe中，基于解决方案的不同范围定义了3种演示：解决方案演示、系统演示和团队演示。系统演示是由敏捷发布火车的所有团队提供的对新系统所有内容的集成展示，而解决方案演示则是衡量价值流进展的首要度量标准。
本节将对团队演示进行描述。团队演示基于Scrum定义的仪式，用于评审本次迭代所完成的增量结果，有些看板团队也会使用团队演示。如果要计划和举办一次有效的团队演示，是需要团队成员提前做一些工作的。如果没有这种演示，团队就无法得到快速反馈，也无法沿着正确的方向前进。
详述
团队演示的重要性不言而喻，它提供了一种快速的方式，可以从发起人和客户那里收集到基于上下文的反馈。所以，每次演示提供3个重要职能：
团队演示是迭代时间盒的结尾，同时体现了团队成员所做出的贡献与努力，向业务提供了新的价值
团队演示为团队提供了一个机会，可以向业务部门展示自己做出的贡献与努力，并让团队感受到工作和进展中的满足感与自豪感
团队演示允许客户和利益相关者看到可工作的特性并提供反馈
目的
团队演示的目的是向产品负责人和其他利益相关者展示可工作的故事，并得到他们的反馈，从而度量团队的进展。团队演示是一个1～2小时的新功能演示，其准备工作是在迭代计划期间就开始考虑了，团队需要思考如何对所承诺的故事进行演示。团队应该能演示每个用户故事、探针、重构，以及新的非功能性需求。这种“以终为始”的心态，能帮助和培养团队对所需功能点达到更细致深入和更准确的理解，从而也有助于迭代计划的进行。
流程
团队演示一般从评审迭代目标开始，然后走查所有承诺过的故事。每个已完成的故事要以一个可工作、已测试的系统来演示。探针可以通过用研究成果的形式来演示。当把所有已完成的故事演示之后，如果存在没有完成的故事，团队可以反思一下没有完成的原因。这种讨论通常会帮助团队发现开发障碍或风险、错误假设、优先级的变更、不准确的估算，或者过度的承诺。可以把这些结果带到迭代回顾会议上，团队就如何更好地计划和执行以后的迭代进行更深入的讨论。图3.11-1说明了团队演示情况。
团队演示除了能让团队感受到他们在已结束的迭代中的出色工作之外，还可以让团队省思一下他们距离完成PI目标的差距和进展情况。
参与人员
团队演示的参与人员包括：
敏捷团队，包括产品负责人和Scrum Master
敏捷交付火车中的其他利益相关者，或者本迭代中涉及的共享服务人员
业务负责人、高层管理者（发起人）、客户，还可能有其他团队的成员。当这些人参加团队演示时，他们通常会把兴趣和对细节的关注，更多地放在如何与系统演示保持一致性上。否则的话，可能由于团队演示往往更加注重在团队的细节层面上，容易导致“演示疲劳”。
议程
下面是团队演示议程的一个示例：
评审此次迭代的业务环境和迭代目标
演示每个故事、探针、重构，以及可应用的非功能性需求，并收集反馈
讨论所有未完成的故事，并且查明原因（原因可能会有助于下一次迭代计划）
识别从本次迭代或演示中涌现出来的当前最新风险和障碍
指导原则
以下是成功进行团队演示的一些小提示：
团队成员对单个故事的演示准备，要限制在1～2小时
演示会议的时间盒设定为1～2小时
最小化PPT幻灯片的使用
只演示已完成故事的可工作、已测试的系统功能（参照5.10节中关于“完成定义”的描述）
如果一个主要的利益相关者不能参加，产品负责人应该在会后及时跟进向其汇报进度并获得反馈
参考资料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 9.
[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007, chapter 15.
