胡ؕ说说Q里面肯定存在着不少的错误,q请高手指正?
Use Stories是pȝ要实现的功能。它表述h非常的简单,一个Use Stories只需要几句话可以写完。之所以这h因ؓ用户需求的l节是非常易变的Q而其高层描述却是相对E_的。所以我们可以通过使用Use Stories的方法来从高层确定需要开发的内容Q这些单U的Use Story相当于系l中可能的点Q而由我们通过与用户交所得到的所有Use Stories则构成了一个面Q它是整个pȝ所需要实现的功能?
深入思考上面这D话的含义就会发现Use Stories在整个项目的初始分析阶段L作用只是一个占位附。他告诉我们q样功能在实作的时候应该要实现Q但是具体需要实C么,怎么实现则是在P? q程中的分析阶段所需要的事情。所以在写Use Stories的时候请切记Q一定要单概括,不可明确描述实现l节斚w的问题?
说到q里׃能不说一下Use Story与Use Case的关p,我个为Use Story是一个更高层的分析阶D,它的抽象层次非常的高Q如前面所_它是一个占位符Q而在具体对一个Use Storyq行分析的时候则可以使用Use Case分析技术,一个Use Story分解成ؓ若干个Use Case。当然上面这D|q的前提是需要开发的pȝ_的大Use Story对相对较大,一个Use Story可以折分一pdUse Case。但是如果项目的规则相对较小Q那么可以直接用Use Case来取代Use StoryQ这个在开发的时候需要灵zȝ掌握Q不可死板追求到底用Use Storyq是Use Case?
Use Story中除了包含对功能的简单描qC外,q可以酌情加入对异常情况的描q。虽然在具体分析一个Use Story的时候还需要将其异常情况进行详l的列出Q但是在撰写Use Story的时候还是有必要的尽可能的将它们列出Q其原因在于Q对异常情况的描q可以帮助我们发C些在正常情况下无法体现出来的Use Story之间的关pR这Ҏ们撰写Use Story的描q部分是有一定的帮助的,另外也可以在q个初始阶段提出一些问题,然后{待q入具体q代的分析阶D|再进行解{?
Use Story内的描述只是开发者系l的一个最初步认识Q所以以后开发者在实际开发时参考这些Use Story时一定要持着一U怀疑态度Q再重复一ơUse Story只是寚w层系l一部分的抽象度非常高的描述。用户在具体开发的时候应该维护一份Use Story列表Q如果在实际开发一个Use StoryQ或者这个Use Story所对应的某一个Use CaseQ的时候,遇到了对其它Use Story有媄响的问题应该在这份Use Story列表当中标出。以便我们在q些受媄响功能进行分析的时候可以尽量多的认识到q些影响它的问题。?
用户在对Use Storiesq行优先U的排序后,q个序虽然不是在未来完成整个系l的q程中实现Use Story的顺序(因ؓ需求是易变的)Q然而一般情况下q个Use Stories的优先排序Q却军_了第一?q代的开发内宏V优先高的Use Story应该先完成,q是直面风险的一U方式,按照XP的描q来看, 用户认ؓ优先U越高的Use Story所存在商业价值就大Q当然其风险和不定性也p大,所以我们应该先实现它?
在用L定了W一ơP代过E中所需要开? 的Use Stories后,那么我们可以将q些Use Stories分解成相应的d了,注意Q用戯然ؓW一ơP代选择了相应的Use SotriesQ但是这些Use Stories却未必会在第一ơP代当中完成,因ؓ正如前面所说Use Stories的作用只是一个占位符Q我们通过Use Stories所了解的系l功能只是极为抽象的内容Q单凭这些内Ҏ们是无法估算出完成一个认识所需要的具体旉的,所以在军_开发一个Use Story的时候需要对q个Use Storyq行q一步的分析Q将q个Use Story拆解成若q个d。折解的目的是Use Story所被折解成的Q务将都是可以q行开发时间评估的Q大基本可知)Q只有这Ld开发h员实际工作v来才会感觉到心里有数Q一个Use Story所表示的抽象范围比较广Q可以先这个Use Story折解成若q个Use Case或者更的Use StoryQ再一ơ,Use Case要比Use Story的抽象极别低Q,然后再将具体的Use Case折解成具体可以进行评估的d。而如果我们对一个Q务无法进行评估的话,那么可能p明我们Q务还有细分的余地Q我们可以将它拆解成更小的Q? Q当然这里有一U情冉|׃团队内的开发h员都不清楚Q务所涉及到的专业知识Q所以造成无法对Q务的工作旉q行评估Q在q种情况下,可能需要一个此? 域的专家帮忙了,或者如果没有这h件的话,那么开发团队在l过对这U专业知识的短时间学习后再对dq行评估Q,或者重新评C用此技术所付出的代h 否可以在一定的成本范围之内Q?
在对Use Storyq行拆解的过E当中经怼遇到的一个问题就是可以从q一步的分析q程当中得到一些浅在的Use Story或者Use Case。可以将q些Use Story或者Use Case加入到列表,然后评估其是否有必要被加入到本次q代Q如果有的话Q那么一q进行分析,如果没有的话Q那么将其安排到其它的P代中来完成?
在拆解Q务的q程中,我们应该保持Ҏ? 问题的注意力QD个例子来_比如说我们要处理一个发送信息到指定用户的Use CaseQ这个Use Case核心的问题就是将信息成功的发送到指定用户处,而在拆解q个Use Case的时候我们发现校验收件h用户是否有效的操作也是一个相Ҏ较复杂且工作量比较大的工作,因ؓ它涉及到与帐Ll的配合工作。在q个时候我们所? 取的{略应该是用h验操作视为完成整个发送信息过E操作当中的非核心步骤,不需要对q个问题太过U缠。在分析的时候只需要把它当做一步操作,而在? 做的时候也只需要定义一个用h验的接口Q然后用Mock对象的技术来满发送邮件时对用h验系l的需求即可?
另外在拆解Q务的q程当中q应该注意的一
ҎQ不应该让我们所能够承受的复杂度和负载度标Q比如说当我们发C一个Use Story分解出来的Use
Case复杂的以让我们不能够一ơ对付他们的时候就应该明智的将对Use Story的分析改成对某一个或者某几个特定Use
Case的分析。只有用客中化整ؓӞ各个ȝ的策略才能够使我们在面对大型软g的时候保持我们的控制力。?
Archie的评价?2004.10.07
虽然不能准确的对故事q行估算Q但是还是要q行估算的,而且团队的速度也是用故事的度量单位来衡量,而不是Q务?
要进行估就要对故事q行比较详细的了解,要和客户q行大量的沟通,了解C么程度呢Q能q行估算了ؓ止。?