关键词：《敏捷软件开发》原则、模式与实践》，（美）Robert C.Martin著 ，读书笔记， 敏捷开发，敏捷实践
第一章 敏捷实践
- 敏捷联盟。
敏捷宣言：
个体和交互 胜过 过程和工具，
可以工作的软件 胜过 面面俱到的文档，
客户合作 胜过 合同谈判，
响应变化 胜过 遵循计划。
虽然右项也有价值，但是我们认为左项具有更大的价值。
1）个体和交互 胜过 过程和工具
不要认为更大、更好的工具可以自动帮你做的更好，通常，它们造成的障碍要大于带来的帮助。
团队的构建要比环境的构建重要得多。
2）可以工作的软件胜过面面俱到的文档
编写系统原理和结构方面的的文档总是一个好主意，但文档应该是短小的（最多一二十页）并且主题突出的（仅论述系统的高层结构和概括的设计原理）
在给新的团队成员传授知识方面，最好的两份文档是代码和团队。在团队成员的头脑中，保存着时常变化的系统的脉络图road map，人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。
直到迫切需要并且意义重大时，才来编制文档。
3）客户合作胜过合同谈判
成功的项目库需要有序、频繁的客户反馈。让软件的客户和开发团队密切的在一起工作，并经常的提供反馈。
那些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。
客户周复一周的观察着每个功能块的演进，所以他们知道何时这个功能块能够满足他们的需要。
即便经历大的功能块被裁掉，加进来另外一些功能模块，合同和项目都经受住了这些变更，并获得成功。成功的关键在于和客户之间的真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。
4）响应变化胜过遵循计划
a）响应变化的能力常常决定这一个软件项目的成败。
b）计划不能考虑得过远：
首先，商务环境的变化会引起需求的变动。
其次，客户会逐步增加对需求的认识。一旦客户看到系统开始运作，很可能会改变需求。
再次，团队会逐步增加对系统的认识。即便我们熟悉需求且相信需求不改，仍然不能从一开始就很好的估算开发时间。
c）较好的做计划的策略是：
为下两周做详细计划（清楚的知道下两周要完成的任务，一旦花费时间制定了对于迫切任务的详细计划，就很难进行改变），
为下三个月做粗略计划（粗略了解一下以后三个月要实现的需求，近细远粗保持了计划的灵活性），
再以后就做极为粗糙的计划（至于系统一年以后要做什么，有个模糊的想法即可）。
2.原则。
1）我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。（初期交付的系统中所包含的功能越少，最终交付的系统的质量就越高）
2）即使到了开发的后期，也欢迎改变需求、敏捷过程利用变化来为客户创造竞争优势。（敏捷团队会非常努力地保持软件结构的灵活性）
3）经常性地交付可以工作的软件、交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
4）在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
5）围绕被激励起来的个人构建项目库。给他们提供所需要的环境和支持，并且信任他们能够完成工作。（敏捷项目中，人被认为是项目取得成功的最重要的因素，所有其他的因素——过程、环境、管理等等——都被认为是次要的，当它们对人有负面影响时，就要对它们进行改变）
6）在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。（敏捷团队不需要书面的规范、书面的计划或者书面的设计，文档不是默认的沟通方式，默认的沟通方式是交谈）
7）工作的软件是首要的进度度量标准。（敏捷项目通过度量当前软件满足客户需求的数量来度量开发进度。只有当30%的必须功能可以工作时，才可以确定进度完成了30%）
8）敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
9）不断地关注优秀的技能和好的设计会增强敏捷能力。
10）简单——使未完成的工作最大化的艺术——是根本的。
11）最好的框架、需求和设计出自于自组织的团队。（敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目中所有方面的参与权力。不存在单一的团队成员对系统构架、需求或者测试负责的情况。）
12）每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。（敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整，为了保证团队的敏捷性，必须随环境一起变化。）
标签：读书笔记,Robert,胜过,客户,文档,敏捷,软件,团队 From： https://www.cnblogs.com/johnnyH/p/16818561.html