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

2020-03-01 251浏览

  • 1.软件工程在微软的演化 邹欣 2019/6 （内容仅仅代表个人看法）
  • 2.
  • 3.邹欣 – 介绍 • 现任微软亚洲研究院首席研发经理。 负责新型 AI 平台的研发和 AI 推广工 作。 • 25年微软研发工作经历，参与了 Outlook, Visual Studio, 必应搜索, Windows “小娜” 智能助手的研发。 在研究院期间，领导了“人立方”、人 脸识别技术 FaceSDK、大数据挖掘、 学术搜索等创新项目。 • 技术专著： 《移山之道》、《编程 之美》《构建之法》 • 软件工程教育社区http://edu.cnblogs.com
  • 4.软件工程在微软的演化 – 传说和个人经历 • 程序 = 算法 + 数据结构 • 软件 = 程序 + 软件工程 • 企业 = 软件 + 商业模式 世界前五的公司： • 1988 • 1998 • 2008 • 2018 它是怎么做软件的？ • 理念，工具，流程，文化 • 如何演化的？
  • 5.摘要 微软公司的软件开发流程在过去的40年中经历了哪些变化？ • 创业小公司 • 快速发展的公司 / 成熟的大公司 • 大公司 Refresh 工具、流程、角色、文化, 有哪些经验和教训？ 这些经验教训对于其他团队有什么价值？ • 哪些是暂时的对策，哪些是长期有效的核心原则 • 我们能有什么借鉴？
  • 6.
  • 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微信公众账号 关注大会微信公共账号，及时了解大会动态、 日程及每日更新的案例！ 关注公众号获得 更多案例实践