Caroline Te Aika - 2019年6月10日
随着我们继续走向云计算之旅，思科IT部门将Office 365推广到118,000名员工。您可以在此博客中了解我们的愿景和战略。
我们的实现有两个不同寻常的角度，可以为您自己转移到Office365提供建议。首先，我们没有按原样使用Office365，而是将其与WebEx团队集成在一起。（在此博客了解更多相关信息。）其次，我们使用行业标准规模化敏捷框架（SAFe）管理实现。虽然SAFe更常用于软件开发，但我们发现它非常适合构建和组织Office 365的复杂部署。
为何选择SAFe？
思科IT一直在使用敏捷开发，并且已经开始大规模使用SAFe投资敏捷，这是扩展敏捷团队合作的最流行的蓝图。但是，对于像Office 365这样的程序，它具有实现、开发、基础结构元素和相对高度的不可预测性，很难知道哪种方法最有益。
在研究了这些选择之后，我们决定使用SAFe。大多数项目团队和交流中小企业在敏捷方面的经验非常有限，但他们同意抱着怀疑的态度尝试一下。
组建团队
因此，在最初的计划研讨会之后不久，我（作为指定的产品经理）起草了一份拟议的计划积压（优先功能列表），我们一起组建了团队结构，该结构将构成我们Office 365的敏捷发布培训（ART）。
我们组建了三个Scrum团队：
- 核心支持：电子邮件和日历，设置基础架构和租户管理，准备好核心网络以及准备邮箱迁移流程。
- 安全性：Active Directory安全性、端点安全性、授权和身份验证、移动邮件以及法律和合规性。由于积压工作太大，一个团队无法管理，我们随后将此团队分成两部分。
- 生产力：桌面生产力应用程序、移动生产力应用程序、文档共享和协作编辑、与WebEx团队、Office 365组的集成，以及数据和见解。
我们还组建了两个scrumban团队，为他们提供比Kanban团队更多的结构，但比完整的Scrum团队更少的计划开销：
- 运营、支持、治理和财务
- 用户体验、沟通和组织变革管理
我们提供了敏捷方法的基本培训。之后，团队成员继续在工作中学习。
组建团队的团队
所有团队都作为敏捷发布培训（ART）一起工作——一个计划、提交和执行的“团队的团队”。产品经理负责组织积压工作、为用户故事设定优先级、发布培训工程师负责简化流程。我们每12周聚集一次，计划下一个项目增量，然后每个团队在这两者之间都具有高度的自主性。为了保持在团队级和项目级之间的信息流动，团队将他们的日志输入第三方工具（CA Agile Central），这样我们就可以在一个地方看到所有的进展。我们的常规ART检查点可以保持信息流动——每两周进行一次系统演示，证明这对于确保整个项目了解最新进展和发展尤为有效。
我们很快就扩大了规模。在我们决定使用SAFe三周后，团队展开了工作。我们现在即将完成我们的第五个计划增量，并且在工作量开始逐渐减少之前，预计可能会看到另外两个或三个完整的PI。
赢得怀疑论者
别搞错了：SAFe是一个非常大的文化变革，我们的一些团队成员在一开始就很担心。它帮助我们得到了我们的IT领导者和一个接受尝试新的和不熟悉的工作方式的团队的大力支持。
总体而言，虽然不完美，但使用SAFe框架进行Office 365实施对我们来说效果很好。团队喜欢拥有自主权并控制自己的积压工作。与此同时，ART为我们提供了结构、基于节奏的“恰到好处”的计划、可见性和问责制。
我们面临的一个缺点是难以实现可预测性，即我们可能计划一定数量或为一个计划增量工作，但很难准确地说明可以做什么。在这种类型的部署中，不可预测的操作和支持工作量会使准确性变得更加困难。让人们采用新的工作习惯也很困难，比如定期更新拉力赛。如果他们不这样做，能见度就会下降。
文化转型具有挑战性。学习充当产品负责人并对产品的各个方面负责都需要时间。管理者需要尊重优先排序流程，而不是在流程之外添加“额外的”。团队成员必须学会自我排定优先级，并知道什么时候分享小块或进展，而不是等到最后。
随着时间的推移，通过SAFe实现成熟将有助于解决这些挑战和弊端。我们的下一个目标是帮助Scrum团队更好地预测他们可以实现的目标（故事点评估，敏捷说话），以及何时实现（速度管理）。
在我的同事Jason Freeth和Dave Jones的博客中（下周发表）可阅读有关我们安全考虑的更多信息。
有问题吗？或者类似经历？请在评论框中分享。
原创翻译，若有不妥敬请指正
