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)
将产品或系统的使用手册、维护条例、使用参考等等一系列文档根据各功能开发的进展进行编辑
趁着概念新鲜明确，将它们写入文档

好处是：
第一避免编辑多余的不必要的文档或不必要的内容
第二，但是也要注意不要将文档工作放到最后，而造成文件内容缺乏或遗漏。

软件开发管理模式的简单介绍和比较

Traditional(Waterfall)
RUP
CMM
Scrum
ASD
Crystal
eXtreme(XP)
DSDM
MSF(Microsoft Solution Framework)
自scrum后为灵活性模式

SCRUM

由Ken Schwaber和Jeff Sutherland提出和倡导
是一种极为轻型的灵活性模式的翻版
非完整的：没有整个流程的定义
采用所谓的"sprints"，即一般是一个月为周期，来进行循环式的短期性的开发和发行管理
每天进行15分钟的团队“scrum会议”
采用每天进行项目的最新状态汇报，发表“burn down graph”
适合于整个开发团队在同一个大房间里一块工作

scrum本意是指橄榄球在开赛前的手拉手聚在一起商议进攻方案，在这里是指项目管理的模式，指每天在开始工作前要所有团队成员在一起开会，商讨当天的工作和遇到的问题。

Adaptive Software Development(ASD)
由Jim Highsmith提出和倡导
也是一种轻型的灵活性模式，强调在混乱的边缘上争取平衡
不要求执行者完全按照流程规则来做
在项目周期里安排一个学习阶段，具体解决哪些是重要的开发任务
将项目的历程分成3个阶段：思索、合作、学习(speculate,collaborate,and learn)
讲究在合作阶段进行循环式的重复渐进，采取“时间盒”(TimeBoxed)的方法

Crystal
由Alistaire Cockburn提出和倡导
灵活性模式的一种，尊重不同大小的项目在管理上需要有不同程度的正式性管理规章，强调在完成目前的开发项目的同时，要将眼光放在开发团队和企业未来的位置
使用几个不同的管理方式：透明、黄色、桔黄、红色等模式
采用轻型化的规章制度
比较注重项目文档的用途，要求管理人员使用各种文件来帮助管理

eXtreme Programming(XP)
由Kent Beck,Ward Cunningham,Ron Jeffries提出和倡导
在所有的灵活性管理模式中是最著名的
使用所谓的故事卡进行项目的计划规划
要求在开发过程中一直有客户的参与
很短的开发周期：任何一个开发分段都不超过3个星期
群体式负责制：任何人可以参与任何部分的开发
使用重组(Refactoring)来进行渐进式设计
采用TDD和连续性整合
要求每周40小时工作时间

Dynamic Systems Development Method(DSDM)
是一个通常由来推动的管理方法
将开发周期分成5个部分：可行性认证、商业需求认证、功能模式循环、设计和建造循环、以及最终的开发
是一种偏向于繁重规章制度的模式
开发的计划和设计采取渐进式的
目前有一些商业工具可以用来帮助使用这种方法进行项目管理
类似RUP，但是有明确的风险管理指南，能达到较好的灵活性
这个方法不是很常用，与其他几种方式相比知名度较小，使用较少。

MSF-Microsoft Solutions Framework
由Randy Miller,Paul Haynes提出，微软倡导
是基于传统模式的基础上发展起来的
属于比较正式的模式，但最新版本包含了灵活性的模板，加入了使用者角色(Personals)的概念
推行一个从角色到使用方案的设计流程
开发过程采用循环型的3星期的周期
要求单元测试的程序与开发程序的原代码一起提交
要求100%的原代码执行测试(Code coverage)

How Much architecting is enough?(到底应该做多少事先的构架设计和计划？)
灵活性与纪律性(指规章制度的严肃性严谨性)的平衡，两位作者做了一个调查，发现了与crystal模式相似的结论，就是在项目管理实施过程中没有一个一成不变的规章制度，而要根据项目的规模的大小和开发团队规模灵活确定，当一个项目比较小时，事先的构架设计和计划就可以比较少，而当一个项目比较大时，事先的构架设计和计划以及规章制度就要相对增大，才能更有利于项目的顺利实施。

管理流程设计的一些准则和指南
团队成员之间的融洽交往是任何项目管理不可缺少的。有时非得用面对面的交流
规章制度太多会变成繁重的负担。选择对开发的灵活性和软件质量最有利的规章去执行
通常情况下大型的团队管理规章可以多些
将自我调节的能力设计利用到流程管理中去

总结
不同大小的项目可以采取不同的、能够最佳适合于它的管理方法
灵活性模式有很多传统模式所没有的灵活性
灵活性模式对建立团队文化很有效
灵活性模式也有它的局限性
采用时可以考虑逐步采取其中的一部分先执行，根据效果再做调整