《敏捷软件开发（原则、模式与实践）》前三章笔记

 《敏捷软件开发（原则、模式与实践）》
（美）Robert C.Martin 著
        邓辉 译
        孟岩 审

笔记

笔记摘录：Eleven

第一部分 敏捷开发

第1章 敏捷实践
    
    教堂尖顶上的风标，即使由钢铁制成，如果不懂得顺应风势的艺术，一样会被暴风立即摧毁。
                                                ——海因里希.海涅（1797－1856，德国诗人）

1 敏捷联盟宣言（The Manifesto of Agile Alliance）
我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法，通过这项工作，我们认为：
    个体和交互     胜过    过程和工具
    可以工作的软件 胜过    面面俱到的文档
    客户合作        胜过 合同谈判
    响应变化        胜过    遵循计划

1.1 个体和交互胜过过程和工具
    人是获得成功的最为重要的因素。
    一个优秀的团队成员未必就是一个一流的程序员，一个由平均水平程序员组成的团队，如果具有良好的沟通能力，将要比那些虽然拥有一批高水平程序员但是缺乏沟通和料流的团队更有可能获得成功。
    合适的工具对成功来说是重要的，但是其作用不可被过分夸大，敏捷方法建议从小的工具开始，尝试一个工具，直到发现它无法适用时才去更换它。例如：如果开始的时候没有迫切要求使用庞大的、高性能的数据库，那么就可以先使用文件来取代。  
    记住，团队的构建要比环境的构建重要得多。一个项目中，一个你该首先致力于构建团队，然后再让团队基于需要来配置环境。

1.2 可以工作的软件胜过面面俱到的文档
    没有文档的软件是一种灾难，然而过多的文档比没有文档更糟，会浪费时间和精力，如果文档和代码不能同步，文档会造成更多的代价和误导。
    对于团队来说，编写并维护一份系统原理和结构方面的文档将总是一个好主意，但是必须短小而且主题突出，“短小”的意思是说，最多有一二十页。“主题突出”是说应该仅论述系统的高层结构和概括的设计原理。
    在给新的团队成员传授知识方面，最好的两份文档是代码和团队。（代码是惟一没有二义性的信息源），在团队的头脑中，保存着时常变化的系统脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。
    Martin文档第一定律（Martin's first law of document）：直到迫切需要并且意义重大时，才编制文档。

1.3 客户合作胜过合同谈判
    成功的项目需要有序、频繁的客户反馈。作者认为小嗯木成功的关键在于和客户之间真诚的写作，并且合同指导了这种写作，而不是试图去规定项目范围的细节和固定成本下的进度。

1.4 响应变化胜过遵循计划
    响应变化的能力常常决定这一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面的变化。
    作者认为较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。我们应该清楚地知道下两周要完成的任务，粗略地了解一下以后三个月要实现的需求。至于系统一年后将要做什么，有一个模糊的想法