2011-10-26 17:26:27 VipWangJian 阅读数 137
Story编码

编码规范学习:开发人员在开始代码前,PL要组织大家对编码规范进行学习,在编码过程中要严格按照编码规范进行执行。
功能代码实现:开发人员开始实现功能代码,做好UT,并及时重构。有条件的可以按TDD方式开发。这里要特别强调的是开发人员要做好工具的检查工作,包括:代码规范性检查、PC-Lint或FindBugs检查、圈复杂度检查、重复代码检查、UT测试覆盖率分析等。
本地构建:构建前一定要将配置库的最新代码更新到本地,构建的方式建议在项目组统一使用脚本自动化实现,主要的活动包括:编译、链接、UT测试,只有所有UT用例(包括其他人的)测试通过才能将代码check in到配置库。Check in到配置库的代码也包括测试代码、数据库脚本等,然后将会加入到持续集成环境中。
代码Review:不管是否采用了结对编程,现阶段建议还是要安排代码Review人员,包括测试代码也要安排Review,以弥补结对编程的经验不足。Review的方式不限,可以采用交叉Review的方式,但至少要有一个人能够通读代码(建议MDE),从整体上把握代码架构和质量。
AT测试:编写AT用例,然后做相应的测试。对于能自动化的功能,则建议测试和开发一起实现自动化


开发完成标准:
通过代码review、完成静态检查和编译 ;
完成单元测试和模块级测试,并集成到CI系统中;
通过AT用例验证,并把补充的用例记录到Story设计文档中;
如测试有自动化用例,则要执行自动化用例,并解决发现的问题才能进行签收
2010-05-27 12:22:41 zhanghsh2010 阅读数 300
1 Story划分能够根据INVEST原则:独立的(Independent)、可商讨的(Negotiable)、有价值的(Valuable)、可以估计的(Estimatable)、足够小的(Small)、可测试的(Testable),支撑后续分迭代进行开发;
2 定义了不同用户类型的使用场景,是场景测试的输入;
3 定义明确的Story验收准则(具体要求),帮助理解规格,减少由于规格不清楚造成的返工和反复沟通;验收用例需要在Story开发前或开发中给出,不能滞后于开发,;
4 给出明确的Story间的依赖关系,从而确定开发顺序,减少打桩和需求反复;
5 明确如何演示;
2009-11-03 14:34:00 chengyb74 阅读数 9960

 

对于敏捷开发来说,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 阅读数 7395

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可以包括框架,技术等内容。

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