为什么“专人准备汇报”是反敏捷的？
敏捷的核心价值观和原则是：
个体与互动 高于 流程与工具
问题：专人准备汇报，将“互动”变成了“汇报”。信息流动从团队内部的直接、频繁沟通，变成了通过一个“信息中转站”（即专人）进行加工和传达。这削弱了团队成员的直接互动和共同责任感。
理想状态：整个团队共同参与评审会，每个成员（开发、测试、产品负责人等）都应直接沟通进展、困难和下一步计划。信息是透明和第一手的。
可工作的软件 高于 详尽的文档
问题：专人花费大量时间制作的精美PPT、图表和报告，本质上是“详尽的文档”。它描述的是“我们做了什么”，而不是“我们做出了什么可以工作的软件”。
理想状态：最有力的汇报就是直接演示可工作的软件。团队在评审会上现场演示在本迭代中完成的功能，这才是最真实、最无可辩驳的进展证明。PPT应该是辅助，而非主角。
响应变化 高于 遵循计划
问题：专人准备的汇报材料往往是静态的、事后的总结。它聚焦于“我们是否完成了计划？”，而不是“我们交付的东西是否还有价值？是否需要调整？”
理想状态：评审会是一个收集反馈、引发讨论的场合。基于演示的软件，利益相关者可以立即看到变化并提出新的见解，团队可以据此调整下一个迭代的计划。动态的对话比精美的计划总结更重要。
构建能自我组织的团队
问题：专人（尤其是项目经理或团队外的某人）准备汇报，暗示着团队不需要或没有能力为自己发声。这剥夺了团队的自主权和责任感，让他们感觉是在“被汇报”而不是“主动展示”。
理想状态：团队是自我组织的，他们自己最了解工作进展。由团队（通常是Scrum Master引导，团队成员轮流主讲）来主导评审会，能培养团队的主人翁意识和沟通能力。
“专人准备”会带来的具体弊端：
信息过滤与失真：专人可能无意中过滤掉关键细节或“坏消息”，导致管理层获得不准确的项目状态。
增加开销和延迟：准备精美的汇报材料需要时间，这些时间本可以用于开发或测试，造成了不必要的开销。
形式主义：会议重点从“评审软件价值”变成了“评审PPT质量”，大家开始纠结于措辞、配色和动画，而不是软件本身。
团队脱节：团队成员可能对汇报内容不熟悉或不认同，在会议上无法有效回答深入问题，显得被动。
是否存在合理的例外情况？
尽管有上述问题，但在一些现实场景中，我们确实会看到“专人”的参与。关键在于区分他们的角色：
信息整合者，而非创造者：在大型或分布式团队中，可能需要一个人（如Scrum Master或技术负责人）来帮助整合来自不同模块或成员的信息，确保汇报的结构清晰。但核心内容必须由直接工作的团队成员提供。
对外沟通的接口：当需要向更高层级、非技术背景的利益相关者（如高级管理层、投资人）汇报时，可能需要将团队的详细演示提炼成更高阶、更聚焦于业务价值的摘要。这个人（可能是产品负责人）的角色是翻译和提炼，而不是代替团队创作。
团队内部的协调助手：对于新组建或沟通能力较弱的团队，Scrum Master可以作为一个“教练”，帮助团队准备和练习如何有效地进行演示，但其目标是让团队最终能独立完成。
正确的做法应该是什么？
敏捷倡导的是 “共同准备，直接沟通”。
迭代评审会不是“汇报”，而是“演示和协作”。会议的主角是整个团队和可工作的软件。
准备是轻量级的：团队在迭代末期花很短的时间（例如站会时）一起确定要演示的内容和顺序。可以使用任务板、CI/CD仪表盘等实时数据作为辅助，而不是重新制作PPT。
每个人都是发言人：开发者演示自己开发的功能，测试人员分享测试结果和质量指标，产品负责人讲解业务价值。
聚焦于反馈：会议的核心目的是收集反馈，而不是寻求批准。要问“基于您今天看到的，我们下一步应该做什么？”
结论
如果一个团队常态性地依赖一个专职人员来准备面向内部的迭代评审会，那这绝对是一种“反敏捷”的信号。 它表明团队在透明度、自我组织和以价值为中心方面出现了问题。
真正的敏捷在于整个团队作为一个整体，透明、自信地向利益相关者展示他们的工作成果，并共同迎接变化。汇报材料本身应该是这个协作过程的自然产出，而不是一个事先精心编排的“表演”。