敏捷需求分析[1]

发表于:2007-05-14来源:作者:点击数: 标签:敏捷分析需求人的很多
在很多人的印象中,敏捷软件 开发 是种类似黑客行为的过程,是 程序员 最爱的勾当。不写文档,不作 需求分析 ,没有 项目经理 ,做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要,因此在经过考虑后,放弃了

  在很多人的印象中,敏捷软件开发是种类似黑客行为的过程,是 程序员最爱的勾当。不写文档,不作需求分析,没有 项目经理,做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要,因此在经过考虑后,放弃了敏捷方法。

  真的是这样吗?敏捷过程到底是如何做需求分析?用户故事和用例有什么区别?敏捷过程如何去管理需求的?这些是一些想要实践敏捷的人一直在困惑的事情。

  我们常常看到书中讲,程序员拿到一个用户故事后,怎么计划,怎么分解,怎么写单元测试,怎么小步前进,怎么持续集成。这是典型的程序员视角。事实上,敏捷方法分为三部分,敏捷项目管理,敏捷需求分析,敏捷软件开发。上述书中提到的完全是敏捷开发中的实践,很多人了解到的敏捷,只是敏捷的三分之一。

  在敏捷的 团队中,作一个敏捷程序员确实是非常舒服的事情。从程序员的角度来看,只需要选择一张他感兴趣的故事卡片,了解清楚该卡片的需求,开始从功能测试写代码,等通过了所有测试就完工。基本上不需要考虑太多的事情,非常轻松愉快。但程序员向谁去问清楚需求?故事卡片是怎样写出来的呢?让我们来关注开发前发生的事情。

  了解敏捷过程的人都知道,Kent Beck在XP过程中提到了现场客户,如果一个敏捷团队能够有现场客户,这当然是最棒的事情。但多数情况下,客户都是很忙碌的,很难全力投入到软件开发过程中。这时候,我们就需要商务分析师这个角色,来充当客户的角色。

  我在ThoughtWorks的团队中担任的就是商务分析师这个角色。商务分析师最重要的职责就是与客户交谈,了解和分析需求,将其制作成用户故事并将需求转述给程序员。同时,商务分析师也要代替客户负责功能验收测试

  敏捷思想的核心是人与交流。需求问题实际上是一个交流问题。商务分析师要和客户交流,搞清楚客户到底需要什么,到底为什么需要这些东西。商业价值是商务分析师关注的最终目标。有了目标的指向,就可以不迷失方向。和客户进行交流,最终目的就是挖掘出客户的商业目标。可能大家会经常有这样的经验,客户说,我要这个功能,我想要怎么怎么样。这时候要特别注意,他说的这些东西并不是真正的需求。商务分析师需要详细的问客户为什么,挖掘出他真正的目标。

  在这个目标下,商务分析师开始进行需求的分析:我们到底是否真的需要这个需求?有没有更好的解决方案?有没有简单并且低廉的方式?换一种形式是不是也能达到这样的需求?这个需求有多少地方涉及到以前的软件变更?

  搞清楚这些事情后,就可以写出用户故事。用户故事的书写遵循一定的原则,一般包括三部分:"作为(系统的一个涉众),我想要(做一件事),从而(达到一个商业价值)"。在书写的时候格式比较随意,可以在故事卡背面写上注释或疑问,甚至画上界面原形图。

  举一个最常见的用户故事例子,"作为一个普通用户,我希望能够用用户名和密码登录,以便我能享受到个性化的服务"。其中,用户是系统涉众,登录是他想要做的事情,而他的目标是获得个性化的服务。

原文转自:http://www.ltesting.net