Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
企业组织采用敏捷做法的原因有很多。 主要原因包括：
- 缩短上市时间并加速产品交付
- 提高组织效率以管理不断变化的优先事项
- 提高软件质量和交付可预测性
- 提高项目可见性和降低项目风险
随着组织的发展，你希望缩放做法，以保持敏捷并满足不断变化的目标。 为此，请考虑以下两个指导原则：
- 对于你、你的团队和组织而言，怎样才算成功？ 你最感兴趣的是：按时交付？ 产品质量？ 可预测性？ 客户满意度？
-
返回到第一个原则 ，返回到 敏捷宣言 中枚举的原则和共享值，正如 Scrum 创始人之一 Ken Schwaber 所指出的：
- “价值和原则可以规模化，但做法却区分上下文。”
- “保持价值观，保留原则，为自己思考。 敏捷的一个核心前提是，做这项工作的人是最能弄清楚如何做的人。”
创建节奏和流
通过采用一个共享节奏和一组定期通信，可以在整个组织中创建恒定的活动流。 有助于在大型组织中创建节奏和流的做法包括：
- 共享节奏：定期冲刺 (sprint) 和发布可建立业务节奏。 让所有团队以共享节奏工作对所有协调和协作活动都很有帮助。
- 冲刺通信：为了让组织和所有团队了解功能团队的进度和计划，每个功能团队都可以通过数字频道（如 Microsoft Teams、Slack 或电子邮件）共享其以前的冲刺结果和当前冲刺计划摘要。
- 冲刺演示和视频：创建快速 2 到 3 分钟的视频，演示团队生成的新功能。 在冲刺通信或团队频道中共享指向此类视频的链接。
- 展示会议：若要通知其他团队并询问有关正在开发的软件的反馈，团队将展示他们完成的工作。 在整个项目生命周期内定期召开这些会议，并向所有相关方开放。
- 质量指标仪表板：为了支持深入了解产品质量并鼓励维护 bug 规则，请定期与组织共享质量指标。 这些指标可能包括每个功能团队的活动缺陷、缺陷趋势、测试覆盖率和缺陷泄漏率。
- 协调会议和仪式：定期或根据需要召开协调团队的会议，以解决重叠的目标、依赖关系和风险。 考虑实施团队的 Scrum of Scrums 或程序增量（PI）规划会议。
与客户交互
在整个产品生命周期中吸引客户是一个主要的敏捷原则。 使每个团队都能在所拥有的功能集上直接与客户交互。
-
持续反馈循环：在客户反馈机制中生成。 这些循环可以采用多种形式：
- 客户语音平台：让客户通过专用门户、社区论坛或集成反馈系统轻松提供反馈、添加想法并投票支持下一代功能。
- 产品内反馈：实现产品内反馈按钮和遥测，以收集有关产品体验和特定功能的见解。
- 客户演示和用户测试：计划定期演示，要求客户提供反馈，并执行可用性测试会话，以帮助塑造下一代产品，并跟踪生成客户想要使用的应用程序。
- 早期采用者和 beta 版计划：制定计划时应该考虑到所有团队可能在某个时候都希望参与。 早期采用者可以访问早期版本的工作软件并提供有价值的反馈。 通常，这些程序通过为早期采用者列表启用选择 功能标志 来工作。
- 数据驱动决策：查找检测产品以获取有用数据并测试各种假设的方法。 推动一种试验友好的文化，庆祝学习和基于证据的决策。
提高项目可见性
你和你的团队对正在完成的工作的目标、愿景和进度有了更深入的见解，可以更好地降低风险和管理依赖项。
- 团队结构：无论你的组织有多大，围绕 6 到 9 人的小型团队构建组织，都可以有效地进行缩放。 创建在项目组合管理区域下分组的垂直自治功能团队。
- 工作分解结构：将大型目标、功能或要求分解为较小的目标、特征或要求仍然是项目管理的主要内容。 通过将工作分解为类似规模的任务，团队可以做出更好的估计并识别风险和依赖项。
- 合并视图和仪表板：使用联机跟踪工具聚合工作并跨团队获取知识。 生成实时仪表板，以使用 Azure DevOps Analytics 服务显示进度、趋势和关键绩效指标。
- 体验和设计评审：在开发开始之前召开这些会议，以教育领导有关方案和优先级、收集反馈、设置期望，并展示有关该功能的任何跨团队问题。
为高效员工队伍赋能
能够良好扩展并且能够导致员工更加快乐、投入和富有成效的特定敏捷实践包括：
- 嵌入式领导和心理安全：使组织中的团队和领导能够尽可能自组织和管理。 团队自主性提高了组织敏捷性和团队效率。 确保团队拥有成功所需的公司赞助，并创建团队成员能够安全表达想法和关注的环境。
- 每日站立： Scrum 会议 有助于让团队专注于他们每天需要执行的作，以最大限度地提高他们满足冲刺承诺的能力。 随着组织的发展，他们应考虑交错召开这些会议，以便根据需要进行跨团队参与。
- Scrum 的 Scrum：来自不同敏捷团队的代表定期开会，报告团队中已完成的工作、后续步骤以及问题或障碍。
- 团队通信和知识共享：提供并鼓励团队通过公司网络分享其做法和指导。 常用工具包括团队 wiki、Microsoft Teams、Confluence 或 Azure DevOps wiki。
- 协作和代码质量：鼓励非正式团队到团队的通信和协作。 将代码评审、设计评审、配对编程和 Mob 编程等做法制度化。 这些做法不仅增加了团队协作，而且有助于发展个人和整体公司能力。
改善组织文化
通过关注想要构建的文化来提高组织效率。 当个人、团队和组织采用一种或多种持续改进做法时，文化将发生变化。 一些可规模化的敏捷做法包括：
回顾：问以下问题：“什么进展顺利？”，“我们应该以不同的方式做什么？”，以及“我们应该停止做什么？”，以帮助团队反思他们如何改进他们的流程和做法。 回顾有助于团队了解哪些工作良好以及需要改进的内容。 你可以随时随地进行回顾。 但是，定期将某些追溯措施制度化有助于建立持续改进的做法。 例如：
冲刺回顾 有助于团队定期识别需要改进的领域。
发布回顾 有助于组织识别需要改进的通信和内部实践领域，并推动下一版本的改进。
运营评审：通常每月举行，并包括来自整个价值流的代表。 在设计这些追溯会议时跨越项目和其他计划的组合并使用客观的定量数据，以引发有关影响团队之间性能的动态的讨论。
有关规划和召开追溯会议的想法、提示和工具，请参阅敏捷追溯会议资源 Wiki。 另请参阅市场追溯会议扩展。
改进跟踪板：改进流程的好主意随时可能来自任何人。 捕捉这些想法并快速讨论和决定如何处理，以便于支持流程改进工作。
白板提供了一种简单直观的方法来捕获想法。 此外，还可以创建改进跟踪团队，并捕获你在电子 板上跟踪的想法。
制度化共享和学习：共享最佳做法和沟通想法有助于组织内的所有团队成长和改进。 开发学习文化支持这种和其他持续改进活动。 请考虑以下想法：
内部 Wiki 和知识库
实践共同体和行会
Hackathon（开发者马拉松）周或创新时间
内部 DevOps 和敏捷指导团队，以支持采用这些做法的团队
定期午餐学习会
内部会议和技术会谈
文化游戏 为敏捷经理提供了良好的资源，可帮助团队采用敏捷做法并共享最佳做法。
实践社区：支持内部常见学科（例如站点可靠性工程师、软件架构师、UX 设计人员、数据科学家和安全专家）
可工作的软件
“经常交付可工作的软件，从几周到几个月，优先选择较短的时间刻度。”
“可工作的软件是进度的主要度量值。”
- 敏捷宣言
随着软件、功能和复杂性的增加，你需要采用有助于生成易耗型解决方案的做法。
- 功能标志和渐进式传递：使用功能标志可以安全地启用或禁用对不同功能的访问。 支持为早期采用者启用功能以获取工作反馈。 实现渐进式交付模式，例如金丝雀发布和蓝绿部署。
- 发布列车和持续交付：提供另一种类型的节律以交付一项或多项功能。 功能团队了解推出新功能的预定时间表，并据此进行计划。 发布列车可以对应于为组织建立的相同冲刺节奏，或者以不同的节奏进行。 请参阅缩放敏捷框架，了解如何设置冲刺和发布列车。
- 持续集成和持续部署（CI/CD）：采用自动化流程，消除手动工作，并通过测试、生成和部署周期自动执行软件流。 实施全面的测试策略，包括单元测试、集成测试和自动验收测试。
- 内部源代码和开放开发：将开源软件社区中开发的价值和精神带给内部开发团队。 鼓励跨团队进行代码共享、文档和协作开发实践。
- 云原生做法：采用容器化、微服务体系结构和云原生部署模式，以提高可伸缩性和可维护性。
新式做法和注意事项
随着敏捷实践的发展，请考虑以下其他新式方法：
- DevSecOps 集成：在整个开发生命周期内集成安全做法，而不是将安全性视为单独的考虑因素。
- 站点可靠性工程（SRE）：采用 SRE 做法来提高系统可靠性和降低运营开销。
- 价值流映射：映射和优化从想法到客户交付的价值流。
- OKR（目标和关键结果）：使用 OKR 围绕可衡量的结果（而不仅仅是输出）使团队保持一致。
- 设计思维：整合以人为本的设计方法，以更好地了解客户需求。
相关内容
除了上述做法，还可以在以下文章中找到有关缩放敏捷工具的更多指南：
行业资源
不可规模化的做法
- 估计大型计划：部分瀑布项目方法涉及估计资源和时间表。 计划越大，这些估计提供任何值的可能性就越小。 随着项目的增长，可能会出现风险和不可预见的问题和障碍，使许多估计失效。
- 作为跨团队指标的速度：虽然 团队速度 可以提供有用的指标，以便深入了解每个团队在冲刺周期内完成的工作量，但无法添加团队速度来获取有意义的或有用的指标。 此外，依赖多个团队的工作速度来可靠地完成远程预测是有问题的。 团队的估计工作方式可能有所不同，并且这些变化会随时间推移而增加。
- 自上而下的规范性解决方案：不能搞“一刀切”，一种解决方案通常不适合所有团队。 支持团队自治意味着让团队在提供必要的框架和支持的同时找到自己的解决方案。
- 形式主义的敏捷：单纯采用敏捷实践而不理解其目的或根据具体环境调整，往往导致实施效果不佳。