有效冲刺 (sprint) 追溯
David Starr 是聚焦提高软件开发的专业的 Scrum.org 的首席软件工匠。 他还成立了在线技术社区 ElegantCode.com。
2012 年 7 月
测试核心质量，并使用的做法可确保追溯是团队的最强大的改进工具。 超过技术范围，本文提供用于维护和增强任务的工作和结果。
应用于
应用程序生存周期管理，Visual Studio，Team Foundation server
不要维护和提高性能，系统趋势在平均信息量并逐步下降。 这是与真正的软件开发团队，也是专业运动员和使用大的跑车。 因此 scrum 建议冲刺 (sprint) 追溯、于正常集中的一个定期发生的 scrum 团队的事件和性能。
冲刺 (sprint) 追溯是 scrum 团队在其及其工作反映的会话，从而改进的可操作的计划。 冲刺 (sprint) 追溯是最终事件在每个冲刺 (sprint) 中，指示每个冲刺 (sprint) 周期即将结束。
从 2011 年十月 scrum 准则：
冲刺 (sprint) 追溯是 scrum 团队的机会可以检查自身并创建计划以在下一个冲刺 (sprint) 期间可以将制定的改进。冲刺 (sprint) 追溯的目的是：•如何检查最后一个冲刺 (sprint) 转到有关方，关系，进程和工具；•标识和 orders 进度成功和潜在的改进的大型项目；此外，•创建实现改进的一个规划 scrum 团队完成其工作方式。
团队在冲刺 (sprint) 追溯特意改进。 有效冲刺 (sprint) 追溯是在帮助优秀团队的一个重要组件变得大，并且大的团队继续自身。
概述
冲刺 (sprint) 追溯为何重要
追溯广泛视为最不可缺少人员中心的敏捷方法。 测试和调整位于灵活性的焦点，并且，追溯分别检查和调整以软件组织的贵重资产，团队。 不继续过程改进作为可跟踪性要求，真实灵活性不可一致的。
性能不可提高和维护不执行任何操作。 但是执行会话不是所需成功。 必须注意确保团队计划改进。 如果改进的计划不属于该结果的一部分，实际上不是冲刺 (sprint) 追溯。
当执行良好，追溯通常最有用的过程) 团队实行。 当执行佳，可以将浪费和严厉提供的追溯。
运行状况冲刺 (sprint) 追溯剖析
scrum 添加 ACE 有关冲刺 (sprint) 追溯内部结构。 而不是建议冲刺 (sprint) 追溯执行方式，scrum 指定冲刺 (sprint) 追溯的输出：scrum 团队用于下一个冲刺 (sprint) 将制定的改进。
此灵活性 birthed 大多数专门设计的工具和技术实施追溯。 一些常见的做法本文后面将介绍，但是，无论使用的特定技术，首选冲刺 (sprint) 追溯具有以下特性：
整个团队网络
在团队讨论焦点而不是单独
团队的定义执行访问和具有希望地扩展
可操作的承诺列表生成
以前的冲刺 (sprint) 追溯结果进行访问
讨论与所有参与者相关
整个 scrum 团队参与每个冲刺 (sprint) 追溯。 通常，这意味着产品所有者和开发团队提供作为参与者，在 scrum 主管完成会话时。 有时，scrum 团队邀请其他参与者会话中。 当紧密地使用客户或其他利益干系人，这尤其建立的。
不管 + 谁中，冲刺 (sprint) 追溯的环境必须处于安全设置为所有参与者。 这意味着参与者必须诚实、透明，当将与其他方面时。 激情在追溯可能 lights 性能问题，并且改进讨论；熟练的便利确保正讨论能够保持和 professional，并重点保护整个团队改进。 这不是个人批评或攻击的机会。
(有关帮助您的 Microsoft Visual Studio 2012 工具的更多信息计划和管理冲刺 (sprint)，请参见 协作 [重定向]。)
增加定义执行
在 scrum 的开发团队使用定义执行注意哪必须满足的有关其工作，在被视为完全之前。 例如，它实现的开发团队可以决定每个函数都必须至少有一个传递的自动测试。 或团队的定义执行可能会声明，必须注释掉所有代码。
开发团队定义执行被视为段展开。 新窗体的团队速度比改进的共享历史记录的一个较成熟的团队将不会有一个不太紧凑和较小的定义执行。 展开完成的集的团队的定义。Kaizen 的核心，这意味着在改进的日本术语一个记住常量焦点。 当团队可以最初只需要时在签入代码前的代码生成，它们应能够随时间的推移与所需的更横征暴敛的标准对于单元测试附带的新代码。
每个冲刺 (sprint)，开发团队有希望地了解通知展开定义执行的操作。 冲刺 (sprint) 追溯用于讨论如何将观察并了解在冲刺 (sprint) 期间结果，以及的理想论坛更改可能对定义执行。
由于没有每个产品所有者具有焦点或涉及在内部开发团队实践，某个 scrum 团队除冲刺 (sprint) 追溯到两个不同阶段中：
在整个 scrum 团队的焦点
在开发团队的焦点
有关定义执行的更多信息，请参见 MSDN 文章 完成和撤消。
使可操作的承诺
在会议期间，虽然讨论可分离和聚合，冲刺 (sprint) 追溯未成功，则不会提交由团队。 它不是反映的足够在冲刺 (sprint) 期间，会发生什么。 scrum 团队执行的操作的可操作的承诺它将：
keep 执行
开始执行
停止执行
“可操作”中的单词是有意义的。 可操作的承诺具有广泛的步骤对于完成和验收条件，如一个好的要求。 一个可操作的承诺由团队清晰地阐明并了解。
当团队首次启动实施追溯时，他们发现计划经常会发现容易确定问题如何执行有关它们。 因此，团队发布的承诺看起来类似这样：
在较小的批处理的工作
使要求可读性
多个单元测试中写入
在估计时，请更加精确
它们不能提交；(它们是目标或瘦地遮掩的投诉。 这些是绑定问题在冲刺 (sprint) 追溯过程中，团队可能希望讨论，但是，可操作的承诺列表更象这样：
每天至少两次签入代码：午餐之前和在"主页"的。
快速新产品积压工作项作为用户情景并包括验收条件
创建证明自动化的失败测试的 bug 修复之前存在
在产品积压工作梳理会议期间，使用计划啤牌
在以前的冲刺 (sprint) 追溯做的承诺在每个新的冲刺 (sprint) 追溯中访问。 这是所需的追溯可以保留它们的含义和值。 的内容是相同令人沮丧如顺序决定改进，而无需在单据进度这样做的团队。
对于冲刺 (sprint) 追溯可以是重要的团队成员比必须投资必须更存在，它们。 创建可操作的目标的团队在团队的成功网络参与者和投资它们。
请将其保留相关
冲刺 (sprint) 追溯基本上是使用的技术显示操作，并且 scrum 的行为团队自身。 当一个自我组织系统变为自知时，从而自校正和特意改进，同时使工具执行此操作。
为使跟踪有用的，因此必须是对参与者。 如果焦点不在参与者值的操作，优点不会意识到。 它认为必须允许的团队考虑，和改进在区域十分重要。 此外，如果方便或主导个性驱动追溯到特定的结论，团队避免承担自身及其工作的责任。
访问的主题应与专业知识相关的所有层。 例如，在访问的 ACE 值细则高级测试驱动的开发 (TDD) 方案，如果某些团队成员不熟悉即使单元测试。 实际值可以在决定递增数字测试团队编写，在获取某些测试，或者在具有确保团队成员在 TDD 教练其他。
保留在 scrum 团队、不为单个而不是一个更大的组织的焦点。 焦点整个团队通过真诚地发现自身作为一个自我组织单元，而不是单独的松散联邦。
解决问题个人。在团队跟踪期间不正确。 不仅私下最适当地生成个人反馈，各个行为不是团队可以同时更改的操作。 在一个单独的团队焦点在冲刺 (sprint) 追溯过程中灾难的配方，并可能导致不可挽回的伤害给团队成员的相互信任。
为使追溯可以有意义的，它们应关注问题团队可以控件。 批评完整公司休假策略可能是称心用于查找一个具有同情心的耳朵的操作方，但是，执行一点可帮助团队改进。 必须注意的问题团队可能会影响自己它可以选择到特定策略的，如响应。
更改技术
具有执行任务的许多技术。 尝试不同的冲刺 (sprint) 评审展会话的构造保持内容新鲜和有趣的。 作为 scrum 团队的主要方便起见，scrum 主管应至少熟悉部分较常见的技术。
具有整个书籍有关追溯和增强博客上的文章最重要信息从获取其工作。 一些最常见简要介绍此处。
基本技术
在最基本冲刺 (sprint) 追溯的便利询问团队的基本问题并便于讨论。 方便或 scrum 主管可以使用各种激发灵感技术获取团队答案：
要在冲刺 (sprint) 中进度成功？
任何可以使用改进的此冲刺 (sprint) 中发生？
我们将决定执行在冲刺 (sprint) 中？
在沈默，的 3-5 使过程中派生这些答案的简单技术对于每个团队成员编写 2-3 答案到便笺的这些问题。 一旦创建，建议在所有墙分组可以在轮询之前发现。 可操作的承诺列表可以从而从团队的集思广益派生。
大多数其他冲刺 (sprint) 评审展技术仅在本主题的区别，并且可以重点介绍一个问题或此阶段处理。 仍，结果是最关键的，并且所有好支持此基本设计。
查看前提交
除了看下一个冲刺 (sprint) 外，每个冲刺 (sprint) 追溯在以前的冲刺 (sprint) 和讨论应包括发出的承诺查看有关团队的成功在实现这些目标。 如果此讨论不是每个冲刺 (sprint) 追溯的部分，参与者很快了解其承诺不重要，并且，它们将停止满足它们。
此外，查看冲刺 (sprint) 评审展承诺的正确的位置是在冲刺 (sprint) 中，而不仅仅是在末尾。 对于改进的提交，将其发送能以帮助确保它们每天考虑。 某些团队在一个公共区域值发送在冲刺 (sprint) 追溯期间进行的承诺在墙是提醒为每个人都与他们应侧重于每天改进。
专用技术
具有执行部分或冲刺 (sprint) 追溯的整个的许多其他方法。 许多技术的名称下面列出，其中每个值得的详细讨论。 所有下面是有大量文件证书和联机各种释放。
冲刺 (sprint) 追溯的技术
Fishbowl
疯狂错误哀伤高兴
海星
问题节点构树
旅途行
6 个认为将帽子
具有鉴赏力的追溯
5 个页面
措施计划
赛车
深渊
完美游戏
改进游戏
风船追溯
力场分析
四升
世界 Café
情感地震仪
查找以方便的特定两个丰富的资源展开它们的评审展工具中为：
《敏捷追溯：使优秀团队大由酯类德比 and diana larsen。
冲刺 (sprint) 追溯不是 scrum 主管的操场。 最近铸造的 scrum 主管有时会诱惑从冲刺 (sprint) 轻率会因技术到冲刺 (sprint)。 在追溯的类型防止分为车轮痕迹时的团队，磨炼该某些一致性将给出最佳结果。 重点介绍可操作的结果的团队将看到从其任务的大多数值。
在追溯不起作用
错误比无效或浪费时间，请非常运行冲刺 (sprint) 追溯可以是破坏性和破坏性给团队。 因此，特别是，当团队不熟悉工作时，有经验的便利进行会议是强烈建议的。
帮助通常是 scrum 主管的工作，但是，对于 scrum 主管新给角色，这不是中的字段。 它比 scrum 操作知识需要更多的冲刺 (sprint) 追溯可以具有正数结果；它要求帮助技能和能够生成离开负讨论的一组在正数结果。
常见气味
错误任务的一个常见示例是加剧到牢骚会话的一个。 确保比标识内容进度成功拙劣转到的较为容易，“改进建议”细流可以很容易转变为投诉洪流，当您不重定向此会话时。
冲刺 (sprint) 追溯不适用的其他气味包括：
在追溯而论“无限后”或“在以后事件”报告而不是机会对改进计划
未绑定参与者
注释中的单个的性能
中未出现的可操作的承诺
没有“什么我们涌出了”答复；团队需要了解和赞赏其正和负行为和工作
在上述情况，跟踪否定性的根本原因到缺少信任和承诺在一个或多个团队成员部分通常非常容易。 当没有解决此时的银色项目符号，scrum 特殊电量 scrum 主管与致力于解决这样的情况。
有效我们因此很好地终止。
虽然冲刺 (sprint) 追溯非常强大重要的事件，它们是 scrum 的一个通常被放弃的元素。 与最近和普通成功的 scrum 团队往往合理化需要执行冲刺 (sprint) 追溯。 这相当类似于决定调整的人员停止执行。
这次元对话可以侦听所示：
六个 + 月在演示 ScrumDeveloper 后戴维:质量启用，bug 放置。士气很高，手动回归开销不大。因为我们因此运行良好，无需冲刺 (sprint) 追溯帮助我们再次改进。这样 bob:该闪出警报声音。取消该会话将保存我们可以在上添加更多功能所花费的时间。六个 + 月 LaterBoss bob:质量放置了，并且 bug 增加。团队成员将内容，并且许多回归工作手动执行。开发人员戴维:由于 scrum，它是。我们告诉您它不是一个银色项目符号，也不清楚地工作。这样 bob:true。我将找到一个方法顾问实现新过程。
显然，它不是失败此处的 scrum。 省略 scrum 成功的关键组件的组织决议为失败的催化剂。 遗憾的是此方案太常见中。
scrum 团队到达高性能大多数细状态少见，美好和脆弱的。 有意义的追溯是在继续这些团队的一个重大组件可在这样的高级别。 反映在自身团队通过自调整和实现较高级别的性能和产品质量。 这是 Kaizen 的要点和内核到改进的所有物理程序。
当跟踪工作时，结果将触可知的。 在尝试新的事项的团队的兴奋。 当跟踪工作时，这些内容将不可避免为 true:
团队在一段时间内实现可衡量地减少高质量标准
单个在团队的上下文中了解他们的角色
可操作的承诺由所有团队成员了解
最后，那么，当冲刺 (sprint) 追溯很好地工作时，团队不断增大为组织的中心，用生产力和贵重物品。 优秀的软件开发团队将不会显示。 它们通过对改进的有意考虑仅在然后形成。 冲刺 (sprint) 追溯是该诞生的一个关键组件。