Sprint 和 Scrum 敏捷开发最佳实践 - Azure Boards

link之家

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

冲刺 (sprint) 规划会议

许多冲刺计划涉及产品负责人和团队之间的谈判，以确定即将到来的冲刺重点和工作。对规划会议进行计时，将其限制为 4 小时或更少，这非常有用。

在会议的第一部分，你的产品负责人将与团队会面，讨论可能包含在冲刺中的用户故事。你的产品所有者共享信息并回答团队对这些故事的任何问题。此对话可能会显示数据源和用户界面布局等详细信息。或者，它可能会显示响应时间预期，以及安全性和可用性的注意事项。团队应在积压工作项表单中捕获这些详细信息。在本次会议的这一环节中，你的团队将了解需要构建的内容。

在规划冲刺 (sprint) 时，你可能会发现要捕获并添加到积压工作的其他需求。确保其定义明确且按优先级顺序排列。

此外，将冲刺目标设置为规划工作的一部分，可以帮助团队专注于每个冲刺最重要的内容。

规划冲刺后，可能需要与关键利益干系人共享该计划。

可以从以下资源了解详细信息：

什么是 Scrum？

冲刺规划白皮书

Scrum 指南

生成和管理产品待办事项列表白皮书

设置冲刺目标

Scrum 团队使用冲刺目标来集中于他们的冲刺活动。他们经常在短跑计划会议上设定这个目标。目标总结了团队希望在冲刺结束时完成的任务。通过明确目标，可以在团队内对核心目的形成共识。冲刺目标还有助于在优先级发生冲突时指导团队。

战线的提示：定义冲刺目标

冲刺目标定义产品所有者和团队认为实现该冲刺的最终目标。这不是没有真正关系的积压工作项的随机选择，而是一段简短的描述，概括了团队应努力完成的工作。通常，产品所有者会提出冲刺目标，然后为下一个冲刺选择多个项目。该冲刺 (sprint) 的项应全部符合该共同目标。

冲刺目标可以面向功能，但也可能具有大型流程组件，例如部署自动化或测试自动化。

本冲刺将重点介绍简单的用户情景。我们将使用它来证明建议的解决方案有效。

此冲刺 (sprint) 围绕实现安全功能来正确保护网站的管理部分。

此迭代的目的是集成最重要的支付网关，以便我们可以开始收款。

设置冲刺目标有助于团队保持专注。它使在冲刺中定义任务的优先级更容易，并且它可能有助于限制所涉及的利益干系人和最终用户的数量。

在冲刺审查期间，你应该问自己最重要的问题是你是否设法达到冲刺目标。你完成的故事数量是次要的。如果目标完成，即使并非所有情景都已完成，冲刺 (sprint) 也会成功。

由 Jesse Houwing 贡献，他是 Visual Studio DevOps Ranger 以及为荷兰 Avanade 工作的高级顾问。

成功会审会议的提示

修复 bug 表示与其他工作的权衡。使用会审会议来确定修复每个 bug 对与满足项目范围、预算和计划相关的其他优先级的重要性。

建立团队的标准，以评估要修复的 bug 以及如何分配优先级和严重性。应将与显著价值（或重大延迟机会成本）或其他项目风险的功能相关的 Bug 分配更高的优先级和严重性。请将分诊标准与其他团队文档一起保存，并根据需要进行更新。

使用会审条件来确定要修复哪些 bug 以及如何设置其状态、优先级、严重性和其他字段。

根据你在开发周期中的阶段调整分类标准。在早期，你可能会决定修复你会审的大部分 bug。但是，在开发周期的后期，你可能会提高筛选标准，以减少需要修复的 bug 数量。

对错误进行处理后，请将其分配给开发人员。然后，开发人员可以调查并确定如何实现修补程序。

管理技术债务

请考虑将 bug 栏和技术债务作为团队整体持续改进活动的一部分进行管理。你可能会发现这些感兴趣的资源：

良性和不良技术债务（以及 TDD 如何提供帮助），Henrik Kniberg 著

管理技术债务，由 Sven Johann 和 Eberhard Wolff 发布

经验之谈：Bug 管理

敏捷 Bug 管理：不是矛盾修饰法
作者：Microsoft的 Visual Studio 云服务首席项目经理 Gregg Boer

解决每个冲刺 (sprint) 的任何已知 bug 债务

在每个冲刺 (sprint) 中，团队都会查看 bug 积压工作中任何剩余的 bug，并投入一定的精力将已知 bug 集降低到零或接近零。无论是一天、一周还是整个冲刺 (sprint)，他们都会先修复 bug。稍后在冲刺 (sprint) 中发现的 bug 不被视为初始承诺的一部分。除非它们具有高优先级，否则它们将置于下一个冲刺 (sprint) 的 bug 积压工作中。

许多团队都在基于承诺的组织工作。通常，管理层对团队履行承诺的能力具有很高的价值。对一组已知的 bug 执行容量规划会使冲刺 (sprint) 规划更具确定性，从而增加了他们履行承诺的机会。在冲刺 (sprint) 期间发现的任何新 bug 都不是初始承诺的一部分，并将在下一次冲刺 (sprint) 中解决。

管理企业中的 bug 债务

一个正在转型到持续消除债务文化的组织可能面临以下问题：如何让团队在不明确指示具体行动的情况下减少错误数量？领导希望团队改变，但赋予团队自主性，以确定他们的变化方式。一个选项是使用防虫帽。

例如，假设每个工程师的 bug 上限为三个 bug。因此，10 人的团队在其 bug 积压列表中不应有超过 30 个 bug。如果团队超过其预算上限，预计将停止新功能的开发，并降低至 bug 数量上限以下。团队应始终处于预算上限之下，但团队可以自行决定如何实现这一点。 Bug 限制可确保团队不会长期背负 Bug 债务。首先，团队可以从导致 bug 注入的错误中吸取教训。

请记住，bug 上限代表 bug 积压中的缺陷数量。它不包括在开发功能的冲刺 (sprint) 中发现和修复的 bug。这些 bug 被视为已撤消的工作，而不是债务。

虽然 bug 可能导致技术债务，但它们可能并不代表所有债务。

软件设计不佳、编写不善的代码或短期修复都可能导致技术债务。技术债务反映了所有这些问题产生的额外开发工作。

跟踪工作以解决技术债务，如 PBI、用户情景或 bug。若要跟踪团队在产生和解决技术债务方面的进度，需要考虑如何对工作项和要跟踪的详细信息进行分类。可以将标记添加到任何工作项，以将其分组到你选择的类别中。

Scrum Master 的角色

Scrum Masters 通过采用 Scrum 流程来帮助构建和维护健康的团队。他们指导、辅导、教授和协助 Scrum 团队正确使用 Scrum 方法。 Scrum Masters 还充当变更代理，帮助团队克服障碍，并推动团队大幅提高工作效率。

Scrum Masters 的核心职责包括：

支持团队采用并遵循 Scrum 流程。例如，不应让每日 Scrum 会议成为持续 45 分钟的公开讨论。

防止产品所有者或团队成员在冲刺 (sprint) 开始后增加工作。

清除阻止团队向前推进的阻塞问题。这项工作可能需要你完成一些小任务，例如批准新生成计算机的采购订单或解决团队中的冲突。

帮助团队努力解决发生冲突和问题并从流程中吸取教训。

提出揭示隐藏问题的问题，并确认整个团队很好地理解了哪些人正在沟通。

确定并防止团队的潜在问题升级为严重问题。正如在发现 bug 后不久修复 bug 成本更低一样，在问题仍然较小且易于管理时修复团队问题也更容易且更不具破坏性。

防止团队在迭代评审会议期间呈现不完整的用户故事。

向业务利益干系人收集、分析和呈现数据，以演示团队如何改进和增长。例如，如果你的团队在减少 bug 数量的同时增加了提供的价值，应通过定期与业务利益相关者沟通来使这些价值变得更为显著。

良好的 Scrum 大师拥有或培养出色的沟通、谈判和冲突解决技能。他们积极倾听人们说和写的话。他们还听他们如何传递他们的信息，例如他们的身体语言，面部表情，声速和其他非语言通信。

正如在发现 bug 后不久修复它更便宜一样，当一个团队问题还小且易于管理时，修复它也更容易，更不易造成干扰，以防它成长为严重问题。

每日 Scrum 会议

每日 Scrum 会议有助于让团队专注于第二天需要执行的作。保持专注有助于团队最大限度地提高履行冲刺承诺的能力。 Scrum Master 应强制实施会议结构，并确保会议按时间开始，并在 15 分钟内完成。

成功的 Scrum 会议的三个方面包括：

每个人都站起来。站起来有助于使会议保持专注和简短。

它们准时开始和结束，每天在同一地点同时进行。

每个人都参与其中，每个团队成员回答三个 Scrum 问题：

自从最近的 Scrum 以来，我完成了什么？
下一个 Scrum 之前可以完成哪些任务？
哪些阻塞问题或障碍可能会影响我的工作？

团队成员应努力快速简洁地回答他们的问题。例如：

昨天，我更新了类，以便反映我们从数据库提取的新数据元素，并使其出现在界面中。此任务已完成。今天，我确保新数据元素与表中的存储过程及其他数据元素一起被正确计算。我相信我今天能完成这个任务。我需要有人来查看我的计算。我没有障碍或阻碍问题。

此响应传达了团队成员完成的内容、团队成员计划完成的内容，以及团队成员希望一些帮助查看代码。

与下一个示例形成对比：

昨天，我在课程上工作，效果不错。今天，我处理接口。没有阻碍性问题。

团队成员没有提供有关他们所处理的哪些类以及他们将完成的接口组件的足够详细信息。事实上，“完成”一词从未出现过。

报告期间不应有人打断，这一点非常重要。每个人必须有足够的时间回答这三个问题。

在会议结束后，当人们回到办公桌后，应该进行更深入的讨论；如果需要大量讨论，则应安排后续会议进行。

许多团队使用“虚拟停车场”方法延迟讨论。当团队成员认为需要进一步讨论的主题出现时，他们可以静静地走到白板或挂图前，在停车场中列出主题。在会议结束时，团队确定他们将如何处理列出的项目。

冲刺 (sprint) 评审会议

在冲刺 (sprint) 的最后一天召开冲刺 (sprint) 评审会议。你的团队演示了它在冲刺中完成的每个积压工作项。产品所有者、客户和利益干系人接受满足其期望并识别任何新要求的用户情景。客户在查看演示后通常更充分地了解其需求，并可能确定他们希望看到的更改。

在这次会议上，某些用户故事被视为已完成。不完整的用户故事保留在产品待办列表中。新的用户故事被添加到待办列表中。在下一次冲刺计划会议上，这两组故事将被排名并进行估计或重新估计。

在此会议和回顾会议之后，你的团队计划下一个冲刺。由于业务需求迅速变化，因此你可以利用此会议与产品所有者、客户和利益干系人一起再次查看产品积压工作优先级。

冲刺 (sprint) 追溯会议

回顾会议，如果执行得当并定期进行，能支持持续改进。

冲刺回顾会议通常在冲刺审查会议后的最后一天进行。在此会议中，你的团队将探讨其执行 Scrum 以及可能需要调整的内容。

根据讨论，你的团队可能会更改一个或多个流程，以提高自己的有效性、工作效率、质量和满意度。这次会议和由此产生的改进对于自我组织的敏捷原则至关重要。

若要支持团队的追溯会议，请考虑安装市场追溯会议扩展。此扩展支持收集有关项目里程碑的反馈、组织和确定反馈的优先级，以及创建和跟踪可作的任务，以帮助团队随着时间的推移改进。

在团队冲刺回顾期间，关注和解决这些领域的问题：

影响团队总体有效性、生产力和质量的问题。
影响团队整体满意度和项目流的元素。
是什么导致了积压工作项不完整？团队可以采取哪些措施来防止将来出现这些问题？

例如，请考虑一个团队，该团队只有一个人可以执行多个任务。孤立的专业知识会严重威胁冲刺 (sprint) 的成功。个别团队成员投入额外的时间，而其他团队成员则感到沮丧，他们无法做更多帮助。今后，团队决定练习 eXtreme 编程，以帮助随着时间的推移纠正此问题。

作为一个团队，努力确定是调整一个或多个流程，以最大程度地减少冲刺期间出现的问题。

你的团队可能需要执行一些工作才能实施改进。例如，发现自己受到太多失败生成的负面影响的团队决定实施持续集成。由于他们不想中断流程，因此在生产版本中启用试用版本之前，他们花了几个小时才设置一个试用版本。为了表示此工作，他们创建了一个峰值，并针对产品积压工作的其余部分组织了该工作。
结束冲刺活动
什么是 Scrum？
敏捷回顾：使优秀的团队变得伟大