本文主要是介绍02.敏捷回顾——为团队量身定做回顾检视会笔记，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
02.敏捷回顾——为团队量身定做回顾检视会笔记
00.如果你是一名教练或迭代开发团队负责人，你可能在每个迭代开发结束后组织你们自己的回顾检视会，或许你们在团队成员之间轮流做回顾检视会的主持人。无论哪种情况，如果你正在策划和组织一个回顾检视会，将会一系列的决定要你来做，如会议目标、后勤保障及会议的顺序等。
01.再多看一眼，检视一下你关于历史团队、士气和项目进展情况的判断是否准确。如果你是为其他团队做准备，仔细研究一下他们的背景，扫视一下他们的工作环境。看看草图、白板和其他人工产物。注意一下那些还在，那些不见了。与正式的和非正式的团队负责人谈谈。你收集这些信息将帮你和团队一起选择一个适当的目标。你所观察到的东西给你提供了提什么问题和团队可能会面临什么问题的线索。
02.当你跟团队谈话时
*这次迭代开发的输出产品是什么？团队的目标是什么？结果是否像预期的那样？
*以前的项目评审历史什么？发生过什么事？后续的跟进是什么？
*当团队进行回顾检视会的时候，有什么来自公司其他部门的情况，会对团队产生影响？比如，裁员的谣言、最近的公司并购、取消的生产计划。
*团队成员之间的关系怎样？相互的依赖关系如何？个人之间的关系和工作关系是怎样的？
*团队成员们感觉怎样？他们忧虑和担心的事情是什么？他们对什么事情感到兴奋？
*对回顾检视会的发起人和他的团队来说，取得什么样的成果才值得花费这些时间？
*以前团队和引导员（主持人）合作的怎样？
03.回顾检视会的目标包括：
*寻找改进我们实践活动的方法
*探索我们过去做得好的方面
*发掘没有完成任务的背后的原因
*寻找改进我们影响客户需求的方法
*修复被损害的关系
04.如果大家认同有益改进，并且完成了团队的计划，你可以提前结束回顾检视会。一旦团队达到目标，就没有必要延长会议时间。只要团队能够实现既定目标，会议施长一些时间没有太大关系。如果团队仅仅取得了肤浅的认知和计划，着也许就需要更多时间了。
05.在逻辑停顿点上、精力下降或大家表现出有需求的时候安排休息。对于2小时以上的回顾检视会，把中间休息安排在日程表里面，90分钟左右休息一次，每次最少10分钟。
06.关键不是要让大家离得太远，而是靠得更近些，这样便于一起看数据图、白板纸和会议中公示的其他信息。
07.拟定回顾检视会的准备
*决定：目标是什么？
*决定：什么人参加？
*决定：多长时间？
*决定：在哪里开会？
*决定：怎样不知会议室？
08.回顾检视会需要回答问题：
*召开此次回顾检视会的目标是什么？
*此次回顾检视会的目标是什么？
*回顾检视会要开多久？
*会议地点的哪里？
*会议的基本框架是什么？
09.回顾会召开日程
*预设会议基调
活动：聚焦/散焦
为什么？开场白之后（重申会议目标、时间安排和工作协议），这项活动帮助建立一种正确看待问题、不互相责备的心态。我们鼓励公开讨论。
*收集数据
活动：带彩色标点的时间表
为什么？团队检视过去相当长一段过程，这将帮助他们回忆先前的迭代开始中发生的事情。帮助大家看清各个事件之间的联系。彩色标记将帮助我们看清事实，并有效地利用时间。
*激发灵感
活动：模式及转移、鱼骨图、汇总报告和综合分析
为什么？我将带领大家识别和命名导致我们目前问题的模式和重要事件。
为什么？在观察了模式之后，我们需要确定问题的根源。我们将对重要事件及问题背后的因素进行分析
为什么？我们需要各小组分担工作，寻找共同的线索和原因。
为什么？如果潜在问题不能在团队内部解决，我们就需要制定一定影响策略去告诉经理为什么解决这个问题那么重要。
*决定做什么
活动：用小圆点确定优先次序
为什么？我们需要确定最主要的两三个问题根源，在开始下一个迭代开发时加以解决。我们不可能一次进行太多的变革，我们只需要做能够产生最大效果的几件事。
选项1：写故事卡（回顾检视计划游戏）
为什么？我们可以带着故事卡上的事项参加下一次计划会，并且把他们融入我们其他的工作中。
选项2：增加工作协议
为什么？团队或许需要更多相关的工作协议（因为他们已经在违反一些现行的协议），这件事会在会议期间马上就可以做。
选项3：写建议书
*检视会总结收尾
活动：增量/变量、感谢大家
为什么？改进回顾检视会
为什么？给大家一个认可贡献的机会。在一个艰难的迭代开发和努力完成的回顾检视会之后，我们需要一个提升，提醒自己：别忘了感谢团队的努力工作。
10.回顾检视会的日程表：
这篇关于02.敏捷回顾——为团队量身定做回顾检视会笔记的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
