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