为什么呢?从根本上说，项目管理实际上是风险管理，项目管理的过程基本上是基于风险控制表进行的。而对于软件开发来说，大部分的风险警报只有在编码和测试的时候才会出现。也就是说，编码开始的时间越晚，风险警报出现的时间也就越晚。而风险警报出现的晚意味着什么呢?意味着你在设计阶段做的无用功多，意味着你浪费的时间多，意味着你的项目延期多。所以这可能就是XP为什么一出现就受到热烈的讨论，为什么会有增量开发，演进开发等这些尽量提前编码开始时间的方法的原因。
人类的有限理性是什么?就是人们本来知道吸烟有害健康，但还是要去吸烟。对于程序员来说，没有什么比早早地看到程序运行的结果更重要的了，也没有什么比得到同行的一两句赞扬更重要的了，尽管他知道这些赞扬既不会为他带来加薪，也不会为他带来女朋友，但他还是会为此去熬一俩个通宵把程序尽早做出来。对他们来说，用UML,VISIO每天拿着鼠标在纸上谈兵远没有直接用程序把自己的想法表达出来更有意思。这就是程序员的激情，这也是软件项目赖以成功的根本保证。
将设计与编码截然分开，既愚蠢又可笑，更有甚者，将设计人员与编码人员也截然分开，由两组人去做。而这却是现在中国软件业新唐僧们从西天印度取经的结果，软件蓝领，一个有意思的词。记得有一次我和一位从事市场工作的同事谈起了“知识工人”时，他说，对，其实知识工作者也是工人。唉，大势如此，夫复何言。我不了解印度，不敢对印度说三道四，但我直觉地认为，中国软件行业的特点更像美国：有强大的内销市场，软件种类多，覆盖面大，小公司繁荣，新生类软件多等。这样的情况下，每一个软件的开发过程实际都是一个研究探索学习的过程，而在这样的过程中，设计人员只在大脑中想象自己的设计怎么样怎么样运行，我不能设想这样是否可行。 工厂与作坊的区别在哪里，不是指工厂有严格的分工，由明确的流程，而是指工厂能针对目标定制合理的软件过程，并在一次又一次的项目实践中改进它，积累它。不仅仅改进这个软件过程，而更重要的是改进选择合适软件工程的定制方法。在更高一级的抽象中重复，在更高一级的抽象中实现流程。
第二节
1. 软件大规模定制
在这个市场越来越起主导作用，定制的产品广受欢迎的时代，软件是否也可以做到大规模定制呢?首先看什么是软件的大规模定制。规模与产品的开发速度有关，如果一个定制的软件能够在一个月内交付，如果定制软件的交付数量可以与程序员数目成正比，我们可以将这种开发模式叫做大规模定制，如果这种结果能够出现，那一切将是多么美好!但这种开发模式可行吗?大家还记得那句著名的话吗：给再多的女人，生一个孩子也需要9个月。那么，这个答案应该是否定的。但是我们如果将软件生命周期用显微镜观看，也许会发现，我们不能够提高第一个版本的交付速度，但我们也许有可能提高第二个，第三个版本的交付速度。我们先看看软件的生命周期曲线：
图中②表明的是这样一个事实，任何体系结构均有一个扩展的上限，一旦达到这个上限，软件将变得难以重构，这时必须重新开发新的体系结构，有时这种开发可能会完全coding from scratch.
而基于每个体系结构的重构周期取决于该体系结构的设计是否有比较强的灵活性以及包容性。这也说明了体系结构设计的重要性。然而，需要注意的是，体系结构并非只有一层，一个软件的功能事实上可以划分出若干闭包，也就是说，不同功能之间的关系并非杂乱无章或随意组合的，如果去研究它，你会发现有一些功能是相关的，另外一些功能也是相关的，而不同组功能之间相关程度则弱一些，通过对其分解，可以得到若干个闭合的子空间，而对每个子空间作正交分解，可以得到若干稳定灵活的子框架。这说明了什么呢?说明即使每一次小规模重构定制版本，在定制开发新功能的时候，也可以丰富整个体系结构，为后面的重构活动修桥铺路，这是即使小的重构活动也可以产生的边际效益。
这样的生命周期，也体现了软件的这一商品的盈利方式，即高沉没成本，低边际成本。第一个版本，或重新开发体系结构的成本很高，但每一次小的重构则成本很低，但条件是什么呢，就是重构必须快。如果软件开发不以这样一种盈利方式来进行，则即便能存活一年半载，也可能难以为继，所以，如果你不能实现大规模定制，那就最好只作产品，而不要定制。
如果我们能真正实现上面一种软件生命周期，那么软件大规模定制则并非空想。但是这里依旧有一个组织架构问题需要解决，这正是下面要阐述的内容。
2. 非对称双螺旋组织架构
在现实世界中，定制软件的开发组织往往是针对每一次定制需求成立一个项目组的方式来应对，这是一种单层的结构，其缺点是显而易见的，项目组既是负责产品未来发展的唯一组织，也是直接应对当前客户，需要对当前客户负责的组织，这二者之间是有矛盾的。尤其当不同用户的要求有极大差异甚至截然相反的时候，项目组在疲于奔命，产品也在摇摆不定，这样每次的重构周期和产品质量都将是无法预测也无法管理的。那么如何解决这样的一个矛盾呢?
效率来源于分工，定制开发与长线规划是价值取向完全不同的活动，理应交给不同的人去做。我们再增加一层组织，叫做产品组，她专门作长期的产品规划和开发，但她又不是闭门造车，而是与项目组构成一种类似双螺旋结构的互动关系，但这种双螺旋是非对称的。
项目组在产品组开发的基础上为用户定制开发，而产品组的工作包括：1)将项目组作的有较好应用前景或对基础架构有较好加强作用的代码集成到基础架构中;2)基于来自项目组的反馈，预测未来可能有用的功能，基于此预测作日常的常规开发;3)或对来自项目组的预研要求提供支持。
这样，产品的方向及保证是来源于市场，也可保证以相对稳定的方式发展。只是这个产品并非最终产品，而是最终交付给用户的定制产品的开发基础。而最大的好处在于她最大限度的保证了一个稳定的可预测的产品质量。
软件到底什么最重要?当前版本最重要，那么是否就不考虑未来了呢，也不能，那么就都去做吧。其实这也是很多公司管理层与程序员之间的分歧，每个程序员都希望自己的代码漂亮，而漂亮的标准是什么呢?是耦合度低，可重用，可扩展性强，但很少程序员认为，漂亮的标准是可靠稳定。学校在培养程序员的时候也并没有告诉，当前版本的质量才是第一位!
文章来源于领测软件测试网 https://www.ltesting.net/
