敏捷软件开发：原则、模式与实践 第一至五章读书笔记

第一章 价值观和原则

核心价值观：想要项目取得成功，就必须构建起具有合作精神的、自组织团队。

• 过程和方法对于项目的结果只有次要的影响，首要的影响是人。
• 鼓励构建自组织团队的企业比认为“软件团队是一群雷同可替代的人堆砌而成”的企业要有大得多的竞争优势。

一、4个价值观

1. 个体和交互胜过流程和工具

• 一群会交流、沟通的平均水平程序员比一群不进行交流的高水平程序员要更有可能获得成功。
• 工具的作用容易被夸大，应从小工具开始尝试，直到发现无法适用的时候再去更换。
• 应该先致力于构建团队再让团队给予需要来配置环境。

2. 可以工作的软件胜过面面俱到的文档

• 文档过多比文档少更糟糕，文档越多就需要花越多时间维持文档和代码同步，不这样文档就可能产生重大误导。
• 文档中应该要有一份一二十页的系统高层结构和简要的设计原理。
• 培训新成员应该让老团队成员用没有二义性的代码进行人与人之间的直接交流传授。

3. 客户合作胜过合同谈判

• 不能仅仅写下一份想要的软件的描述然后让人在固定的时间内以固定的价格去开发它。
• 项目成功的关键在于尽可能和客户进行真诚协作，使用合同指导这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。

4. 响应变化胜过遵循计划

• 计划应是可以根据商业和技术灵活变化的。
• 详细计划急迫的任务，粗略规划未来的任务，两周内的详细，三个月的粗略，再往后就更粗略。

二、12个原则

1. 以人为中心，提供成员所需环境、资源支持，尽量排除会对人产生负面影响的因素。
2. 团队自组织，外部不直接分派任务给团队成员，团队内部确定完成任务的最优方式。
3. 内部传递信息尽量使用高效的面谈方式，业务人员和开发人员需在一起工作。
4. 定期反省怎么提高效率并调整组织方式、规则、规范、关系以适应不断变化的环境。
5. 尽早交付具有初步功能、有价值的软件。
6. 持续交付可工作的软件，交付时间间隔越短越好。
7. 提倡长期恒定的、可持续的开发速度。
8. 不根据开发阶段、文档数量、基础结构代码量来衡量开发进度，只使用完成必须功能的百分比来衡量。
9. 文档不包含所有项目信息，不需要书面规范、书面计划、书面设计。
10. 提倡高质量技术和好的设计模式，有利于提高开发速度。
11. 不预测明天的问题࿰