从基于ERP&MES的软件系统开发入行,已到七年之痒;超过四年的IT开发团队管理经历;始终致力于帮助我的团队不断进步:从技术选型,多次技术升级,到尝试导入CMMI,导入绩效管理,导入ITIL,导入敏捷。。。很多事不能一次做好,但求持续改善。。。 过了而立之年,遇到了我人生又一个重要MileStone,也是职业生涯第一个PhaseExit,这里的每一篇人生感悟,职业生涯的体会,权当是我的Review Report,愿与您分享,亦感激您的关注!2009年-7月

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

上一篇 / 下一篇  2009-08-17 13:13:46 / 个人分类:Agile&Scrum

      在我的开发团队中,需求分析人员对于敏捷过程仿佛是具有天生的排斥基因,似乎需求过程已成为整个团队或者说一个敏捷项目的瓶颈所在。
      在开发工程师听来如此动听的敏捷宣言,对于需求分析师来说就像是青春期少年吟出的爱情诗歌,浪漫却毫无现实意义。
敏捷宣言ITPUB个人空间"q8O BL9Y[:g,P
  • 个人和协作胜过过程和工具
  • 可以工作的软件 胜过 面面俱到的文档
  • 客户合作 胜过 合同谈判
  • 响应变化 胜过 遵循计划 
ITPUB个人空间 ryw}%k t
      今天刚开始翻看另一本讨论需求过程的书《掌握需求过程》-第二版(《Mastering the Requirements Process》-英国Robertson夫妇合著),发现这是我看到的第一本站在敏捷方法学的角度,探讨需求过程的书。其中的很多观点让我着实忍不住打出来与大家分享。因为至少我个人目前为止,还没看到一篇论述需求过程的文章,能够如此客观和理智地和极富指导意义地,论述需求与敏捷的关系。
    以下蓝色字体部分为这本书中的摘抄,非本人原创。

9{o6H{ H'^QxK0
  • 敏捷方法影响了人们开发软件的方式,使人们更注重紧密的客户关系,而减少了对文档的腔调,我们衷心赞赏这种改进。                                                                                       
  • 敏捷方法学导致了人们对文档的轻视,这种轻视是健康     的。                                                                                            
  • 我们建议在一些情况下可以没有正规编写的需求而成功地开发软件,但我们从不建议在不理解需求的情况下就开发软件。                                                                                        
ITPUB个人空间p5d d-`BCB_
关于敏捷宣言ITPUB个人空间0O5b b2k9|
  1. 个人和协作胜过过程和工具                                        
    k^x;Z2t ~F0所有的Stakeholder,他们是需求的来源。......所有确定需求的技巧,都涉及与相应的stakeholder之间的互动。...没有什么工具或过程可以取代需求分析以及与stakeholder坐下来面对面地讨论需求......
  2. 可以工作的软件 胜过 面面俱到的文档                      ITPUB个人空间Ns|6BD#cxyB&Z
    需求过程并不是一个长而曲折的过程,最终交付一个谁也不会去读的规格说明书,并要求客户在上名签字。在后面讨论迭代式开发是,将讨论如何只为下一个发布版本收集需求并实现需求。......只有诸如将技术设计和编程外包时,我们才会建议开始构建之前编写完整的规格说明书。
  3. 客户合作 胜过 合同谈判                                              
    0mD:oKE!Y0k8iu0协作方式是否目前最有效的确定产品需求的方法。......编写需求不是为了成为与客户签订的合同。而是为了确保双方对需要的东西有共同的,可以论证的正确理解。不要要求客户在需求上签字,应该要求客户参与需求......
  4. 响应变化 胜过 遵循计划                                              ITPUB个人空间6s$Rb"_E
    好的需求实践可以让变更在生命周期尽早发生,这时变更的代价是最低的。通过使用迭代的模型,如场景和原型,需求分析师会让stakeholder在构建软件前就提出变更。

TAG: 敏捷 需求 敏捷宣言

站在左岸对面 引用 删除 gracezjr   /   2009-09-16 09:52:14
1.他们不愿尽快交付需求文档,总认为与用户的沟通还不充分,而他们把这都归咎于“用户还没想好”
2.他们对于先期提交的部分需求文档,不愿承担责任!因为那只是部分,不是全部!他们认为他们还没有完成全面的需求工作,所以要他对那部分文档的准确性负责是不合理的,他们觉得后期变更的代价应该由客户去承担甚至应该由敏捷过程来承担!
太极.敏捷.对象 引用 删除 张恂   /   2009-08-20 14:40:38
“在我的开发团队中,需求分析人员对于敏捷过程仿佛是具有天生的排斥基因,似乎需求过程已成为整个团队或者说一个敏捷项目的瓶颈所在。”

他们有什么具体的排斥理由吗?

敏捷需求通常采用演进式需求分析方法。
西西里 引用 删除 sissili   /   2009-08-17 18:03:22
从敏捷宣言中解析敏捷过程中的需求分析这篇文章已被推荐到敏捷开发圈子中。
 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

Open Toolbar