使用现代工程实践，微软核心服务开发与工程（CSE，前身为Microsoft IT）团队可以快速有效地响应，以满足内部客户和合作伙伴的业务需求。微软的开发平台Visual Studio Team Services（Visual Studio 团队服务，VSTS）提供并内置了支持工程基础（Engineering Fundamentals）和应用程序生命周期管理的工具，为CSE团队带来了采用敏捷方法的机会。通过使用VSTS，CSE致力于持续集成和持续交付的增量更新，并维护以客户为中心的开发流程。
Microsoft IT曾经使用的是传统的瀑布式开发流程，通常需要业务部门等待三个月才能发布新的解决方案或修复bug。此外，Microsoft IT也无法改变关注的焦点，快速响应优先级高的请求。随着服务、软件、PC 和设备业务的变革步伐加快, 传统的软件解决方案发布速度并没有跟上业务需求，而花费的时间越长就会导致失去越多的市场机会，而微软已经错过了许多潜在的销售机会。
Microsoft IT改进了为微软内部客户开发应用程序和服务的方式，通过敏捷开放和现代化的软件工程，帮助微软内部业务团队更快的创造商业价值。为了支持微软的内部客户和合作伙伴, CSE更快地响应不断变化的业务需求，不再花费六个月的时间交付应用程序或更新，而是更快、更高效地传递价值。为了提高反应能力, CSE开始了现代软件工程的旅程，CSE的目标是每天都以持续集成、持续交付的流程发布新功能。
随着VSTS服务和现代软件工程方法的灵活性和速度, 高优先级的项目可以在项目开始的两周内就发布出来。最终, CSE计划在持续发布的基础上，使用 VSTS团队服务为CSE的解决方案提供每天的增量更新。
微软的软件工程文化变革
为了缩短功能和服务开发周期, 并更快地响应内部客户需求, Microsoft IT/CSE开始了向现代软件工程的转型之旅。作为一个组织, Microsoft IT/CSE变得更加敏捷, 采用了 DevOps 的紧密合作和共同负责的文化。Microsoft IT/CSE在改变团队的心态, 更改组织结构, 并开始合并团队角色。Microsoft IT/CSE也在学习如何更好地关注客户体验，这些变化支持新的敏捷工程实践, 并对客户更敏感。
Microsoft IT/CSE的敏捷开发团队，也称为冲刺（Sprints）团队，由工程师、产品经理和业务客户组成，他们协同工作为微软内部业务客户定义和开发解决方案。现代软件工程需要巨大的团队合作和紧密的协作，创建支持这种团队合作所需的组织文化并不是一下子就能完成的，改变人们的思维方式和方法需要时间。在开发团队和领导层中, 人员的心态必须经历重大转变，微软正在进行这一转变的过程中。
从瀑布式开发模型到敏捷开发的转变不仅仅是将一个流程替换为另一个流程。敏捷是一个新的思维方式和持续的批判思维, 因为它要创造新的流程。当客户需求变化时，开发团队必须改变所交付的软件及解决方案，在这种环境下, 结果比过程更重要。微软的工程师团队不再花费数周或数月的时间来设计和规划一个整体解决方案, 然后用甚至更长的时间来开发它；相反, 新的功能请求会在未完成任务（Backlog）中成为高优先级，并且在两周的冲刺中完成编码，新代码将定期集成到生产环境中构建。
在这种环境下, 开发团队成员和管理人员必须要接受模糊性（Ambiguity）和快速改正错误，必须迅速适应新的要求和改变目标。每个团队都必须实现自治并逐步提高，在一个项目中获得的最佳实践，将成下一个项目中成为新的最佳实践的出发点。没有任何事物是一成不变的, 甚至是目标本身。
另外, 团队中的每个人都必须对质量承担同样的责任。微软认为，等待某个人来解决某个问题，这很浪费宝贵的时间，第一个有时间的人就应该能够处理问题。理想情况下, 每个团队成员都应该具有能处理任何问题的背景和技能。最开始的时候，微软还没有达到这个理想的状态, 但是正在稳步地朝着这个方向前进。
现代软件工程
为了更快地响应客户和业务需求, CSE转向了一个现代化的软件工程模型。此模型有两个组件。首先, 通过合并软件工程的开发和运营两个角色——DevOps，提高了工程师人员和文化的成熟度，从而提升了效率。这样, 任何工程师都可以在团队中执行任何任务。第二，采用了敏捷开发原则、方法和工具来提升服务成熟度，从而进一步缩短周期。
（上图为微软现代软件工程成熟度模型）
工程师人员和文化的成熟度
作为迈向现代工程的第一步，微软根据业务流程重新调整了开发团队的组织结构，让二者匹配起来，从而消除了组织障碍, 以便可以将适当的资源分配给每个项目。然后, 微软开始将软件工程 （开发和测试）和服务工程（运营和维护）角色合并到一个敏捷的 DevOps 团队中。目标是让每个团队成员都知道其他角色所面临的问题, 以便能够协作解决问题，这增加了团队的效率和有效性。最终, 任何冲刺 (sprint) 团队成员都可以在任何工程角色中执行任务。
从传统到现代软件工程的发展, 微软确定了四个层次的人与文化成熟度。通过每一层的向上发展, 运维和开发/测试功能逐渐合并。这四个层次是：
1 级——信任：软件工程师（开发和测试）和服务工程师（运维）更多地了解彼此的角色。当他们开始更好地了解彼此, 就培养了更大的耐心和信任。
2 级——共享目标：角色仍然被区分。服务工程师和软件工程师继续了解彼此的角色, 并开始共享一个常规的工作。他们开始互相介入，并在可能的情况下互相帮助。
3 级——角色共享：角色开始合并。服务工程师和软件工程师开始使用通用的系统和工具、培养新的技能, 这样他们就可以开始相互进入对方的角色了。
4 级——完全集成的角色：最后, 服务工程师和软件工程师之间没有区别。每个人都是同一个团队的一员, 有着共同的目标，客户是重点。Bug不再是软件工程师的问题，服务器宕机也不再是运维服务工程师的问题，任何人都可以处理这些问题。这个层面上没有更多的交接, 只有通用工具、流程和项目，所有团队成员对流程和项目都有充分的可见性。每一个人都可以无缝地进入任何一个角色并承担相应的责任。
CSE的工程团队正在这些层级上进步, 尽管速度各有不同，大多数团队成员处于2级或3级。向上一个级别发展的一个障碍是团队成员学习新角色的时间, 同时还要承担日常的任务。
服务成熟度
为了通过快速交付周期保持高质量的软件及解决方案，CSE开始采用现代软件工程成熟度模型的第二个必要方面：服务成熟度。在遵循适当的实践以确保业务客户和最终用户都具有良好的体验并获得想要的结果，就会产生服务成熟度。CSE专注于支持服务成熟的八大支柱和相关原则，它们为一系列方法提供了概念框架，这些方法在开发过程中将这些原则付诸实践。
（上图为微软现代软件工程支柱和原则）
流程和工具
为了缩短发布周期，微软采用了敏捷开发流程，创建了一系列支持的基础环境和工具。
敏捷开发意味着迭代设计，在现代软件工程的流程中，有一个重要组成部分就是迭代设计。迭代设计过程使用快速原型来验证和细化设计选择, 而不是像传统方法那样在项目开始前要创建详细的计划。
微软同时设计了一系列的敏捷开发方法，称之为工程基础（Engineering Fundamentals）。这些工程基础是微软工程师所必须遵守的原则，工程基础以Epics（大的历史版本）、Benefits（收益）、接受标准（Acceptance Criteria）的方式，被嵌入到Visual Studio Team Services（VSTS）中，这些工程基础在工程师的冲刺（Sprints）任务单中不断被继承。工程基础有助于加快软件的开发和部署，通过定义如下实践的方式：快速、按需的开发和测试环境资源调配；无人值守的部署；自动化测试；安全、兼容的服务等。
微软建立了一个基础架构来运行敏捷项目, 包括：
- 迁移到Visual Studio团队服务（VSTS）开发工具上。将现有工作项目和代码，迁移到VSTS上，让所有新项目都使用此工具。
- 降低开发测试环境的人工参与。过去，CSE使用的是物理服务器的静态环境，这需要花费很多时间来维护。今天，CSE采用Azure PaaS解决方案以及基于Azure IaaS的虚拟化来部署环境，这样就可以根据需要而动态地部署环境。
- 提高软件版本构建和测试的自动化程度。自动化会减少每个构建和测试运行所需的时间。
- 为持续集成和持续部署创建框架（Pipeline）。VSTS发布管理提供了一个发布框架（Pipeline）, 它将让工程师可以每天发布面向生产环境就绪的代码。
应用工程基础
每个冲刺团队都将工程基础应用于每个项目。现代软件工程方法是对发展过程的根本性文化变革, 而不是清单上的一组新项目。这鼓励工程师们不仅要考虑他们所提供的代码, 还要思考他们将如何交付, 以及将如何最好地为客户服务。
工程基础作为指导性要求, 每个基础都要在继承的基础上有验收标准。冲刺（Sprint）团队确保他们提供的服务遵循工程基础要素。新员工将其作为指导原则, 以学习如何CSE组织的工程方法。而工程基础也嵌入在VSTS中——工程师们每天都使用这个工具，所以他们很容易找到和使用工程基础。
持续交付
专注于最小可行性（Minimal Viable Product，MVP）的产品：微软的工程师采用了MVP思维，他们专注于开发最小可行的代码, 以便最大程度的收集用户反馈。
- 动态和按需环境资源调配：工程师可以在任何时候实现一个包括所有必要组件和依赖服务的环境, 以便在部署代码时可以运行指定的功能。
- 持续集成：微软工程师可以在任何时候为代码创建一个无人值守的版本，以便在几分钟内生成软件的可执行版本, 这种构建可部署到任何环境而无需争夺资源。这种集成环境提供了解决方案的生产环境视图, 可用于演示新功能并驱动后续代码迭代和功能开发。
- 持续验证：工程师可以在任何时候为部署的软件启动一个自动化的验证过程, 以便在没有人工干预的情况下，在几分钟内完成版本发布的准备。
- 持续的服务部署：工程师可以在任何时候为构建的软件版本启动无人值守的部署过程, 该过程在可执行的环境中只需花费几分钟即可，而无需争夺计算资源。
以客户为中心
在生产环境中进行安全的测试：工程师可以在任何时候开始测试, 从实验中了解或证明软件服务的健康程度。了解用户如何从服务获得价值：工程师们坚持不懈地关注利益相关者，包括用户、客户和合作伙伴，这可以帮助他们了解和传递需求并将需求转换为软件功能、用户情景和任务，从而让客户满意。
CSE工程实践
准备编码：软件工程师可以随时将代码签出到任何开发环境 (本地或远程), 以便在几分钟内编译、运行和调试。
准备构建：软件工程师可以在任何时候获得具备所有必要组件的开发环境, 以便可以签出、编译和运行代码。
组件化：软件工程师使用组件，这让代码库更易于构建、编写和部署。通过使用Flighting函数，可以使新功能和代码变更独立于解决方案的其余部分而被打开或关闭。
安全和隐私遵从性。所有软件服务都非常安全, 并遵守安全和隐私标准，微软工程师将安全基础设施和工具集成到持续交付流程/任务中。
服务健康、分析和监控：微软工程师使用远程测量和数据来形成对用户体验、系统运行状况、服务的业务价值的洞察力，从而支持自动化。
现代软件工程在行动
（上图为微软现代软件工程在行动）
Visual Studio 团队服务 (VSTS) 是微软工程师默认的开发环境。在云中托管的VSTS为微软工程师提供了一个全球可用的、具有弹性的共享开发平台，以创建和开发软件。微软在典型的软件构建中使用四个单独的开发环境方案，每个环境都代表了开发、测试和发布过程中的一个重要部分。这些方案是：
- 开发。开发环境因软件而异, 但这是微软工程师创建一个软件的初始环境，当把开发环境托管到 Visual Studio Online在线版时，将受益于许多内置功能：
- 未完成任务（Backlog）。可以跟踪功能、用户情景和工作项的Backlog，它们对应于整个项目的计划, 并提供整个项目的优先级视图。
- 看板（Kanban boards）。使用“看板”来跟踪跨所有冲刺项目的需求，并允许监控开发工作流以及团队的工作状态。使用“看板”，可以将Backlog转化为整个项目的可视化呈现。
- 链接的代码。使用 VSTS, 任何代码变更都可以链接到用户情景、bug 或任务，它提供了一个基于通过代码库的可跟踪路径，并可视化了解代码库是如何随着项目的进展而演变。
- Git代码库。Git上存储着微软的代码库, 它支持代码共享和协作，而这将增加代码的复用、一致性和透明度。
- Visual Studio控制的代码加载（Gated Check-in）。使用Visual Studio控制的代码管理模式，能够强制性地要求代码变更前至少通过两个代码审查员的确认，以及在代码变更被加载到服务器之前要通过一个成功的编译构建。
- Visual Studio构建系统。使用VSTS构建系统, 通过使用构建代理来实现自动化地构建集成，从而实现持续集成。
- Visual Studio发布管理器。使用Visual Studio发布管理器来自动化测试和部署过程，以实现持续续部署。
- 集成环境。集成环境对敏捷开发方法来说至关重要，它为开发者提供了一个生产环境（live environment）, 可以将冲刺（sprint）版本推向下一阶段。在集成方面, 微软工程师实现最小可行的产品（MVP）: 一个可靠但可能不完整的软件版本，用以向客户演示,并与团队成员共享功能测试、功能审查或投产前的准备。
- 投产前（Pre-production）环境。投产前的环境，主要用于beta测试和试用版。在这种环境中，可以提供一个镜像生产环境的体验, 但只定向发布给选定的用户或用户组进行最终测试。
- 生产环境。生产环境只是让软件解决方案使可为所有用户使用，从而支持微软的业务。从投产前环境中获得一个生产环境是一个很简单的过程，它进一步实现了冲刺版本发布和日常站会（standups）的持续交付目标以及客户至上的思维方式。
实现现代软件工程的收益
将现代软件工程模式与VSTS结合起来, 已经给CSE带来了极大的好处。这些好处包括：
- 以更快的发布周期满足业务部门用户需求——可在两周内提供新功能。
- 问题很快就会被纠正, 而不用让用户等待下一个大的软件版本。
- 不断地交付应用程序组合的更新和增强功能，从而比以前更快地实现软件开发工作的商业价值。
- 将发行版分解为较小的“块”将降低风险, 因为“块”仅表示两周的开发努力, 而不是几个月。
除了更快的发布周期外, 工程师审查和与用户互动的方式也带来了文化上的转变, 从而提高了客户满意度。工程师们现在更好奇软件是如何运行的, 以及用户是否对这些功能感到满意。为了改进软件并使用户的生活更轻松, 工程师们正在学习如何将用户问题转化为工作任务并将其列入优先级。
现代软件工程的最佳实践
迈向现代工程文化需要在多种学科中进行广泛的努力, 包括思维方式和传统领导方法的重大转变。在进行这一转变的同时, 微软学到了一些宝贵的经验教训。
在团队内部建立合作关系。传统管理团队的方式是衡量每个成员的表现，这往往导致团队成员相互竞争。 为了让敏捷开发工作顺利, 团队成员必须在彼此的工作基础上互相依赖, 而不是竞争。为了帮助建立团队合作，要以一个团队为整体来进行评估，衡量每一个团队是否成功达到团队目标。
鼓励团队自行解决问题。团队应有权自行解决任何问题，如果需要向上升级, 那么团队成员应该在提出问题的同时，尽力也提出解决方案。应该鼓励团队成员使用数据来获得洞察力并做出正确的决策。他们的目标应该是克服障碍, 更快交付价值。
采用分阶段方法进行文化变革。任何一个开发组织也不会在一个大的推动下就转变为现代软件工程文化。通过分阶段的方法，设立一系列可实现的阶段性目标，迈向理想的、敏捷的文化更有可能成功。
企业规模敏捷开发的挑战
微软成功的开始在内部小型项目中采用敏捷开发的模式，但在走向大型项目的时候却遇到 了问题。
在较小的项目上, 敏捷为CSE提供了很好的效果, 但是当微软开始在大型的、企业级的项目上使用敏捷模式时, 遇到了瓶颈——减慢了工作速度,、降低了质量，而问题出在团队规模上。敏捷模式最适合九名成员的小团队，当微软试图为大型项目增加人员时，增加的人员越多、团队的效率就越低。有些开发团队非常庞大，达到150人甚至更多，于是陷入了困境。此外，微软也无法预测完成一个超过两周冲刺的大型项目所需的时间和资源，这就产生了预算和资源问题，因此必须找到在企业规模上使用敏捷开发的更好方法。
为了解决这些问题, 微软研究了将敏捷应用于企业项目的第三方框架, 如针对精益软件和系统工程的可扩展敏捷框架（Scaled Agile Framework for Lean Software and System Engineering, SAFe）, 并将它用于开发微软自己的方法论基础。
为了更好地理解微软是如何实现可扩展的敏捷模式, 首先要了解CSE的小型敏捷团队是如何运作的。使用已经建立的敏捷模型, 小型的跨职能团队负责构建和交付服务。微软内部客户创建所需要的用户情景, 定义服务必须提供的内容，即业务价值。用户情景以简单明了的方式编写，很少带有细节。这些明确而简单地定义了开发人员在两周冲刺期间必须要交付的业务价值，然后敏捷团队将用户情景分解为若干可以在一天内完成的任务。使用这个方法, 开发团队能够根据实际信息和客户的需求快速迭代和解决问题。
CSE的小型敏捷团队具有如下角色：
- 产品负责人。该角色对应于敏捷模型中的业务所有者，产品负责人代表客户的利益，帮助确保开发工作满足客户需求。
- 项目经理。该角色在将用户情景转换为不同任务时，负责协调团队的工作。在冲刺 (sprint) 期间，Scrum（一种敏捷开发方法论）大师每天带领15分钟的站会并跟踪进度。
- 软件工程师。该角色负责设计、编码、构建、测试和发布软件。
- 服务工程师。该角色负责协调事件管理；变更请求；传统发布方式下的更新、打包和发布版本管理等；与数据中心和云核心有关的传统IT问题；任何必要的服务监控。
当然，随着微软向现代软件工程演进，这些角色也不断变化融合。
在微软应对大型敏捷工程的时候，出现的问题包括：随着每个团队的变大, 复杂性也随之变大，加入的人越多, 团队的交付能力就越慢——接近几乎闲置的状态，而每天的站会变得越来越长。同一个团队的人，最终工作在极端不同的任务上，彼此之间很难协调。
- 对代码之间的依赖关系缺乏理解和管理。当在一个团队中增加了太多的成员时，工作效率变得低下且难以协调；但是当尝试使用小型团队时却遇到了瓶颈，即不同的团队在负责不同的任务，当并行任务数量过多时，彼此之间无法预期所需要的上下游任务的完成时间，导致有些团队的空置。
- 在设定期望时遇到困难。整个团队没有机会在下一个冲刺前进行计划，所以也不知道项目会有多大。这意味着不能告诉产品负责人，何时能完成工作。反过来，产品负责人也无法设定客户的期望。
- 错过最后期限。对于大型项目, 团队无法在设定的截止日期前完成, 因为他们对所涉及的工作量不清楚。
- 过度工作的团队成员。当试图进行大型项目时，团队的生产率开始下降，团队管理人员被迫增加更多的开发者, 并迫使人们加班。这只会让事情更糟，由于没有人知道一个项目需要多少工作，因为试图在截止日期内完成项目，开发人员常常发现自己被过度的工作负担所淹没。
- 质量降低。随着规模的扩大, 质量开始下降。团队成员因做太多工作而精疲力竭，他们停止了思考, 只是做了被告知的事情。新功能需求得到优先考虑，所以持续工程和当前的产品问题没有得到需要的关注。
- 预算困难。当不理解项目工作量的真实范围时，很难预计到底完成项目需要多少预算。
因此，微软希望保持小型敏捷团队的效率和有效性，同时让小型团队能够在大型项目上进行合作。在提到第三方框架（如SAFe）基础上，微软开发了一个框架, 可以在各个层面上扩展敏捷的规模。从上往下框架层面分别为：
- 应用组合（Portfolio）。在微软框架的顶部，是设计产品套件和协调开发的地方。在这个层面，团队负责创建和管理Epic和Scenarios（场景）。其中，Epic是一组集成了单个服务的大服务。这可以类比成汽车模型，Scenarios是Epic中的大型组件，例如车身、车架、悬架或电气系统。Epic和Scenarios都是用通俗易懂的语言描述，任何人都能够理解。规划包括年度路线图。Epic一般需要2到6个季度才能完成，一个Scenario需要超过一个季度的时间才能完成。主要项目经理、总经理或总监根据项目的跨度，来监督这个层面的工作。
- 项目（Program）。在这个层面上，团队负责管理功能（Feature）的开发。Feature是Scenario的片段，称之为增量。继续使用汽车的例子, 如果电气系统是一个场景, 增量可能包括诸如保险丝盒、点烟适配器、电线等等。每个小的敏捷开发团队都有一个在项目团队中的代表，项目团队的工作包括集成小型敏捷团队的可交付成果、功能规划以及确保工作与客户需求相一致。Feature规划按季度完成——每个增量都在一个季度内完成。项目经理负责管理小型敏捷团队的工作, 并将其与客户需求进行协调。这里没有在小型敏捷团队中每天举行的站会, 而是每周或每双周对小型团队代表举行会议。如果一个Feature是一个更大套件的一部分，每个Feature团队都会向集成Feature的应用组合团队送去一个代表。
- 团队/执行（Team/Execution）。微软框架的基础层，是小型的敏捷开发团队，理想地限制在每队九个成员的规模。这些小型团队用经典的敏捷方式进行代码编写，并且是基于用户的场景和任务。业务价值将在两周的冲刺中交付。
（上图为微软可扩展的敏捷框架）
下图显示了可扩展的敏捷过程如何在项目级别上的运作。
（上图为项目级别中的可扩展敏捷过程）
扩展敏捷规模时的焦点区域。微软的框架是在企业项目中使用规模化敏捷方法时的基础。要使项目在新的框架内成功，就必须不断地集中精力减少依赖关系、在自治与一致性间平衡、改变文化以及将冲刺和发布分离开来。
减少依赖。微软了解到, 不断减少依赖关系很重要, 否则会减慢工作的速度并造成瓶颈。而如何减少依赖关系，则是在个案的基础上，找出依赖关系并确定它们的影响, 然后减轻甚至消除它们。依赖关系可能发生在团队、体系结构和流程等方面。
团队。微软组织和构建团队的方式会影响依赖关系。基于这个原因，微软正在从一个横向的团队结构转向一个纵向的队伍——从专业化分工的团队变成一个可以独立而全面解决自己问题的团队。例如, 当多个团队依赖单个数据库团队时, 数据库团队必须分级并排定工作的优先级，这会造成瓶颈。为了避免这种情况, 每个团队必须具备解决问题所需要的所有技能，并自治式地完成工作。
微软还致力于组织地理位置偏远的团队，让他们能够相对独立，并且只在冲刺或增量级别进行定期沟通。例如，微软CSE的一些团队在印度，于是就让这些团队做自己的工作，这样他们就不必经常与雷德蒙德的团队沟通，否则会让他们慢下来。
架构。微软试图在设计产品时，减少依赖关系和瓶颈、避免重复性工作。微软不希望多个团队依赖于单个产品或功能，当不能完全消除依赖关系时，尽量减少它们的影响。例如，微软在销售和营销领域的五个团队使用SAP系统进行支付，尽管他们在一个为期两周的冲刺周期中工作, 但SAP的更新仅每6个月发布一次。与SAP的发行版保持同步是一项繁重的工作，而且每个团队还要分别管理版本同步的工作。为了解决这个问题，微软组建了一个团队来构建一个称为“Pay as a Service”的抽象层，它具有简单的输入和输出体系结构，并使用各个团队管理版本同步的同样方法，这样团队可以更快地行动，因为不会重复同样的工作。
流程。流程包括跟踪和组织数据、变更审批委员会（CAB）会议、每天的跨团队协调会议和帮助台等。共享过程提高了团队之间的一致性, 实现了规模经济效益。另一方面, 多个流程可能会产生大量的开销, 因此在必要的时候要统一团队步调，这需要“足智多谋”。微软希望确保采取的任何流程都要有明显的收益，而对团队的影响要微乎其微。专注于流程还包括关注团队的持续改进, 不断减少依赖关系。
在自治性和一致性间保持平衡。从一组服务中组装解决方案，就像让每个敏捷团队在被子的一部分上工作一样。如果每个人都独立工作而没有协调，那么当他们把所有独立制作的被子的一部分拼合起来时，会发生什么呢？可能不像预期或期望的那样。而且，这么做很可能导致效率低下，所以需要团队之间的协调。
另一方面, 微软的敏捷团队又希望快速而持续地改进，自治可能是最简单的方法；但是对于大型项目，每个团队都是一个更大规模团队的成员，必须要与其他团队协作。为了平衡团队目标和大型项目的需求，要确定团队需要在哪里被协调, 以及在哪里可以自治。
这样做时要记住，很容易将术语“一致性”转换为“标准”或“需求”。如果试图向团队提供工作的刚性细节, 这反而会阻碍他们。相反, 只对小团队进行需要的调整, 足以给更大的团队提供所需的数据和功能即可。微软的目的不是让小团队以某种方式做事, 而是要提高与其他团队在相关合作领域的效率。在这些约束条件下, 每个团队都可以自由地找到最适合自己的解决方案。每个人都不必以同样的方式工作, 但所有团队都在关键领域保持一致，这样更大的团队才能发挥作用。
微软在特定区域统一团队。例如：所有团队都有日常站会, 使用相同的流程和基础设施, 并分享相同的两周交付节奏；所有团队都已迁移到 Visual Studio Online在线版；处理同一程序的团队也共享相同的待完成任务列表；而团队如何从待完成任务列表中选取和分配任务的顺序，是基于更大的目标。微软还使用一种通用语言来报告团队进度、速度，并演示团队价值和影响。这让微软团队对未来有了更大的视野和一定程度的可预测性。
微软还提醒团队，尽管大规模使用敏捷会产生更多的依赖关系和降低自治性，但它也会产生规模经济效应。相应的系统和基础结构已经建立，团队不必在它们上面花费时间和资源。
改变文化。在为企业项目而扩展敏捷工程的规模时，问题会被放大。做每件事需要更长的时间, 包括在整个组织中改变文化。微软不得不后退一步, 找出如何弥合领导层、利益相关者和敏捷团队之间的沟通鸿沟。微软努力消除在人这一层面的障碍，以增加更多的认同并在所有层面推行一致的愿景。清晰的沟通、减轻依赖关系和解决障碍是一个不断发展和重复的过程。微软以与项目中对待backlog的同样方式，对待这个过程。
微软发现合理设定期望值很重要。当微软开始大规模使用敏捷方法时，所有的项目都被标记为“最高优先”。微软认识到，需要让合适的人提前参与讨论，以便让每个人都知道将采取什么行动以及何时采取行动。微软CSE会沟通交付的优先级，并讨论交付顺序。
微软改变的另一个方面是如何定义将要交付的内容。在传统的瀑布模型中，相关人员和客户能清楚地知道在未来很长一段时间才能交付的软件到底是什么样，详细到颜色、大小和功能等。而在敏捷模型中，需要承诺了产品线和日期, 但为了允许在需要时进行修正，导致对最终产品的确切含义是含糊不清的。例如，可能会说到2017年底将生产出世界领先的虚拟现实眼镜，然后就没有更具体的了。
领导力在规模化敏捷工程中的作用也是不同的，需要改变思维方式和学习过程。领导人过去每年都聚在一起创建路线图和项目, 并将它们交给工程团队，工程团队则响应承诺的交货日期，领导层将推动团队实现既定目标。随着敏捷程度的提高, 领导层应该了解到团队具有一定的工作能力，必须为这些团队提供适当的工作量。领导人还需要事先了解组织如何根据工作量而扩大或缩小的规模。他们知道结果是他们的责任，例如随着销售和营销团队的领导越来越多地参与Epic和Scenario，他们正在对开发过程拥有更大的自主权。通过开发生命周期, 他们实际上是在进行更大范围的冲刺。通过这一经验, 他们正在学习像 Scrum 高手一样规划自己的backlog。
将冲刺与发布分离。除了软件代码，商业价值可能是一个计划、有关设计的决策、测试环境的框架、Epic和Scenario等。为了交付商业价值, 没有必要将软件推向生产环境。在这种扩展的敏捷模型中，软件发布在冲刺（sprint）之外发生。
这个问题涉及流程和工程上的最佳实践，这需要改变团队的心态。通常，瀑布模型下的版本具有交付项目的目标日期。微软发现从瀑布到敏捷的大型团队，通常会试图将瀑布流程变成冲刺，包括通常的瀑布发布里程碑——alpha版、beta版、预发布版、生产环境发布版和清理（Cleanup）版。他们认为提供商业价值同样需要发布，如果一个团队需要六个月的时间来发布服务，那么首次冲刺将持续六个月。当这样的团队被告知要进行为期两周的冲刺时，他们经常会尝试将瀑布方法强制推入这个被缩短的冲刺周期，但是却不会起作用。
相反, 当使用现代软件工程最佳实践进行发布时，会移动到已运行的系统中去。微软从规划和体系结构开始, 构建一个功能, 然后执行代码；将远程测试就位, 以便跟踪系统中发生的情况并自动进行测试。开发人员应该能够很容易地发布代码，如果代码有问题，就会被踢回来。最终目标是让团队按下按钮, 就将功能发布到生产环境中。
随着团队在规模化敏捷模型中的成熟, 他们正在学习将发布过程与冲刺分开。在冲刺 (sprint) 中发生的事情不一定会在发布中达到高潮，而是代表定义的业务价值。随着团队采用越来越短的冲刺，他们意识到需要在更长的周期进行持续发布，即使仍需要六个月。随着时间的推移, 发布周期可能会变得更短, 但不需要与冲刺 (sprint) 匹配。通过分离冲刺与发布流程, 可以让敏捷系统更成熟, 也让发布周期更加成熟，互相不需要让另一方产生负担。发布应在后台进行。
经验和教训
在扩展敏捷方法时，微软了解到, 优先考虑以下方面很重要：
- 最小化依赖关系。这样可以防止几个团队依赖一个团队来实现可交付结果时出现的瓶颈，没有一个团队拥有可以决定整个项目的任何部分。如果一个可交付结果进入了关键路径并开始减慢项目的速度, 任何其他的团队都可以着手继续工作。
- 交付价值。在典型的敏捷模型中, 涉及提供服务的小型团队，服务将作为价值发布到生产中。在纵向扩展的敏捷模型中，价值的评估方式不同，因为在开发中的代码不一定会立即被推入生产环境中。它与其他团队的在开发中的代码一起集成，重点仍然是交付价值。
- 成熟和一致的团队。最初，微软的每个敏捷团队都以相对自主的方式运作，并采用自己的节奏、工具和流程。当微软试图协调多个团队的工作以交付大规模的产品或套件时, 这就产生了问题。今天，微软的团队更加一致。随着时间的推移，微软将继续关注完善团队和方法，以创建一个越来越好的系统。
微软在做什么
随着微软继续进行现代软件工程的旅程，微软提供的商业价值比在瀑布模型下交付的要高，客户对结果更满意。使用微软模型来改进敏捷扩展的领域包括：提供更好的质量代码, 降低服务的波动性；设定并满足期望；团队成员积极参与这一过程；创建更准确的计划, 实现准确的预算编制；提供接近100%的计划增量功能。
在规模化敏捷的前提下，微软发现那些领导层最了解并参与流程的团队，将获得最大的好处。小型团队每天都在敏捷环境中工作，对这一套工作流程通过日常经验变得越发熟练。然而，项目和应用组合级别的团队领导，被从日常的敏捷过程移除了。此外，需要更长的时间来完成一个完整的周期而不是两周的冲刺，一个完整的周期可能需要几个月的时间。因此，领导层需要更长的时间才能完全理解敏捷方法是如何规模化运作的，甚至在领导者经历了一个完整的周期之后，微软期望继续扩展敏捷模型的规模来处理更大的项目，让领导者学习如何在更高的层次上管理敏捷。
轮换DevOps角色，提高服务质量
为了加强对敏捷方法的采用，Microsoft IT/CSE将“直接负责人”（Directly Responsible Individual ，DRI）添加到了DevOps团队中，通过关注事件管理、服务可用性和服务健康状况等，轮换角色可帮助微软的敏捷团队在问题影响客户之前主动发现和修复问题。由于需要解决的服务问题越来越少，团队成员有更多的时间来交付业务价值。因此，微软得以更快的速度和更高的效率提供更好的服务。
增加直接负责人（DRI）是许多信奉DevOps文化的高性能敏捷软件工程团队的选择，这个角色也被其它不同的名字所熟知, 比如Google的“警长”（sheriff）或者 Facebook的“特定响应者”（Designated Response Individual）。在敏捷团队中轮换, DRI负责服务可用性、服务运行状况和事件管理，DRI以客户为中心并推动积极的变化, 以改善客户的服务经验。
在Microsoft IT/CSE中，也使用了DRI来帮助微软敏捷团队更快、更有效地提供更好的服务。DRI积极地着眼于生产环境中的服务, 从而帮助敏捷团队更加积极主动。这帮助微软敏捷团队减少了多达50%的服务请求单和bug数量，也让团队其他人有更多时间来提供业务价值。
没有增加DRI角色之前，微软工程师团队每天只能从每个软件工程师那里得到四到五小时具有生产力的工作。自从将这一角色添加到团队中，每个软件工程师每天可创造生产力成果的时间增加到六小时。该角色还降低了风险，因为解决问题不会影响团队在冲刺（sprint）上交付的能力。此外，微软还发现DRI减少了与服务项目交互的次数, 所以成本也在下降。
DRI流程与期望
在微软的敏捷团队中，有一个主DRI和一个辅助DRI。主DRI把时间100%分配给这个角色，没有其它团队任务。每天，主DRI要检查事件日志，对关键事件或事件模式作出响应，还记录缺陷，并根据根本性原因将其分配给个人工程师处理。为了保证可见性，辅助DRI会被主DRI抄送所有的事项。在主DRI不可用或繁忙的情况下，辅助DRI会介入。
所谓轮换，即主DRI和辅助DRI角色会在所有团队成员中轮替。为了实现无缝转换，辅助DRI成为下一轮的主DRI。在同一冲刺期间，主和辅助DRI不会与Scrum 大师的角色重叠。轮替的节奏是每两周一次, 与理想的两周冲刺节奏一致。这确保了DRI可以参加每隔一周举行的服务审查和其它服务线的会议。这还确保了DRI在冲刺中有足够的影响力，并且有机会花时间在首选的工程活动中。轮换从冲刺的第一天开始，持续到下一个冲刺的第一天，冲刺团队自行跟踪和管理他们的DRI计划。
对于出现的问题，DRI执行根本原因分析, 并与负责该功能区域或组件的软件工程师交互。DRI没有被期望成为英雄并修复所有问题；然而，如果问题很容易解决，DRI可能会独立地继续解决问题，同时也会跟踪扩展团队的可见性。DRI需要创建一个VSTS的工作项目，并在可能的情况下将其链接到出现问题的事件中，以便于追踪。
由于DRI活动需要团队的一定配合，这占用了团队的“带宽”，因此微软将主要的DRI时间安排为Visual Studio Team Services (VSTS)中的“休息日”，这使得DRI工作不会对冲刺计划产生影响。DRI以两种方式响应出现的问题。在核心工作时间内，DRI会检查需要解决的关键问题或问题模式。而在核心时间之外, 当需要软件工程来响应事件时，服务工程团队会与DRI合作。主要DRI的随叫随到时间表是轮换的，这样没有人需要在每年一个以上的主要假期中被随叫随到。
在处理严重程度较高的现场生产环境问题时，主DRI应该参与到辅助DRI的工作中去，除非主DRI确信问题可以快速解决。DRI还有权与具有相应知识从而可以帮忙的其他团队成员联系。找他人援助，即使那些人并被有处于随时被召唤状态，也是正确的做法。多人在关键问题上一起上可以缩短解决问题的时间并减少DRI的压力，否则DRI只能自己处理问题。这种互助也会帮助团队成员更加理解DRI，从而得到成长。
当然，微软希望随着DRI这一角色越来越成熟，将减少甚至最终消除对团队支持的需求，这样将解放敏捷团队的“带宽”，让他们创造更多业务价值和提高质量。今后，主DRI还将负责把软件部署到生产环境中，DRI将确保部署过程中具有正确的部署文档、自动化和验证，部署之后还将检查结果和服务状态。这种做法还将减少接触潜在敏感信息的团队成员数量，这也是一种符合Sarbanes-Oxley（SOX）法规的模式。
DRI收益
随着DRI主动调查内部异常和提交问题（Tickets）趋势，微软团队在每次冲刺时都在解决bug。这改善了客户经验, 减少了每周的异常和提交问题的趋势。
而当团队成员作为DRI参与时, 他们会获得有关端到端服务的知识。DRI负责全面了解服务、客户体验以及服务如何实现业务价值。这种更广泛的关注，使团队成员更负责地交付高质量的客户体验，并推动更丰富的设计。每个DRI都带来了独特的视角和不同的值，这种关注的多样性有助于团队在许多领域改进服务。例如，一个微软的DRI发现一个服务与数据存储不在同一个区域运行。这种模式在预生产中不存在，如果没有DRI的职能可能就不会被注意到。现在，团队可以将服务重新部署到与客户相同的区域，这将减少延迟并改善客户体验。
以前, 当客户遇到软件缺陷时, 会重试要执行的任务或使用其它已知的变通办法。DRI则在客户把问题升级之前，就主动识别阻断问题并修复缺陷。在某些情况下, 在客户甚至意识到存在问题之前，DRI就已经记录了软件缺陷，这极大地缩短了微软团队平均检测（MTTD）和平均解析（MTTR）两个指标的时间。
将IT转变为创新引擎
在企业的数字化转型过程中，通常期望从自己的IT团队中孵化出创新能力，通过自己的IT组织来推动数字化转型。然而，企业的IT组织往往背负“技术债”。企业内部IT往往行动缓慢、过度流程导向、缺乏灵活性、倾向于规避风险、缺乏创造力，这也经常导致企业会引入外部专家以避免内部IT的掣肘。
微软认为，与其引入外部专家，不如提高自己内部IT团队的现代化程度与能力。其好处包括确保更好的解决方案可持续性和可重用性，利用公司内部已经有的专业知识和关系，以及减少供应商支出和总体复杂性。从员工统计的角度来看，随着数字原生的千禧一代的越来越多，对速度、创意和新技术趋势的使用驱动力只会越来越大。
内部IT组织的现代化，可以从建立一个孵化中心开始，孵化中心是组织内的一个小组，专注于新的应用、新的想法、最新技术，并利用新的方法进行交付。该小组旨在与内部业务团队和其他IT团队合作，开发具有创造力和敏捷性的现代解决方案，他们必须愿意违反标准的IT惯例和流程，以超越客户的期望。
内部创新孵化中心的作用不仅仅是提供具体的解决方案，还向企业内部展示了可以在整个IT组织中采用的新技能组合和工作方式。一旦该小组开始取得成效，就可以作为其它更好、更快、甚至成本更低的交付的例子。其最终目标是转变为一个创新引擎——一个快节奏、灵活、有创意的数字化解决方案交付引擎，以类似于消费类初创企业的方式满足客户需求。
历史上，曾经的微软IT也引入了的现代化IT创新小组，旨在帮助满足数字化转型的需求。在2014年的时候，该团队分别位于华盛顿州雷德蒙德和印度海德拉巴，这个团队旨在创造创新的、具有消费者价值的企业级体验——让内部用户喜爱他们的设备，同时提供前所未有的灵活性体验。
微软现代化IT创新小组的方法论：
- 首先是从一张白纸开始，要让这个创新小组可以突破任何现有的限制，其目标是消除过去和现在的偏见——不要对今天做出改进，而是重新开始；
- 创新小组要能组织接纳那些对新工作方式持开放态度，对创造力、数字激情和快速结果有偏执的人，例如微软现代化IT创新小组就大量直接从高校中雇用成员，同时研究创业公司和小企业领导的物质——不仅要了解他们做了什么，还要了解他们没有做什么；
- 成功的创新需要减少对团队的限制，因此要支持原则而不是流程、倾向于有自己的判断而不是绝对的标准、不断迭代而不是一开始就追求完美，以及基于文档的直接协作，都是减少内部组织约束并同时培养敏捷性和创造力的方法，而对于那些必要的公司流程则只保留最关键的部分（比如安全），同时为这些流程创造“便捷路径”或“高速路版本”，以便帮助创新小组而不是成为障碍——灵活不仅来自于该创新小组内部，也来自于周边相关的大环境；
- 该创新小组应该视为价值资产而不是威胁，包括传统IT团队在内的所有各方都应该分享成功，这是健康的利益分享和项目的先决条件，甚至可以由创新小组提供创新方案的V1或V2版本后再交由传统IT团队继续开发；
- 培养健康的跨组织合作激励文化，要确保与这个创新小组合作的其它公司内部组织不会感受威胁，而是更愿意看到合作的价值，成功还意味着从失败和实验中学到宝贵的经验教训；
- 积极传播“这是什么、为什么以及如何实现”，在微软实践中，创新小组首先为内部客户提供敏捷服务，其次是支持R&D团队交付创新而增值的结果，然后就是积极传播“这是什么、为什么以及如何实现”，同时创新小组也以年为单元轮换不同的开发人员进入该小组，以便在整个微软工程师团队中传播敏捷的文化。
内部IT组织的现代化对任何企业来说都不容易，这就像在开发应用程序时执行迭代循环一样。当然，来自高管的支持也很重要。就微软而言，直接来自最高层。通过微软的实践，有理由相信大多数企业可以很好地将IT转变为创新引擎。
