摘要:
一件用户通过pȝ完成他一个有价值的目标Q买一|饮料)的事。这Lq程叫“用h?user case)”或者“用h?user story)”。本文描qC敏捷开发的技巧:如何以用h事管理项?
什么是用户故事(user story)
假定q个目的客h个饮料自动售货机的制造商。他们要求我们ؓ他们的售货机开发一ƾY件。我们可以找他们的市场经理了解这个Y件的需求?br />
因此Q我们的客户是他们的市场经理。谈需求的时候,有一回他q样_“用户往售货机每塞一个硬币,售货机都要显C当前该客户已经投了多少钱。当用户投的钱够买某一N料时Q代表这N料的按钮的灯׃亮。如果那个用h了这个按钮,售货机就放一|饮料到出口Q然后找雉l他。?br />
上面的话描述的是一件事情,一件用户通过pȝ完成他一个有价值的目标Q买一|饮料)的事。这Lq程叫“用h?user case)”或者“用h?user story)”。也是_上面我们的客h说的话,是在描qC个用h事(user storyQ?br />(我解释一下ؓ什么用故事q个词,没兴也可以忽略。在一个系l面前,每个用户要完成同L目标Q都要做q个pȝ讑֮的例行的事,qg事情不是一个例子,所以不叫事例,q也不是故事Q也不能一D历E,而是一个例行的事?
如果我们惌Cq段用户故事Q我们可能会用这L格式Q?br />
名称Q卖饮料
事gQ?br />
1. 用户投入一些钱?br />
2. 售货机显C用户已l投了多钱?br />
3. 如果投入的钱_买某U饮料,q种饮料对应的按钮的灯就会亮?br />
4. 用户按了某个亮了的按钮?br />
5. 售货机卖Z|饮料给他?br />
6. 售货机找雉l他?br />
注意刎ͼ一个用h事里面的事g可以q样描述Q?br />
1. 用户做XX?br />
2. pȝ做YY?
3. 用户做ZZ?br />
4. pȝ做TT?br />
5. ...
用户故事只是描述pȝ的外在行?/b>
一个用h事只是以客户能够明白的方式,描述了一个系l的外在行ؓQ它完全忽略了系l的内部动作。比如,下面有下划线的那些文字,属于不应该出现在用h事中的系l内部动作:
1. 用户投入一些钱?br />
2. 售货机将塞进来的钱存在钱里Q然后发送一条命令给屏幕Q屏q显C目前已l投入的金额?br />
3. 售货机查询数据库里面所有饮料的hQ判定钱_买哪些饮料,对于p够买的那些饮料,对应的按钮的灯就会亮h?br />
4. 用户按下一个亮h的按钮?br />
5. 售货机卖Z|饮料给用户Q然后将数据库里面该饮料的存货数量减1?br />
6. 售货机找雉l用戗?br />
不管是口头描q的Q还是书面Ş式,q样的内Ҏ描述用户故事时一个很常见的错误。特别的Q千万不要提及Q何有x据库Q记录,字段之类的对客户一Ҏ义都没有的东ѝ?br />
评估发布旉
用户故事是用来干嘛的Q假定客户希望在50天内递交q个pȝ。我们做得了吗?Z解答q个问题Q我们就要在目开始的阶段Q试着扑և所有的用户故事Q然后评C下,每一历E需要多长的开发时间。可是,怎么评估呢?
比如Q我们现在收集了下面q些用户故事Q?br />
卖饮料:如上面所说的?br /> 取消购买Q在投入了一些钱后,用户可以取消购买?br /> 输入理密码Q授权的人可以输入管理密码,然后增加存货Q设定h|拿走里面的钱{等?br /> 补充饮料Q授权的人可以在输入理密码后增加存货?br /> 取出q里的钱:授权的h在输入管理密码后Q可以取出钱里的钱里面的钱?br /> 安全警报Q有些事情经常发生的话,pȝ会自动打开安全警报?br /> 打印月销售报表:授权的h可以打印出月销售报表?br />
然后扑և里面最单的用户故事Q这里的“简单”,意思是说实现周期最短)。我们不一定非常精准的判断哪个最单。只要挑Z觉得最单的p了。比如,我们觉得“输入管理密码”是最单的用户故事。然后我们判断说Q这个用h事算1个“故事点Qstory pointQ”?br />
用户故事 故事?br />卖饮料 ?br />取消购买
输入理密码 1
补充饮料
取出q里的钱 ?br />安全警报
打印月销售报表 ?br />
不过一般我们不会列出清单,而是做出一堆卡片脓在墙上,每张卡片记录一个用h事,然后故事点写在卡片上面Q?br />
什么是用户故事(user story)
假定q个目的客h个饮料自动售货机的制造商。他们要求我们ؓ他们的售货机开发一ƾY件。我们可以找他们的市场经理了解这个Y件的需求?br />
因此Q我们的客户是他们的市场经理。谈需求的时候,有一回他q样_“用户往售货机每塞一个硬币,售货机都要显C当前该客户已经投了多少钱。当用户投的钱够买某一N料时Q代表这N料的按钮的灯׃亮。如果那个用h了这个按钮,售货机就放一|饮料到出口Q然后找雉l他。?br />
上面的话描述的是一件事情,一件用户通过pȝ完成他一个有价值的目标Q买一|饮料)的事。这Lq程叫“用h?user case)”或者“用h?user story)”。也是_上面我们的客h说的话,是在描qC个用h事(user storyQ?br />(我解释一下ؓ什么用故事q个词,没兴也可以忽略。在一个系l面前,每个用户要完成同L目标Q都要做q个pȝ讑֮的例行的事,qg事情不是一个例子,所以不叫事例,q也不是故事Q也不能一D历E,而是一个例行的事?
如果我们惌Cq段用户故事Q我们可能会用这L格式Q?br />
名称Q卖饮料
事gQ?br />
1. 用户投入一些钱?br />
2. 售货机显C用户已l投了多钱?br />
3. 如果投入的钱_买某U饮料,q种饮料对应的按钮的灯就会亮?br />
4. 用户按了某个亮了的按钮?br />
5. 售货机卖Z|饮料给他?br />
6. 售货机找雉l他?br />
注意刎ͼ一个用h事里面的事g可以q样描述Q?br />
1. 用户做XX?br />
2. pȝ做YY?
3. 用户做ZZ?br />
4. pȝ做TT?br />
5. ...
用户故事只是描述pȝ的外在行?/b>
一个用h事只是以客户能够明白的方式,描述了一个系l的外在行ؓQ它完全忽略了系l的内部动作。比如,下面有下划线的那些文字,属于不应该出现在用h事中的系l内部动作:
1. 用户投入一些钱?br />
2. 售货机将塞进来的钱存在钱里Q然后发送一条命令给屏幕Q屏q显C目前已l投入的金额?br />
3. 售货机查询数据库里面所有饮料的hQ判定钱_买哪些饮料,对于p够买的那些饮料,对应的按钮的灯就会亮h?br />
4. 用户按下一个亮h的按钮?br />
5. 售货机卖Z|饮料给用户Q然后将数据库里面该饮料的存货数量减1?br />
6. 售货机找雉l用戗?br />
不管是口头描q的Q还是书面Ş式,q样的内Ҏ描述用户故事时一个很常见的错误。特别的Q千万不要提及Q何有x据库Q记录,字段之类的对客户一Ҏ义都没有的东ѝ?br />
评估发布旉
用户故事是用来干嘛的Q假定客户希望在50天内递交q个pȝ。我们做得了吗?Z解答q个问题Q我们就要在目开始的阶段Q试着扑և所有的用户故事Q然后评C下,每一历E需要多长的开发时间。可是,怎么评估呢?
比如Q我们现在收集了下面q些用户故事Q?br />
卖饮料:如上面所说的?br /> 取消购买Q在投入了一些钱后,用户可以取消购买?br /> 输入理密码Q授权的人可以输入管理密码,然后增加存货Q设定h|拿走里面的钱{等?br /> 补充饮料Q授权的人可以在输入理密码后增加存货?br /> 取出q里的钱:授权的h在输入管理密码后Q可以取出钱里的钱里面的钱?br /> 安全警报Q有些事情经常发生的话,pȝ会自动打开安全警报?br /> 打印月销售报表:授权的h可以打印出月销售报表?br />
然后扑և里面最单的用户故事Q这里的“简单”,意思是说实现周期最短)。我们不一定非常精准的判断哪个最单。只要挑Z觉得最单的p了。比如,我们觉得“输入管理密码”是最单的用户故事。然后我们判断说Q这个用h事算1个“故事点Qstory pointQ”?br />
用户故事 故事?br />卖饮料 ?br />取消购买
输入理密码 1
补充饮料
取出q里的钱 ?br />安全警报
打印月销售报表 ?br />
不过一般我们不会列出清单,而是做出一堆卡片脓在墙上,每张卡片记录一个用h事,然后故事点写在卡片上面Q?br />
敏捷开发的必要技巧完整版