解析极限编程拥抱变化-读书笔记

解析极限编程拥抱变化.jpg

第1章 极限编程定义

1. 极限编程（Extreme Programming, XP）和社会性的变革相关。过去适用的一些习惯和模式在今天可能会妨碍我们做得最好，XP要求我们放弃这些习惯和模式，放弃那些妨碍生产率但保护我们自己的防御行为。虽然这可能会使我们感觉到自己失去了掩蔽。P1
2. XP要求我们承担自己有能力做什么，然后去做这些能力所及的事情。同事允许并希望其他人也这样做。放弃我们不成熟的自负——“我比其他人都懂很多，我需要的就是让我独立行事，成为最棒的”。P1
3. XP是一种软件开发的风格，专注于编程技术、清晰沟通还有团队协作的精彩实践，这些将帮助我们完成以前几乎不可想象的事情。XP包括：P2
   • 一种软件开发的哲学，基于沟通、反馈、简约、勇气和尊重的价值观。
   • 一整套被证明在软件开发中有用的实践。这些实践相辅相成的，相互增强。我们将它们作为以上价值观的表达形式。
   • 一系列用来将以上价值观投入实践的、辅助的原则和职能技术。当缺乏对应你的独特难题的现成实践时，它会起作用。
   • 一个共享这些价值观和实践的社区。
4. XP是一条可以使得一起开发软件的人们共同进步直至卓越的途径。它和其他方法的区别有：P2
   • 开发周期短，提供及早的、具体的、持续的反馈。
   • 增量计划方法。迅速地提出一个总体计划，并在项目生命周期中不断演化。
   • 能够灵活安排功能的实现，以对变化的业务需求做出反应。
   • 使用有程序员、客户和测试人员编写的自动测试来监控开发进度，支持系统的演化，并尽早发现缺陷。
   • 通过口头沟通、测试和源代码沟通系统结构和意图。
   • 演化的设计过程贯穿整个系统生命周期。
   • 依赖于能力普通但能积极参与的程序员之间的紧密协作。
   • 各种实践兼顾项目成员的短期直觉以及项目的长期利益。
5. XP可以表述为：P3
   • 在XP中你只需要做能够为客户创造价值的事情，带着很多包袱是不可能快速前进的。
   • XP是一种方法论，它建立于解决软件开发方法中的约束之上。XP在所有这些领域都有潜在的作用，但并不是直接解决这些领域中的问题。方法论常常解释为“一组用来确保成功的规则”。
   • XP对任何规模的团队都起作用。
   • XP适合模糊或者快速变化的需求。
6. “不设防才是真正的安全”的观念。隐瞒一些事情来保持安全的就习惯并不能真正起作用。隐瞒20%工作量不能保护我，当项目失败的时候，没有尽全力的事实并不会真的让我感觉好一点，也无法消除不能让项目运作所带来的失败感。如果我尽了全力写程序而人们不喜欢，我任然可以自我感觉很好，因为我尽力了。P4
7. XP团队竭尽全力去取胜而且用于承担后果。如果自尊没有跟项目联系起来，在任何情况下我们都会尽全力做到最好。在XP中我们不为失败做准备。在人际关系上保持一点距离、通过偷懒或加班来隐瞒工作量、拖延反馈导致又一次责任扩散，所有这些行为在XP团队中都没有存在的空间。P4
8. XP如何解决开发过程中的风险。P5
   • 进度延迟——XP提倡短发布周期。这样，任何延迟的范围都是有限的。XP使用客户要求的功能的每周迭代来行成关于进度的详细反馈。提倡优先实现高优先级的功能，这样可以保证在发布版本中错过的功能的价值比较低。
   • 项目取消——XP中的最小发布必须是满足最大商业意义的部分。这样，在部署之前出错的可能就会较少，同时也保证了软件的价值最大。
   • 系统恶化——XP中并创建并维护一整套自动化测试，以确保质量基线。
   • 缺陷率——XP中既包括了程序员书写的每个函数的测试，也包括了客户书写的对每个程序特性的测试。
   • 业务误解——XP提倡业务人员成为团队成员，因此客户和团队的知识都能反映在软件中。
   • 业务变更——XP缩短了发布周期，客户可以随意用新的功能替代没有完成的功能。
   • 错误特性太多——XP坚持只解决最高优先级的任务。
   • 人员流动——XP要求程序员估算自己工作所需时间并完成工作。XP鼓励团队中的相互沟通，来减少孤独感，因为这常常是工作不满的主要原因。鼓励相信成员逐渐承担越来越多的责任，新成员之间互相版主，同时老成员也为新成员提供帮助。
9. 什么是XP。P7
   • XP是放弃旧的、低效的技术和习惯而采用新的有效的技术和习惯。
   • XP是因为你今天的竭尽全力而充分欣赏自己。
   • XP是努力在明天做得更好。
   • XP是要求你按照对团队共同目标作出的贡献来评价自己。
   • XP是让你的一些人性需求在软件开发中得到满足。

第一部分 探索极限编程

第2章 学习开车

1. XP的范式（paradigm）：保持清醒、适应、变化。P10
2. 软件中的所有东西都在变。需求在变，设计在变，业务在变、技术在变，团队在变，团队成员在变。问题不在于变化，因为变化总是要发生；问题在于我们没有应对变化的能力。P10
3. XP让你通过不断的、小的纠正来适应，通过短周期的部署软件来朝着目标前进，这样你就不会过很长时间才发现自己走错了方向。P11

第3章 价值观、原则和实践

1. 价值观让实践有的放矢，实践使价值观变得具体可见。在价值观与实践之间架起桥梁的是原则。原则是生活中具体领域的指导方针。P13

第4章 价值观

1. 对于软件开发“刚刚入门”的人而言，最大的问题在于：他们专注于个体的行为。实际上相对于个体行为作为团队的一份子而言，个体行为并不那么重要。P16
2. 人们对编码风格充满热情。毫无疑问编码风格有好坏之分，但最重要的问题是一个团队要选择共同的风格工作。特殊的编码风格往往揭示了这样的价值观：不惜任何代价的个体自由。这些是不能帮助团队取得成功的。P16
3. XP中包含了5个指导开发的价值观：沟通、简单、反馈、勇气和尊重。P20
   • 沟通：在团队软件开发中最要紧的是沟通。每当开发中出现问题的时候，通常已经有人指导了解决方法，但有权作出改变的人却不知道。
   • 简单：简单是XP价值观中智力色彩最强烈的。构造一个优雅地解决今天问题同事又足够简单的系统是很难的。昨天的简单解决方案在今天看来可能任然不错，但也可能过于简单了，或者太复杂了。当你需要作出改变，以重新获得简单性时，你必须找到一条从你当前位置到目的地的路径。
   • 反馈：没有哪个固定方向是长久有效的，不论我们再谈论软件开发细节、系统需求还是系统架构。超越经验而确定出来的方向，它的半衰期尤其短。变化是不可能避免的，变化产生了对反馈的需要。
   • 勇气：勇气是面对恐惧的有效行动。有时勇气表现为对某种行动的偏爱。如果你知道问题是什么，那你就去做吧。有时勇气表现为耐心。如果你知道有问题存在但不知道问题是什么，则需要勇气来等待真正问题的明显出现。
   • 尊重：前面提到的4个价值观指向处于他们背后更深刻的另一个价值观：尊重。如果团队成员不关心彼此，也不理会别人所做的事情，XP是无用的。要同时提高软件开发的人性和生产率，每个人对团队的贡献都应该得到尊重。

第5章 原则

1. 谈话是首选的沟通方式，文字沟通本质上更为浪费，文字沟通是单向的交流方式。谈话可以支持澄清事实、立即反馈、头脑风暴，以及其他文档无法做到的事情。
2. 人性化。成为一名优秀的开发者需要什么。P23
   • 基本安全：没有饥饿、身体伤害和对所爱的人的威胁。害怕失去工作会导致这个需求受到威胁。
   • 成就感：为社会做贡献的机会和能力。
   • 归属感：参与团队并从中得到认可、责任和为共同目标做贡献的机会。
   • 成长：拓展自己的能力和前途的机会。
   • 亲切感：与团队其他成员之间的高度理解和被理解的能力。
3. 经济学。P24
   必须有人为所有的这些买单。不考虑经济学的软件开发会有导致空洞单存的“技术性成功”的危险。要确定你正在做的东西有商业价值，符合商业目标和商业需求。
4. 互惠互利。P25
   每项活动都应使所有与其相关的活动获益。互惠互利是XP中最重要的原则，也是最难坚持的原则。任何一个问题总是有让某人付出代价而其他人获益的解决方案。
5. XP通过互惠互利的方式来解决“与未来交流”的问题。P25
   • 今天我撰写了能帮助我更好地设计和实现的自动化测试，这些测试同样可以保留给以后的程序员使用。这项实践让现在的我获益，也让以后的维护者获益。
   • 我非常谨慎地重构以消除那些偶然导致的复杂性，这既给我带来了满足感和更少的缺陷，也让后来者能更容易地理解他们碰到的代码。
   • 我会从清楚且一致的隐喻集中选择名称，这些名称能加速我的开发，也使得留给新程序员的代码更清晰。
6. 自相似性。P26
   试着讲一个解决方案的结构复制到一个新环境中，即使他们的粒度不同。
7. 改进。P27
   软件开发的卓越是通过改进达到的。这个循环就是：做到你今天能做的最好，为了明天能做得更好所必须的理解而努力。这步意味着需要等到完美才开始做。
   把价值观转化为实践时，改进原则表示为实践就是：马上开始行动，随着时间的推移逐步精化结果。
8. 多样性。P28
   如果一个团队的成员很相似，那么这个团队虽然舒适但效率不高。团队需要将不同的技能、态度以及看待问题和缺陷的视角整合在一起，来考虑解决问题和实现解决方案的不同方法。也就是说，团队需要多样性。
9. 反省。P28
   好的团队并不只是进行他们的工作，他们会思考如何工作和为什么工作。他们会分析为什么成功或失败。他们不会试图掩藏他们的错误，而是暴露它们并从中学习。谁都不可能突然间变优秀。
10. 流。P29
    软件开发的流是指通过同时参与所有的开发活动来交付有价值软件的稳定流。XP的实践倾向于活动的连续流，而不是离散的阶段。
    软件开发长久以来用大块的程序进行交付。“宇宙大爆炸”集成反映了这种趋势。许多团队应对压力的倾向是，减少部署和集成的频率，从而使程序块更大——这会让问题变得更糟。反馈减少使问题更糟糕，导致更大的程序块。被延迟的事情越多，程序块就越大，风险也越大。相反，流的原则建议通过频繁地部署较小的增量来改善这种情况。
11. 机遇。P30
    要学会把问题看作改变的机遇。这不是说在软件开发中没有问题。但是，“幸存”（survival）的态度会导致仅仅解决足够的问题而蒙混过关。要达到优秀，就必须把问题转化为学习和改进的机遇，而不仅仅是幸存。极限的一部分意思就是有意识地选择将每个问题转化为机遇：个人成长的机遇、关系升华的机遇、软件改进的机遇。
12. 冗余。P31
    软件开发中关键的困难问题应该用几种不同的方法解决。甚至如果一种方案最终失败了，其他的方案还可以阻止灾难的发生。冗余的成本不仅仅是与没有灾难发生的情况相比所多出来的那一部分花费。
13. 失败。P31
    失败不是浪费吗？不是，如果它能够产生知识的话。知识是有价值的，这种价值有时候是很难获得的。失败也许是不可避免的浪费。如果你知道实现故事的最佳方法，你只需用那种方法实现它就可以了。如果你不知道，找到它最经济的办法是什么呢？当你不知道要怎么做的时候，冒一点风险失败可能是通向成功的最短最稳妥的道路。
14. 质量。P32
    通过牺牲质量来控制的手段是没有效率的。质量不是一个控制变量。项目不会因为接受低质量而加快进度，也不会因为要求更高质量而使进度减慢。要求高质量通常导致更快的交付，而降低质量标准通常会导致更晚的不可预见的交付。
15. 婴儿步。P33
    人们总是试图大步地进行大的转变。毕竟有一段很长的路要走，而且要在很短时间内抵达。但突然间发生重大改变是危险的。被要求改变的是人，而改变是令人不安的，人们适应变化的速度毕竟是有限的。婴儿步并不是说多慢或者停止变化。在适当的条件下，人们和团队可以非常快地迈出很多的小步，以至于看起来就像是在跳跃前进。
16. 接受责任。P34
    责任不能被指定，只能被接受。如果有人试图给你责任，只有你自己能够决定是否负这个责任。责任和权利需要并行。两者错位会扭曲团队的沟通。当一个过程专家告诉我该怎样工作，却不承担这些工作及其后果的时候，权利和责任就错位了。我俩都无法从一个理智的角度出发来看到或使用那些帮助我们改进的反馈。另外，错位还要付出情绪方面的成本。

第6章 实践

1. 实践本身是空洞的。除非以价值观作为目的，否则实践会变得生搬硬套。P35

第7章 基本实践

1. 坐在一起。P37
   在大到足够容纳整个团队的开放空间中进行开放。为了满足隐私和“自己的”空间的需求，可以在附件设置一些私人空间，或者对工作时间做出限制，这样团队成员对隐私的需要可以在其他地方得到满足。
2. 完整团队。P39
   将拥有项目成功所必须的各种技能和视角的人都包含进团队。其实这就是过去早就有了的交叉功能团队（cross-functional team）的想法。但这个实践的名字反映了它的目的：一种团队的整体感，成功所需要的所有资源准备。一个健康的项目需要热烈的交互，这些交互应该主要是按团队来进行组织，而不是以不同的功能组为单位进行。
3. 信息工作空间。P40
   让你的工作空间与你的工作相关。一个对项目感兴趣的观察者应该能够走进团队并在15秒之内对项目如何运转有个大致的概念。他也应该能够通过近距离的观察而获得更多的真正或潜在问题的相关信息。
4. 充满活力地工作。P41
   只要你可以在有效率的时间段高效地工作就足够了。
5. 结对编程。P42
   所有产品程序的编写都由坐在一台机器前的两个人完成。结对程序员：
   • 使彼此都专注于任务。
   • 一起头脑风暴，讨论系统的精化。
   • 理清想法。
   • 当搭档陷入困境时要主动，这样才能减少挫折。
   • 使彼此都对团队的实践负责。
6. 结对与个人空间。P43
   不同的人和文化对舒服的身体空间的大小要求是不同的。在结对时尊重个体区别是重要的。
7. 故事。P45
   使用客户可见的功能单元进行计划。软件开发已经被“需求”这个词误导了，“需求”在词典中被定义为“必须或强制的东西”。这个词带有一种绝对和永久的含义，这抑制了“拥抱变化”。
8. 周循环。P46
   一次计划一周的工作。在每周开始的时候开会。在这个会议中：
   • 回顾迄今为止的进展，包括上周的实际进展与期望进展的吻合进度。
   • 让客户挑选在这周内要实现的故事。
   • 把故事分解成任务。团队成员签字接受这些任务并估算它们的工作量。
9. 季度循环。P48
   一次计划一个季度的工作。每个季度根据更大的目标对团队、项目、进度和安排做一次反省。在季度计划中：
   • 确定瓶颈，尤其是那些在团队控制之外的。
   • 开始修补措施。
   • 计划季度的主题。
   • 挑选对应那些主题的整个季度的故事。
   • 集中在宏观想法上，考虑项目和组织的关系。
10. 松弛。P49
    在任何计划中，都包含了一些假如落后了就可以取消的小任务。你总可以在后来增加更多的故事、并且交付比承诺更多的故事。在不信任和不兑现承诺的气氛中，实现你的许诺是很重要的，已实现的许诺对重建信任关系是大有帮助的。
11. 10分钟构建。P50
    在10分钟之内自动地构建整个系统和运行所有的测试。超过10分钟的构建，人们一般很少愿意使用它，因此会导致反馈机会的丧失。更短的构建则不能给你时间去喝咖啡。
12. 持续集成。P51
    不超过两个小时就对改变的地方进行一次集成和测试。团队编程并不是分而治之，而是分、治以及集成。集成步骤是不可预知的，但很容易就会花费比原始编程更多的时间。你等待越长的时间才集成，花费就越多，越不可预知。
13. 测试优先编程。P52
    在改变任何代码之前先编写一个自动化测试。测试优先编写能马上解决很多问题：
    • 范围蔓延 ——很容易就会使程序失去控制并引入一些“以防万一”的代码。
    • 耦合与内聚——如果测试编写起来很困难，这是个信号，说明在设计上有问题，而不是测试的问题。低耦合、高内聚的代码是很容易测试的。
    • 信任——如果一段代码不能运行，那么它的作者是很难得到别人信任的。
    • 节奏——编程的时候很容易就会几个小时都不知道自己再干什么。如果使用测试优先编程的方法，下一步要做的工作就会很清楚。
14. 增量设计。P53
    每天都考虑你的系统设计，力求使得系统设计适应当天的系统需求。如果你对系统最佳设计的理解发生了飞跃性的进步，则需要进行逐步而持久的工作，让设计和你对系统的理解新保持一致。

第8章 启程

1. 改变从意识开始。改变所需要的意识来自于感觉、直觉、事实或局外人的反馈。感觉虽然有价值，但需要和事实或可信任的观点相互校验。

第9章 扩展实践

1. 真实客户参与。P61
   将那些生活或业务受到待开发系统影响的人纳入到团队中来。有远见的客户可以参与季度计划和周计划。拿出开发资金的一部分给他们，让他们提出想要的功能。如果这些客户可以比市场上其他人提前6个月看到一些问题，那么做出他们想要的系统会使你领先于你的竞争对手。
2. 增量部署。P62
   找到你能马上处理的一小片功能或少量的数据集，并部署它。
3. 团队连续性。P63
   将高效的团队凝聚在一起。在大组织中有一种趋势，那就是将人抽象成物品：即插即用的编程单位。软件中价值的创造不仅取决于开发人员所知道的和所做的事情，也取决于他们之间的关系以及它们共同完成的事情。忽视关系和信任的价值，而仅仅是简化调度问题，这在经济上将是失败的。
4. 收缩团队。P64
   随着团队能力的增强，保持工作量不变，同时逐渐减少团队的规模。这样可以从团队中抽出人来组成更多的团队。如果一个团队人数太少，就将它与其他的小团队合并。
5. 根源分析。P65
   下面是XP中一个响应缺陷的过程：
   • 编写系统级自动测试，用以演示缺陷及原本想要的行为。
   • 编写范围尽可能小但同样能在现这个缺陷的单元测试。
   • 修改系统以通过单元测试。这也应该使系统测试通过。如果不能，返回到步骤2.
   • 一旦缺陷排除了，找出产生这个缺陷的原因，也找出没有发现它的原因。采取必要的措施来防止这类缺陷将来再次出现。
6. 共享代码。P66
   团队里的任何人可以在任何时候改善系统的任何部分。如果系统出错了，并且修正它没有超出我正在做的事情的范围，那么我应该挺省出来修正它。
7. 代码和测试。P67
   项目中需要维护的永久制品只有代码和测试，其他的文档都可以从代码和测试中生成。
8. 单一代码库。P68
   保持一个代码流。你可以在一个临时分支上开发，但永远不要让它的生存期超过几小时。多代码流是软件开发中巨大的浪费源。
   不要让你的源代码有更多的版本。与其增加新的代码库，不如修正那些潜在地妨碍你使用单一代码库的设计问题。
9. 每日部署。P69
   每天晚上都需要将新代码融合到产品中。因为程序员桌面上和产品之间的任何差距都有风险。没有与已部署的软件同步的程序员是冒着风险的，冒着在没有精确反馈信息的情况下做决策的风险。
10. 协商范围的合同。P70
    签订具有固定的时间、成本和质量的软件开发合同，但是要求就系统的精确边界进行不断的协商。通过签署一系列的短期合同而不是一个长长的合同，可减少风险。
11. 依用付费。P70
    对于依用付费的系统，你可以在系统每次被使用时收费。现金是最终的回馈。资金不仅是具体的，而且你可以小费它。将软件开发同资金流直接联系起来能够为系统的改进提供精确而及时的信息。

第10章 完整XP团队

1. 测试员。P74
   XP团队中的测试员帮助客户在实施前选择和编写系统级的自动化测试，并为程序员知道相关的测试技术。在开发早期，测试员的角色转变为，在功能没有实现之前帮助定义和说明可接受的系统功能的组成部分。
   在周循环中，降临至选定故事头上的第一件事就是它们将被变成系统级的自动化测试。
2. 交互设计师。P75
   XP团队中的交互设计师要选择系统的整体隐喻，编写故事和评估已部署系统的使用情况来为新故事寻找机会。团队要有限处理最终用户所关心的。交互设计的工具能版主团队分析和搞清楚用户领域，虽然这不能取代同真实人物的交谈。
3. 架构师。P76
   XP团队中的架构师要查找并进行大规模的重构、编写系统级的架构压力测试，并实现故事。在项目的整个周期，架构师逐步地应用他们的专业知识到项目中，他们指导者项目架构的进化。小系统的架构应该与大系统的架构不一样。对于小系统，架构师要确保系统有适当小的架构。随着系统的增长，架构师要确保架构的跟进。
4. 项目经理。P77
   XP团队中的项目经理负责促进团队内的沟通，协调同客户、供应商组织其他角色的沟通。项目经理充当项目历史的记录者，提醒团队已经取得多少进展。项目经理需要有创造力，来包装项目信息陈述给主管和同行。需要频繁地变更信息来保持准确性，项目经理的挑战在于有效地和别人沟通这些变更。
5. 产品经理。P78
   在XP中，产品经理要编写故事、挑选每季度循环的主题和故事、挑选周循环的故事、在实现工作涉及故事没有设计的领域时回答疑问。产品经理不只是在项目开始阶段挑选一些故事然后就可以休息了。他们要随时关注在每个时刻什么可以发生了，而不是提前预测什么将发生。
6. 主管人员。P79
   主管人员要给XP团队提供勇气、自信和责任感。XP团队的力量以及朝着共同目标的共同前进都有可能是缺点。如果团队目标不能和公司目标保持一致怎么办？如果因为压力和成功的兴奋使目标偏移了怎么办？主管人员负责或监督XP团队的工作之一就是清晰地表达并维持更大范围的目标。
7. 技术文献书写员。P80
   XP团队的技术出版物的作用是要提供关于系统特性的早期反馈，以及同用户建立更亲密的关系。
8. 用户。P82
   XP团队中的用户帮助编写和挑选故事并在开发中做出领域相关决策。
9. 程序员。P82
   XP团队中的程序员评估故事和任务，将故事细分成任务、编写测试、编写实现功能、自动化枯燥的开发过程、逐步地改进系统的设计。
10. 人力资源。P83
    对XP团队成员的个人考评和应用XP之前没有什么差别。在XP中，有价值的雇员是这样的：
    • 行为受人尊敬。
    • 与他人相处良好。
    • 主动承担任务。
    • 言而有信。
11. 角色。P84
    成熟XP团队的角色不是固定和严格的。我们的目标是让每个人为团队的成功做出最大的努力。首先，固定的角色可以帮助培养新习惯，比如让技术人员做技术决策，业务人员做业务决策。但是，在团队成员间建立了相互尊重的新关系以后，固定角色妨碍了每个人做出最大贡献的目标。

第11章 约束理论

1. 一种考虑整个系统吞吐量的方法是约束理论。约束理论认为任何系统在某一时间只存在一个约束（偶尔也会存在两个）。要提高系统的整体吞吐率，那么必须首先找出那个约束，并确保它能够全速工作，然后再寻找某些办法，或者增加约束的容量，来分流一部分工作到其他非约束部分，或者完全消除约束。P85

第12章 计划：管理范围

1. 计划可以使目标和方向清楚明确。XP中的计划开始于把当前的目的、假设和事实公布与众。利用当前明确的信息，你们可以就什么是范围之内的、什么是范围之外的，以及下一步该做什么达成共识。P90
2. 任何时间尺度的计划都有这样四个步骤：P92
   • 列出可能需要完成的工作部件。
   • 估算这些部件。
   • 为计划周期设定一个预算。
   • 就预算内需要完成的工作达成共识。谈判时，不要改变这些估算或者预算。

第13章 尽早测试、经常测试、自动测试

1. 软件开发的另一个目标是减少缺陷的出现到一个可以适度增长团队信任的水平。用于减少缺陷的投资，跟对团队工作的投资一样有意义。P97

第14章 设计：时间的价值

1. 概括来说，向XP风格设计的转换是设计决策时期的转换。推迟设计，到可以根据经验进行及可以马上使用设计的时候。这就允许团队：
   • 更早部署软件。
   • 毫无疑问地做决策。
   • 避免忍受糟糕的决策。
   • 当起始设计假设被取代时，维持开发的速度。
2. XP团队更喜欢尽可能简单的解决方案。设计简单性的四个标准：
   • 适合于希望得到它的人们。设计如何华丽优美并不重要，入股哦需要使用它工作的人不明白它，它对他们来说就不简单。
   • 易交流。需要交流的所有思想都表现在系统中。就像单词表里的单词，系统的每个元素都需要跟未来的读者沟通。
   • 提取了共因子。逻辑或结构的重复使得代码难以理解和修改。
   • 最小化。在以上三点限制下，系统应该具有尽可能少的元素。元素越少就意味着需要的测试、归档和交流地越少。

第15章 增大XP规模

1. 项目中的人数并不是软件开发规模的唯一衡量标准。软件发展可以在很多维上扩大规模：
   • 人数
   • 投资
   • 整个组织的大小
   • 时间
   • 问题的复杂性
   • 解决方案的复杂性
   • 故障的后果
2. 当面对一个大问题时，我用三个步骤工作：
   • 将问题转化为小问题。
   • 应用简单的解决方案。
   • 如果还有问题则应用复杂的解决方案。
3. 人数。P111
   如果仅仅用小的团队不起作用，那就把大的编程问题转化为一些小的问题，每个问题可以由小团队来解决。首先，有一个小团队解决问题的一小部分，然后我们沿着它的自然分割线划分系统，让几个团队开始在其中工作。分割系统的同时可能会引入风险，使得集成时可能合不起来，所以要频繁地集成以协调各团队之间不同的假设。这是一个“治而分之”的策略，而不是“分而治之”的策略。
   “治而分之”的目标是能够把每个团队当做单独的团队管理，以限制协调的成本。尽管如此，整个系统仍然需要频繁的集成。
4. 投资。P112
   将其看做消费的公司可以把XP看做对一个已部署项目的维护。把大部分软件开发看做资本投资的公司可以使用季度或年度的周期针对特定题的批准执行大量的开发，即使项目的精度范围没有预先详细说明。
   如果你要以XP的风格开始一次大规模的软件开发，尽早子啊财政上找个同盟帮助你操纵这些问题。
5. 组织的大小。P112
   在XP团队中，项目经理每周五回来询问每个队员这个星期做了什么。他以季度计划的形式记录这些信息。在季度评审时，就会看到团队计划包含了组织中最精确的评估。
6. 时间。P113
   在时间上扩大规模的最简单的情形是让团队再整个项目的过程中维护项目的连贯性。从而使自动化测试和增量设计可以用来保持系统进一步成长的活力和能力。
7. 问题的复杂性。P114
   XP非常适合需要专家紧密协作的项目。这些项目初期的一个挑战是，让每个人都协调工作，同时相互学习取长补短。
8. 解决方案的复杂性。P115
   XP处理额外复杂性的策略总是一样的：分解复杂性，同时持续交付。让你所在的角落明朗化。如果你在一个区域修正一个缺陷，把你所负责的地方整理好。一个异议就是这个“额外的”整理工作要花太长时间，而且团队很可能在修正缺陷的中断上浪费时间。因此，整理能帮助减少工作的开支。可见的计划使每个人都容易明白时间消耗在哪里，因此更容易接受针对做好工作的必要的评估。
9. 故障的后果。P115
   XP的流原则建议审计不应该是在项目结束时的一个阶段，而应该较早并且经常地审计。

第16章 访谈

1. 脑子里有一个尺度。对于适合用XP的项目，我们会用XP中所有的方法。理想的XP项目是由一个充满热情的团队用Java语言进行不熟悉领域的开发。如果我们要扩展遗留的C++代码，我们必须要将XP的方法嵌入到更加瀑布化的项目中。我们要事先做更多的需求分析和设计工作，并且在给客户部署之前要有正式的测试阶段。P119
2. 遗留项目无法使用“简单设计”的实践，因为从一开始设计可能就不是简单的。而由于设计的复杂性，导致没办法写充足的测试，这样就会存在太多的Bug。此外，由于在C++中缺乏重构工具，重构很难进行。就是这些导致项目开始和结束两头的瀑布阶段。
3. 一定要采用XP过程，同时根据特性进行计划，要记得计划中的条目都应该是用户所关心的特性，还要保证每个季度都宣布一次计划，而且对计划的迭代要更加频繁，在实际开发中，我们甚至两个星期就迭代一次，同时不要忘记保证迭代的绝对稳定呢。最后，记得要让开发团队工作在一个开放的空间里，并分配以为客户和开发团队坐在一起。就算你不得不把XP嵌入到瀑布风格的开发中，你仍然可以获益很多。

第二部分 XP哲学

1. XP过程就是应用在软件上的精益制造。P123

第17章 XP诞生的故事

第18章 泰勒主义和软件

1. 在工程组织里把QA作为一个单独的部门也传递了这样的信息：工程学和质量是分离和并行的。这样带来的结果是，在组织里把质量从工程中分离出来使得质量部门的工作更像是惩罚性的，而不是建设性的。P131
2. 我不是说质量、架构或框架对软件开发是不重要的。恰恰相反，它们太重要了，因此我们才不会采用泰勒主义的社会结构，后者阻止沟通和反馈的流程，而这些对于在变化的环境中开发可运行的、灵活的、低成本的软件是至关重要的。P131

第19章 丰田生产制度

1. 丰田生产制度（Toyota Production System，TPS），最大的浪费就是生产过剩的浪费。P133
2. 在软件开发中生产过剩的浪费随处可见：很快就荒废了的臃肿的需求文档；从未用过的精心构思的架构；完成开发好几个月也没有在产品环境中集成、测试和执行的代码；以及直到无关轻重或是会引起误解时才被人阅读的文档，这些生产要素对软件开发是非常重要的，我们必须立即获取它们的使用价值，以便得到我们要消除浪费的反馈信息。P134

第20章 应用XP

1. 找一个经理主管人员在组织里发起对XP的支持，会让你在过度到这种新的工作风格时与公司的沟通更和谐。开始组织变化之路仍然要从你自己做起，这是你可以控制的一个变化。首先锻炼你的技能，然后将它们投入使用。模范带头开始是一种有力的领导形式。P137
2. 期望别人做你自己不想做的事情是无礼和低效的。让别人冒你不想冒的险，将破坏队员间的关系和团队凝聚力。权利和责任的错位会导致不信任，你也将以此失去学习、反馈和自我提高的机会。P137
3. 学习技能并付诸应用的策略在很多粒度上都会起作用：P137
   • 你学会测试先编程，然后和你的团队共享这种方法和经验。
   • 你的团队要学会逐个故事评估和开发，然后邀请内部客户挑选故事。
   • 你的组织要学会按计划部署可靠的软件，然后邀请外部客户参与做计划。
4. 首先改变自己，然后把改变的成果贡献给其他人。这两个步骤都能创造价值。我改变，是因为我发现了改进的方法。而当我向客户提供新技能时，我已经经历了它们带来的好处。P137
5. 如果你知道怎么改进，那就去改进，你做出改变并观察效果，然后对这些变化融会贯通，使之成为固定的习惯，最后你到了稳定状态从而可以吸收更多反馈并确定下一步行动。P137
6. 推动快速转变的条件如下：P138
   • 校准价值观。团队和组织愿意以XP的价值观指导工作。
   • 痛苦。团队最近经历了一次失败，比如开发中止或部署失败，这些痛苦而清晰的记忆使人们更加愿意尝试剧烈的变化。
7. 选择教练。P139
   “教练”这个词意味着在成为团队一份子和坚持自己独立观点之间的一个平衡。开始阶段，教练负责发现改进的机会并引导实验解决它们，教练要有经验和洞察力，才不会陷入日复一日的团队工作中。

第21章 纯度

第22章 离岸开发

1. XP的价值观就像适合于坐在一起的团队一样适用于多点开发。更强烈地用户反馈，因为距离产生了自然隔离。P144

第23章 永恒的编程之道

1. XP依赖于有能力的程序员的成长：能够快速地评估、实现和部署可靠的软件。P149

第24章 XP和社区

1. 社区的支持是软件开发中一笔巨大的资产。的确如此，不管这里谈及的社区是团队自身，还是当地具有相同目标的软件开发者，或是全球性的社区，它们都具有极高的价值。社区提供了一个可靠的地方以吐露问题和共享经验。社区是个好地方，既可以找到志同道合的听众，也可以聆听别人。P150

第25章 结语

1. XP的关键是诚实，与我真正的价值观相协调。一旦把诚实作为自己的目标，我发现，我实际上持有的价值观不是我想让世界思考我所坚持的。P152