2010-05-27 12:22:41 zhanghsh2010 阅读数 302
1 Story划分能够根据INVEST原则:独立的(Independent)、可商讨的(Negotiable)、有价值的(Valuable)、可以估计的(Estimatable)、足够小的(Small)、可测试的(Testable),支撑后续分迭代进行开发;
2 定义了不同用户类型的使用场景,是场景测试的输入;
3 定义明确的Story验收准则(具体要求),帮助理解规格,减少由于规格不清楚造成的返工和反复沟通;验收用例需要在Story开发前或开发中给出,不能滞后于开发,;
4 给出明确的Story间的依赖关系,从而确定开发顺序,减少打桩和需求反复;
5 明确如何演示;
2015-09-04 11:34:48 u011790275 阅读数 4397

谈到敏捷开发, 许多人纠结的第一个问题便是: User Story 如何的划分? 更有不少人, 一遇到在 User Story 上有延迟交付或交付的质量不佳时, 便说是因为 User Story 的拆分不对, 就整天在纠结所谓 User Story 颗粒度大小的问题。

然而, 事实的真相是如何呢?

首先, 先从敏捷开发实践的本身说起:

敏捷开发之所以强调 “敏捷” , 主要是希望藉由 User Story 的划分 , 能帮助开发人员, 有效的管理版本开发上需求的复杂度, 而使开发人员能在最短的时间内 “发现自身的问题”, “发现自身的不足”, “发现因自身的问题、不足与外部的变化所造成的风险” 。

所以, 敏捷开发的核心基础, 最强调的便是: “User Story 必需要是可测的” 与 “User Story 间的持续集成” 。

接下来再谈一下, 人的思维、人的一念之间是如何严重的扭曲了敏捷开发?!

当一个开发人员, 他 (她) 只是在证明自己“没做错事” 时, 而不是在 “发现自身的问题” 时, 那在拆分User Story 上, 便会发生这些场景:

1.       将 User Story 拆的需 3 周甚至一个月以上才能完成; 这样的思维与作法, 只是在证明自身所负责开发的 User Story 是可被 “测试的” 。但, 却只是被 “测试人员可测试的” ; 也就是说, 有的开发人员希望将 User Story 要拆的 “够大”, 只是要掩饰自身无法做 “有效” 的 “开发者自动化测试” 罢了。

2.       将 User Story 拆的只需完成单一且极简单的 “功能点”; 这样的思维与作法, 只是在证明自身所负责开发的 User Story 是可被 “如期交付的” ; 也就是说, 有的开发人员希望要将 User Story 拆的 “够小”, 只是要掩饰自身无法理解与掌握 “完整的业务场景” 与 “软件架构” 罢了。

所以, 我们要纠结的不应该是所谓 User Story 颗粒度大小的问题; 而是应协助开发人员能诚实的发现与面对自身的不足与所面临的问题, 并给予开发人员适当且必要的赋能与协助。因为, 唯有如此, 开发人员的能力提升了, 则开发人员便自然能在 “更短的时间内” “真正有质量 (有品味)” 的完成 “复杂度越高” 的User Story。

所以, 我们要纠结的不应该是所谓 User Story 颗粒度大小的问题; 我们应该真正专注的是: 如何能使开发人员能在 “更短的时间内” “真正有质量 (有品味)” 的完成 “复杂度高” 的 User Story。

 

 

2009-11-03 14:34:00 chengyb74 阅读数 9961

 

对于敏捷开发来说,User Story是开发的基础,它不同于传统的瀑布式开发方式,而是把原本需求拆成最小粒度的Story,以方便拆分Task,估计开发时间,领取开发任务。

优点和好处

  1. Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
  2. Allowing developer and client to discuss requirements throughout the project lifetime
  3. Needing very little maintenance
  4. Only being considered at the time of use
  5. Maintaining a close customer contact
  6. Allow projects to be broken into small increments
  7. Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
  8. May be easier to estimate development effort

 

 

User Story模板

User Story可以遵循以下模板:As a <User Type> I want to <achieve goal> So that  I can <get some value>
 翻译成中文就是:作为一个<某种类型的用户>,我要<达成某些目的>,我这么做的原因是<开发的价值>。

 
User Story应遵循INVEST规则

  1. Independent 独立性,避免与其他Story的依赖性。
  2. Negotiable 可谈判性,Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细,开发人员可以给出适当的建议。
  3. Valueable 有价值性, Story需要体现出对于用户的价值
  4. Estimable 可估计性,Story应可以估计出Task的开发时间。
  5. Sized Right 合理的尺寸, Stories应该尽量小,并且使得团队尽量在1个sprint(2 weeks)中完成。
  6. Testable 可测试性, User Story应该是可以测试的,最好有界面可以测试和自动化测试。每个任务都应有Junit Test.

一些经验:

  1. 永远不要在User Story中使用And和Or,因为这是些分支词就表示分支任务,把它们拆成两个Story.
  2. 数据整理:通常情况下1个sprint(2周一次迭代)可以做4~5个Story,极端大的Story不可大于1个sprint。
  3. 数据整理:通常情况下1个sprint(2周一次迭代)可以做50个左右的Task。
  4. User Story用于描述用户故事,不要包括任何的技术,框架等内容。Task可以包括框架,技术等内容。
2010-05-27 12:24:01 zhanghsh2010 阅读数 28
1 是否进行了头脑风暴?
2 头脑风暴会议的结论是否已经更新到Story Card中?
3 每日checkin之前是否已经完成本地构建?
4 Story签收前代码是否已经review?
5 是否已经检视测试人员的测试用例?
6 Story签收前是否已经将TO DO LIST归档?
7 Story签收前是否更新EA工程、Story Card中的实际代码量、签收日期信息?
8 代码重构需要 是否归档到汇总表单?
9 代码、测试用例的检视意见是否已经归档?
2014-02-07 15:24:53 u013102039 阅读数 7407

Agile概念的比较详细的说明见:http://www.cnblogs.com/astar/archive/2012/02/28/Scrum.html

Story概念:

  • User Story是敏捷开发的基础,它不同于传统的瀑布式开发方式,而是把原本需求拆成最小粒度的Story,以方便拆分Task,估计开发时间,领取开发任务。
  • User Story是从用户的角度对系统的某个功能模块所作的简短描述
  • 一个 User Story 描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值
  • User Story是敏捷开发和管理的核心,要确保Story的输出质量。

Story优点和好处:

  • Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
  • Allowing developer and client to discuss requirements throughout the project lifetime
  • Needing very little maintenance
  • Only being considered at the time of use
  • Maintaining a close customer contact
  • Allow projects to be broken into small increments
  • Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
  • May be easier to estimate development effort

User Story划分原则(INVEST规则):

  • 独立性(Independent):一定要保证Story在功能上的独立,尽量不要有Story之间的依赖,否则会大大影响将来的开发和测试。
  • 可谈判性(Negotiable):Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细,开发人员可以给出适当的建议。
  • 有价值性(Valuable): Story需要体现出对于用户的价值。
  • 可估计性(Estimable):Story应可以估计出Task的开发时间。
  • 大小合适(Sized Right):关于Story的粒度,建议的开发工作量是3-5天(包含针对Story所做的开发者自测工作量),如果Story不能拆分到3-5天的开发粒度,则一定要确保该Story在一个迭代周期内可开发测试完成。
  • 可测试性(Testable):要从可测试性考虑需求,同时要考虑能够独立测试,每个任务都应有Junit Test。另外注意,伴随Story要同时输出可接受性测试用例(Acceptance Test Case,以下简称AT),用于验证Story是否开发完成,可以给测试人员做Story测试。AT用例在Story协作阶段只是对测试要点、场景的描述,在迭代开发阶段可以继续补充和完善。

Task:

  • 为了能够及时,高效地完成每个 Story,Scrum 团队会把每个 Story 分解成若干个 Task。
  • 每个Task 的时间最好不要超过8小时,保证在1个工作日内完成,如果 Task 的时间超过了8个小时,就说明Task的划分有问题,需要特别注意。

User Story模板:

  • User Story可以遵循以下模板:As a <User Type> I want to <achieve goal> So that  I can <get some value>
  •  翻译成中文就是:作为一个<某种类型的用户>,我要<达成某些目的>,我这么做的原因是<开发的价值>。

一些经验:

  • 永远不要在User Story中使用And和Or,因为这是些分支词就表示分支任务,把它们拆成两个Story.
  • 数据整理:通常情况下1个sprint(2周一次迭代)可以做4~5个Story,极端大的Story不可大于1个sprint。
  • 数据整理:通常情况下1个sprint(2周一次迭代)可以做50个左右的Task。
  • User Story用于描述用户故事,不要包括任何的技术,框架等内容。Task可以包括框架,技术等内容。

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