将 Agile 扩展到大型团队Scale Agile to Large Teams

作者: Gregg BoerBy: Gregg Boer

许多人不会在同一句子中使用 "Big" 和 "Agile" 这一词。Many people wouldn’t use the words “Big” and “Agile” in the same sentence. 大型软件组织已经获得了很大的信誉和更改速度变得很慢。Large software organizations had earned a reputation of being big and slow to change. 但这种情况正在改变。But that is changing. 许多大型组织都已成功地进行了 Agile 转换。Many large organizations have successfully made the transformation to Agile. 他们已了解如何缩放 Agile 原则,并在扩展框架(如 SAFe、LeSS 或结点)变得流行之前完成此操作。They have learned to scale Agile principles and have done so before scaling frameworks such as SAFe, LeSS, or Nexus became popular.

Microsoft 的 Team Services 组织这样一个组就会构建 Azure DevOps 产品。One such group, the Team Services organization at Microsoft, builds the Azure DevOps product. Team Services 有35功能团队,每3周发布一次生产。Team Services has 35 feature teams that release to production every 3 weeks.

团队服务中的每个团队都拥有从开始到完成的所有内容。Every team within Team Services owns everything from start to finish and beyond. 它们拥有客户关系。They own customer relationships. 他们管理自己的产品积压工作(backlog)。They manage their own product backlog. 它们将代码写入生产分支并将其签入。They write and check code into the production branch. 每3周部署一次生产分支,并且发布成为公共的。Every 3 weeks, the production branch is deployed and the release becomes public. 然后,团队会监视系统运行状况并解决实时站点问题。The teams then monitor system health and fix live-site issues.

根据敏捷原则,自治团队的工作效率更高。According to Agile principles, autonomous teams are more productive. Agile 组织希望其团队能够在日常执行中使用自治。An agile organization wants their teams to have autonomy over their day-to-day execution. 但没有对齐的自治将导致混乱。But autonomy without alignment would result in chaos. 20个团队独立工作不会生成一种统一的优质产品。20 teams working independently would not produce a unified, high quality product. 对齐为团队提供了其用途。Alignment gives teams their purpose. 对齐可确保团队满足组织的目标。Alignment ensures the teams meet organizational goals. 如果没有对齐,甚至最佳的执行团队也会失败。Without alignment, even the best performing teams would fail.

若要缩放 Agile,你必须:为团队启用自治,同时确保与组织进行协调。To scale Agile, you must: enable autonomy for the team, while ensuring alignment with the organization.

若要管理对齐与自治之间的精细平衡,请定义你的分类、你的规划过程和使用功能聊天。To manage the delicate balance between alignment and autonomy, define your taxonomy, your planning process and use feature chats.

分类Taxonomy

明确定义的分类定义组织的命名法。A clearly defined taxonomy defines the nomenclature for your organization.

Agile 团队需要明确定义的积压工作(backlog)才能成功。An agile team needs clearly defined backlog to be successful. 敏捷组织!So does the agile organization! 如果不清楚地说明你的组织目标,就不能预期团队能成功完成。You cannot expect the teams to be successful without clearly stating your organizational goals.

Agile 组织需要清楚地定义其目标,并陈述每个团队需要如何为这些目标做出贡献。An agile organization needs to clearly define its goals and state how each team needs to contribute to those goals. 若要实现此目的,必须为组织定义分类。To accomplish this, you must define a taxonomy for your organization.

常见分类为长篇故事、功能、情景和任务。A common taxonomy is Epics, Features, Stories, and Tasks.

长篇故事Epics

长篇故事声明对组织的成功至关重要的计划。Epics declare initiatives important to the organization's success. 长篇故事可能需要几个团队和多个冲刺(sprint)才能完成,但没有结束。Epics may take several teams and several sprints to accomplish, but they are not without an end. 长篇故事有一个明确定义的目标。Epics have a clearly defined goal. 一旦获得,故事就会关闭。Once attained the Epic is closed. 正在进行的长篇故事数量应可管理,以使组织保持聚焦。The number of Epics in progress should be manageable, to keep your organization focused. 长篇故事被分解为多种功能。Epics are broken down into Features.

功能Features

功能定义了实现长篇故事的目标所需的新功能。Features define new functionality required to realize an Epic’s goal. 功能是发布单位,也就是说,它们表示向客户发布的内容。Features are the release-unit, that is, they represent what is released to the customer. 可以根据最近完成的功能列表生成已发布的发行说明。Your published release notes can be built based on the list of Features recently completed. 功能可能需要多个冲刺(sprint)才能完成,但应调整大小以确保向客户提供一致的价值流。Features can take multiple sprints to complete, but should be sized to ensure a consistent flow of value to the customer. 功能分解为情景。Features are broken down into stories.

情景Stories

情景定义了团队在创建功能时必须提供的增量值。Stories define incremental value the team must deliver to create a Feature. 团队将此功能分解为递增部分。The team breaks the Feature down into incremental pieces. 一个已完成的情景可能不会为客户提供有意义的值。A single completed story may not provide meaningful value to the customer. 但是,已完成的故事表示生产质量的软件。However, a completed story represents production-quality software. 故事是团队的工作单位。Stories are the team’s work unit. 团队定义完成功能所需的情景。The team defines the stories required to complete a Feature. 可选择性地分解到任务中的情景。Stories optionally breakdown into Tasks.

任务Tasks

任务定义完成情景所需的工作。Tasks define the work required to complete a Story.

计划Initiatives

这种分类法并不完全适合。This taxonomy is not a one-size-fits-all. 许多组织都在长篇故事的级别上引入了一个称为 "计划" 的级别,这种计划分解为长篇故事。Many organizations introduce a level above Epics called Initiatives, Initiatives break down into Epics.

每个级别的名称都可以根据你的组织进行定制。The names of each level can be tailored to your organization. 但是,以上定义的名称 (长篇故事、功能、情景) 非常接近行业标准。However, the names defined above (Epics, Features, Stories) are fairly close to being industry standard.

独立性行Line of Autonomy

设置好分类后,定义您的独立性行。Once your taxonomy is set, define your Line of Autonomy. 独立性行是指团队成为清晰所有者的点,管理层不会干扰。The Line of Autonomy is the point at which the team is the clear owner and management doesn’t interfere.

以下示例已绘制功能下面的独立性行。The example below has drawn the Line of Autonomy below Features. 管理拥有提供对齐功能的长篇故事和功能。Management owns Epics and Features, which provide alignment. 团队拥有情景和任务,并对其执行方式具有独立性。Teams own Stories and Tasks and have autonomy on how they execute.

管理层不会将所有权扩展到独立性行的下方。Management doesn’t extend ownership below the Line of Autonomy. 例如,管理人员不会告诉团队如何分解情景、计划冲刺(sprint)或执行工作。For example, management doesn’t tell the team how to decompose stories, plan their sprint, or execute their work.

但是,团队必须确保其执行与管理目标保持一致。The team, however, must ensure their execution aligns with management’s goals. 团队拥有其积压工作(backlog)时,必须将其积压工作(backlog)与分配给他们的功能进行对齐。While a team owns their backlog of stories, they must align their backlog with the Features assigned to them.

规划Planning

若要缩放 Agile 计划,需要为每个分类级别制定计划。To scale Agile planning, you need a plan for each level of your taxonomy. 滚动波计划是关键的:该计划为固定时间段提供了方向,并按预期的时间间隔进行校准。Rolling wave planning is key: The plan provides direction for a fixed period of time, with expected calibration on regular intervals. 例如,可以每6个月校准一个18个月的计划。For example, an 18-month plan could be calibrated every 6 months.

此处为每个分类级别定义规划方法:长篇故事、功能、情景和任务。Here we define planning methods for each level of a taxonomy: Epics, Features, Stories, Tasks.

影像Vision

通过长篇故事表示,并设置组织的长期方向。Expressed through Epics and sets the long-term direction of the organization. 管理拥有计划并每6个月校准。Management owns the plan and calibrates it every 6 months. 长篇故事定义要在未来18个月完成的操作。Epics define what we want to complete in the next 18 months. 这是一项全体会议。The Vision is presented at an all-hands meeting. 预计约60% 的远景计划。Expect to accomplish about 60% of the Vision plan.

赛季Season

通过功能描述并设置未来6个月的策略。Described through Features and sets the strategy for the next 6 months. 功能确定我们要为我们的客户提供哪些功能。Features determine what we want to light up for our customers. 管理部门拥有季节性计划,并在全体会议上提供远景和季节性计划。Management owns the Seasonal plan and presents the Vision and Seasonal plans at an all-hands meeting. 所有团队计划都必须与管理的季节性计划一致。All team plans must align with the management’s Seasonal plan. 预计会达到季节性计划的80%。Expect to accomplish about 80% of the Seasonal plan.

3-冲刺(Sprint)计划3-Sprint Plan

定义团队将在接下来的3个冲刺(sprint)中完成的情景和功能。Defines the Stories and Features the team will finish over the next 3 sprints. 团队拥有该计划并校准其每个冲刺(sprint)。The team owns the plan and calibrates it every sprint. 团队通过功能聊天 (参阅下面的) 来提供管理计划。The team presents the plan to management via the Feature Chat (see below). 计划指定团队执行与六个月的季节性计划的对齐方式。The plan specifies how the team’s execution aligns with the 6-month Seasonal plan. 预计约为3个冲刺(Sprint)计划的90%。Expect to accomplish about 90% of the 3-Sprint plan.

冲刺(Sprint)计划Sprint Plan

定义团队将在下一个冲刺(sprint)中完成的情景和功能。Defines the Stories and Features the team will finish in the next sprint. 团队拥有冲刺(sprint)计划,并将其通过电子邮件发送到整个组织以获得完全透明度。The team owns the sprint plan and emails it to the entire organization for full transparency. 该计划包括团队在过去的冲刺(sprint)中完成的内容,以及其对下一个冲刺(sprint)的关注。The plan includes what the team accomplished in the past sprint and their focus for the next sprint.

预计约95% 的冲刺(Sprint)计划Expect to accomplish about 95% of the Sprint plan

独立性行Line of Autonomy

绘制的独立性行用于显示团队计划自治的位置。The Line of Autonomy is drawn to show where teams have planning autonomy. 上述计划过程按如下方式绘制自治行:The above planning process draws the Line of Autonomy as follows:

如上所述,管理层不会将所有权扩展到独立性行的下方。As stated above, Management doesn’t extend ownership below the Line of Autonomy. 它们使用远景和季节计划提供指导,并为团队提供自治以创建3个冲刺(sprint)和冲刺(Sprint)计划。They provide guidance using the Vision and Season plans and give teams autonomy to create 3-Sprint and Sprint plans.

功能研讨–独立性在何处满足协调Feature Chats – where autonomy meets alignment

功能聊天是一项低工作人员会议,其中每个团队都向管理人员提供了3个冲刺(Sprint)计划。A Feature Chat is a low-ceremony meeting where each team presents their 3-Sprint Plan to management. 此会议确保团队计划与组织目标保持一致。This meeting ensures team plans align with the organizational goals. 它还可帮助管理人员随时了解团队正在执行的操作。It also helps management stays informed on what the team is doing. 尽管每个冲刺(sprint)计划都校准了3个冲刺(sprint)计划,但每1-3 冲刺都需要功能聊天。While the 3-Sprint plan is calibrated every sprint, Feature Chats are held as-needed, every 1-3 sprints.

功能聊天会议向每个团队分配15分钟的时间。A Feature Chat meeting allocates 15 minutes to each team. 如果有10个功能团队,则可以在2.5 小时的时间段内安排这些会议。With 10 feature teams, you could schedule these meetings over a 2.5-hour time block. 每个团队准备一张3张幻灯片,并提供以下幻灯片:Each team prepares a 3-slide deck, with the following slides:

功能Features

团队将在接下来的3个冲刺(sprint)中亮起。The features the team will light up in the next 3 sprints.

债务Debt

团队如何管理技术债务。How the team is managing their technical debt. 债务是不符合管理质量要求的任何内容。Debt is anything that doesn’t meet management’s quality bars. 工程部主管设置的质量栏 (对齐) 的所有团队都相同。The Director of Engineering sets the quality bars, which are the same for all teams (alignment). 示例质量栏包括 # bug/工程、百分比单元测试通过和性能目标。Example quality bars include # bugs/engineer, % unit tests passing, and performance goals.

问题/依赖关系Issues/Dependencies

影响团队进度的任何内容。Anything that impacts the team’s progress. 团队无法解决或依赖于其他需要升级的团队。Issues the team can’t resolve or dependencies on other teams that need escalation. 每个团队(而不是中间经理)都直接向管理工作。Each team, not middle managers, presents their slides directly to management. 此团队介绍了3个冲刺(Sprint)计划如何与六个月的季节性计划一致。The team presents how their 3-Sprint plan aligns with the 6-month seasonal plan. 领导要求阐明问题并提出更改建议。Leadership asks clarifying questions and suggests changes in direction. 他们还可以请求跟进会议来解决更多问题。They can also request follow-up meetings to resolve deeper issues.

如果团队的计划未能满足管理的期望,则管理可能会请求重新计划。If a team’s plan fails to align with management’s expectations, management may request a re-plan. 在这种极少的活动中,团队将重新计划并计划另一次功能聊天来查看。In this rare event, the team will re-plan and schedule a second feature chat to review it.

信任–保持其对齐和自治的胶水Trust – the glue that holds it alignment and autonomy together

在大规模练习 Agile 时,信任是一个双向街道:When practicing Agile at scale, trust is a 2-way street:

管理层必须信任团队才能执行正确的操作。如果管理不信任团队,他们不会为团队带来独立性。Management must trust teams to do the right thing. If management doesn’t trust the teams, they won’t give teams autonomy.

通过持续交付高质量的代码,团队盈利信任。如果团队不可信,管理层不会为他们带来独立性。A team earns trust by consistently delivering high quality code. If teams aren’t trustworthy, management won’t give them autonomy.

管理必须为团队提供清晰的计划,使其能够与团队进行协作并信任他们的团队执行。Management must provide clear plans for teams to align with and trust their teams to execute. 团队必须与组织协调其计划,并以可靠的方式执行。Teams must align their plans with the organization and execute in a trustworthy manner.

当你希望将敏捷扩展到大型组织时,关键是要为团队提供自治,同时确保它们与组织目标保持一致。As you look to scale agile to large organizations, the key is to give teams autonomy while ensuring they are aligned with organizational goals. 关键的构建基块是明确定义的所有权和信任的文化。The critical building blocks are clearly defined ownership and a culture of trust. 完成此基础后,你会发现 Agile 可以很好地进行缩放。Once you have this foundation in place, you will find that Agile can scale very well.

免费开始免费 Azure Boards的敏捷工具入门。get started for free Get started with free agile tools in Azure Boards.

Gregg Boer Gregg Boer 是 Azure DevOps 中的主要组计划经理。Gregg Boer is a Principal Group Program Manager in Azure DevOps. Gregg 的优点是主义的一大优点,推动了 Microsoft Azure DevOps 和 Team Foundation Server 产品提供的敏捷管理解决方案愿景。A big believer in the benefits of Agile, Gregg drives the vision for Agile management solution provided by Microsoft’s Azure DevOps and Team Foundation Server products.