微软 邹欣 软件工程在微软的演化

CodeWarrior

2019/07/08 发布于 编程 分类

GIAC2019 

文字内容
1. 软件工程在微软的演化 邹欣 2019/6 (内容仅仅代表个人看法)
3. 邹欣 – 介绍 • 现任微软亚洲研究院首席研发经理。 负责新型 AI 平台的研发和 AI 推广工 作。 • 25年微软研发工作经历,参与了 Outlook, Visual Studio, 必应搜索, Windows “小娜” 智能助手的研发。 在研究院期间,领导了“人立方”、人 脸识别技术 FaceSDK、大数据挖掘、 学术搜索等创新项目。 • 技术专著: 《移山之道》、《编程 之美》《构建之法》 • 软件工程教育社区 http://edu.cnblogs.com
4. 软件工程在微软的演化 – 传说和个人经历 • 程序 = 算法 + 数据结构 • 软件 = 程序 + 软件工程 • 企业 = 软件 + 商业模式 世界前五的公司: • 1988 • 1998 • 2008 • 2018 它是怎么做软件的? • 理念,工具,流程,文化 • 如何演化的?
5. 摘要 微软公司的软件开发流程在过去的40年中经历了哪些变化? • 创业小公司 • 快速发展的公司 / 成熟的大公司 • 大公司 Refresh 工具、流程、角色、文化, 有哪些经验和教训? 这些经验教训对于其他团队有什么价值? • 哪些是暂时的对策,哪些是长期有效的核心原则 • 我们能有什么借鉴?
7. 开发模式:牛仔 • Cowboy Style (牛仔风格) • 个人能力 • 努力工作 • 动手实践 • 依靠个人能力
8. • 时间紧: • 睡在机房里面 • 任务重,无实体机器: • 分工:Paul 写模拟 器, Bill 在模拟器 上写Basic 的解释器 • 突发情况:发现没有 写解释器loader • 在飞机降落的过程 中写出来 • 结果: • 第一次在实体机 器上演示就成功 如何克服困难?
9. 1978年的源代码 • 6955 lines, • 161,685 bytes • This is currently the oldest publicly available piece of source written by Bill Gates. • Like the 8080 version, the 6502 version was developed on a PDP-10, using the MACRO-10 assembler.
10. 一个员工对BillG 说 : 俺上午10点钟来上班,晚 上10点才离开。累… BillG 的回答是: a) 同志们辛苦了! b) 洗洗睡了吧! c) 你不是一个人在战 斗… d) 怎么搞的,只工作了 半天? 有奖竞猜
11. 创业风格 • 理念: • 创业,Albuquerque • 工具: • 自己动手做 • 角色: • 一人扮演多个角色 • 流程: • 目标导向 • 文化: • You‘ve got to drive hard
12. 最初的项目管理工具 • 记事本 (Notepad),白板 • Excel • 项目总经理亲自写脚本收集数据,生成进度图 • 优点 • 容易上手,自己做工具解决问题 • 各级领导对项目进度非常了解 • 问题: • 不能记录历史 • 对于大型团队的扩展有困难 • 分享和多人编辑有问题
13. 快速成长的公司 Vision: • A computer on every desk and in every home.
14. 成熟公司 专用系统 Raid – 杀虫剂 SQL DB + PC 客户端 bug:增删改查
15. Raid • 典型的 client/server 结构 • 所有的记录都是 “bug” - 创建,编辑,查询 • Bug 的字段 (field) • Title/priority/severity/assigned to • 特定的 “issue type” • Bug, suggestion,localization issue, performance • 不同的问题有不同的工作流 • 提供数据接口, 可以下载数据到 Excel 等做可视化和历史分析 • Raid 成为微软文化的一部分: “raid me a bug”. • 管理了 windows 95/2000, office 97 项目的开发,数据库记录达到百万级
16. Outlook 团队新 DEV手册 • 项目目的是什么? • 机器设置 • 构建代码运行 • 吃 “狗食” • 源代码控制 • 核心技术介绍 • 如何 debug • 如何和PM / Test 打交道 • 在微软如何成功? • 人员-负责领域
17. 用 BBS 管理项目? • 我们平时就在BBS 上活动,能否也用BBS 来管理软件开发呢? • Outlook 98: • 相关的团队成员开一个帖子管理一个功能 • 同时测试 Exchange 服务器的BBS 功能 • 可以快速定义各种表单,快速分享 • 非常清楚的角色和责任 • 问题: • 没有历史记录 • 不能做结构化的查询 • 就像今天的 SharePoint,校园BBS • 经验:让团队决定自己的项目管理方式
18. 为啥不能用 MS Project 来 管理软件项目的开发? 非常好的顶层计划工具 • 巨大的甘特图挂满了 走廊 MS Project 问题 • 如何分享? • 它假设所有人完成了 一个任务,才开始下 一个任务 • 无法管理复杂的依赖 关系 • 如何管理任务的历史? 当任务转给另一个同 事,历史如何转过去? • 怎样显示整个团队的 状态?
19. Product Studio – 升级版的Raid • Raid 的升级版本 • 支持更多类型 • bugs/TestCases/TestResults. • 甚至包括任务管理
20. TFS - 最全面的团队项 目管理工具 • 全面 – 可以处理各种类型的工作,可以扩展 • 灵活 • 5 ~ 2000 团队 • 支持不同的流程 (MSF Agile, CMMI) • 和各种工具集成 • Work item tracking / source control / build / reporting • Web 界面 • API 支持插件和第三方客户端 缺点: • 对于绝大多数团队来说太复杂
21. • 大部分项目用 TFS 来管 理 • 人员: 30,000 • 源代码: 100G • 地点: 六个不同的时 区 • 每周内部发布 TFS 最复杂的项目: Win10
22. 团队的角色 – 在实践中演化
23. PM 的角色来历 • 随着团队变大,交流变得复杂 • O(n^2) • 软件需求更加复杂 • Charles Simonyi 有一个想法
24. 繁忙的工程师 • 软件越来越复杂 • 程序员没有时间和精力来让软件更可用,更好用。 • 程序员不能把市场部门吹的牛变成准确的功能定义 • 产品的设计牵涉很多代码之外的工作: • • • • 和各种客户交流 各种可用性测试 分析竞品 考虑如何改进流程 • 大多数程序员没有时间/精力/能力/兴趣做这些事情。
25. 最初的想法 • 把程序员分两种: • 编程大师(Master) vs. 编程奴隶 (Slave) • 大师 • 和客户交流, 写spec,设计文档 • 奴隶 • 实现spec • 但是没有人想当奴隶…
26. Program Manager 的角色 • 第一次定义了 PM 的角色 • • • • 收集需求 写spec,设计界面 协调开发/测试/本地化/市场推广/… 带领团队达成决定 • PM: 关注整体,时间/资源/功能的平衡 • Dev/test/etc: 关注于具体的技术问题 Jabe Blumenthal
27. 管人的 vs. 管事的 Proj. Manager (管人) 带领下属做好一个项目 Prog. Manager (管事) 和同伴一起做一个功能 一个老大对全局负责 很多 PM 负责各个方面 有最终决定权 和别人一起达成一致意见 也管人 只管事情。 迫使PM 写高质量的Spec 来说 服同事
28. 文化 Death March ZBB • 在产品稳定阶段 • 把所有bug 降到 0 • 周末是平的线段, 表 示周末不用来上班 • 平时965 • 每周有一天是必须达 到目标
29. 成熟的大公司 • 工具: • 不断演进的内部工具 • 为何不用商用的开发工具? 代码量太庞大,那些工具 都崩溃了。 • 角色: • 各司其职,平等合作 • PM 驱动,不出大错,在 V3 超过对手 • 流程: • 严格的流程,18个月的发布周期可以精确到天 • Postmortem 项目总结和增量改进 • 文化: • 强调内部协作,内部同步,内部测试
30. 方法论 MSF • 1. 推动信息共享与沟通(Foster open communications) • 2. 为共同的远景而工作(Work toward a shared vision) • 3. 充分授权和信任(Empower team members) • 4. 各司其职,对项目共同负责(Establish clear accountability and shared responsibility) • 5. 交付增量的价值(Deliver incremental value) • 6. 保持敏捷,预期和适应变化(Stay agile, expect and adapt change) • 7. 投资质量(Invest in quality) • 8. 学习所有的经验(Learn from all experiences) • 9. 与顾客合作(Partner with internal and external customers)
31. MSF:充分授权和信任 • 平等协作—成员之间、团队之间是平等协作的关系 • 充分授权给团队和成员 • 所有的成员都应该能得到充分的授权,他们有权在职权范围内按照自己的 承诺完成任务 • MSF提倡自下而上的计划,每个人有充分的权力估计并决定自己的任务需 要多长时间,而不是上级交给的时间,这意味着让真正做这件事的人按照 自己的估计去完成任务。
32. Postmortem 尸体解剖 项目回顾 • 尸体解剖: • 哪里做得好? • 哪里做得不好? • 如何改进? • 团队大领导回避 • 团队成员投票决定改 进的计划
33. • 由下而上的总结和反馈。 • 项目结束后,全体员工讨论,计划/设计/实现/测 试/发布 阶段, 如果你可以重新来过,什么方面 可以做得更好?“ • 在问 “为什么” 的时候, 要多问几次, 找到问题的根 源。软件发布后用户报告了一个大问题。 每个里程 碑都执行 • ”为什么?" • 因为程序没有考虑某种边界条件. • "为什么在测试阶段没有测试出来?" • 因为这个代码是测试的最后阶段才加进去 的。 • “为什么不通知PM/Test?” • 因为dev 认为没有问题的, 很简单的修改。 • "为什么不通知别人?" • 因为dev 认为那些都是软件工程无聊的规定... dev 是大牛人, 不必遵守的。 • “为什么?!”
34. 方法论 – CMM & 六西格玛 • MSF & CMM • 我们要用软件成熟度模型来衡量并改进软件工程流程么? • MSF & Six Sigma (六西格玛) • Six Sigma = 99.99966% 的时候没有出现问题。 • 一百万行代码中只有 3.4 行是有bug 的 • 我们应该把软件开发等同于硬件生成么?或者是艺术设计? • MVP: Minimum Viable Product 最小可用产品 • MBP: Maximum Beautiful Product 最大最美产品 • 微软的经验: • 招到最优秀的人,让他们决定。 Keep It Simple
35. 成熟大公司 创新者的窘境 • 成功公司的两难 • 如果公司不断满足已有用户需求,则产品在趋于 饱和的市场缓慢发展,在产品的生命周期结束后, 不免会被新的颠覆性创新淘汰; • 如果公司主动寻找颠覆性创新,则遭到公司内部 流程、价值观和文化的排斥。 • 现实 • 成功的企业要满足股东们巨大的期望值,不敢冒 险
36. Table PC • 2001: MS Tablet PC • … • 2010: Apple’s iPad • ! • 2012: MS Surface
37. 手环 • 2003: MS announced SPOT watch • … • 2013: many new watches and wearables
38. 大公司 – Hit Refresh
39. 流程的改进 • 持续集成,收集数据,持续改进 • 必应团队: • 在真实的环境中实验新的功能, • 同时跟踪数据,考察不同设计的效果。 A/B Test A/B 测试
40. 流程的改进:逐级发布 - Daily Build & Test: Canary (金丝雀版本) - 取决于质量, 把版本推送到 - 部门/全公司 - Windows-Insiders
41. 角色的变化:Test / QA • 软件测试(Test): 运用一定的流程和工具,验证软件能实 现预先设计的功能和特性,工作的流程和结果通常是可量化 的。例如,测试用例、Bug、代码覆盖率、MTTF、软件效能 的参数, 等等。正因为流程和结果是明确定义的、可量化的, 所以很多测试工作可以自动化。 • 软件质量保障工作(Quality Assurance): 软件团队为了让软 件达到事先定义的质量标准而进行的所有活动,包括测试工 作。
42. 角色:逐渐取消了专职测试? • 所有团队: 开发人员负责单元测试并有覆盖率的要求 • Bing/Azure 等团队: • 大数据,分布式系统,AI 的功能:要求高质量的程序来进行测试,而不是手工测试。 • Windows 等团队: • 从用户数据分析程序问题,数据驱动,用户驱动。 • 很多数据工程师打造了全面覆盖的工程系统,收集/分析/展现数据 • 用户界面和场景测试? • 由项目的PM 来负责,dogfood,以及用户反馈 • 利益的冲突? • 不要考验人性。重要的事情要有独立测试。
43. 谁来保证质量? 开发 单元测 试 开发 模块测 试 集成测 试 自动测试工具 dogfood Beta 测 试 产品问 题收集 PM/运维 数据收集平台
44. 开源:新做法 • 和用户社区有紧密的联系,要发布的功能都事先通气 • 在公司内部采用了Stack Overflow 企业版,大家在内部的Stack Overflow 进 行技术交流 • TFS 也和Git 无缝集成,微软的默认源代码管理工具采用了Git 为了让Git 能 处理 庞大的代码库,TFS 团队还进行了几次技术改造,并且把这个项目开 源共享。 • 为何用开源? • 工业界的水平赶上来了,而且很多地方领先 • 用内部的工具,有培训/维护/职业发展的成本 • 什么才是我们公司的核心竞争力?一套内部的工具?
45. 文化:人员流动 • 以前:要领导同意,才能去别的组面试 • 现在:自行面试,决定调动时告知原来小组即可 • 自组织的团队: 每个大的里程碑结束后,所有的团队成员都可以自己选择下 一个项目 • 这时候,项目的领头人,通常是研发组长和PM,就要一起极力向大家兜售自己 项目 的意义,声称在他们领导下的团队将是多么有意思,等等。 • 数据显示,八成的团队成员会留在原来的团队,二成换组。 • 这对于团队技能的持续性、开拓新机会、带来新鲜血液, 都是很好的平衡。
46. 方法和工具 • 很多你以前认为独到 的方法和工具,现在 都是基本要求了,这 个时候是否让它们变 成生态系统公开的一 部分? • 地位也在变化
47. 成熟公司 - Refresh • 工具: • 拥抱开源工具,内部工具开源, 改进Git • 角色: • 取消专职Test,出现DevOps • 流程: • Agile, SCRUM, 社区驱动,用户驱动, 直接让用户反馈 (Windows Insider) • 文化: • 强调理解用户,解决用户的问题 • 自主性:员工能自己决定工作的部分内容 • 精通:在某个重要的领域做到最好 • 使命:工作有挑战性,工作的结果有意义
48. 总结 & 讨论 • 工具: • 从专用的内部工具到和开源社区紧密结合 (VS Code) • 角色 • PM 在业界第一次出现 • 手工的测试角色 (Test) 的出现和消失 • 设计在某些团队成为驱动的角色 • 文化 • 以结果为导向,努力工作 • 吃自己的狗食 • 让团队做决定 • 事后诸葛亮会议, 不断增量改进 • 尊重个人,发挥个人的能动性
49. Cargo Cult 货船崇拜 • 二战时美军在太平洋某个小岛修 建了机场, 岛上的土著们看到士兵头戴钢盔,身背步话机, 嘴里不停地叽里咕噜。 然后,神奇的大鸟从 天而降,士兵们从鸟肚子里拉出一箱箱货物, 土著们也偶尔能 分到一些口香糖、香烟等新 鲜玩意。 • 美军走了,怎么办? • 货船崇拜(Cargo Cult),就是试图以形似而神 不似的努力, 去期望奇迹的发生。
50. 避免 “形似而神不似” • 什么样的条件能导致装 满货物的飞机降落到一个小岛上? • 这个事情发生的本质原因是什么? 是用椰子壳 做的头盔么?如果把头盔换 成正牌的美军头盔,“ 飞机到来”的成功率会增加么? • 做好软件项目,离不开人、技术、工具和方法。什么是软件开发的本质? • 文盲戴上度数合适的眼镜,就能识字么?“识字”的本质是什么? • 团队A 用简单的看板方法,把写有任务内容的小贴纸贴在墙上;团队B 用大 型项 目管理软件,把任务状态存储在数据库中, 并通过算法画出任务变化 的曲线。仅此区别,能推导出这两个团队的成功率的区别么?
51. 工程师文化的演化 • 以前: • 个人英雄主义 • Ownership – 这是我做的功能! • Ownership – 这是我们团队发明的轮子! • 工程师导向:我做了这个高技术的功能,你们快来用吧! • (Windows Vista File System) • 现在: • 同理心,协作 • 有用户数据支持这样的设计么? • 你做了什么去帮助别人成功? • 你从别人那里借鉴了什么?
52. 不同类型的构建 “Building” • Build To Learn: • 开发软件,构建系统的目的是做进一步的试验,试图发现客观规律或某个试验方法的优点 与缺点。这些项目经常是科研论文的基础工作。 • Build To Show: • 为了突出地展现某个技术的作用,开发一些演示为目的的软件,这些项目很吸引眼球,经 常获得新闻报道,但是功能未必全面或实用。 • Build To Serve: • 为了服务一定范围的目标用户而构建的工具等,有时以公开的SDK 形式发布,让别的研发 人员使用。 • Build To Win: • 以在市场上赢得用户为目标而构建的软件。这也是种种科学发现,技术突破最好的试金石 。所有以营利为目的的公司和团队都在为此努力。
53. (a) Build to Learn (b) Build to Show (c) Build to Serve (d) Build to Win
54. • You’ve got to drive hard • Empathy – understand our users
55. 欢迎关注msup微信公众账号 关注大会微信公共账号,及时了解大会动态、 日程及每日更新的案例! 关注公众号获得 更多案例实践