微软千人开发团队怎么用Scrum

Posted 2021-04-25 dotNET跨平台

微软VS团队结合Scrum敏捷开发和DevOps思维后，每2次Sprint（也就是6周）就会发布一个新版本本，如VS 2015每隔6周就会发布一个技术预览版本。

Visual Studio是微软最重要的核心开发工具，到去年10月止，全球.NET开发人员近6百万人，光是VS 2013年版本，下载次数就达到7百万次。参与VS开发的人数超过4,700人，分布在美国、瑞士、中国、印度等地的微软研发中心。这群人要负责190万个开发工作项目，完成了近3,600万个程序代码库，累计数据量达到15.3TB。开发团队平均每个月会组建（Build）22万多次。

早从2010年时，微软开发团队就开始运用开源软件，但是为了避免软件产品的程序代码有侵权风险，直到3年前，微软仍然严格禁止开发工程师接触开源程序代码，连看一下都不行。目前近2千人规模的Visual Studio（简称VS）开发团队，不论是谁，都得经过3道申请程序，上签到微软开发平台负责主管，也就是得到微软开发平台事业部全球资深副总裁潘正磊点头同意才行。

但在微软宣布拥抱开源，发布.NET核心程序代码之后，现在，微软反而鼓励工程师参与开源社区，任何工程师接触开源程序代码不需要获得任何形式的核准，除非要在自家产品内放入开源程序代码，甚至微软还开始积极招募擅长开源开发的人才。

从看一眼都不行，到现在要能和全球开源社区合作开发，微软并非一夕之间就有能力跨入开源。过去微软设计产品只需和内部沟通，现在得和社区合作。开源社区贡献的程序代码如何和套装产品整合，也需要新的流程。潘正磊表示，拥抱开源最需要的调整不是组织，而是要改变工作方法。

拥抱敏捷开发是微软迈向开源的关键一步

「过去，微软开发工作的安排可以是计划性，但是开源之后，无法预估多少人会有兴趣贡献程序代码。」潘正磊表示：「微软没有转型到敏捷开发，现在就不可能开源。因为无法提供合适的测试、适当的自动化、适当的持续整合机制来确保程序代码的正确性。」拥抱敏捷开发正是微软能够迈向开源的关键。早期微软采用瀑布式开发流程，不论哪一套产品的开发团队都有各自的瀑布式流程作法，每次要推出一个新版本本，往往需要2～3年的时间才能完成。

为了加快产品开发步调，2005年左右，微软开始在内部推广敏捷开发模式，2006年扩大训练Scrum能力，VS开发团队是率先推广Scrum的微软产品团队，VS也开始支持Scrum。不过，即使微软开始在内部推广Scrum，2005年后的3次Visual Studio改版本，从VS 2008、VS 2010到VS 2012，仍旧是每隔2～3年才会推出一次大改版本。

VS 2012推出后，产品发布策略大转变

直到2012年版本发布后，VS产品发布策略出现了大转变。潘正磊表示，微软做了一个重大决策，要让开发流程更加敏捷化，来加快产品交付周期。

VS 2012发布后，微软开始每隔2～4个月就发布一个更新版本本，不只修补问题，还会增加新功能。光是从VS 2012年发布后一年内，就推出了4次更新版本本，并且在2013年时还推出了VS 2013的全新改版本，从此，微软发布VS产品的步调有如搭上了顺风车，既有版本本每隔2～4个月可以发布一次更新，而还未上市的下一版本VS也能持续发布预览版本。

过去，微软盒装软件每3年才改版本一次的作法就像是发行百科全书一样，每次推出就是一整套，为了确保内容详细程度和正确性，需要订定长期计划、撰写大量内容和进行大量校对来确保每一页内容的正确性。
在微软旧式的瀑布式开发流程时期，微软会花3个月时间来订定长期计划，部门主管还订定5年产品计划，而产品经理则是要想象2年后的市场需求，来拟定2年后产品上市时的功能蓝图。

完成产品计划后，开发团队会将2年产品开发时间，预先订出多个要达成的阶段里程碑（Milestone），每一个里程碑会发布一个对应的测试版本。工程师们再依每一个里程碑估算自己的工作进度，并修正产品进度，来计算出2年后的哪一天能发布产品。

每一个里程碑阶段内还得设定程序代码开发完成的时间点（Code Complete），因为得预留时间作为测试工作和功能稳定调校，微软过去至少会预留两倍的程序代码开发所用的时间。多数情况是，微软工程师很快就完成程序代码的开发，反而是花了很多时间让功能稳定，例如整合不同功能间的冲突或整合。

微软在1995年时曾发生过盒装产品上市后因为致命问题而全球召回的窘况。为了避免再次发生这种微软称为召回等级的臭虫（Recall Class Bug），因为微软软件往往会发布到全球各国，支持多种语言甚至多种OS的版本，因此衍生了大量的测试工作。

在旧式开发阶段，微软得配备了大量测试人力，几乎和开发团队的人数规模相当。到了研发VS 2013版本时，潘正磊决定要改变VS团队开发产品的方式，导入DevOps思维，要让微软开发更加敏捷化。

潘正磊解释，为了因应互联网时代非常快速的产品功能交付需求，这是许多新创公司和大型云端服务业者如Google、Facebook等都采用了DevOps思维，将开发和维运一体化的作法，让「开发团队要直接为运维环境中的软件负责。」

而且更重要的是，潘正磊说，在DevOps中的Ops概念，不只是确保网站运作，让网站不会当机而已，而应该要「扩大Ops（维运）的概念，如何让用户顺利安装软件，也可以是运维的一环。」就算是盒装软件，只是产品提供的方式和网站服务不同，但一样可以套用维运的概念。

开发与测试的结合是落实DevOps的关键之一

如何实践DevOps流程的关键是开发工程师与测试工程师角色的结合，不再像过去开发团队工作完成了才交给测试团队接手，而是开发与测试工作合而为一，转变成持续测试、持续整合的开发模式。

因此，微软在开发组织分工上，也不再像过去分为产品管理、开发和测试等三大类职务，以及各自所形成的3种组织团队，而改将工程师区分成产品经理和工程师两种职务角色，同一项功能的架构设计、程序代码开发和测试工作都由同一个人或小组负责。

微软也改采功能团队（Feature Team）的团队工作方式，一个团队约12～18人，内有1～2个产品经理，搭配一群来自过去开发团队和测试团队的工程师，组成一个兼具开发与测试能力的小组，来负责产品中的一项重要功能，例如C#编译程序就由两个功能团队负责。

2年半前，微软甚至还改装总部的18号大楼，过去微软办公大楼是一条走廊贯穿，两侧许多小型办公室，人人都可以关起门来工作。但是，这栋大楼改装后，打破了旧有办公隔间，改成了团队办公室（Team Room）的较大空间隔间设计。同一团队的人都能在同一个开放办公室内工作，彼此都可以看到对方，听见其他人的谈话，随时站起来就可以面对面沟通，旁边再搭配几间小型空间，作为临时讨论或开会的场所，房间内还设有每天站立会议用的大型屏幕来呈现任务广告牌。这栋大楼大约进驻了1千名研发人员。因效果不错，后续3栋大楼的装修也都采取同样的设计。

不同于瀑布式开发流程，微软新开发流程聚焦于改变

敏捷开发流程结合了DevOps思维后，和传统瀑布式开发最大的不同点，潘正磊说，是聚焦于改变（Focus on Delta），瀑布式开发就像一次推出全套新百科全书似的大改版本作法，而DevOps思维更像是快速进行大量的小改版本，一次只更新一个章节、甚至只是其中的某一页。
这也是和微软过去截然不同的产品生产流程，新作法是聚焦于不断缩短产品生产周期，来加快交付速度。「因为这是未来的互联网公司所必备的能力。」潘正磊说。

因此，在产品开发周期上，潘正磊也要求，所有VS开发团队，不论是盒装软件版本或是VS Online云端服务的研发团队，都统一改采每3周完成一个Sprint（冲刺阶段）作法，不再像过去那样采取开发里程碑分阶段的作法。

微软也不再制订产品的5年计划了，而是缩短为只订定每6个月的计划，也就是两季长的计划，并每6个月进行市场或竞争对手评估，让产品能因应市场最新变化。另外还会订定一个18个月后要实现的产品愿景，来规划如软件架构调整或本质性需求调整等需要较长时间作业的目标。

Sprint是Scrum敏捷开发中一个计算开发周期的方式，每个Sprint就是一个包括开发、测试到发布软件的完整过程，微软等于每3周就会发布1个新的小版本，并在内部试用一周后就对外发布供外界试用，而不像过去得等到一个里程碑达成后才会发布一个新版本本软件。在每一个Sprint开始第一周的第一天，每一个功能团队都要完成Sprint计划，并于第三周结束时发布产品成果。

不过，依据开发产品不同，发布给外部试用者的时程也略有不同。例如开发Visual Studio Online的新功能就是每一个Sprint完成后就发布到云端让使用者试用，而开发VS IDE版本的团队则是每2个Sprint发布一次技术预览版本。

Scrum模式的开发团队规模不大，原有上千人的大型团队重组成很多个小型功能团队后，潘正磊表示，跨团队持续保持联系相当重要。所以，每个团队的PM在每一个Sprint开始时，要发出一封Sprint启动邮件，将这一次的Sprint计划描述，如任务目标，这次要完成的用户情境（User Story）寄给其他团队或直属主管。Sprint结束时也同样要发信将开发完成的项目告诉其他人，还要录制一段操作新功能的示范影片，来展示已经完成的成果确实可用。

管理整个部门的潘正磊则是依重要性来选择要密切关注的功能团队，每3个星期审视一次，例如她最近最常关注的则是负责.NET开源计划的团队。其他功能团队则是每隔3个Sprint亲自和团队成员聊聊。

从臭虫数量变化检验是否落实Sprint

微软VS团队全面导入敏捷开发流程后，潘正磊经常被质疑的问题是，你们做的是真的Sprint吗？因为有不少软件公司在高层要求下，尽管开发团队导入了敏捷开发，产品发布周期从一年一次缩短到每季发布一次，但其实只是将原来的1年期瀑布式开发流程，缩短为3个月的瀑布式开发流程，而不是真正的敏捷化。

潘正磊检验Sprint是否落实的方法是从程序臭虫（Bug）数量的变化来观察。倘若程序臭虫的数量会在程序代码开发结束展开测试之后迅速暴增，再随着功能稳定修正后再大幅减少。臭虫数量大起大落的数据变化，代表了这只是压缩版本瀑布式开发。若真有落实Sprint，因为要确保所开发出来的产品是处于随时可用的状态，若出现了任何臭虫，开发团队会实时修复和更新，臭虫数量就不会出现大起大落的变化曲线。

用用户真实数据来引导开发计划

另一个与瀑布式开发截然不同的新思维是正视真实数据的重要性，潘正磊说：「数据是落实DevOps思维的另一个核心关键，在线环境中产生的数据才是真正有说服力的数据，要用这样的数据来引导所有的开发计划和流程，而不是测试环境中假想的用户环境。」现在微软每个功能团队发布试用版本后，会关注有多少用户开始使用新功能，若使用人数低于预期，就要找出原因，并解决下一版本要如何改善来提高使用量等问题。
例如VS团队有次开发了一套结合html 5和javascript来开发移动应用的套件，发布预览版本后，产品经理追踪实际使用数据后才发现，过半数有意下载者所用的操作系统是Windows 7环境，而这个预览版本只支持Windows 8.1。因此，很多使用者连安装都出问题而无法使用。负责开发的团队看到这个数据后便决定改变下一个预览版本的开发计划，先增加对Windows 7环境的支持。

或是几个月前，IE浏览器内负责执行JavaScript的Runtime是由VS团队负责开发。两组功能团队为了某一个Runtime优化作法该不该做而争执不休，过去，微软是由资深主管出面调解摆平，但这样往往影响了团队间的合作默契，现在则是靠数据来判断。这两个团队后来开发了一支爬虫程序，搜集全球500大网站常用的JavaScript类库发布，发现有40％的网站能够得益于这种优化方式，就不再争论该不该这么做而是直接就这么做了。

善用用户真实数据还有另一个好处。有时并非新功能不受用户青睐，而是因为其他非软件因素，导致用户无法进入新功能的使用情境，连试用的机会都没有。

「团队要真正注重于用户的需求和实际体验。」潘正磊说。所以，每个月，她都会找一天，用一个下午的时间，亲自从使用者情境的角度来试用新版本功能。甚至，她也要求旗下VS开发人员，要用这一周编译组建完成的Visual Studio IDE来开发下一周的新功能，等到6周后发布IDE时，至少微软内部人员已经先试用了好几个礼拜，这是微软的Dogfooding作法（吃自家狗食）。

相较于过去瀑布式开发，就算取得用户的真实使用数据，也得等到3年后的改版本才能解决问题，潘正磊认为，开发团队现在要能够拿到数据，马上响应，再马上发布，这就是一个DevOps开发的循环，「现在是速度决胜！」。

尽管微软VS团队已经能够做到3周发布一次VS Online新版本本，6周发布一次VS IDE软件新版本本，但是，潘正磊仍不满足，她说，我们只是从一本大百科全书，进展到快速发布，每次发布一本小书，距离能够一次发布一个章节，甚至是只有更新1页的颗粒度（Granularity），还有很长一段路。这也是微软VS团队下一步敏捷开发要实现的目标。


微软开发平台事业部全球资深副总裁潘正磊决定从VS 2012版本，要让开发流程更加敏捷化，来加快产品交付周期，因此决定全面改变微软研发软件的流程。


为了和其他敏捷团队保持联系，团队PM在每次Sprint启动的第一天要寄出Sprint计划邮件给其他团队或直属主管，结束时也要发信通知大家，并录制一段成果示范影片来证明程序代码真的可用。


微软新旧开发模式大比较（瀑布式开发vs.敏捷开发）

微软现在所有Visual Studio开发团队，不论是盒装软件版本本或是VS Online云端服务的研发团队，都统一导入Scrum敏捷开发，采每3周完成一个Sprint（冲刺阶段）作法，不再像过去的瀑布式开发流程时期，采取开发里程碑分阶段的作法。

微软旧有瀑布式开发流程

微软过去采用瀑布式开发流程，VS产品开发时程约2年，先用3个月想象2年后的可能需求，再设定多个里程碑（如图M1、M2）区分开发阶段，每阶段内先开发程序代码，再进行测试与功能稳定，达成里程碑后发布一个顾客可用的版本。

微软现有敏捷开发流程

现在微软以每3周为1个Scrum敏捷开发的Sprint（冲刺）周期，每次Sprint结束后要发布一个VS版本本，试用1周后就发布给使用者。程序架构设计、开发与测试都由同一个人或同一组人负责。

瀑布式开发的Bug曲线大起大落

图中虚线代表程序臭虫（Bug）数量的变化，在微软旧有的瀑布式开发时期，臭虫数量在测试开始后大量出现，得等到臭虫修复后功能稳定后，臭虫数量变化大幅减少后，才能发布一个版本本给使用者。

敏捷开发的Bug曲线起伏不大
蓝色虚线代表了微软VS团队改采3周一个Sprint后的程序臭虫数量变化。若发现了新的程序缺陷，开发团队可以很快修复，臭虫曲线变化不大，代表程序代码质量更稳定。白色虚线是瀑布式开发的臭虫曲线。

为了和其他敏捷团队保持联系，团队PM在每次Sprint启动的第一天要寄出Sprint计划邮件给其他团队或直属主管，结束时也要发信通知大家，并录制一段成果示范视频来证明程序代码真的可用。

---

3. 欢迎扫描我们的二维码（长按下面的二维码图片、并选择识别图中的二维码）