XP的规则和经验

浏览器 文化礼品 网站
聚合到我的好诶网博告网 提供的广告

 

XP在软件工程的四个方面都有自己的规则和经验,下面我们就想来罗列一下:

计划:
1
. 填写用户故事卡片
2
. 通过发布计划会议确定开发日程
3
. 频繁的发布小的版本
4
. 计算项目开发速度
5
. 一个项目划分成多个开发周期
6
. 通过周期计划开始一个周期
7
. 在开发组间交换成员
8
. 每天开始的时候进行一次简便会议
9
. 当xp出问题的时候修复它。

设计
1
. 简单性
2
. 选择一个系统隐喻
3
. 在设计会议时使用CRC
4
. 通过侦察来降低风险
5
. 在开始不要设计太多的附加功能
6
. 任何时候只要有可能就要refactoring

编码
1
. 客户应该是小组的一员
2
. 编码必须写到规定的水平
3
编码之前先写单元测试
4. 所以的代码都由两个人完成
5
. 同一时间只有一组(2个)人集成代码
6
. 代码经常整合
7
. 所有人拥有所有代码
8
. 把优化工作放在最后
9
. 不超时工作

测试
1
. 所有的代码都必须有单元测试
2
. 所有的代码在分布之前必须通过所有单元测试
3
. 当一个BUG发现时,就增加新的测试
4
. 我们经常运行验收测试,并公布分数。

下面我们分别详细介绍上面的规则和经验
在计划中,我们有以下的规则和经验:


. USER STORIES
1
.比较
USER STORIES
USE CASES有着一样的目的,但其实却是不一样的。在实施计划的会议上,USER STORIES都是用来帮助估计时间的,他们替代了大量的需求文档,USER STORIES通常是由客户撰写并用来描述他们需要的系统的功能,它们类似于情节描述,但是它不仅仅描述用户界面,它们是有一定格式,一般大概三句话,完全由用户用自己的语言写成,用来描述任务,不包含任何的技术用语。
USER STORIES
也产生可验收测试,一个或者多个验收测试必须增加以检查USER STORIES是否已经被正确的采用。
USER STORIES
最难以理解的一点就是,它怎样来区别于传统的需求分析的。它们之间最大的区别是在于分析需求的详细水平上,USER STORIES仅仅提供足够于风险分析的情况,它提供的情况用于估计USER STORY所需要的开发时间,当开发者对USER STORIES的大概情况做出判断后,他就去见客户,面对面的接受一个更详细的需求描述。
开发者估计多长的时间可以完成这个USER STORY,在XP的经验中,1-3周是理想的USER STORY开发时间,理想的开发时间是指在没有打断的情况下将USER STORY代码实现所需要的时间,不是由别人来指派,而是由你自己才确切的知道任何去做。长于三个星期,就意味着你应该将该USER STORY细分,如果小于一周,你就需要将USER STORY合并。根据XP的经验,在发布计划的时候,一个项目中USR STORYS 的数量最大不应该超过80个,最小应该不小于20个。
USER STORY
和需求文档的另一个区别是集中在使用者的需求上。在USER STORYS
上,你必须尽量的避免接触太多的特定技术(如:数据的流程,算法等)细节,你应该尽量的保持STORIES集中在描述用户的需要和价值上,要尽量反对去描述特定的界面输入输出。

2
.流程

XP中,UserStory是一个关于系统如何去解决一个问题的情节。每一个User story用一张卡来书写,代表着一块以某种方式跟客户相关联的功能模块。从整个项目的计划到开发的过程(游戏计划,提交日程安排,反复计划)中所有的卡片都被保留,他们被客户优先提出,被开发者评估,然后被分给软件工程师以便他们安排开发的日程,当有一些功能测试被用户拥有时,这就意味着UserStory真正的完成了。

阅读更多
个人分类: 软件工程
想对作者说点什么? 我来说一句

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

关闭
关闭
关闭