XP的规则和经验

我喜欢的 浏览器	我喜欢的 文化礼品	我喜欢的 网站
FireFox 2.0	100部奥斯卡影片	博告网
		加入博告网日进斗金不是梦！
聚合到我的好诶网博告网 提供的广告

 

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真正的完成了。