软件项目管理的一些规则

最近重读了《人月神话》，感觉其中一些对软件开发项目管理的总结非常精辟，将其中一些摘录如下：

1、编程系统产品开发的工作量是供个人使用的、独立开发的构建程序的9倍。

2、人们通常期望项目在接近结束时，软件项目能收敛的快一些，然而，情况确实越接近完成，收敛的越慢。

3、缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素的总和影响还大。

4、系统编程的进度安排背后的第一个错误的假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。

5、人月是危险和带有欺骗性的神话，因为他暗示人员数量和时间是可以相互替换的。

6、在若干人员中分解任务会引发额外的沟通工作量---培训和相互沟通。

7、关于进度安排，我的经验是1/3计划，1/6编码，1/4构件测试以及1/4系统测试。

8、Brooks法则：向进度落后的项目增加人手，只会使进度更加落后。

9、向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。

10、同样有两年经验而且在受到同样培训的情况下，优秀的专业程序员的生产率是较差的程序员的10倍。

11、小型、精干的队伍是最好的---思绪尽可能的少。

12、一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法---既能获得由少数头脑产生的产品完整性，又能得到队为协助人员的总体生产率，还彻底的减少了沟通的工作量。

13、为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。

14、纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。

15、他只是坐在那里，嘴里说：“做这个！做那个！”，当然，什么都不会发生，光说不做是没有用的。

16、团队组织的目标是为了减少必要的交流和协作量。

17、程序开发呈程序规模的指数增长。

18、培养开发人员从系统整体出发，面向用户的态度是软件编程管理人员最重要的职能。

19、在大型团队中，各个小组倾向于不断的局部优化，以满足自己的目标，而较少考虑对用户的整体影响。这种方向性的问题是大型项目的主要危险。

20、项目经理的基本职责是使每个人都向着相同的方向前进。

21、开发人员交付的是用户满意程序，而不仅仅是实际的产品。

22、用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

23、一天一天的进度落后比其重大灾难更难以识别、更不容易防范和更加难以弥补。

24、里程碑必须是具体的、特定的、可度量的事件，能进行清晰的定义。

25、状态的获取是困难的，因为下属经理有充分的理由不提供信息共享。

26、老板的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌的接受报告、绝不越粗代疱，将能鼓励诚实的汇报。