敏捷软件开发中的规划与架构考量
1. 需求、资源与日期
在敏捷规划里，我们依靠已知确切拥有的资源。依据项目类型，要么管理层分配一定数量的资源用于项目，要么像服务合同那样，会有特定的资源分配额度，最好不要超支，时间限制也是固定的。但需求却是不断变动的目标，所以规划是灵活的，仅包含对可能实现的需求按优先级进行的粗略估计。在适应变化时，内容是可调整的参数，实际交付成果将是在给定时间框架和资源条件下所能完成的最佳成果。每个团队都需思考如何尽可能多地完成工作。
与之相反，传统瀑布式项目管理采用的方法截然不同。它先收集固定的需求列表，然后估算实现这些需求所需的成本和时间。这种方法忽略了在大多数情况下，资源和日期是不可协商的既定约束条件。无论在规格说明中承诺处理哪些需求，团队交付的内容始终会受到团队规模和可用时间的限制。
若管理层既固定了需求，又确定了日期和资源，这既非瀑布式也非敏捷式，而是不专业且注定失败的做法。团队将陷入永无止境的紧急状态，这不可持续，最终只能降低质量。
以下是两种规划方式的对比表格：
|规划方式|需求|资源|日期|内容调整|
| ---- | ---- | ---- | ---- | ---- |
|敏捷规划|变动目标，粗略估计|固定或有限额度|固定|可调整内容以适应变化|
|传统瀑布式规划|固定列表|估算|估算|较难调整，受需求和初始估算限制|
2. 敏捷是混乱的许可证吗？
敏捷软件开发的批评者担心敏捷会导致混乱和无政府状态。他们认为，如果不在项目全程创建包含预期工作项和估算工作量的详细进度表，就无法衡量项目进度。在他们看来，在敏捷环境中，版本发布内容可能是个人追求兴
