敏捷方法和计划驱动方法各自的擅长领域 |
特征 | 敏捷方法 | | 计划驱动方法 |
应用 | | | |
主要目标 | 快速提供价值:响应变更 | | 可预见性:稳定性;高可靠性 |
规模 | 较小的团队和项目 | | 较大的团队和项目 |
环境 | 难控制:高度变更;以项目为中心 | | 稳定:少变更;以项目/组织为中心 |
管理 | | | |
客户关系 | 专职的现场客户:关注于排定有线级别的增量开发 | | 根据需要和客户进行交互:关注合同规定 |
计划和控制 | 内部的计划;定性控制 | | 文档化的计划:定量控制 |
沟通 | 隐式的人与人之间的知识 | | 显式的文档化的知识 |
技术 | | | |
需求 | 排定优先级的非正式的用户素材和测试用例;会经受不可预见的变更 | | 规范化的项目、性能、接口、质量和可预见的演化需求 |
开发 | 简单设计:短增量:认为重构代价低廉 | | 大量的设计:较长的增量:认为重构代价昂贵 |
测试 | 测试用例可以执行并用来定义需求 | | 文档化的测试计划和规程 |
人员 | | | |
客户 | 专职的,工作在一起的CRACK*型客户 | | CRACK*型客户,并不总是工作在一起 |
开发者 | 至少有30%全职Cockburn级别2和3型专家:不要级别1B和-1型人员** | | 初期需要50%Cockburn级别3型人员:始终需要10%Cockburn级别3型人员:需要30%级别1B的可用人员,不要级别-1的人员** |
文化 | 通过更多的自由度来达到舒适和权力(靠混沌得以繁荣) | | 通过政策和规程框架来达到舒适和权力(靠秩序得到繁荣 |
*易于协作、有代表性、有授权、尽责、在行
**这些数字会随着项目复杂性的不同而显著变化 |