Back to Software_Engineering

Extreme programming

1. 关于极限编程

2. 极限编程过程

Extreme_Programming.png

3. 关键活动

  1. 客户作为团队成员
  2. 用户素材
  3. 短交付周期
  4. 验收测试
  5. 结对编程
  6. 测试驱动的开发方法
  7. 集体所有权
  8. 持续集成
  9. 可持续的开发速度
  10. 开放的工作空间
  11. 计划游戏
  12. 简单的设计
  13. 重构
  14. 隐喻

4. 极限编程过程实践

以下是我对极限编程的一些实际过程的理解和实践:

4.1. 客户作为团队成员

我们希望客户和开发人员在一起紧密地工作,以便于彼此知晓对方所面临的问题,并共同去解决这些问题。 XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团队。客户包括:和开发人员同属一家公司的一组业务分析师或者市场专家;用户代表;支付开发费用的人。 最好的情况是客户和开发人员在同一个房间中工作,次一点的情况是客户和开发人员之间的工作距离在100米以内。距离越大,客户就越难成为真正的团队成员。 目前软件需求都是产品经理提出来的。产品经理和开发团队紧密合作,共同面对发现的问题并解决。

4.2. 用户素材

为了进行项目计划,必须要知道和项目需求有关的内容,但是却无需知道得太多。对于做计划而言,了解需求只需要做到能够估算它的程度就足够了。你必须要知道存在很多细节,也必须要知道细节的大致分类,但是你不必知道特定的细节。 需求的特定细节很可能会随时间而改变,因此在离真正实现需求还很早时就去捕获该需求的特定细节,很可能会倒置做无用功以及对需求不成熟的关注。 在XP中,我们和客户反复讨论,以获取对于需求细节的理解,但是不去捕获那些细节。我们更原意客户在索引卡片上写下一些我们认可的词语。这些词语可以提醒我们记起这次交谈。基本上在和客户进行书写的同以时刻,开发人员在该卡片上写下对应于卡片上需求的估算。估算是基于和客户进行交谈期间所得到的对于细节的理解进行的。 用户故事就是正在进行的关于需求谈话的助记符。它是一个计划工具,客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。

User Stories,对用户需求的一直表述。目前没有想到如何实践。

4.3. 短交付周期

XP项目每两周交付一次可以工作的软件。每两周的迭代都实现了客户的一些需求。在每次迭代结束时,会给客户演示迭代生成的系统,以得到他们的反馈。 a.迭代计划 每次迭代通常耗时两周。这是一次较小的交付,可能会被加入到产品中,也可能不会,它由客户根据开发人员确定的预算而选择的一些用户故事组成。 开发人员通过度量在以前的迭代中所完成的工作量来为本次迭代设定预算。只要估算成本的总量不超过预算,客户就可以为本次迭代选择任意数量的用户故事。 一旦迭代开始,客户就统一不再修改档次迭代中用户故事的定义和优先级别。迭代期间,开发人员自由的将用户故事分解成task,并一句最具技术和商务意义的顺序来开发这些task。 b.发布计划 XP团队通常会创建一个计划来规划随后大约6次迭代的内容,这就是所谓的发布计划。一次发布通常需要3个月的工作。它表示了一次较大的交付,通常此次交付会被加入到产品中。发布计划是由一组客户根据开发人员给出的预算所选择的、牌号优先级别的用户素材组成。 发布计划不是一成不变的,客户可以随时改变计划的内容。

目前开发团队还无法做到,但本项会列入实践计划中。

4.4. 验收测试

可以以客户指定的Acceptance Tests的形式来捕获有关用户素材的细节。用户素材的验收测试是在就要实现该用户故事之前或者实现该用户故事的同时进行编写的。 验收测试使用能够让它们自动并且反复运行的某种脚本语言编写,这些测试共同来验证系统按照客户指定的行为运转。 一旦通过一项验收测试,就将该测试加入到已经通过的验收测试集合中,并决不允许该测试再次失败。这个不断增长的验收测试计划每天会被多次运行,每次系统被创建时,都要运行这个验收测试集。

近期不具备实践的基础。

4.5. 结对编程

所有的产品代码都是由结对的程序员使用同一台多年共同完成的。结对人员中的一个控制键盘并输入代码,另一位观察输入的代码并寻找着代码中的错误和可以改进的地方。 两个人频繁互换角色,最终生成的代码是由他们两人共同设计,共同编写的。 结对的关系每天至少要改变一次,以便于每个程序员在一天中可以在两个不同的结对中工作。在一次迭代期间,每个团队成员应该和所有其他的团队成员在一起工作过,并且他们应该参与了本次迭代中所涉及的每项工作。 这将极大地促进知识在团队中的传播。

征求了研发组长的意见,已经开始简化实施。

4.6. 测试驱动的开发方法

已经就此进行了一次培训。希望能够在一些项目上开始实践。

4.7. 集体所有权

没有看到实践的必要。

4.8. 持续集成

本人有相关经验,在之前的团队已经实施了。

但目前的团队缺乏实践的基础。

4.9. 可持续的开发速度

XP的规则是不允许团队加班工作。在版本发布前的一个星期是该规则的唯一例外。

应该是公司层面的问题,开发团队很难控制。

4.10. 开放的工作空间

需要物质基础。

4.11. 计划游戏

本人之前有此过程的实践经验。

4.12. 简单的设计

XP团队使他们的设计尽可能地简单,具有表现力。此外,他们仅仅关注了计划在本次迭代中要完成的用户故事。 这意味着XP团队的工作可能不会从基础结构开始,他们可能并不先去选择使用数据库或者中间件。团队最开始的工作是以尽可能最简单的方法实现第一批用户故事。只有当出现一个用户故事迫切需要基础结构时,他们才会引入该基础结构。

下面有三条XP指导原则:

a.考虑能够工作的最简单的事情 XP团队总是尽可能寻找能实现当前用户故事的最简单的设计。

b.你将不需要它

c.一次,并且只有一次 极限编程者不能容忍重复的代码。无论在哪里发现重复的代码,他们都会消除它们。

此实践非常开发人员个人经验和技能,目前没有实施基础。

4.13. 重构

代码往往会腐化,随着我们添加一个又一个的特性,处理一个又一个的错误,代码的结构会逐渐退化。

重构就是在不改变代码行为的前提下,对其进行一系列小的改造,旨在改进系统结构的实践活动。

重构是持续进行的。

此实践非常开发人员个人经验和技能,目前没有实施基础。

4.14. 隐喻

随时能够描绘系统的未来景象。

貌似在说架构师个人的能力?

5. Reference


CategoryProcess

MainWiki: Extreme_Programming (last edited 2008-08-13 18:28:16 by twotwo)