微软的秘密读后感~微软的产品开发流程

产品经理提出设计，由程序经理经过产品设计会，把项目分解成3天以内可以完成的个个小特性，这点很重要3天之内可以完成的功能必然是个不大的功能。而且必然应该是可以完成的功能，不会涉及框架和麻烦的牵扯处理。书中还注意到一部分，程序经理是万里挑一的是为了完成哪些看似不可能或根本不可能完成的任务还能一步一步推着做的人。有不能分解的任务必然是设计上有缺陷的任务程序经理要为这些功能负责。一方面这些小的特性断绝了产品间的耦合功能，使单元测试和自动测试成为可能。也通过这样的分解把压力分解掉了不会把产品设计的压力推到普通研发人员的身上。
我们看微软通过产品功能和特性的细化分解来使相对外行的产品设计人员和研发人员之间进行了有效的沟通。
1~开发人员只对小功能特性的开发负责，并针对这些开发编写自动测试程序，并对这个功能提供项目进度的时间评估。虽然说这些特性很小，当一个组集中开发几个特性的时候，要对时间做评估并给出进度表。
2~这和把整个功能丢给程序，2~3个月之后来看结果的区别很大。首先压力也都丢了出去，项目在这2~3个月内可能会反复修改，任何小的特性也会反复修改，局部的修改又往往不会考虑全局的安全。当2~3个月后程序拿出一个似是而非的东西时。压力全部在开发人员身上！技术和产品在小特性上的划分本身就会有着严重的分歧。
3~为什么产品不能做这个划分工作呢？当产品引入一个新的功能时，这个功能在产品来看非常的小，可能只是一个按钮，一个视图。但有可能在软件上会需要引入一堆的功能，这个一般的研发和程序都是很难看的非常全面。这也不是设计的问题，完全正确的把这些隐藏在背后的功能，能确实实现并划分成3天以内的小功能，交给开发人员去实现。就需要一个对未来极有信心并可以确实对状态做出正确评估的程序经理来分解这些任务。
我们看到原来产品和程序之间的压力关系是，产品提出了设计后压力和风险之后开发的时间内都丢给了程序。可能直到最后产品要交付测试了才发现其中的问题。
而微软的做法使每个小功能成为进度的基点，每天都有完成一小步，当发现在某个功能走不下去的时候，最迟3天后产品和程序经理就会发现进度有问题。这样就可以做出及时的调整和重新安排时间。但这样对产品和测试的要求比较高，首先细划的功能很可能只是一个命令行的交互或脚本的一个函数。研发交付这个功能时产品和测试要对软件有起码的了解，至少知道脚本是怎么回事。这也就是office系列为什么有VBS的原因，只是软件开发过程中的一个副产品而已。

 

这点也是中国软件公司严重缺乏的一点，从书中我们可以看出盖茨包括微软的高层都是对技术相当了解，也就是说能够把握住技术细节和框架的关键问题。产品提出的设计需求，由程序经理分解后，再有微软的高层根据分解的结果和执行对项目进度进行把控，交给普通研发和程序完成的是3天内可以完成的任务。设计由产品完成，当软件非常复杂需要设计架构问题时由多个程序经理负责。这个很工作量也是成正比的，程序架构的工作并不多，但技术含量最高需要多个程序经理共同完成，功能的划分本身也说一种程序架构，工作也不会太多，据说微软的程序经理在还有一半的时间能用来开发代码。这些架构的工作虽然不是很繁重但对经验和能力要求很高，进过划分的功能都会转化为较小的软件功能或问题，一般的研发人员也可以顺利完成。这就是为什么微软的研发人员对时间的估计通常都很乐观，因为他们对待的问题很单纯复杂度相对较低，可以专心在软件性能，代码质量上。而国内的官本位思想的作怪下，一个项目经理好像没什么可以干的。甚至有些项目经理把产品直接丢给技术让他们几个星期做一个需求或几个需求不闻不问。

 

这两天尝试用微软项目经理的思考方式去分解任务，真的很难把一个项目考虑的周全，和正常的开发方式完全相反。正常的开发方式是开发一点，想一点下一步做什么。除非对项目既有信心和极有经验才能很有把握的把没有开发过的项目分解成几个小的项目，还有考虑任务小到4个小时到3天内可以完成，基本上说是已经想好这个软件要怎么具体实现了。如果考虑把一个项目分解出1~2个月的工作量那么按每天1百行计算。6千行的代码要在脑子里反复思考跳过任何可能的阻止开发的不可逾越的问题。这种在程序上不可逾越的问题很多例如某个在特定环境得到某个窗口的句柄小任务，如何得到用什么样的api等等。

 

我觉得能够胜任这个工作的程序经理很少的，因为国内对程序经理的要求是所谓的沟通所谓管理所谓理念，那些和技术完全没有关系虚无缥缈的东西。我认为一个程序经理的工作就是把复杂的问题分解成简单的问题，并反复思考其中可能遇到的技术风险，并给产品部门合适的时间表。而不是把产品部门的需求粗糙的分配给组内的某个程序员，由普遍的程序员评估一个有技术风险的项目。如果项目小还可以，如果项目相对较大例如3天以上。产品和技术人员就会在实施过程中出现严重的矛盾，因为对公司管理层而言这个项目在实施的过程中就出现了不可控制的空白期。这就是管理层希望借助所谓日报，周报，月报，弥补这个控制上的空白期，但普通程序员对于项目的评估和分解本身就存在巨大的风险？很大的可能是在巨大压力和完全没有约束的环境下提交一个没有测试没有总体架构和质量优化的代码。而在这个过程中任何人都显得无能为力，视乎管理层，产品，程序经理对程序员都无力向帮，只有程序一个闷头闷头的写代码。因为程序写代码的时是写一点想一点，当遇到不能逾越的技术风险时，项目周期已然过半或即将结束！！

 

http://blog.csdn.net/CSDNATM/archive/2010/07/12/5730142.aspx

看了这篇CSDNATM这篇博文后我补充些。
当初探究微软开发模式是为了在程序员的角度上看待需求分解的问题。
而不是在用户角度上或者逻辑角度上，所有不涉及到
http://blog.csdn.net/qingrun/archive/2010/07/13/5730754.aspx
这篇博文的问题。

任务分解最终落实在软件工程上的目的是为了单元测试！！！也就是微软的秘密里所说的自动测试！！
为什么叫喊多年的单元测试或叫自动测试极难推广因为在需求分解到程序的过程中没有做到两个统一。
用户需求逻辑和函数输入输出的统一。
单元测试的第一个要求就是函数的输入输出的标准化。在一个函数里至少不能把需要测试的内容环境返回到到一个自动测试不可捕捉的环境。或者自动测试程序不能输入的环境。例如使用GUI就极大的增加自动测试程序得到输入和输出的难度。
用户需求逻辑无论如何划分只要能够把输出和输入变成可以捕捉即可。没有返回结果的也要返回正确或错误的逻辑结果。但用户的需求往往天南地北尤其是使用GUI界面后这种统一造成了极大的难度。
难度不在任务的分解而是分解的恰到好处最大的满足单元测试的要求，使单元测试可以最大限度覆盖整个工程这个过程极难。

 

微软的开发也不是要站在非常高的高度上去解决所有需求问题后开始编写代码，我们看为什么要对程序经理要求在极大的压力下可以继续前进呢？因为在计算机硬件满足的层面只要想得到的动画或3D效果或者其他理论上都效果可以实现的只是需求时间长短的问题。程序经理在得到一个需求后如果不能分解出所有需求可以先分解12个月或24个月的工作量。12个月24个月是微软的一个标准开发周期，当管理层决定继续做的时候下一个开发周期程序经理要继续分解，即使他知道这个工作可能极其庞大永远都不可能完成但决不能灰心丧气。常人在做一件永远不能完成的任务时就会非常消极。。。程序经理要有极大的耐心和无畏的勇气。所以微软这类管理人员是非常难得的人必须万里挑一。而微软的管理层也不多，程序经理往往直接向盖茨或鲍勃汇报。如果你耐心的看完我的帖子会发现微软的开发结构非常简单,垂直到普通的开发人员只需要3层或4层。程序经理上面会根据项目的大小设置一个类似总监的位置，例如nt的卡特勒，office项目等等。但程序经理的进度报告是会直接放到盖茨的桌子上。就是说盖茨只要垂直3层几乎是直接管理着微软的开发工作。

 

让所有人参与到软件开发中来是件很不容易的事情，尤其让对不懂技术的产品，BD，运营，管理等等非技术人员可以很好在软件开发中发挥应有的角色，是一件漂亮的现代行为艺术。微软是众多表演艺术家的杰出代表。

 

微软的秘密所透露出来的微软开发过程最后是落实在了自动测试和每日构建。这是微软所有软件开发的基础框架，而且自动测试和每日构建和软件体系结构密不可分，但在最后交付软件时却可以完全删除。有点类似加工机械对最终用户来说这套体系是看不见得。不过自动测试和单元测试是和软件工程在设计过程和实施过程中是密不可分的。自动测试和每日构建的基石是项目分解，而项目分解的基石是程序经理。微软提出的4个小时到3天的分解单位是也许另有目的，程序经理分解的任务也许牛人4个小时就搞定了而普通的程序员需要3天，这解开了一个困惑就是微软的普通开发人员的时间是自己确定的。呵呵看来也只有自己知道自己是不是牛人。自动测试和每日构建是大规模软件开发中质量控制的基石，这点才最为重要的也是我们软件工程苦苦求索的部分。所有产品级软件开发最终目的是要做出一个质量可靠的产品给用户。方法也许很简单但颠覆我原来对软件工程认识，现在写软件要想想，再想想，自己做自己的程序经理。这个帖子丢在这吧让更多的人能够看的到也许有些帮助。做为一个真正的程序经理要思考什么做什么，有什么样的思想品质微软都告诉我们了。