Scrum 和最佳做法

  • 项目

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

冲刺 (sprint) 规划会议

大部分冲刺 (sprint) 规划涉及产品所有者和团队之间的谈判，以确定在即将到来的冲刺 (sprint) 中要处理的重点和工作。 将规划会议的时间限制在 4 小时以内很有用。

在会议的第一部分，产品所有者与团队会面，讨论冲刺 (sprint) 中可能包含的用户情景。 你的产品所有者共享信息并回答你的团队对这些情景提出的任何问题。 此对话可能会显示数据源和用户界面布局等详细信息。 或者，它可能会显示响应时间预期，以及安全性和可用性的注意事项。 你的团队应在积压工作项窗体中捕获这些详细信息。 在会议的这一部分，你的团队将了解它必须生成的内容。

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

此外，在规划工作量过程中设置冲刺 (sprint) 目标可以帮助团队专注于每个冲刺 (sprint) 最重要的内容。

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

可通过以下资源进行详细了解：

设置冲刺目标

Scrum 团队使用冲刺 (sprint) 目标来聚焦其冲刺 (sprint) 活动。 他们经常在冲刺 (sprint) 规划会议期间设定这个目标。 目标总结了团队希望在冲刺 (sprint) 结束时完成的任务。 通过明确说明目标，可以在团队内部形成对核心目的的共同理解。 冲刺 (sprint) 目标还有助于在发生有关优先级的冲突时指导团队。

经验之谈：定义冲刺 (sprint) 目标

冲刺 (sprint) 目标定义了产品所有者和团队认为是实现该冲刺 (sprint) 的最终目标。 这不是一个随机选择的没有真正关系的积压工作项，而是一段简短的文本，用于捕获团队应尝试完成的工作。 通常，产品所有者会在为下一个冲刺 (sprint) 选择多个项之前提出冲刺 (sprint) 目标。 该冲刺 (sprint) 的项应全部符合该共同目标。

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

例如：

  • 此冲刺 (sprint) 将重点介绍一个简单的用户情景。 我们将使用它来证明建议的解决方案是否可行。
  • 此冲刺 (sprint) 围绕实现安全功能来正确保护网站的管理部分。
  • 此冲刺 (sprint) 涉及集成最重要的支付网关，以便我们可以开始收取资金。

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

在冲刺 (sprint) 评审期间，你应该问自己最重要的问题是，你是否设法实现了冲刺 (sprint) 目标。 其次才是你完成了多少个情景。 如果目标完成，即使并非所有情景都已完成，冲刺 (sprint) 也会成功。

由 Jesse Houwing 撰写，他是 Visual Studio devops Ranger 兼 Avanade Netherlands 的高级顾问。

成功会审会议的提示

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

  • 建立团队标准，以评估要修复的 bug 以及如何分配优先级和严重性。 与具有重大价值（或显著延迟机会成本）的功能或其他项目风险相关的 Bug，应分配更高的优先级和严重性。 将会审条件与其他团队文档一起存储，并根据需要进行更新。
  • 使用会审条件确定要修复的 bug 以及如何设置其“状态”、“优先级”、“严重性”和其他字段。
  • 根据你在开发周期中的位置调整会审条件。 在早期，你可能会决定修复你会审的大部分 bug。 但是，在本周期后期，你可能会提出会审条件，以减少需要修复的 bug 数量。
  • 会审 bug 后，将其分配给开发人员。 然后，开发人员可以调查并确定如何实现修补程序。

管理技术债务

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

经验之谈：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 上限。

例如，假设每个工程师的 bug 上限为 3。 那么，10 人团队的 bug 积压工作不应超过 30 个 bug。 如果团队超过该上限，就会停止对新功能的工作，并保持在 bug 下限。 一个团队希望始终处于上限之下，但团队要决定如何做到这一点。 bug 上限可确保团队不会长期承担 bug 债务。 首先，团队可以从导致 bug 注入的错误中吸取教训。

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

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

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

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

Scrum Master 的角色

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

Scrum Master 的核心职责包括：

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

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

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

  • 帮助团队解决出现的冲突和问题，并在此过程中学习。

  • 提出揭示隐藏问题的问题，并确认整个团队都充分了解大家正在沟通的内容。

  • 识别潜在问题并保护团队，避免潜在问题成为主要问题。 正如在发现 bug 后尽快修复 bug 的成本更低一样，在团队问题较小且易于管理时，修复团队问题也更容易且破坏性更小。

  • 防止团队在冲刺 (sprint) 评审会议期间呈现不完整的用户情景。

  • 收集、分析数据并将其呈现给业务利益干系人，以演示团队的改进和发展方式。 例如，如果你的团队增加了它所交付的价值量，同时生成较少的 bug，则通过定期与业务利益干系人沟通来使该价值显现出来。

优秀的 Scrum Master 拥有或发展了出色的沟通、谈判和冲突解决技能。 他们积极倾听大家说的话并注意他们写的内容。 他们还关注大家是如何传递信息的，例如他们的肢体语言、面部表情、语速和其他非语言交流。

正如在发现 bug 后尽快修复 bug 的成本更低一样，在团队问题较小且易于管理时，在它变为大问题前修复团队问题也更容易且破坏性更小。

每日 Scrum 会议

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

成功的 Scrum 会议有三个方面：

  • 每个人都站起来。 站立有助于使会议保持专注和简短。
  • 准时开始和结束，并且每天在同一位置同一时间进行
  • 每个人都参与，每个团队成员回答三个 Scrum 问题：
    • 自从最近的 Scrum 以来，我完成了哪些工作？
    • 在下一个 Scrum 之前，我能完成哪些任务？
    • 哪些阻塞性问题或障碍可能会影响我的工作？

注意

Scrum 会议的重点是需要从一个团队成员传递到另一个团队成员的工作状态。

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

“昨天，我更新了类，以反映我们从数据库提取的新数据元素，并使它显示在接口中。 这个任务已经完成。 今天，我确保使用存储过程和表中的其他数据元素正确计算新的数据元素。 我相信我今天能完成这个任务。 我需要有人来审阅我的计算结果。 我没有障碍或阻塞性问题。”

此响应传达了团队成员完成的工作、团队成员将完成的工作，以及团队成员希望有人帮助审阅代码。

对比下一个示例：

“昨天，我处理了类，它正常工作了。 今天，我处理接口。 没有阻塞性问题。”

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

请务必确保没有人会中断报告过程。 每个人都必须有足够的时间来回答这三个问题。

会议结束后应进行更深入的后续讨论，当大家回到办公桌前，或者，如果需要进行大量的对话，则应在后续会议中进行。

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

冲刺 (sprint) 评审会议

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

根据此会议，某些用户情景被接受为完整。 不完整的用户情景保留在产品积压工作中。 新的用户情景被添加到积压工作中。 这两组情景将进行排名，并在下一次冲刺 (sprint) 规划会议中评估或重新评估。

在此会议和追溯会议之后，你的团队规划下一个冲刺 (sprint)。 由于业务需求变化很快，你可以利用此会议与产品所有者、客户和利益干系人一起再次评审产品积压工作的优先级。

冲刺 (sprint) 追溯会议

如果追溯会议进行顺利且定期进行，则支持持续改进。

冲刺 (sprint) 追溯会议通常发生在冲刺 (sprint) 的最后一天，即冲刺 (sprint) 评审会议之后。 在此会议中，团队将探讨 Scrum 的执行以及可能需要调整的地方。

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

注意

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

在团队冲刺 (sprint) 追溯会议期间，请解决以下几个方面的问题：

  • 影响团队整体效率、工作效率和质量的问题。

  • 影响团队整体满意度和项目流的元素。

  • 什么原因导致不完整的积压工作项？ 团队能采取哪些措施来防止将来出现这些问题？

    例如，假设某个团队有多个任务，而团队中只有一个人可以执行这些任务。 孤立的专业知识会严重威胁冲刺 (sprint) 的成功。 单个团队成员投入了额外的时间，而其他团队成员则感到沮丧，因为他们无法提供更多帮助。 随着时间的推移，团队决定练习极限编程，以帮助更正此问题。

作为一个团队，应确定是否调整一个或多个流程，以尽量减少在冲刺 (sprint) 期间出现的问题。

你的团队可能需要执行一些工作来实现改进。 例如，发现自己受到太多失败生成的负面影响的团队决定实施持续集成。 由于他们不想中断进程，他们花了几个小时来设置试用版，然后在生产版本中打开试用版。 为了表示此工作，他们创建了一个峰值，并针对产品积压工作的其余部分组织了该工作。