实现可规模化的敏捷做法
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
企业组织采用敏捷做法的原因有很多。 主要原因包括：
- 缩短上市时间，加快产品交付
- 提高组织效率以管理不断变化的优先事项
- 提高软件质量和交付可预测性
- 提高项目可见性和降低项目风险
随着组织的发展，你需要规模化做法以保持敏捷性并达到不断变化的目标。 为此，请考虑以下两个指导原则：
- 对于你、你的团队和组织而言，怎样才算成功？ 最感兴趣的事项：准时交付？ 产品质量？ 可预测性？ 客户满意度？
- 返回到首要原则，返回到敏捷宣言中枚举的原则和共同价值，正如 Scrum 的创始人之一 Ken Schwaber 所指出的：
- “价值和原则可以规模化，但做法却区分上下文。”
- “保持价值，坚持原则，独立思考。 敏捷的一个核心前提是，做这项工作的人是最能弄清楚如何做的人。”
创建节奏和流
通过采用一个共享节奏和一组定期通信，可以在整个组织中创建恒定的活动流。 有助于在大型组织中创建节奏和流的做法包括：
- 共享节奏：定期冲刺 (sprint) 和发布可建立业务节奏。 让所有团队以共享节奏工作对所有协调和协作活动都很有帮助。
- 冲刺 (sprint) 电子邮件：若要使组织和所有团队随时了解功能团队的进度和计划，每个功能团队可以通过电子邮件发送其以前的冲刺 (sprint) 结果和当前冲刺 (sprint) 计划的摘要。
- 冲刺 (sprint) 演示：2 到 3 分钟的快速视频，演示团队开发的新功能。 此类视频的链接可以包含在冲刺 (sprint) 电子邮件中。
- 展示会议：为了通知其他团队并询问有关正在开发的软件的反馈，团队会展示他们所做的工作。 在整个项目生命周期内定期召开这些会议，并向所有相关方开放。
- Bug 摘要电子邮件：为了支持深入了解产品质量并鼓励维护 Bug 规则，请定期与组织共享质量指标。 这些指标可能包括每个功能团队的活动 Bug、Bug 趋势和每个工程师的 Bug。
- 协调会议：定期或根据需要召开协调团队的会议，以解决重叠的目标、依赖项和风险。
与客户交互
在整个产品生命周期中吸引客户是一个主要的敏捷原则。 使每个团队都能在所拥有的功能集上直接与客户交互。
- 持续反馈：构建客户反馈循环。 这些循环可以采用多种形式：
- 客户之声：让客户轻松提供反馈、添加想法并就下一代功能进行投票。 提供反馈通常通过专用网站来完成。
- 产品反馈：产品内反馈按钮是请求有关产品体验或特定功能的反馈的另一种方式。
- 客户演示：定期安排的征求客户反馈的演示有助于塑造下一代产品，并让你跟踪客户想要使用的应用程序。
- 早期采用者计划：此类计划应以所有团队可能希望作为一份子参与的想法进行制定。 早期采用者可以访问早期版本的可工作软件，然后他们可以提供反馈。 通常，这些计划的工作原理是为早期采用者列表启用某些功能标记。
- 数据驱动的决策：寻找检测产品以获取有用的数据以及可以测试各种假设的方法。 帮助推动建立一种庆祝学习的实验友好型文化。
提高项目可见性
你和你的团队对所做工作的目标、愿景和进度的见解越多，就越能降低风险和管理依赖项。
- 团队结构：无论你的组织规模有多大，都围绕 6 到 9 个规模的小型团队来构建组织。 创建在项目组合管理区域下分组的垂直自治功能团队。
- 工作分解结构：将大型目标、功能或要求分解为较小的目标、功能或要求可实现稳定的项目管理。 通过将工作分解为类似规模的任务，团队可以做出更好的估计并识别风险和依赖项。
- 合并视图：使用联机跟踪工具聚合工作，以跨团队获取知识。 构建仪表板以显示进度和趋势。
- 体验评审：这些会议在功能开发开始前召开，用于就方案和优先级进行领导层培训、收集反馈、设定期望，以及发现有关该功能的任何跨团队问题。
为高效员工队伍赋能
下面这些具体的敏捷做法可以很好地规模化，并让员工更快乐、更投入和更高效地工作：
- 嵌入式领导：使组织内的团队和领导者能够尽可能进行自我组织和自我管理。 团队自主性可提高组织敏捷性和团队效率。 确保团队获得成功所需的企业支持。
- 每日站立会议：也称为 Scrum 会议，有助于使团队专注于他们每天需要做的事情，以最大程度地提高他们履行冲刺 (sprint) 承诺的能力。 随着组织的发展，他们应考虑交错召开这些会议，以便根据需要进行跨团队参与。
- 整体团队 Scrum：来自不同敏捷团队的每日站立会议成员每天开会，报告其代表团队中已完成的工作、后续步骤和问题或阻碍。
- 团队通信：提供并鼓励团队共享其做法和指导，供他们和其他团队通过公司网络进行访问。 用于此目的的常见工具包括团队 Wiki、OneNotes 或 Markdown 网站。
- 协作：鼓励非正式团队对团队通信和团队内部的协作。 规范化如代码评审、设计评审、规范评审等做法，不仅能增强团队协作，而且有助于培养个人能力和公司整体能力。
改善组织文化
通过关注想要构建的文化来提高组织效率。 当个人、团队和组织采用一种或多种持续改进做法时，文化将发生变化。 一些可规模化的敏捷做法包括：
追溯会议：通过提出以下问题：“进展顺利吗？”、“我们应该在哪些方面有所改变？”和“我们应该停止做什么？”等问题，帮助团队反思如何改进其流程和做法。 追溯会议可帮助团队了解哪些正常工作以及哪些方面需要改进。 追溯会议可以随时随地召开。 然而，以有规律的节奏将某些追溯会议制度化有助于将持续的改进做法制度化。 例如：
追溯会议可帮助团队定期确定需要改进的领域。
发布追溯会议可帮助组织确定需要改进通信和内部做法的领域，并为下一次发布提供改进。
运营评审：通常每月举行一次，并且包括来自整个价值流的代表。 在设计这些追溯会议时跨越项目和其他计划的组合并使用客观的定量数据，以引发有关影响团队之间性能的动态的讨论。
有关规划和召开追溯会议的想法、提示和工具，请参阅敏捷追溯会议资源 Wiki。 另请参阅市场追溯会议扩展。
改进跟踪板：改进流程的好主意随时可能由任何一个人提出。 捕获这些想法以讨论并决定如何快速采取行动是支持流程改进工作的关键。
白板提供了一个简单和直观的方式来捕获想法。 此外，还可以创建改进跟踪团队，并捕获在电子看板工作版块上跟踪的想法。
制度化共享：共享最佳做法和沟通想法有助于组织内的所有团队成长和改进。 发展学习文化是支持这项以及其他持续改进活动的关键。 值得考虑的一些想法：
内部 Wiki
内部通讯组
黑客马拉松周数或 10% 黑客时间
为采用敏捷做法的团队提供支持的内部敏捷支持团队
文化游戏为敏捷经理提供了一个很好的资源，可帮助团队采用敏捷并共享最佳做法。
做法社区：支持内部通用规则（例如 DBA、SW 架构师、UX 设计）
可工作的软件
“经常交付可工作的软件，从几周到几个月，优先选择较短的时间刻度。”
“可工作的软件是进度的主要度量值。”
- 敏捷宣言
随着软件、功能和复杂性的增加，你需要采用有助于生成易耗型解决方案的做法。
- 功能标记：使用功能标记启用或禁用对不同功能的访问权限。 为向早期采用者启用功能提供支持，以获取工作反馈。
- 发布训练：提供另一种类型的节奏来交付一个或多个功能。 功能团队了解预先计划的新功能推出时间表，并正确规划。 发布训练可以与为组织建立的相同冲刺 (sprint) 节奏相对应，或者以不同的节奏发生。 有关如何设置冲刺 (sprint) 和发布训练，请参阅 Scaled Agile Framework。
- 持续集成：采用无需手动工作而是通过测试、生成和部署周期自动执行软件流的流程。
- 内部开源：将开源软件社区中开发的价值和精神带给你的内部开发团队。
相关文章
除了上述做法，还可以在以下文章中找到有关规模化敏捷工具的更多指导：
行业资源
不可规模化的做法
- 估计大型计划：部分瀑布项目方法涉及估计资源和时间表。 方案越大，这些估计有价值的可能性就越小。 随着项目的增长，可能会出现风险和不可预见的问题和障碍，使许多估计失效。
- 速度：虽然团队速度可以提供有用的指标来深入了解每个团队在冲刺 (sprint) 周期中可以完成多少工作，但无法添加团队速度来获得有意义或有用的指标。 此外，使用从许多团队获得的速度可靠地完成长期预测也存在问题。 团队在估计工作的方式上有所不同，这些变化会随时间推移而增加。
- 自上而下的规范性解决方案：不能搞“一刀切”，一种解决方案通常不适合所有团队。 支持团队自治意味着让团队找到自己的解决方案。