《敏捷软件开发》—读书笔记01.敏捷实践

1. 敏捷联盟

敏捷软件开发宣言：

1. 个体和交互胜过过程和工具
2. 可以工作的软件胜过面面俱到的文档
3. 客户合作胜过合同谈判
4. 响应变化胜过遵循计划

1.1 个体和交互胜过过程和工具

一次次项目的惨败，激发我们创建一个过程来约束我们的活动、要求有某些人为制品（如文档）的输出。
如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目。
一个优秀的团队成员可能是一个平均水平的程序员，但是却能够很好地和他人合作，合作、沟通、交互能力比单纯的编程能力更为重要。
合适的工具对于成功来说是非常重要的。使用过多的庞大、笨重的工具就像缺少工具一样，都是不好的。建议是从使用小工具开始，尝试一个工具，直到发现它无法适用时才去更换它。
团队的构建要比环境的构建重要得多。应该先致力于构建团队，再让团队基于需要配置环境。

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

对于团队来说，编写并维护一份系统原理和结构方面的文档将总是一个好主意，但是这份文档应该是短小的并且主题突出的，最多有一二十页，应该仅论述系统的高层结构和概括的设计原理。

在给团队成员传授知识方面，最好的两份文档是代码和团队。

1.3 客户合作胜过合同谈判

1.4 响应变化胜过遵循计划

较好的做计划的策略是：为下两周做详细的计划，为下三个月做粗略的计划，再以后就做即为粗糙的计划。我们应该清楚地知道下两周要完成的任务，粗略地了解一下以后三个月要实现的需求，至于系统一年后将要做什么，有一个模糊的想法就好了。

2. 原则

下面是敏捷实践区别于重型过程的特征所在。

1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
2. 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3. 经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5. 围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最具有效果并且富有效率的传递消息的方法，就是面对面的交谈。
7. 工作的软件是首要的进度度量标准。
8. 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9. 不断关注优秀的技能和好的设计会增强敏捷能力。
10. 简单——使未完成的工作最大化的艺术——是根本的。
11. 最好的架构、需求和设计出自于自组织的团队。
12. 每隔一段时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。