泛型编程与c标准库-read.docVIP

极限编程概述 作为开发人员，我们应该记住，XP并非唯一选择。 ——Pete McBreen，软件技术专家 在第1章中，我们概述了有关敏捷软件开发方法方面的内容，但它没有确切地告诉我们去做些什么；其中给出了一些泛泛的陈述和目标，却没有给出实际的指导方法。本章要改变这种状况。 2.1 极限编程实践 2.1.1 完整团队 我们希望客户、管理者和开发人员紧密地工作在一起，以便于彼此知晓对方所面临的问题，并共同去解决这些问题。谁是客户？XP团队中的客户是指定义产品的特性并排列这些特性优先级别的人或者团体。有时，客户是和开发人员同属一家公司的一组业务分析师、质量保证专家和/或者市场专家。有时，客户是用户团体委派的用户代表。有时，客户事实上是支付开发费用的人。但是在XP项目中，无论谁是客户，他们都是能够和团队一起工作的团队成员。 最好的情况是客户和开发人员在同一个房间中工作，次一点的情况是客户和开发人员之间的工作距离在100m以内。距离越大，客户就越难成为真正的团队成员。如果客户工作在另外一幢建筑或另外一个州，那么他将会很难融合到团队中来。 如果确实无法和客户工作在一起，该怎么办呢？我的建议是去寻找能够在一起工作、愿意并能够代替真正客户的人。 2.1.2 用户故事 为了进行项目计划，必须要了解需求，但是却无需了解得太多。对于做计划而言，了解需求只需要做到能够估算它的程度就足够了。你可能认为，为了对需求进行估算，就必须要了解该需求的所有细节。其实并非如此。你必须知道存在很多的细节，也必须知道细节的大致分类，但是你不必知道特定的细节。 需求的特定细节很可能会随时间而改变，一旦客户开始看到集成到一起的系统，就更会如此。看到新系统的问世是关注需求的最好时刻。因此，不要去捕获某个在很长一段时间之后才会实现的需求的特定细节，否则很可能会导致无用功以及对需求不成熟的关注。 在XP中，我们和客户反复讨论，以获取对于需求细节的理解，但是不去记录那些细节。我们更愿意客户在索引卡片上写下一些共识的言语，这些只言片语可以提醒我们记起这次交谈。基本上在客户进行书写的同一时刻，开发人员在该卡片上写下对应于卡片上需求的估算。估算是基于在和客户进行交谈期间所得到的对于细节的理解进行的。 用户故事（user story）就是正在进行的关于需求的谈话的助记符。它是一个计划工具，客户可以使用它并根据需求的优先级和估算代价来安排实现该需求的时间。 2.1.3 短交付周期 XP项目每两周交付一次可以工作的软件。每两周的迭代都实现了利益相关者的一些需求。在每次迭代结束时，会给利益相关者演示迭代生成的系统，以得到他们的反馈。 迭代计划 每次迭代通常耗时两周。迭代是一次较小的交付，可能会被加入到产品中，也可能不会。迭代计划由一组用户故事组成，这些用户故事是客户根据开发人员确定的预算选出来的。 开发人员通过度量在以前的迭代中所完成的工作量来为本次迭代设定预算。只要估算成本的总量不超过预算，客户就可以为本次迭代选择任意数量的用户故事。 一旦迭代开始，客户就同意不再修改当次迭代中用户故事的定义和优先级别。迭代期间，开发人员可以自由地将用户故事分解成任务（task），并依据最具技术和商务意义的顺序来开发这些任务。 发布计划 XP团队通常会创建一个发布计划来规划出随后大约6次迭代的内容。这就是所谓的发布计划。一次发布通常需要3个月的工作。它表示了一次较大的交付，通常此次交付会被加入到产品中。发布计划是由客户根据开发人员给出的预算所选择的、排好优先级别的一组用户故事组成。 开发人员通过度量在以前的发布中所完成的工作量来为本次发布设定预算。只要估算成本的总量不超过预算，客户就可以为本次发布选择任意数目的用户故事。客户同样可以决定在本次发布中用户故事的实现顺序。如果开发团队强烈要求的话，客户可以通过指明哪些用户故事应该在哪次迭代中完成的方式，制订出发布中最初几次迭代的内容。 发布计划不是一成不变的。客户可以随时改变发布的内容。他可以取消用户故事，编写新的用户故事，或者改变用户故事的优先级别。但是，客户应该尽量不去更改一次迭代。 2.1.4 验收测试 可以以客户指定的验收测试的形式来记录有关用户故事的细节。用户故事的验收测试是在就要实现该用户故事之前，或者在实现该用户故事的同时才开始编写的。验收测试使用脚本语言编写，这样它们可以自动、反复地运行。这些测试共同来验证系统是否按照客户指定的行为运转。 验收测试是由业务分析师、质量保证专家以及测试人员在迭代期间编写的。编写验收测试使用的语言对于程序员、客户以及业务人员来说都很容易阅读和理解。程序员就是从这些测试中了解他们正在实现的故事的真实工作细节。这些测试成为真正的项目需求文档。验收测试描述了每个特性的所有细节，并用作验证这些特性是否被正确完成的决定