《敏捷软件开发原则，模式与实践》阅读笔记二

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

短交付周期：
XP项目每两周交付一次可以工作的软件。每两周的迭代都实现了客户的一些需求。在每次迭代结束时，会给客户演示迭代生成的系统，以得到他们的反馈。
    1.迭代计划
    每次迭代通常耗时两周。这是一次较小的交付，可能会被加入到产品中，也可能不会，它由客户根据开发人员确定的预算而选择的一些用户故事组成。
开发人员通过度量在以前的迭代中所完成的工作量来为本次迭代设定预算。只要估算成本的总量不超过预算，客户就可以为本次迭代选择任意数量的用户故事。
一旦迭代开始，客户就统一不再修改档次迭代中用户故事的定义和优先级别。迭代期间，开发人员*的将用户故事分解成task，并一句最具技术和商务意义的顺序来开发这些task。
    2.发布计划
    XP团队通常会创建一个计划来规划随后大约6次迭代的内容，这就是所谓的发布计划。一次发布通常需要3个月的工作。它表示了一次较大的交付，通常此次交付会被加入到产品中。发布计划是由一组客户根据开发人员给出的预算所选择的、牌号优先级别的用户素材组成。
发布计划不是一成不变的，客户可以随时改变计划的内容。
        2.1.4验收测试
    可以以客户指定的Acceptance Tests的形式来捕获有关用户素材的细节。用户素材的验收测试是在就要实现该用户故事之前或者实现该用户故事的同时进行编写的。
    验收测试使用能够让它们自动并且反复运行的某种脚本语言编写，这些测试共同来验证系统按照客户指定的行为运转。
一旦通过一项验收测试，就将该测试加入到已经通过的验收测试集合中，并决不允许该测试再次失败。这个不断增长的验收测试计划每天会被多次运行，每次系统被创建时，都要运行这个验收测试集。
所有的产品代码都是由结对的程序员使用同一台多年共同完成的。结对人员中的一个控制键盘并输入代码，另一位观察输入的代码并寻找着代码中的错误和可以改进的地方。
    两个人频繁互换角色，最终生成的代码是由他们两人共同设计，共同编写的。
结对的关系每天至少要改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。在一次迭代期间，每个团队成员应该和所有其他的团队成员在一起工作过，并且他们应该参与了本次迭代中所涉及的每项工作。
这将极大地促进知识在团队中的传播。