研发过程对比---读《微软的秘密》有感

   2010年在成都三官堂买的《微软的秘密》，这两年陆陆续续看了几次。如同《走出软件作坊》的作者阿朱说的一样，每看一次都有一些感想。这本书写的是微软90年代及其之前的开发经验，但是对我们当前的开发来说，仍然有很多值得汲取的经验。当今各种敏捷、scrum开发方法大行其道，可从本质上来说，也是对软件工程管理的改进，希望能够及时、快速的交付更好的软件产品。

    书中多次谈到如何决定产品的优先级。当产品面对非常多特性的时候，我们究竟是要全部完成还是只完成一部分。从scrum开发来说，解决方案非常明确的。我们每个月甚至每两周收集项目的需求，然后对需求做综合的评价，决定未来一个月需要完成那些特性或者项目。如果我们把不重要、或者把当前紧急的项目给搁下了，事后上峰review项目进展的事后，肯定会追究责任的。不过这种优先级排定也有弊端，比如一些可以改进用户体验，但是不重要的事情，很难排上日程。这也是大网站某些时候用户体验改善慢的原因。
    scrum开发方式，scrum master是一个强调沟通的工作。需要和组员沟通工作、检查进度、发现问题；和测试协调资源；和产品经理沟通需求，组织需求PK会；和项目相关的团队讨论各种需求。

    在微软，也强调建立学习型组织，讲究在工作过程中带领新人。通过“午餐会、休假会、转岗”等到方式促进团队的学习和交流。而我们有明确的师兄带领徒弟的工作。我们会组织各种分享、讲座分享经验。我们甚至有内部的技术大学、讲师来传递知识。在这一点上，我们比微软走的更远。

    在微软，提到一个合适的软件交付日期是有用。因为有一个截止日期，会强迫大家对工作设置优先级，对不重要的需求可以先砍掉再说。我们在这方面有一定的经验，但是项目的延期明显很多。都说是通过一线开发对开发时间的承诺来保证项目完成的日期，然后各种资源依赖、技术困难导致我们项目的延期。

    在微软强调项目的事后分析，强调自我批评和总结经验。同时，有专门的人员总结好的经验，并且主动建议到新的团队。我们公司也有流程管理人员，貌似也有对经验的总结。目前来看，一是推广scrum开发，另外一种是推广单元测试。还有是推广各种管理工具如web编译平台、项目周报和发布管理，还有bug管理、账号申请等到。 这些都不错，就是很少推荐其他团队好的经验过来。好的经验、方法，是我们更需要的，而不是增加更多流程、更多的检查点。 我们团队自己也做项目总结或者月度总结。每次总结有点、不足和调整，为了防止大家不好意思开口，还让大家先写在纸上，汇总之后再讨论。最有建设性的意见是整理代码规范，脚本的模板，整理了一批shell常用的函数。最后我发现，时间和资源的矛盾会经常出现。

    在微软强调code review，我们同样重视。不过强调的是两个dev，一个test，3个人一起review，甚至要求架构师或者专家一起review代码。代码review，通过会反馈很多问题。甚至少了一行注释，少了一个空格之类，非常严格。经过了code review，最大的感触是觉得自己有很多的不足，还有很多需要改进。
    曾经通过会议review代码，这种方式效率非常低下。首先很多人不清楚项目背景，需要先讲清楚背景，说明实现的基本原理，最后才是真正的看代码。由于多数人没有做准备，这种review是一个马拉松式的折腾。从经验来看，最好是完成一个模块就做一下review，而不是项目完全完成之后再做。
   

    在测试阶段，我们强调上线手册清晰、完整、有效，要求有code review的结果，绝对不能有“版本验证错误（bvt bug）”，也就是不能安装运行的情况。不过很难有完整的测试文档，估计这是因为互联网行业的缘故。

    最后在晋升方面，也讲述了微软自己的方案。开发、测试等等有管理和技术的发展通道，各自都有自己的发展渠道和级别。在微软，貌似开发的地位是比较高的，只做技术，照样可以过的非常滋润，甚至让人“妒忌”。