在我的开发团队中，需求分析人员对于敏捷过程仿佛是具有天生的排斥基因，似乎需求过程已成为整个团队或者说一个敏捷项目的瓶颈所在。

在开发工程师听来如此动听的敏捷宣言，对于需求分析师来说就像是青春期少年吟出的爱情诗歌，浪漫却毫无现实意义。

敏捷宣言

个人和协作胜过过程和工具
可以工作的软件 胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划

今天刚开始翻看另一本讨论需求过程的书《掌握需求过程》-第二版（《Mastering the Requirements Process》-英国Robertson夫妇合著），发现这是我看到的第一本站在敏捷方法学的角度，探讨需求过程的书。其中的很多观点让我着实忍不住打出来与大家分享。因为至少我个人目前为止，还没看到一篇论述需求过程的文章，能够如此客观和理智地和极富指导意义地，论述需求与敏捷的关系。

以下蓝色字体部分为这本书中的摘抄，非本人原创。

敏捷方法影响了人们开发软件的方式，使人们更注重紧密的客户关系，而减少了对文档的腔调，我们衷心赞赏这种改进。

敏捷方法学导致了人们对文档的轻视，这种轻视是健康的。

我们建议在一些情况下可以没有正规编写的需求而成功地开发软件，但我们从不建议在不理解需求的情况下就开发软件。

关于敏捷宣言

个人和协作胜过过程和工具
所有的Stakeholder，他们是需求的来源。......所有确定需求的技巧，都涉及与相应的stakeholder之间的互动。...没有什么工具或过程可以取代需求分析以及与stakeholder坐下来面对面地讨论需求......
可以工作的软件 胜过面面俱到的文档
需求过程并不是一个长而曲折的过程，最终交付一个谁也不会去读的规格说明书，并要求客户在上名签字。在后面讨论迭代式开发是，将讨论如何只为下一个发布版本收集需求并实现需求。......只有诸如将技术设计和编程外包时，我们才会建议开始构建之前编写完整的规格说明书。
客户合作胜过合同谈判
协作方式是否目前最有效的确定产品需求的方法。......编写需求不是为了成为与客户签订的合同。而是为了确保双方对需要的东西有共同的，可以论证的正确理解。不要要求客户在需求上签字，应该要求客户参与需求......
响应变化胜过遵循计划
好的需求实践可以让变更在生命周期尽早发生，这时变更的代价是最低的。通过使用迭代的模型，如场景和原型，需求分析师会让stakeholder在构建软件前就提出变更。

ITPub博客

从敏捷宣言中解析敏捷过程中的需求分析

最新文章