【IT168 技术文章】
70年代基本上一个软件在项目规模上比较小，一两个人基本可以胜任一个软件的开发，这样的人被称为hero,认为是英雄主导着一个软件项目的进度，但随着业界对软件依赖的增加，软件在规模、复杂度上都有较大的增加，一两个人已经无法胜任工作的需要，而且，开发人员一旦离开公司，那么整个项目甚至整个公司可能会陷入瘫痪的地步。所以，在80年代初，软件公司开始重视软件开发的项目管理，把其他行业成功的软件项目管理经验开始引入软件开发领域。
美国PMI，Project Management Institute(项目管理研究所)在软件工程项目管理方面起到了很大的推动作用，每年发行一本PM book。微软在软件开发管理上也是基本参照传统的软件开发模式来做的。
除企业对软件开发项目管理的推动作用外，学术界也推出了有关的管理模式，如CMM（软件成熟度模型）。CMM在部分软件企业得到了推崇，但是并不是所有的软件企业都采用CMM，微软本身就没有采用。尽管如此，微软本身的管理方法与CMM也有异曲同工的地方。
业界也在推行自己的管理模式，RUP,Six Sigma,ISO,etc.关键是软件开发管理中的关键的部份要掌握好。
传统模式在美国很多公司都使用过，对这些开发模式不能盲目崇拜。
--------------------------------------------------------------------------------------------------
传统的和其他的管理模式受到挑战
被认为太死板和官僚
效率高低受到质疑
太重规章制度项被认为是开发的枷锁
在执行起来太过于繁重
可能违背需要智力高度集中的软件开发工程管理的特性
因此这几年来开始有人唱反调
软件开发具有自己的特点
*********************************************************
传统的项目管理模式
根据PMI观点，传统的项目管理通常具有几个固定的阶段：
第一项目启动阶段，第二计划阶段，项目的规模、项目的需求、项目的估算，第三阶段设计规范书(软件开发的蓝图)，第四项目时间表(schedule)。样品的试开发。第五执行阶段，编程开发。同时fix bugs.第六控制阶段，对发现的错误进行回车重新开发。第七结束阶段。
启动、计划、执行、控制、结束
这五个阶段的传统的项目管理模式在业界使用的比较普遍。
灵活性模式的概念和实践
1、轻型的计划(Light Weight Planning)
信奉改变(Embrace Change):从整个的项目的开始起就期望计划、需求、和设计都会改变。
整个开发过程有客户的经常参与，甚至邀请客户来到开发团队的工作处，对正在进行开发的半成品使用、审核、提意见。
客户直接参加项目的计划的修改
整个开发计划是个不断更新的过程
轻型计划的象征：没有事先的计划
加州大学俄凡分校在校园的时候，他们只盖了大楼，铺了墓地，却不建筑人走路的路边人行道。第二年，建校的人回来，在草地上由人们走出来的路径上，修建了让走路的人行道。Perl语言就是这样一类的语言，它并没有事先全设定好的规则，Perl语言就是那些在墓地上由人们走出来的人行道。
计划是一个连续性的过程，而不是一个一次性的过程。
2、经常性的发行(Rrequent Releases)
短期的重复开发周期
采取所谓的“时间盒”方法--将预定的周期锁定为一个发行周期
保持产品接近发行的状态
好处是：
第一为团队提供一种完成任务的快乐和成就感；
第二给用户提供了在开发早期进行回馈的机会。
3、简化的设计(Simple Design)
先对那些已经确定了的功能进行设计
使用YAGNI(You aren't going to need it)
意识到任何多余的功能，一旦加入到软件产品中，会增加修改和维护的费用。
好处是便于返车重新设计和开发。每次改动都可能会影响其他部分的功能组件。
4、以测试为驱动的开发(Testing Driven Development--TDD)
编写产品的程序前先写测试的程序
单元测试(Unit Test)应该全部自动化
单元测试的运行应该成为开发的日常工作
好处是：
第一保证测试部分能保质保量完成
第二以这种方法写出的程序质量较高
5、重新组合(Refactoring)
重组：在不改变功能和行为的前提下，对软件的内部结构为更容易理解和更方便修改而进行设计和编程上的改动。
采用渐进式的设计方式来逐渐完善程序
好处是：
第一帮助推动渐进式的设计方式，使得软件的避免一次性做完，却又带有费用昂贵的必需的改动
第二常常重组，再加上利用TDD，改动的费用会降低
何时进行重组？
Martin Fowler:
当你发现你必须在一个软件程序里加一个新的功能、但现有的程序的结构却无法让你奶方便地加入这个新的功能的时候，你应该先重新组合现有的程序，使得经能够让你方便地加任何新的功能，然后再加入你想加的新功能。
6、连续性的整合(Continuous Integration)
将开发团队多人开发的各功能组件进行整合，最后生成完整的软件系统或产品，应该是一个经常进行的、连续不断的过程。
每天或每几个小时进行总汇编和产品建造(Daily Build)
好处：
第一帮助开发团队及时发现Build Breaker并采取纠正措施
第二对任何由于设计差错无法完善地与整个系统进行整合的功能组件能及时进行设计改动
7、及时文件编辑(Just-In-Time Documentation)
将产品或系统的使用手册、维护条例、使用参考等等一系列文档根据各功能开发的进展进行编辑
趁着概念新鲜明确，将它们写入文档
好处是：
第一避免编辑多余的不必要的文档或不必要的内容
第二，但是也要注意不要将文档工作放到最后，而造成文件内容缺乏或遗漏。
