1. 开发基础
1.1. 管理的原则
1.1.1. 项目估算
1.1.2. 计划
1.1.2.1. 项目估算与时间进度
1.1.2.2. 确定项目人员、加入时间
1.1.2.3. 确定项目组运作方式
1.1.2.4. 确定项目生命周期模型
1.1.2.5. 管理风险
1.1.2.6. 确定项目策略（如何控制产品特色、是否外包）
1.1.3. 跟踪（项目可视化）
1.1.3.1. 管理级别的跟踪控制
1.1.3.1.1. 任务列表
1.1.3.1.2. 进展状况会议
1.1.3.1.3. 进展报告
1.1.3.1.4. 里程碑审查
1.1.3.1.5. 预算报告
1.1.3.2. 技术级别的跟踪控制
1.1.3.2.1. 技术审查
1.1.3.2.2. 技术审计
1.1.3.2.3. 里程碑的质量检查
1.1.4. 度量
1.1.4.1. 搜集基准数据（生产率、代码行与质量）
1.2. 技术的基本原则
1.2.1. 需求管理（正确的将需求摆在首位）
1.2.1.1. 需求分析（业务模型分析、数据流分析）
1.2.1.2. 系统建模实践（数据流图表、实体关系图表、状态变迁图表）
1.2.1.3. 与客户的沟通实践
1.2.1.3.1. 用户界面原型
1.2.1.3.2. 常规会议实践
1.2.1.4. 需求管理与项目生命周期模型的关系
1.2.2. 设计
1.2.2.1. 主要设计风格(面向对象设计、结构化设计、数据结构设计)
1.2.2.2. 基础设计概念（信息隐匿、模块化、抽象、封装、层次、算法、数据结构）
1.2.2.3. 标准设计（异常处理、国际化、数据存储、日志、输入/输出、内存管理、数据库设计、性能）
1.2.2.4. 对特定领域设计的独有考虑（财务、科学、嵌入式、实时、安全）
1.2.2.5. 架构安排（子系统组织、分层结构、子系统通信方式）
1.2.2.6. 设计工具的使用
1.2.3. 构建
1.2.3.1. 编码风格
1.2.3.2. 特定数据类型的使用原则
1.2.3.3. 控制相关的概念（条件的使用、循环的使用、复杂度的控制、递归）
1.2.3.4. 断言和其他以代码为核心的错误检测方法
1.2.3.5. 打包
1.2.3.6. 单元测试与调试
1.2.3.7. 持续集成
1.2.3.8. 代码优化策略
1.2.3.9. 与特定编程语言相关的其他事情
1.2.3.10. 构建工具（编程环境、IDE、代码版本控制、构建工具、依赖管理）
1.2.4. 软件配置管理
1.3. 质量保证的基本原则
1.3.1. 易错模块的辨别（20%的模块包含了80%的BUG）
1.3.2. 测试
1.3.2.1. 单元测试（10%-50%）
1.3.2.2. 系统测试（20%-60%）
1.3.2.3. 最终用户发现
1.3.2.4. 其他查错技巧（回顾）
1.3.3. 技术回顾
1.3.3.1. 走查
1.3.3.2. 代码Review
1.3.3.3. 检查
1.4. 按照最佳实践来做
2. 风险管理
2.1. 风险评估
2.1.1. 风险识别
2.1.1.1. 功能蔓延
2.1.1.2. 需求镀金或开发人员镀金
2.1.1.3. 质量低劣
2.1.1.4. 计划过于乐观
2.1.1.5. 设计欠佳
2.1.1.6. 银弹综合症
2.1.1.7. 人员薄弱
2.1.1.8. 外包失败
2.1.1.9. 与客户发生摩擦
2.1.2. 风险分析
2.1.2.1. 风险暴露量
2.1.2.2. 估计损失的大小
2.1.2.3. 评估损失发生的概率
2.1.2.4. 整个项目的延期和缓冲
2.1.3. 风险优先级
2.1.3.1. 风险列表排序
2.2. 风险管理
2.2.1. 风险管理计划
2.2.1.1. 风险描述
2.2.1.2. 谁引起
2.2.1.3. 表现形式
2.2.1.4. 可能发生时间、地点、发生原因、怎样发生
2.2.2. 风险化解
2.2.2.1. 不要冒险
2.2.2.2. 将风险从系统一部分转移到另一部分
2.2.2.3. 花钱调研
2.2.2.4. 消除产生风险的根源
2.2.2.5. 接受风险（后果不严重而处理代价很大）
2.2.2.6. 发布风险（让客户、领导知道）
2.2.2.7. 控制风险
2.2.2.8. 记住风险
2.2.3. 风险监控
2.2.3.1. 前10个风险的清单
2.2.3.2. 中间检查
2.2.3.3. 专门人员
3. 避免典型错误
3.1. 人员
3.1.1. 挫伤积极性
3.1.2. 人员素质低
3.1.3. 英雄主义
3.1.4. 项目后期加入人员
3.1.5. 办公环境恶劣
3.1.6. 与客户发生摩擦
3.1.7. 缺乏有效的项目支持
3.1.8. 缺乏用户介入
3.2. 过程
3.2.1. 没有计划
3.2.2. 过于乐观的计划
3.2.3. 在压力下放弃计划
3.2.4. 缺乏足够的风险管理
3.2.5. 在模糊的项目前期浪费时间
3.2.6. 没有设计，直接跳到编码
3.2.7. 设计低劣
3.2.8. 缺少质量保证措施
3.2.9. 缺少管理控制
3.2.10. 项目估算时遗漏必要的任务
3.2.11. 后期赶进度
3.2.12. 鲁莽编码
3.2.13. 承包方（外包）导致的失败
3.3. 产品
3.3.1. 需求的镀金（性能、复杂的功能设计）
3.3.2. 功能蔓延
3.3.3. 开发人员的镀金（迷恋新技术）
3.3.4. 讨价还价、又推又拉的交易
3.4. 技术
3.4.1. 过高估计新技术、方法带来的节省量
3.4.2. 项目中间切换工具
3.4.3. 未采用版本控制工具
4. 面向进度的实践
4.1. 快速开发中的核心问题
4.1.1. 不同种类的软件要求不同的解决方案
4.1.2. 需要什么样的开发方法
4.1.2.1. 进度计划有严格限制的产品
4.1.2.2. 表面上的快速开发
4.1.2.2.1. 有过项目失控的经历，防止项目失控
4.1.2.2.2. 客户需要对项目具有可预测性
4.1.2.2.3. 客户将最低的费用与快速开发混为一谈
4.1.2.2.4. 希望开发者免费加班
4.1.2.3. 感知与现实
4.1.2.3.1. 客户期望不切实际
4.1.2.3.2. 感觉开发慢速
4.1.2.4. 时间花到什么地方去了
4.1.2.4.1. 项目越大，编码占用的时间越少
4.1.2.4.2. 可以改善的地方
4.1.2.5. 开发速度的平衡
4.1.2.5.1. 费用、进度和产品的平衡
4.1.2.5.2. 质量的权衡（质量指的的是可用性、有效性和健壮性，不是代码质量）
4.1.2.5.3. 个人效率的权衡（合适的团队规模）
4.2. 实现快速开发的实践
4.2.1. 项目生命周期模型
4.2.2. 估算
4.2.3. 进度计划
4.2.4. 面向客户开发
4.2.5. 激励机制
4.2.6. 团队合作
4.2.7. 团队结构
4.2.8. 功能限定
4.2.9. 生产率工具
4.2.10. 项目修复