| 2020-11-18
本文主要是讲Azure DevOps和DevOps Server团队在应用敏捷原则过程中，如何管理团队，角色，计划，迭代和流程的改进，由Aaron Bjork分享。
原文：Agile principles in practice - Azure DevOps | Microsoft Docs
亚伦·比约克（Aaron Bjork）是 Azure DevOps团队的项目经理，他于2018年分享了Azure DevOps团队如何采纳敏捷原则以及其实践情况。
Azure DevOps和Azure DevOps Server简介
Azure DevOps和Azure DevOps Server是供软件开发团队协作，规划，编写，生成，测试和部署其代码的平台，该团队由约800名员工组成。
Azure DevOps是基于订阅的云服务产品。其开发团队进行为期3周的迭代，并在每次迭代结束时发布版本。
Azure DevOps Server是私有化本地部署产品，它每年打包约3-4次更新，然后通过更新包将其部署到私有化的Azure DevOps Server。
引入敏捷原则的前后对比
在下面的列表中，您可以找到我们的开发团队在将敏捷实践应用于工作流程中所做的一些改变。
四个关键性变化
我们决定，做出下面四个关键点的变化，能让我们的开发和发布周期更高效且健康。
一、文化的改变
“文化可以把战略当早餐吃掉。” - 彼得•德鲁克
我们发现，对人而言，关键的激励因素是自治（ autonomy,），精湛（mastery）和目标（purpose）。在微软，我们正在寻找将这些因素带给我们的产品经理，开发人员和设计人员的方法，以使他们感到有能力构建正确的产品。
我们在引入的方法中会认真考虑两个因素，即对齐和自治：
- 对齐：自上而下发生，确保人们了解我们将要做的事情，并确保人们在业务目标，方面以及我们为什么要努力做的事情上保持一致
- 自治：从下而上发生，确保人们每天上班，并觉得他们对日常活动和决策产生重大影响
二、改变对待团队的方法
在Azure DevOps中，我们开始更多地考虑团队而不是个人。我们将人员和团队分为两部分：产品经理和工程师。
产品经理：负责构建的内容以及为什么构建它
工程师：负责建造并确保高质量
1、团队有以下特点：
- 跨职能
- 10 ～ 12人组成
- 自我管理
- 明确12～18个月内的章程与目标
- 独立的团队工作空间
- 自主负责生产环境中的特性
- 自主负责特性的部署
2、团队的结构变化如下：
以前，团队是根据系统的水平分层而组建的，如UI团队，数据团队和API团队等，但是，现在我们想要的是在产品中端到端拥有特性领域的团队。我们在某些水平层次上实施严格的准则，以确保团队之间产品的统一性。
我们力争做到了按垂直领域组建团队：
3、可以自主选择团队
每隔约18个月，我们就会进行所谓的“黄色粘性运动”。在这项活动中，开发人员可以选择他们感兴趣的产品领域，并希望在接下来的两个计划周期内继续工作。此活动为团队提供了自治权——可以选择他们要从事的工作，还可以帮助组织保持一致，因为这可以确保我们在团队之间保持平衡。
大约有80％的人最终选择他们目前所服务的团队，但是这让他们感到有选择的权利。
4、透明与责任
在每个冲刺的末尾，每个团队都会发送一封邮件，说明他们在上一个冲刺中已经完成的工作以及在下一个冲刺中计划做的事情。
三、改变做计划与学习的方式
“计划毫无价值，而计划就是一切。” ——艾森豪威尔
我们将规划分成四个级别，它们是：
- 迭代级 (3个星期)
- 半季度级 (3个迭代)
- 半年级(6个月)
- 战略级(12个月)
工程师和团队主要负责迭代级和半季度级计划，领导层负责半年级和战略级规划。
我们发现，这种计划结构有助于我们在计划时最大程度地学习。我们能够获得反馈，部署，找出客户想要的东西，并实际快速有效地实施这些事情。
四、创造了保持健康的新方法
在此之前，我们会推迟发现或修复代码缺陷，让它一直堆积到开发阶段结束时。到了最后时刻，我们才发现它，才对其进行修复，然后再验证一次。重复这个过程，这就像在不断制造一个缺陷“过山车”游戏。随着缺陷数量的减少，团队士气也在下降，因为在这个期间，他们除了修复缺陷以外，什么也做不了。
1、缺陷上限法
错误上限由以下公式计算：工程师的数量 X 5 = Bug的上限
如果团队的Bug数在迭代结束时超过了这个Bug上限，则该团队不能再开发新功能，而是必须把Bug数降至上限之下。这是一种偿还债务的方式。
2、屏蔽干扰
团队已经想出了自己的方式来提供聚焦工作，并以缺陷和生产事件的形式来解决这种中断文化。
团队将每个冲刺自行组织为两个不同子团队：功能（F团队）和屏障（L团队）。F团队开发所承诺的功能，L团队处理所有生产环境站点出现的问题和事件。轮转节奏由团队确定，它使成员可以更轻松地计划工作以外的活动。
小结（Four Takeaways）
- 认真地对待敏捷，但不必过于“迂腐”。敏捷可能过于严格了，应该让它像思维方式或文化一样成长。
- 不要庆祝“活动”，而要为“结果”喝彩。写代码并不比功能部署重要。
- 您不能欺骗发布。除非你具有“迭代末尾必须发布新服务或更新产品”的心态，否则你一定无法完成发布所需的所有工作。“每个迭代必须发布”的要求有助于建立节奏。
- 建立你想要的文化后，您将获得想要的行为。