《程序员》2009年2月刊，第70页有一篇如题的文章，比较清晰的阐明了敏捷与传统方法在分析时机、划分单位、细化过程、文档要求和应对变更五个方面的差异。摘抄要点如下：
传统需求分析
敏捷需求分析
需求分析时机
更多地集中在项目早期
近乎均匀地贯穿于项目的整个生命周期
需求划分单位
基于功能分解，划分模块或子系统，一个模块或子系统的颗粒度通常较大
基于能否独立业务价值，切割成一个个用户故事，一个故事有时会跨越传统的模块或子系统边界；故事的颗粒度较小
需求细化过程
一步到位，可供开发人员设计开发
逐步细化，仅就下一个迭代需要实现的部分进行详细分析
需求文档要求
正式文档，往往有明确的格式要求。既作为设计开发人员必须严格遵守的规约，也作为向客户提交的必备产出物之一。难维护，难验证（跟踪）
非正式文档。仅仅是辅助开发团队与客户沟通，不作为规约，也不作为必备产出物。更多强调通过自动化功能测试用例来跟踪系统需求
应对需求变更
有严格的控制流程，视变更为风险
视变更为必然或预期中的事情
敏捷方法中需求文档的作用和传统方法不同：
- 需求文档不是需要严格评审的项目产出物
- 不用担心需求文档过时或已经与系统不符
- 文档没有固定的格式，视沟通的需要而定
- 鼓励非文档方式的沟通
选择敏捷或传统过程与方法的考虑因素
需求易变
需求稳定
客户或业务人员随时可找到并与之沟通
客户或业务人员较难接触到
客户更在意产品投入市场或系统投入运营所需的时间
客户更在意产品或系统是否覆盖了制定的需求或功能范围
团队（包括交付团队和客户团队）成员分布在同一地域
团队成员分布在不同地域
交付团队拥有更多的开发过程自动化技能及工作环境，诸如自动化测试、持续集成等
交付团队拥有较少的开发过程自动化技能及工作环境
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
