软件开发是一项复杂的活动。一个典型的软件开发项目可能会给你提供很多的机会去从错误中吸取经验教训，甚至比有些人一生获得的机会还多。
项目典型错误包括人员相关的错误、过程相关的错误、产品相关的错误、技术相关的错误。
人员相关的错误
典型错误1：挫伤积极性
不当的激励或是管理，容易挫伤人员的积极性。当开发人员的积极性降低时会极大的影响人员的工作效率从而影响快速开发的进度。
典型错误2：人员素质低
在激励之后，项目组人员的能力或者成员之间的关系可能对生产率有巨大的影响。聘请能力欠佳的人员极大的影响着快速开发。
典型错误3：对有问题的员工失控
不能很好的处理有问题的员工也会威胁开发速度，这是个很常见的问题。
典型错误4：英雄主义
有些软件开发人员过于强调个人英雄主义，认为某种英雄主义是有必要的。随着自行度的逐步上升，晓得挫折就会演变成真正的灾难。
典型错误5：项目后期加入人员
也许这是最常见的典型错误。当项目工期拖后，认为加入人员可以提高项目组目前的生产率。
典型错误6：办公环境拥挤嘈杂
拥有安静、隐蔽办公环境的人员比在嘈杂、拥挤环境中的人员往往会有更好的工作业绩表现。嘈杂、拥挤的工作环境会延长项目工期。
典型错误7：开发人员与客户之间发生摩擦
开发人员没有与客户进行充分的沟通，从而与客户之间产生摩擦，这会导致缺乏对需求的准确理解和导致用户界面设计较差。这种摩擦如果加剧会导致双方取消项目，同时也会转移客户和开发人员双方对项目的注意力。
典型错误8：不现实的预算
不现实的预算本身不会延长项目周期，但它会助长认为项目开发周期太长这种风气，而这是有害的。
典型错误9：缺乏有效的项目支持
快速开发的许多方面需要得到高层对项目的支持。
典型错误10：缺乏各种角色的齐心协力
软件开发中的所有主要人员必须齐心协力专注于项目，只有完全投入到项目中，才能允许准确调整各种角色的协同关系，否则不可能达到快速开发。
典型错误11：缺乏用户介入
没有用户早期介入的项目充满需求误解的风险，易受项目后期功能蔓延的威胁。
典型错误12：政治高于物质
有四种不同类型的项目组。
“政治家”型项目组强调“管理之上”；“研究者”型项目组的精力集中在研究和收集信息上；“独立主义者”型项目组单打独斗，建立项目分界，以划清与非项目组成员的关系；“多面手”型项目组对每件事都完成一点，他们往往保持好与经理的关系。项目初期，管理层更看好政治家型和多面手型项目组，但经过较长时间后，政治家型项目组就会沦落到死亡边缘。
典型错误13：充满想象
项目初期充满想象，认为事情会毫无理由的按照想象的那样运作，这会破坏整个项目计划，并可能成为许多软件问题的根源。
过程相关的错误
典型错误14：过于乐观的计划
制定过于乐观的项目计划相当于自己为项目失败画出了底线，破坏了有效的项目计划，并会缩短关键性的前期开发活动，如需求分析和设计。
典型错误15：缺乏足够的风险管理
如果不主动管理风险，那么只要有一件事情做错就会将一个快速开发项目变成一个慢速开发项目。
典型错误16：承包方导致的失败
有的项目紧急，有时会把部分工作外包出去，如果对承包方不加认真的管理，签约外包非但不会加快项目速度，反而降低项目速度。
典型错误17：缺乏计划
不编制计划就进行开发，是不会达到目的的。
典型错误18：在压力下放弃计划
项目组制定了计划，当遇到困难时就放弃计划。项目失败的原因不是在放弃计划本身，而是不能制定替代措施，并一头栽进编码和问题处理中去。
典型错误19：在模糊的项目前期浪费时间
模糊的项目前期是项目开始之前的时间，通常是花在审批和预算过程中。
典型错误20：前期活动不合要求
由于需求分析、总体设计和详细设计并不直接生成编码，因此对于急于砍掉不必要活动的项目来说，他们是最容易想到的目标。
典型错误21：设计低劣
前期活动不合要求的一个特殊情况就是设计低劣。设计强调的重点是权宜之计而非设计质量，所以在完成整个系统前，往往需要一段时间的设计周期。
典型错误22：缺少质量保证措施
紧急的项目通常会砍掉一些表面看来不重要的功能，包括设计和编码修改、测试计划等。这种削减会破坏项目的开发速度。
典型错误23：缺少管理控制
在项目中很少设置管理控制点，缺乏必要的计划拖延迫近警告。
典型错误24：太早或过于频繁的集成
对于紧急的项目，有的会在项目结束前进行多次项目集成，这种额外的集成不利于产品，他们仅仅是在浪费时间，延长进度。
典型错误25：项目估算时遗漏必要的任务
在进行项目估算时可能会忘掉一些可视性较差的任务，这些任务会导致项目计划延长20%~30%。
典型错误26：后期赶进度
一种重新估计的错误是对计划拖延的不适当的反应。当项目落后于原计划进度时，很多都是简单的决定将进度赶上原计划时间，但他们从来都做不到。
另一种重新评估错误来自于产品。如果你正在构建的产品发生了变更，你需要构建的时间也需要变更。
典型错误27：鲁莽编码
传统的“边编码边修改”方法和含糊进度的结合大多以失败告终。
产品相关的错误
典型错误28：需求的镀金
项目开始时，有些项目具有比实际需求多得多的功能，用户往往对复杂的功能并不感兴趣，而复杂功能的增加与开发进度延长的时间简直是不成正比的。
典型错误29：功能蔓延
在整个项目中平均仍有25%的需求变更，这样的变更对软件计划至少会有25%的影响，这对快速开发项目可能是致命的。
典型错误30：开发人员的镀金
开发人员着迷与新的技术，在自己的产品中实现其他产品中发现的华而不实的功能，而不管这些功能是否需要。设计、实现、测试、文档化以及支持这些不必要的功能会延长整个项目的进度。
典型错误31：又推又拉的交易
当项目管理者批准项目延期时并根据更改后的进度加入新的任务时，已经表明管理者已经含糊的承认进度有问题。一旦纠正了进度，同一个人仍然会采用明确的行为再度犯错。
典型错误32：研究导向的开发
如果你的项目存在要求创建新的算法逻辑或者采用新的计算技术这样的计算机科学约束，你就不能做软件开发，只能做软件研究。软件开发进度是完全有理由可以预测的，而软件研究进度甚至理论上都不可预知的。
技术相关的错误
典型错误33：银弹综合症
当项目组锁定到一种新的方法，新的技术或严格的过程上，并期望它们来解决进度问题时，他们是不可避免要失望的。
典型错误34：过高估计了新技术或方法带来的节省量
项目组应该预见到对生产效率的提高应该有所计划，采用新技术而带来的生产率的提高最高可达到10%，而不能假设可以提高1倍的生产率。
项目重复使用以前的项目代码，是过高估算的一个特例。重用是一种非常有效的方法，但时间节省很少像预期的那样多。
典型错误35：项目中间切换工具
当在项目中间更换工具时，伴随采用新工具而来的人员学习和掌握的过程、重复的工作、不可避免的错误会彻底抵消它带来的益处。
典型错误36：缺乏自动的源代码控制手段
缺乏自动源代码控制会使项目遭受不必要的风险。
