2006年，实用书架，共178页。 用英语写，用英语读。
（媒体使我在我的文章中澄清了有关可能的会员链接的问题，因此请阅读。 ）
几乎免责声明 ：从技术上讲，这也是一本商业书籍，但它涉及的是我工作的过程方面，而不是编程方面。 对于对过程和持续改进感兴趣的读者来说，它可能仍然很有趣，并且它的建议可以委托给其他生活和其他专业。
我将不去开写关于回顾的书的回顾，而是直接解释为什么需要这些回顾，以及它们适合软件开发团队每周例行工作的地方。
我将从敏捷方法论开始。 敏捷是与产品创建过程（主要是软件品种）相关的一种心态。 传统的方法（通常称为瀑布式 ）将创建任何类型的产品的过程分解为不同的连续阶段-一个不能在另一个完成之前就开始。 设计和需求过程可能要花费几个月的时间，之后程序员才能开始处理产品，直到产品完成，他们才向客户透露。 这部分可能要花一年甚至更长的时间，并且经常在那年年底发现完成的产品与客户的想法完全不同。
敏捷方法论基于较短的工作周期-从一周到四周不等，其中将最初的需求分解为更小的部分，然后在指定的时间内开发这些部分并将其显示给客户，客户迅速提供了有价值的反馈，然后将其引入到持续的开发过程中，最终导致产品更接近客户的最初愿景。
关于敏捷方法论，特别是其中一种实现的名为Scrum的一件有用的事情是，该流程本身是该方法论的产物，因此也可以在短周期内进行检查，并且所提供的反馈有助于随着时间的推移改进它。 Scrum包含几种类型的会议，在Scrum术语中称为仪式 ，在工作周期中的特定时间和间隔内进行。 其中之一就是回顾会议，回顾会议是在周期结束时举行的，目的是讨论工作流程本身，寻找改善流程的方法。 通常需要一个小时到半天，具体取决于所检查周期的范围，并且结果应该是一组已被团队调暗以改善其工作流程的实验，并将在整个实验过程中进行。下一个周期。
回顾的问题在于，如果团队在使用Scrum方法学方面拥有悠久的历史，而这些仪式的推动者（Scrum主管，经理或教练）没有能力使这些会议受益，那么回顾往往会变得平凡和无效的。 它们成为必不可少的罪恶-必须执行一些操作才能在某个地方检查一个盒子，团队成员需要忍受一些事情，以便他们可以在沉迷于经理或Scrum Master之后返回编码。
本书从两个角度处理了回顾的这一众所周知的方面：一个是团队成员，他们对过程的幻想破灭，因为过程不当。 另一类是目前完全不进行追溯但可以从中受益的团队。
有效的回顾通常分为几个部分，使会议向前发展，除了解释它们是什么，如何进行，希望保留什么以及需要多长时间外，作者还提供了一些有用的示例。如何处理这些部分。 他们为回溯协调员（在书开始时解释，不应该是经理或Scrum负责人）提供有价值的信息，包括做什么和不做什么，如何进行有效的回顾会议以及如何保留员工的信息。每个人的注意力，如何吸引安静的团队成员，并礼貌地使过度参与的人冷静下来。
我们当中那些需要进行回顾会议并对其有效性感到失望的人，感觉他们也许真的只是一种仪式，因此，他们绝对应该阅读本书，以复习如何处理回顾会议，以获取最大价值。为了队伍。
（ 这本书可以在这里找到。 ）
