第一章： 经验教训：
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记住，一旦承诺了一个项目进度计划，你将会与它共同度过其中每一天——日复日，年复年。
创建项目进度计划的步骤：
1. 指定项目进度协调者 2. 确定要使用的工具
3. 为项目进度计划会议做准备 4. 开始项目进度计划会议 5.
完成任务
6. 从每个提交中提取数据 7. 使用工具创建PSP 8. 评审每个提交的结果 9. 实施PSP的完全评审 10. 用工具更改PSP
11. 批准PSP
12. 分发所批准的PSP给项目成员。
第五章： 经验教训：
5.1项目跟踪就是在项目中始终保持控制。
5.2召开项目跟踪会议的首要原因，是为了在问题发生之前就找出潜在的问题。 5.3如果不能定期找出和跟踪项目的高风险区，也就不能充分的跟踪该项目。
5.4在项目组员无力有效地解决当前问题的同时，不要去尝试解决更关键的项目问题。 5.5无论什么时候重新设定目标结束日期，都要在添加新日期的同时保持“旧”日期的可见性。
5.6如果一个高风险区在表上列出了很长时间，就表明这个关键问题没有得到必要的关注。 5.7有关项目概观的资料常常反映了上一次PTT会议的进展。
4
5.8如果一个项目活动将持续几个星期，则PTT成员在比较实际进展和计划时需要用支持图做辅助说明。
5.9能否得到诚实、准确、真实的数据是在评价一个项目是否得到控制时要考虑的基本因素。 5.10不论项目处在开发周期的什么阶段，每个项目成员都应该能够随时记录下问题。
5.11如果待评估项目没有已承诺的项目进度计划，那么为它指定风险值就没有什么作用。 5.12根据项目进度计划，PTT会议应该每周举行一次以实现最佳生产率。 5.13PTT会议起到了项目的基本推动力作用。
5.14PTT会议在周二或周三举行是最有效的――随后的一天可预留给工作会议和扩大会议。 5.15为了促进组织低层的责任，通常不应在PTT成员中包括管理层人员。 5.16PTT成员必须能够完全的描述他们的领域。
5.17计划周密的PTT会议日程可以对保持控制产生积极、深远的影响，这不只是为了会议的需要，也是为了项目的需要。
5.18对销售商和转包商活动进展的跟踪应该像对项目其他成员的跟踪一样，按惯例进行。 5.19安排PTT会议时间时要比原计划多留出30分钟的空余。
5.20一套简单的PTT程序会促进成功。
5.21为了把项目做得更好，也为了其他成员的方便，任何项目成员需要时都不妨寻求帮助。 5.22要使项目尽可能的成功，项目领导层就必须全力支持PTT会议和相关活动。 5.23制定修复计划是为了迅速解决问题并限制可能导致的破坏。 5.24为了解决争端，问题升级是合适和健康的行为。
5.25问题升级应该在该项目需要确定后的两个工作日内启动。 5.26进行问题升级时，不要停止对计划的记录工作。
5.27在得到了要跟踪的、通过审批了的项目进度计划时，PTT会议才是最有效的。
跟踪项目进度计划的步骤：
1. 指派PTT领导 2. 选定要用事工具和表格 3. 准备PTT培训 4. 实施PTT培训 5. 准备PTT会议 6. 召开PTT会议
7. 开展工作/问题升级会议 8. 分发PTT会议记录
9. 转第五步直接到项目结束。
第八章： 经验教训：
8.1在投资开发新产品之前，必须花时间理解顾客所提出的问题和要求的前景，这些问题和要求必须得到满足。
8.2产品需求文档关注客户的问题和需要——而不是解决方案。
8.3如果你没有同客户紧密的合作，就不要假设你已经理解了客户的问题和要求。 8.4当你把客户问题打印下来并检验它们的正确性和完整性时，你将学到更多东西。
8.5需求文档关注的重要话题在项目开发前往往被忽视，被错误的假设或在稍后才发现。 8.6需求文档提供了切实可行的方法来验证解决方案。
8.7最成功的产品开发人员是那些坚定地、不知疲惫地理解和满足客户问题与需要的人们。 8.8需求文档表达每个要满足的需求时必须清晰无误。
8.9仅编写需求文档是不够的，文档必须由所有的相关团体达成一致，包括一组预期客户。 8.10产品需求文档的建立是项目开发过程中进行控制的最首要环节。对达成一致的需求文档进行的严格变更控制有助于对整个项目的控制。
8.11如果你的产品不能满足客户的愿望，竞争对手将会很高兴地来帮助你的客户。
第十章： 经验教训：
10.1产品规格说明书要在软件开发过程早期完整的定义所要开发的产品。
10.2产品规格说明书要定义产品到一定的详细程度，这样所有小组均可以进行他们生产性的活动。
10.3产品目标必须在产品规格说明书认可之前被认可。
10.4为了确保产品规格说明书所定义的产品具有技术可行性，高层设计必须在产品规格说明书被认为完备及准确并且可以备认可之前完成。
10.5一个初期的工作原型可以减少大量的针对产品规格说明的变更，否则这些变化将会在稍后的软件开发过程中需要。
10.6在软件开发过程中，产品规格说明文档是最重要的项目文档。
10.7所有与完整的、精确的产品规格说明有关的小组都必须认可文档，以确保它满足他们的需要。
10.8当产品被建造并被测试时，即使是写得最好的产品规格说明也需要变更。
10.9对于一个良好管理的软件开发过程来说，严格执行变更控制过程是必不可少的。 10.10在构建产品之前先定义你要构建的是什么产品是非常明智的做法。
产品规格说明书：定义最终产品
步骤1：建立基线——完整地描述产品 步骤2：从“认可者”处获得同意
步骤3：维持控制——加强变更控制过程
第十二章： 经验教训：
12.1开发测时通常是软件开发过程中的薄弱环节，是问题产生的根源。 12.2在单元测试中，所有的代码都应该被执行。 12.3不是所有的通路的组合都能被执行。
12.4千万在实行测试计划之前完成测试计划的制定，这是它们被称作“计划”的原因。 12.5对人工的测试环境的需求越少，测试越可靠。 12.6独力测试小组必须认可功能测试计划。
12.7如果期望结果是可预测的，那么必须定义和追踪开发测试。
因篇幅问题不能全部显示，请点此查看更多更全内容