14: Overly optimistic schedules. Setting an overly optimistic schedule sets a project up for failure by underscoping the project, undermining effective planning, and abbreviating critical upstream development activities such as requirements analysis and design. It also puts excessive pressure on developers, which hurts long-term developer morale and productivity.
乐观进度表现的方面有：1)对项目的相关风险考虑不足，没有相关的风险管理计划和对风险应对的处理时间。2)项目没有预备一定的缓冲时间。3)项目裁剪或省略掉了生命周期中重要的过程或阶段，如需求分析，设计，或相关评审。
乐观进度是项目成员承担过多的压力，从长期来看伤害团队士气和生产率。
15: Insufficient risk management. if you don‘t actively manage risks, only one thing has to go wrong to change your project from a rapid-development project to a slow-development one.
如果不积极的分析和应对风险，快速开发是一句空话。
16: Contractor failure. Risks such as unstable requirements or ill-defined interfaces can be magnified when you bring a contractor into the picture. If the contractor relationship isn‘t managed carefully, the use of contractors can slow a project down rather than speed it up.
软件或模块的外包或分包，与外包商的关系管理，接口和边界的定义。没有相关的规程或约定很难说外包能够节约成本和加快进度。
17: Insufficient planning. If you don‘t plan to achieve rapid development, you can‘t expect to achieve it.
这个不多说了，计划是后期执行和监控的基础。不能因为计划不准而不计划。这要造成的后果是你始终都不会计划，计划做多了，多做偏差分析后计划自然就慢慢准确了。
18: Abandonment of planning under pressure. Project teams make plans and then routinely abandon them when they run into schedule trouble (Humphrey 1989). The problem isn‘t so much in abandoning the plan as in failing to create a substitute, and then falling into code-and-fix mode instead.
进度压力下可以适当调整计划，但绝对不是抛弃计划。项目如果处于一种无序状态或code-and-fix状态带来的将是更多的进度延后和质量问题。
19: Wasted time during the fuzzy front end. The "fuzzy front end" is the time before the project starts, the time normally spent in the approval and budgeting process. It‘s not uncommon for a project to spend months or years in the fuzzy front end and then to come out of the gates with an aggressive schedule.
在项目开始前缓冲时间做足够多的预备和准备工作以减少项目进行过程中的风险。这些工作包括1)风险分析 2)技能评估和培训 3)团队学习 4)历史经验教训总结 5)项目经验总结，相关约束和规范制定 3)业务需求提前熟悉和调研。
20: Shortchanged upstream activities. Projects that are in a hurry try to cut out nonessential activities, and since requirements analysis, architecture, and design don‘t directly produce code, they are easy targets. On one disastrous project that I took over, I asked to see the design. The team lead told me,” We didn‘t have time to do a design. “The results of this mistake—also known as "jumping into coding"
虽然说磨刀不误砍柴功，但很多人还是希望先用钝刀去砍柴，先看到一些不多的产出，消除心中的恐惧。别人都去砍柴了还能够耐着性子磨刀的人不是简单的耐心的问题，而是出于对自己的充分信任，而对自己的这种信任又建立在多年经验积累的基础上。
21: Inadequate design. A special case of shortchanging upstream activities is inadequate design.
这个很难去判定清楚，设计并不一定要体现到正规的文档和设计模型上面。设计人员和开发人员沟通的一句话，一个流程图可能就是一个设计。所以这里指的设计不要局限到设计的形式，而可能是说根本都没有对整个功能有个总体的实现思路就开始编码。
XP更强调开发的迭代和开发人员间的协同。因此对于设计过度也是我们要重点避免的问题。设计过度的一个重点弊端处了是浪费大量时间外，其它就是扼杀了编码的乐趣。
22: Shortchanged quality assurance. Projects that are in a hurry often cut corners by eliminating design and code reviews, eliminating test planning, and performing only perfunctory testing.
这里又说到好质量成本和坏质量成本的概念了。前期通过预防的手段如培训，Review等来保证质量可以减少后期的大量返工。如果COGQ少投入1天，可能会导致COPQ多投入3天到10天。
设计和编码的Review都是重要的预防手段和过程，不要去追求具体的形式，输出多少文档，而是是否确实做了这些工作？
23: Insufficient management controls. Before you can keep a project on track, you have to be able to tell whether it‘s on track in the first place.
项目的监督控制和项目计划一样重要。项目监督控制的目的就是要及早的发现问题和偏差，分析根源，并第一时间采取纠正措施，使项目按预定轨道前进。
24: Premature or overly frequent convergence.
25: Omitting necessary tasks from estimates. If people don‘t keep careful records of previous projects, they forget about the less visible tasks, but those tasks add up. Omitted effort often adds about 20 to 30 percent to a development schedule (van Genuchten 1991).
WBS分解应该考虑到所有相关的工作，包括培训和会议这些。我们在安排进度计划时候经常忽略了预审，评审，培训，会议这些任务，其实这些任务也是很耗时间的工作。
26: Planning to catch up later. One kind of reestimation is responding inappropriately to a schedule slip. If you‘re working on a 6-month project, and it takes you 3 months to meet your 2-month milestone, what do you do?
进度落后的时候不能够不分析原因而一味的去赶进度。因为进度落后原因往往可能是我们估算的基准数据或生产率数据有问题，这个时候应该采取的措施是调整生产率后重新进行估算，根据新的估算结果对进度计划进行调整。
27: Code-like-hell programming.
编码的健壮性，可测试性，可维护性不是通过Code-and-Fix来保证的。
