学习经验教训

1.1软件开发过程应该由一个可理解的活动集构成，新项目的成员可以从该活动集中选择合适的子集作为新的过程。

1.2为了改善软件开发过程，必须例行公事地检查软件开发过程。

1.3软件开发过程必须从不需要用户执行对产品或项目无用的任务。

1.4软件开发过程必须有一个简单而有力的方法允许过程的使用者提出改善意见或背离的意见。

1.5为你的组织定义恰当的软件开发过程将对控制项目的进度、成本和质量有深刻的影响。

1.6组织应该努力具备尽可能少的软件过程模型。 1.7剪裁软件开发过程的规则必须文档化并且利于理解。 1.8至少需要提供两个显示如何剪裁软件开发过程的完整例子。

1.9用一个更合适的软件过程模型来创建软件开发过程，比试图迫使项目使用一个不太适合的软件开发过程要更好。

1.10对于软件开发过程的全部职责需要尽可能平均和公正的分派给软件开发小组中的各代表。

1.11大多数非管理人员应该负责和操作软件开发过程。

1.12在组织中的每一个人包括所有管理层的人员，要被传授软件开发过程的描述和使用方法。

1.13管理层最后要负责坚持让每个新项目完全遵守所批准的软件开发过程。 1.14每个组织都需要一个唯一定义的软件开发过程。

定义软件开发过程的步骤

步骤1：确定软件模型步骤2：确定活动

步骤3：确定活动间的关系

步骤4：将每个活动的有用信息文档化步骤5：剪裁过程文档化步骤6：改善过程文档化步骤7：过程获得认可并培训员工步骤8：不断地使用和改善过程

第三章：经验教训：

3.1 被每个人给予和感受到的尊敬和重视是企业整体成功的关键。 3.2 与他人一起工作的最好建议是相对待自己一样对待别人。

3.3 知道改善沟通的方法是第一步；“实践——实践——再实践”的黄金规则是最重要的。 3.4 当你犯错误时勇于承认，这会使对抗的一面转变为合作的一面。 3.5你对他人的宽容也会让其他人宽容你的行为。 3.6 交互式的沟通仍是最好的沟通方式。

3.7 当项目中的成员愿意共享知识和经验时，这个项目的团队精神就大大被提高了。 3.8 与另外一人沟通，会使你们都从中受益。

3.9人们更多关注的是你所发信息的方式而不是内容

2

3.10尽力让其他人不对坏消息感到惊讶。

3.11坏消息就好比垃圾，你越延迟遵照此消息行事，那么它就越容易变臭。 3.12把问题搁置在人们和小组之间会对沟通产生消极影响。 3.13你能说得最重要的一句话是：“谢谢你！” 3.14聆听对双方都有很大好处。

3.15大些别人，尤其通过名字，是一种感受到尊重与被尊重的有力方式。 3.16一个折衷的解决方案通常是最好的解决方案。

3.17不要让过去的习惯阻止积极的进步。

3.18如果形成一个有效的小组，那么项目小组必须理解其他人的任务。 3.19在最后的分析中，管理层有权负责确保项目中具有所需要的沟通。

4.1最重要的项目计划是项目进度计划。

4.2项目进度计划都处在控制之中。

4.3在等待制定完整项目进度计划所需的信号时，必须建立一个近期的进度计划。 4.4项目取得进展不可能进行测量，除非已经首先建立了可以测量进展的计划。

4.5自顶向下的计划实在没有任何项目成员参与的情况下制定的，因此不能解释为被提交的计划。

4.6只有已经被很好确定的事情，才能提交以用于制定详细的进度表。 4.7为了达到最大的生产效率，项目成员需要遵循计划。

4.8每延迟一天完成最终进度计划，实际的项目将延期半天，而这些损失对项目来说是无法挽回的。

4.9项目进度计划通常必须包含一页项目主要里程碑的总体图。 4.10与文档相关的活动必须扩展到一系列更小的活动中。 4.11必须完成达到评审水平的文档。

4.12在修改文档时必须修改的地方用强调的形式指出。

4.13当文档项目文档进入更新阶段时，要加强项目内部的沟通。

4.14重要的或复杂的文档必须要执行这五个阶段。// 准备、评审、修改、批准、更新 4.15文档的负责人必须坚持有一个完整的评审阶段。

4.16如果活动互相之间是相互依赖的，不管是直接的还是间接的，都因该尽量避免产生交迭。

4.17当活动交迭数量增加时，管理项目的复杂程度会增加。

4.18当估计活动周期时，把活动分为更小的工作块，并计算每个工作块的周期。

4.19为了得到最好的估计结果，把一个活动分为一些大约需要一周时间去完成的工作块。 4.20一个项目必须有一套每个人制定进度计划时使用的共同程序。 4.21为了缩短项目周期，将工作重点集中在组成关键路径的那些活动。 4.22首先建立一个受进度约束的计划，然后再过渡到受资源约束的计划。 4.23人员排辈布置靠路牌被“管理者”，而且要考虑配备有合理技能的管理者。 4.24，每个项目进度计划都要包括意外事故缓冲时间。 4.25分布意外事故缓冲时间到项目的所有活动中。 4.26保持周末作为一种意外事故缓冲时间的形式。

4.27不要在计划中计划出加班时间，无论如何它是会发生的

4.28当临时人员离开项目时，要准备应付知识和技能的流失。

4.29当开发一个项目进度计划是，要确信考虑节日和假期的因素。

4.30在项目进度计划中包含第二方观点可能是没有什么价值的，但是相应也是廉价和可行的。

4.31活动责任矩阵是阐明项目责任的区域和帮助项目成员预计工作量的强有力的工具。 4.32定制项目检查表只显示一个特定项目成员或特定小组负责的那些活动。

4.33在大多数项目，PSC是一个全日制的职位，而且，建议管理层授权一个非管理者去履行这个职责。

4.34新项目必须把制定羡慕计划作为最优先活动。 4.35当计划日期改变时，应该保存原始日期。

4.36如果你相信项目成员有改正的机会，即决不改变项目进度计划。

4.37应该限制修改项目进度计划的时间。例如，修改一个项目计划的周期应该在12个月或更短的时间之内进行。

4.38最佳的项目进度计划是富有挑战性的而且是可达到的。

4.39虽然每个项目成员对他或她自己的工作负责，但是一个项目领导有保证良好计划项目的最大责任。

4.40记住，一旦承诺了一个项目进度计划，你将会与它共同度过其中每一天——日复日，年