传统行业做数字转型，项目实施乃至组织架构的敏捷化转型是其中重要的一环。敏捷开发的流程主要来自软件开发，但同样适用于其它行业和应用的项目推进与实施。

微软作为“传统”软件行业巨头，近些年同样进行了敏捷文化的构建，成功在科技互联网巨头公司的激烈竞争中再次站稳脚跟。我们来看看微软是如何实践敏捷开发的一系列原则，将其应用在团队管理、人员职责、项目计划和工作流程中。

本文主要参考 Aaron Bjork 发表在微软 DevOps 文档中的 “Agile principles in practice”，有兴趣的读者可以在文末参考文献中找到。

敏捷前 vs 敏捷后

直观起见，我们先看看在工作流程中实践敏捷开发的原则之后微软开发团队的转变：

敏捷前 敏捷后
4-6个月的里程碑 3星期的快速迭代
横向团队 垂直团队
个人办公室 团队办公空间
长计划周期 持续规划学习
产品经理，开发，测试 产品经理和工程团队
年度用户调查 持续用户反馈
功能代码分支 统一代码仓库
20+人的小组 8-12人的小组
保密的路线图 公开分享的路线图
Bug 技术债 零技术栈
100页的参数文档 PPT的参数页
私有代码和资料仓库 内部开源
极深的组织层级 平面的组织层级
由用户数决定KPI 由用户满意度决定KPI
年度功能更新 快速迭代功能更新

关键的改变

为了使开发和交付更加健康有效率，微软的开发团队做出了以下四个重要的改变。

文化改变

“文化用策略来作为早餐。” - Peter Drucker

微软团队发现，激励员工的关键因素是自主性，掌控权和目标。微软在实践中过程中尽力将这些因素传递给他们的员工，使所有人对手头的工作充满使命感。

这其中有两件事情微软非常看重：共识和自主。

  • 共识：从上而下的过程，使员工清楚我们所做的事情与商业目标和愿景的关系，以及背后的主要原因。

  • 自主：从下而上的过程，保证员工每天的工作和决定都充满意义和有影响力。

共识和自主之间有一个微妙的平衡。太多的共识会限制员工的自由度，员工会觉得一切需要照本宣科，这会产生负面的公司文化；太多的自主性会导致结构和方向的迷失，产生很多低效率的决策和计划。

团队改变

微软在 DevOps 中更考虑团队而不是个人。员工和小组主要被分为两类：产品经理和开发者。

  • 产品经理：负责定义做什么和解释为什么要做
  • 开发者：负责如何做以及确保做得好

团队特性

  • 不同背景不同技能的成员
  • 10-12人
  • 自我管理
  • 未来12-18个月的清晰规章和目标
  • 团队公用办公空间
  • 负责开发功能特性
  • 负责部署功能特性

团队组成

敏捷转型之前团队是横向的，所有人可能全部负责用户界面，或者全部负责数据，或者全部负责 API。 敏捷转型后团队对产品中所负责功能部分有端到端的掌控权，这个部分可能是用户界面和数据、API等功能的混合。在特定层级中有严格的规范，保证产品在不同团队中有一致性。

团队自组织

每过大约18个月，开发者可以重新选择自己对哪一个项目更有兴趣，想在接下来的一段时间参与哪一个项目的开发工作。这可以保证团队的自主性，让成员自己决定想要做的事情，也帮助组织重新规划、重建共识。

大约80%的成员会选择继续在现有的项目中工作，但这会继续激励成员因为这是自主选择的结果。

透明而负责

每一次快速迭代之后，每个小组会总结一封邮件，简述前一个迭代期的交付结果和后一个迭代期的开发计划。

计划和学习的改变

“计划本身不重要，但做计划很重要。” - Dwight Eisenhower

微软团队的计划分解为下面的阶段：

  • 快速迭代（3个星期）
  • 短期计划（3次快速迭代）
  • 季度总结（6个月）
  • 策略总结（12个月）

开发者和团队主要负责快速迭代和短期计划，而管理层则主要负责季度和策略总结。

这样的结构可以帮助组织在计划时有最大化学习能力。我们可以快速反馈、部署、找到用户痛点，然后快速有效地实施和产出。

保持产品健康的新方法

在敏捷转型之前，所有出现的问题会一直积累，直到整个项目阶段结束，这时候才寻找问题，解决问题，然后重复这个过程。这会对团队产生不良的影响，因为团队可能需要一段很长的时间来一个个处理问题而不是去开发新鲜有趣的新功能。

微软团队定义了一个“问题上限”的概念。问题上限定义为

  • 开发成员人数 x 5 = 问题上限

如果团队开发中的问题数目超过了问题上限，团队成员就会停止开发新功能而去解决问题，直到问题数目降低到了问题上限以下。这是一种一边开发一边还 bug 技术债的方式。

摒除干扰

团队一般会自我组织来保持专注度，摒除外界的干扰。一般每一次快速迭代团队会分为两个小组；一组专注于开发新功能，另一组负责比如用户沟通、解决反馈问题、出差等外界干扰。两个小组的成员在迭代中不断轮换，使成员也可以更方便计划自己工作以外的活动。

总结四个重点

  1. 认真对待敏捷转型，但也不要循规蹈矩。敏捷的原则有时候会太过严苛，所以敏捷转型的过程要更加灵活，让敏捷的概念慢慢在员工理念和公司文化中开花。
  2. 不要过分专注于过程而一定要坚持结果导向。写过的大量代码和漂亮的 PPT 都不能掩盖最终项目的部署结果。
  3. 项目提交是无法作弊的。只有在每次项目的快速迭代周期之后我们才能对接下来的工作有清晰的认知。快速迭代开发、提交、反馈可以带来一个良好的节奏。
  4. 建立想要的组织文化，才能得到想要的员工表现。

Reference

Agile principles in practice, Aaron Bjork, https://docs.microsoft.com/en-in/azure/devops/learn/devops-at-microsoft/agile-principles-in-practice