新方法学
从无、到繁重、再到敏捷
- 工程方法（计划驱动方法）
- 对开发过程有着严格而详尽的规定
- 官僚繁琐，按照要求来会有太多事要做，从而延缓整个开发进程
- 敏捷方法
- 在无过程和过于繁琐的过程中达到了一种平衡
两者的区别
- 表面区别
- 敏捷型方法通常只要求尽可能少的文档，面向源码
- 本质区别
- 敏捷型方法是适应性而非预见性
- 敏捷型方法是面向人而非面向过程的
预见性和适应性
软件开发模拟工程学科 软件工程方法
- 我们想要可预见的生产进度计划，以便能使用技能较低的人员
软件开发中的设计与建造
- 软件开发中所有工作都是设计
- 创造性的过程是不太容易计划的
- 我们应该对用传统工程模式来进行软件开发的做法保持足够的警觉，因为它们是不同类型的活动，因此需要不同的过程
需求的不可预见性
- 需求变更是常态，问题是我们如何来处理它
- 一种方法是把需求变更看成是因需求工程没作好而导致的结果
人们期待需求应该是可变的
- 要准确获取所有需求是困难的，特别是当开发商不能提供某些需求的费用信息时
- 作软件开发的费用估算是不容易的，这有多种原因
- 软件开发是一种设计活动，难以精确计划
- 系统的基本材料变化非常之快
- 开发活动极大地依赖于项目参与人员，而个体是难以预测和量化的
- 软件的不可触摸性
- 在系统建成之前，有时很难判断一项功能的具体价值
软件开发的一切都取决于系统需求，如果需求不固定，你就不能订出一个可预见性的计划
预见性一般不可能，但像航天飞机这种可以
不可预见过程的控制——迭代
- 最重要的，也是最困难的是要随时知道我们在开发中的情形处境，这需要一个诚实的反馈机制来不断准确地告诉我们
- 迭代式开发的要点是经常不断地生产出最终系统的工作版本
- 理由是：没有什么比一个集成了的、测试过的系统更能作为一个项目扎扎实实的反馈
- 一个稳定的计划只能是短期的，这通常是一个迭代周期
- 一般趋势是让每一个周期尽可能地短，从而获得频繁反馈
适应性的客户
- 通常敏捷方法是固定合同中的时间和价格，而让范围能够可控制地变化
- 每一个迭代阶段，客户检查开发进度，也能变更软件开发方向
- 这种开发的“回应性”是很好的
- 后期的需求变化是个很大的优势，业务人员在开发过程中梳理他们的需求，在系统建造中把这些变化进快地整合进去
成功的标准
- 预见性项目
- 在规定时间和预算内完成
- 敏捷型项目
- 商业价值，即客户得到的软件价值是否大于他们的投入
一个好的预见性项目是依计划而行，而一个好的敏捷型项目会建造出一个与最初计划不太一样却是更好的软件
把人放在第一位
传统正规方法认为个体是不重要的，只有角色才是重要的
泰勒主义的关键理念是认为干活的人并非是那些知道怎样才能把这件活干的好的人
- 泰勒主义只有当计划者比实际操作者更知道怎样做时才有效，不适用于软件开发
面向人的过程管理
- 实施敏捷型过程的一个关键之处是让大家接受一个过程而非强加一个过程
- 开发人员必须有权作技术方面的所有决定
之所以强调开发人员的作用，一个重要的原因是IT行业的技术变化速度非常之快。今天的新技术可能几年后就过时了。这种情况完全不同于其他行业。即使管理层里的以前做技术的人都要认识到进入管理层意味着他们的技术技能会很快消失，因此必须信任和依靠当前的开发人员
度量的困难性
- 一个过程，规定工作应该如何来做的人不是具体来干的人，那么你需要一些方法来度量干工作的人是否工作有效
- 度量软件是非常困难的
度量时，你必须获取影响这种度量的所有重要因素，否则会失效，所以得在两种方法中作选择
- 基于度量的管理
- 适合简单的、重复性的工作
- 传统方法的假设是基于度量的管理是最有效的管理
- 委托式管理
- 干工作的人决定该怎么干
业务专家的引领作用
- 技术人员需要与应用领域的业务专家非常紧密的联系
- 因为需要经常不断联系沟通以使每个人都能及时知道这些变化
自适应过程
-
另一种适应性（之前那种是指在一个开发项目中如何频繁地修改软件以适应不断的需求变更）
-
过程本身随着时间推移变化
- 一个项目在开始时用一个适应性过程，不会到一年之后还在用这个过程。随着时间的推移，开发团队会发现什么方式对他们的工作最好，然后改变过程以适应之
改善自适应过程
- 有哪些做的好的部分
- 有哪些教训
- 有哪些可以改进的部分
- 有哪些没搞清楚的部分
走向敏捷
- 找到合适的项目来全面试验敏捷方法
- 让客户接受敏捷型方法
- 从一个便于管理的小系统开始
- 选择对业务影响小的项目开始
不适合敏捷方法的情况
- 主要取决于人
- 如果有关人员对敏捷方法所要求的密切的合作不感兴趣，那就算了，不要强加