敏捷需求分析

敏捷理解

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

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

 

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

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

 

敏捷需求

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

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

 

商务分析师

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

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

用户故事

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

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

 

验收测试

从这个例子我们可以想象到,这个页面可能存在两个文本框,用于输入用户名和密码,有一个按钮来登录,并且不登录就不能看到个人资料,另外,如果用 户输入错误需要提示"登录失败请重试"。这就是可见性,也可以称为可测试性。我们可以根据这样的可见性写出功能测试,从而驱动这个用户故事的开发,这被称 为 Acceptance Driven Development。

用户故事的作用有两个,一个是作为进度跟踪的依据,一个是作为与人交谈的备忘录。用户故事卡片并不是很精确的需求,因此不需要把事情描述的非常清 楚。将需求的详细分析推迟到实现前夕来完成,这是敏捷需求分析的精华所在 。任何提前做好的东西都会导致浪费,敏捷过程提倡足够就好,避免浪费。

 

故事与用例区别

不少人对用户故事和用例的区别感到疑惑。用户故事的作用是备忘 功能,而不是文档 。而用例需要详细的描述其操作步骤,以及每个异常路径,因而起到了 文档的作用。用户故事是可见的商业价值,而不是功能描述。每个用户故事的粒度和工作量都相差不多,这和用例有很大的区别。用户故事是小粒度的,可测试的, 可见的,并且是有价值的。[注:此处存有争议,请读者辨证阅读,勿断章取义]

 

实际例子

ThoughtWorks有个项目组作的是一个网游物品交易平台。该平台是典型的互联网项目,在开工的时候客户对功能需求还不明确,但需要快速推出抢占市场,正是最适合敏捷过程的项目。

 

需求分析

在项目伊始,商务分析师和客户做了深入的谈话,了解他的商业构想,他的盈利模式,搞清楚宏观的结构 ,然后思考并整理获得的结果,花1-2天时间将 客户需求大略整理为几十个用户故事。这些用户故事并不完善,不足以做好整个系统。但对于我们开始项目的前一阵,已经足够了。我们可以从这里开始项目。

 

故事分析

敏捷方法希望快速交付可用的软件。实现软件的快速交付是通过迭代来完成。在迭代开始前,由一组有经验的开发人员大致评估一下用户故事,标记出不同 的难度和风险,并提出问题供商务分析师来获得更详细的信息,商务分析师会和相关涉众去讨论。然后商务分析师将推荐优先级最高的一组用户故事给客户来挑选 , 客户可以选择这些用户故事,或者指出从他的视角看到的优先级更高的用户故事。这些将成为下一个迭代的内容。

 

迭代交付

客户看到每个迭代交付的可运行的软件后或者得到用户反馈后,常常会有新的想法冒出来 。有些想法是好的,有些想法就属于看到别家网站有这个功能,不假思索的提出的功能。这些不同的需求都需要经过认真的分析,找出哪些是值得我们立即考虑的,哪些是不用急迫的去实现的。

 

沟通例子

有一次和客户谈话时,他说到希望增加拍卖功能。那么,我们为什么需要拍卖呢?客户说希望让用户拍卖物品以获得最高价格。经过考虑,我们发现,网游物品的实时性和唯一性决定了系统不适合使用拍卖机制。拍卖的时效性无法满足实时交易的要求,因此,用户最终放弃了这个特性。

另一次,客服人员提出增加一个查询用户交易的功能,而此时我们有其他更加重要的功能需要先去考虑,查询用户交易功能可以由技术人员临时通过数据库 直接代为查询 ,因为项目运营初期交易不是很多,暂时还不需要专门的后台功能来支持客服的工作。所以把这个需求卡片一直贴在墙壁上,始终没有排到最高的优先 级。

 

客户观点

客户一开始也不是很能够接受敏捷需求中强调商业价值和优先级 的做法。但经过几个月的磨合,客户也逐渐适应了许多敏捷思想,甚至我在和客户讨论时,偶然提起了后期的某种可能的情况,他们还能够帮我纠正应当考虑目前的情况,为近期的情况作计划。

 

项目管理

用户故事的跟踪和管理是由项目经理来进行。每个迭代跟踪卡片的进展 ,是否已经开始实现?是否已经完成代码开发?是否已经开始功能测试?不同的卡片 在迭代前都会评估为不同的大小。我们一般分为大中小三级。等实践过几个迭代后,团队的开发速度基本保持恒定,我们就可以很容易的知道每个迭代能做多少个用 户故事,这样就可以安排下一迭代的开发。

 

分析师工作

每个迭代内分析好 恰好足够下一个迭代开发的需求 ,就是商务分析师每个迭代的主要工作内容。商务分析师的需求分析工作在上一个迭代完成,包括需求的了解,分析,评估和排列优先级

 

迭代计划

在每个迭代开始的时候,由商务分析师 主持召开迭代计划会议,在会议上向所有的程序员解释这个迭代要完成的用户故事 ,然后由程序员自由提问,知道他们能够获得足够开始实现该功能的信息。

 

验收测试

在程序员完成一个用户故事后,商务分析师还要来代表客户做功能验收测试 ,查看是否完成了预计的功能,是否有程序员还没有想到的异常情况。如果存在问题需要退回给程序员继续完成。这在一定程度上保证了系统完成的需求不偏离客户的要求。当然,更多的测试还需要QA来完成。

 

本质内容

我们的实践充分表明了,敏捷过程并不是没有需求分析,而是把需求分析过程分散到整个开发的过程中 ,让开发和需求分析并行进行。这就是ThoughtWorks敏捷方法实施成功的秘诀之一。而商务分析师在这个过程中,起到了纽带和桥梁的作用,是一个团队不可缺少的角色。

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭