微软公司的开发过程
看完这组图解，你能讲清邹欣亲历的微软开发角色分工、协作机制与工程边界
按 空格/→ 演示下一步
全部页面点击任意一页，跳回舞台从这页播放
微软公司的开发过程
看完这组图解，你能讲清邹欣亲历的微软开发角色分工、协作机制与工程边界
邹欣是谁
上一页讲了微软的开发流程，但推动流程运转的核心是开发经理。邹欣正是这一角色的亲历者——在微软从工程师做到开发经理，回国后把经历写进《构建之法》。借她的眼睛，看清开发经理是什么。
个人技术不一定最强，负责战术决策与人员调配，把团队战力拧成一股绳
从学生到工程师的转变
邹欣从学生走进微软，自述像「蜕了一层皮」。这一页聚焦两个问题：微软招什么样的人？招进来后用什么机制把学生炼成能交付产品的工程师？
球探挑新秀不是看他现在能不能砍 50 分，而是三年后能不能成为球队核心
经理眼中的好工程师
学生变工程师，身份是换了，但「做得好」的标准也跟着变。微软经理眼里，看的不只是能不能写代码，而是会从几个互相咬合的维度打量一个工程师。
不是只看颠球（写代码），还看体能（工程化）、配合（协作）、硬仗愿不愿上（ownership）
Peopleware 理念
上一页我们讲了经理眼中的好工程师：技术扎实、主动沟通。但还有一层更深的问题——是谁把这些好工程师变成好工程师？答案藏在微软坚持了几十年的一个理念里：Peopleware。
园丁选种、备土、浇水、施肥——但每天拽叶子是拽不出花的；微软选对人、给资源、给信任，让人才自己长出来
微软 vs 其他公司
微软设三方角色、团队庞大、迭代以年计——其他公司精简得多。差异不是风格，是被规模逼出来的。
- PM/Dev/Test 三角色明确分工
- 单特性团队常 8 人以上协作
- 里程碑以「功能完成」为节点
- 员工先当内部用户（dogfood）
- Dev 常兼 QA，无专职 Test
- 团队小，两披萨原则 5–7 人
- 里程碑以「截止日期」为节点
- 直接面向外部用户发布试错
微软开发全景图
沿主流程从左往右读，虚线是开发与测试之间的快速反馈环。
Planning 规划阶段
规划阶段把模糊的需求逐步变成可执行的 Sprint 承诺。
Development 开发阶段
开发阶段三步走：测试驱动、结对编程、代码审查，把质量内建于每一行代码。
Testing 测试阶段
测试阶段四步走：自动测试打底、持续集成把关、Bug 全程跟踪、修完还要回归。
每日构建与冒烟测试
测试不是写完代码才开始。微软每晚让机器把全员最新代码编译一遍——这叫每日构建；紧接着跑一组最短路径测试——叫冒烟测试。这就是几千人代码库不乱的根本。
每天厨房先做几道招牌菜确认炉火/厨师/调料都OK，客人点餐前就拦住设备问题
Balsamiq Mockups 案例
前页讲了微软靠每日构建和冒烟测试守住质量。但 MVP 的另一面——「做最小可用版本、拿去给真实用户用」——要看一个真实案例才看得清。Balsamiq Mockups 是经典样本。
先只做坐的功能给邻居试，看坐着舒不舒服、提什么改的意见，再决定做整套家具
Release 发布阶段
从内部测试通过到全球用户上手，发布阶段按节奏分四步推进。
Post-mortem 复盘阶段
发布之后,团队坐下来复盘,把教训变成下一次的资本。
团队角色的演进
看主导权如何随阶段流转：粗箭头是接力赛，细箭头是协同流。
创新与技术的平衡
人会成长，代码也会成长——但代码的成长未必都对方向。每个版本微软都要回答：新功能和老代码，哪个先做？
灶台管道不维护，新菜越多上菜越慢，最终拖垮整个餐厅
自测检验
在微软开发过程中，「每日构建+冒烟测试」最核心的作用是什么？
核心要点回顾
- ✓流程闭环：五阶段环环相扣，每段都有硬产出
- ✓质量左移：每日构建+冒烟测试把 bug 拦在最便宜的时刻
- ✓人比流程重要：工程师成长与角色演进才是真正驱动力
- ✓平衡优于极端：创新与成熟技术、商业与工程的取舍智慧
- ✓复盘不追责：挖系统根因，让组织从失败中持续进化
课后思考
先合上书自己想一想，再对照参考答案，看看思路对不对路。
参考答案Post-mortem 把事故的过程、原因、改进措施写成可查阅的公开文档，逼团队面对具体事实而非模糊感受；经验总结往往停留在感受层面，下一次容易重蹈覆辙。
参考答案建议保留 Planning（划清边界）与 Post-mortem（沉淀教训）；Development 和 Testing 合并为每日集成；Release 流程简化，不必照搬大公司的文档厚度。
参考答案仍必要。CI/CD 解决自动化执行，每日构建解决「把集成做成团队纪律」。工具再自动化，也需要人来守住「每天必须集成」这条底线。