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

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

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

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

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

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

敏捷方法影响了人们开发软件的方式，使人们更注重紧密的客户关系，而减少了对文档的腔调，我们衷心赞赏这种改进。                                                                                         敏捷方法学导致了人们对文档的轻视，这种轻视是健康     的。                                                                                             我们建议在一些情况下可以没有正规编写的需求而成功地开发软件，但我们从不建议在不理解需求的情况下就开发软件。

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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22110482/viewspace-612487/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22110482/viewspace-612487/