ITPub博客

首页 > Linux操作系统 > Linux操作系统 > XP中的用户需求分析:Planning Game 和 User Story概述

XP中的用户需求分析:Planning Game 和 User Story概述

原创 Linux操作系统 作者:agile_boy 时间:2009-03-27 17:36:17 0 删除 编辑

Extreme Programming 中的需求分析,是通过Planning Game 完成的。虽然我们从Planning 
Game开始,讨论Extreme Project的具体过程,但实际上,Planning Game中的一些阶段几乎贯穿了项目
开发的始终。(用Game这个词,可以让大家的心理放松些。)

        做计划,是一件说起来容易做起来难的事情。做计划时,程序员考虑的是怎么样编程更快;项
目经理考虑的是到底程序员多久才能做完这些事情;客户考虑的是多久时间后拿到多少东西……一开始
就全面考虑这些问题当然没有什么不对,但计划和任何事情一样,都是一步步完成的。

Planning Game 分为三个阶段,探测、计划和调整。

探测阶段:客户和开发人员一起把需求分解成很多小的,可估算的部分。
计划阶段:客户和开发人员一起制订发布计划。
调整阶段:客户和开发人员一起,在开发过程中,根据实际情况,及时调整原有的计划或者制订新计
划。

象所有的棋牌游戏一样,XP的Planning Game有它的牌(棋)、目标、玩家和游戏规则。

牌(棋):Planning Game中的牌(棋)是User Story。每个User Story都是一个很小的用户需求;经
常是几个词或者一、两句话。每个User Story都写在一个卡片上,卡片上列出了它的商业价值和开发成
本。因为一个User Story的商业价值与开发成本可能和另一个User Story的取舍密切相关,所以这些卡
片有时候看起来比较复杂。

目标:如果我们把产品比作一个盒子,那么游戏的目标就是,在游戏结束时,使盒子中的Story卡上的
商业价值总和尽可能地最大。

玩家:客户和开发人员。

游戏规则:

写Story:游戏中的任何时候都可以将一个新的用户需求写成一个Story。每个Story除了包含它的商业
价值(客户眼中的优先级)外,还有足够的内容以便开发人员估计开发成本。

估计Story:开发人员估计每个Story的理想开发周。如果大于2周,则应该把该Story分解(这个分解过
程,可能会导致多个Iteration。)。如果估计开发时间很短(比如半个小时),则可以考虑在适当时
候把它和另一个Story合并。

制订发布(Release)计划:客户和开发人员一起,决定哪些Story是这一次发布要完成的,哪些是下一
次发布时要完成的,什么时候交付产品,产品应该包括哪些Story。制订发布计划时有两种出发点,基
于Story和基于时间。

基于Story:客户把一些Story卡归为下一个发布计划要完成的内容。每放一张卡,客户描述这个Story
的内容,开发人员估算这个Story的开发时间和发布日期。

基于时间:客户指定了一个交付日期或者发布日期。开发人员估算从现在到那个日期之间,可以完成多
少工作(多少个理想工作周),然后由客户来选择要完成哪些Story,所有选中的Story的总开发时间应
该小于开发人员估算的理想工作周总数。
商业价值和开发风险优先:尽量将商业价值高的Story安排在早期计划中(商业价值优先);尽量将高
开发风险的Story安排在早期计划中(开发风险优先)。开发人员将Story排列后,应该可以承诺在几个
星期内,给客户一个可工作的,但是比较粗略的系统。

纠正估算:比如,开发人员以前估计可以在交付日期之前完成20个Story,但是开发过程中,通过不断
地计算开发速度和重新评估,发现只能完成15个Story。客户就从原来的20个Story中挑选5个放到下一
期开发中。(有时候,客户也有可能为得到所有的Story而延迟交付日期。)

更正商业价值:客户可以随时更改每个Story的商业价值(优先级)。相应地,开发人员根据这些更改
调整Story的开发次序。

引入一个新Story:客户可以随时加入一个新Story。开发人员要估算开发成本和风险。如果客户要求在
这次开发中完成这个Story,开发人员要和客户一起,按照商业价值和开发风险优先的原则,重新估算
相关的Story。

分解一个Story:客户把一个大的或复杂的Story分解成两个或更多的小Story。客户要估计每个分解后
得到的Story的商业价值;开发人员要估算开发成本。分解Story,通常是因为这个Story不可能在短期
内由少数人完成。

Spike:客户可以让开发人员集中资源,用很短的时间(可能是两、三天)来证明一个想法的可行性或
应付一个紧急情况(比如恢复数据)。如果这个需求比较复杂(不是打个小补丁),用户应该把它写成
一个Story。这个Story也应该按照商业价值和开发风险优先的原则被评估。Spike通常都是会影响开发
速度的。

重新估算:开发完一个Story后,开发人员重新估计剩下的Story,可能会发现以前过高估算了自己的开
发能力,也有可能发现开发时间可以缩短。

 

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

请登录后发表评论 登录
全部评论

注册时间:2008-07-01

  • 博文量
    120
  • 访问量
    118817