欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

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

程序员文章站 2022-07-14 21:42:00
...
   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)”,也就是不能安装运行的情况。不过很难有完整的测试文档,估计这是因为互联网行业的缘故。

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