Review
在敏捷团队里面，完成一天的工作后，通常有个Recap的活动：
5-10分钟，大家简要概述一下今天的工作。不同于站会，大家不用更新各自领的用户故事卡或者技术卡的状态。
重点在获得的收获和当前遇到的挑战，获得的收获能及时分享出来，帮助其他团队成员获得灵感；遇到的挑战说出来，也能激发团队智慧更快地协作解决当前的问题。
一天的培训或者工作坊结束后，我们也会花比较短的时间（通常是15分钟左右）做Review，大家一起讲讲当天培训的要点，通常有这样几个形式：
大家自由发言，每人说一个要点，但是后面的学员不能重复前面的学员说的。
分成几个小组，每个小组系统的讲述培训中某一个单元的知识点，小组成员可以补充；其他小组成员可以挑战。
不管哪种形式，都是为了促进大家更多深入的思考和总结。此外，培训讲师在听到学员的讨论后，也能清楚地知道哪些知识点是被大家深入了解的，哪些是不易理解的：在讲师改进培训的同时，还能再一次的将知识点总结和归纳，并传递给学员。
Retro(Retrospective)
回顾会议的目的是通过这样的沟通形式唤起大家对团队的集体意识，指出团队或个人在一段时间内的不足并列出对应行动。持续而有效的回顾和反馈，可以保证团队关心生产力和效率，了解自身的不足，这将成为团队持续改进的起点。具体的细节可以参见我的ThoughtWorks洞见文章《项目管理中的敏捷实践》。
在Retro中我们常遇到这样的问题：
问题一：限于形式，环境不够自由，大家没有充分表达自己的观点
我们需要确认构建安全的环境。每个人都是觉得当前的会议环境是可以自由发表意见的，而不会因为某些人（某位Leader或者是某位客户）而不敢发表意见。
回顾会议有一个最高指导原则（The Retrospective Prime Directive）：
无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
问题二：会议时间很长，讨论陷入细节
解决方法：
全程Timebox，可以给参加人以紧迫感，促使大家尽量简练的表达。
Retro Facilitator（建议邀请团队之外的成员主持）对讨论方向进行引导，如果发现跑题，需要及时把大家拉回来。如果跑题的内容很有意义值得讨论，可以另行安排会议，邀请合适的人参加。如果有些讨论的细节只与参会的少部分人相关，也建议安排另外的讨论。
Facilitator对大家的观点作简练清晰的总结，减少大家由于误解而产生的不必要的解释。同时facilitator需要识别发言太多和太少的人，鼓励发言少的人表达观点。
建议团队在平时养成及时发现和解决问题的习惯，节省集体会议的时间。
问题三，讨论的很开心，但是没有Actions
罗伯特议事规则是建立在“动议”的基础上的(动议是开会议事的基本单元：“动议者，行动的提议也。”会议讨论的内容应当是一系列明确的动议，它们必须是具体、明确、可操作的行动建议。先动议后讨论，无动议不讨论)，基本认为不是“动议”的都是没有价值的。
Retro的形式和方法非常多，最常见的是“Well & Less Well”。比如对于分布式团队，IdeaBoard还能远程在线协同。然在“Well & Less Well”的Retro中，并不是所有条目都是“动议”。我们推荐另外一种Retro的工具——海星图，这种方法帮助团队从不同的角度进行思考：Start和Stop必须为动议（Action），More和Less可以是Visionary（见解、期望）的，Keep两者皆可。这样Action Lists的产出比较容易，讨论也比较容易聚焦在Action上。
实施方法：
When using the starfish, draw the starfish with the topics on a whiteboard, then have the team put post-it notes in the topic areas. 当使用海星图时，可在白板上绘制带有主题区域的海星，然后让团队成员在主题区域中放置便利贴。
The topics are stated in a way that should easily lead to actions. So try to take a few from the session rather than just saying something was not good.这些主题的目的是为了能够便于产生行动，所以应当关注通过讨论得到产出，而不是仅仅抱怨做的不够好。
名词解释：
Keep Doing: Focus on all the good things on the project. Encourage people to think about things in terms of, what would they miss if they didn’t have a particular practice, technique, technology, person, role.关注在项目中好的事物。鼓励人们去思考：如果他们没有某个“特定的”实践、技术、能力、人或者角色等，会错过或失去什么？
More Of: Focus on practices, technologies, behaviors, etc that team members might want to try more of but are not necessarily taking full advantage of. A good example is that maybe people are pair programming but knowledge transfer and a better understanding of the code changing might be gained by doing more of swapping programming partners.关注在实践、技术、行为等——团队成员想要更多去尝试，但是并不一定能被充分利用的事物。一个很好的例子是：大家虽然正在结对编程，但是接下来通过交换结对伙伴可能可以更好的实现知识传递和对代码变更有更好的理解。
Less Of: Focus on practices that might need a bit more refining or that were simply not helpful in the current circumstance. Perhaps they add value but not as much as other practices could. An example here is that perhaps stand ups have become status meetings and so there should less of talking to one person (and more of talking to each other) during them.关注在可能需要更多精炼或在当前情况下根本没有帮助的实践上，也许这些带来了某些价值，但是与其他实践相比差的太多。这里的一个例子是：可能当前站会已经变成了冗长的状态陈述会议，所以接下来应当鼓励缩短个人的说话时间（从而促进在会后有更多的相互之间的交流和讨论）。
Start Doing: Is a great opportunity for team members to suggest new things to try because of things that may not have gone so well or just for simply keeping things dynamic and fun!Perhaps you might also want to try a burn -up chart on the whiteboard or try some new open source tool for helping improve productivity.这是一个非常棒的机会，来让团队成员建议尝试某些新的事物，以改进那些看起来没有很好运作的东西，或者只是为了让事情变得灵活和有趣！比如你可能想在白板上尝试使用燃尽图，或尝试一些新的开源工具来帮助提高生产力。
Stop Doing: Obviously for things that are not very helpful practices or not adding much value. Perhaps it’s about writing that status reporting email at the end of the day (because you can substitute a simple one-minute conversation for it instead). 很显然，这是针对那些不是很有帮助的做法或者不能带来多少价值的事物。 比如在一天结束时写状态报告电子邮件(因为可以用一个简单的一分钟会话来代替)。
写在最后——谈谈会议
会议可以分两种：动议会议和例行会议
工作会议是为了要达成一个决议：
需要相关的日程安排
有明确的能够完成的目标
有为了达成目标而形成的动议
有集体的互动来结束会议
动议会议有一个特质：我们知道会议什么时候完成，一旦达成决定，就不需要继续开会了；当目标没有达成时，会议就没完。
反之也一样：如果你们能够确定结束会议的条件，那么着就是一个动议会议；否则就不是。结束会议的不应该是时间，比如说现在11点了，会议该结束了。
因为时间而结束的会议是另外一种会议——例行会议。这种会议的目的不是达成某个特定的决议，而是“仪式”，是为了信息的传递。工作中不时会有真正需要这样“仪式”的时候。比如说我们敏捷项目管理中常见的站立会议，Review，Showcase等。
本文作者万学凡，ThoughtWorks首席咨询师，武汉。作者保留本文一切权利，未经许可请勿转载。