敏捷宣言
1、人和交互重于过程和工具
人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就算是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。
一个优秀的团队成员未必就是一个一流的程序员。一个优秀的团队成员可能是一个具有平均水平的程序员，但是却能够很好地与他人合作。好的合作（沟通以及交互）能力要比单纯的编程能力更为重要。一个由平均水平的、具有良好沟通能力的程序员组成的团队，将要比那些虽然拥有一批高水平的程序员，但是成员之间却不能进行交流的团队更有可能获得成功。
合适的工具对于成功来说非常重要。像编译器、IDE和源代码控制系统等，对于团队的开发者正确地完成他们的工作至关重要。然而，工具的作用可能被过分的夸大。使用过多庞大的、笨重的工具就像缺少工具一样，都是不好的。
我的建议是从使用小工具开始。尝试一个工具，知道发现它无法适用时才去更换它。不要着急去购买哪些先进的、价格昂贵的源代码控制系统，相反应该先使用一个免费的系统，直到能够证明该系统已经不再适用。在决定为团队购买最好的CASE工具许可证前，先使用白板和方格纸，直到明确地知道需要更多的功能。在决定使用庞大的、高性能的数据库系统前，先使用平面文件（flat file）。不要认为更大的、更好的工具可以自动地帮你做得更好。通常，他们造成的障碍要大于带来的帮助。
记住，团队的构建要比环境的构建重要的多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。
2、可以工作的软件重于面面俱到的文档
没有文档的软件是一种灾难。代码不是交流系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行面熟。
然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且使这些文档和代码保持同步，要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。
对于团队来说，编写并维护一份系统原理和结构方面的文档总是一个好主意，但是那份文档应该短小并且主题突出。短小的意思是说，最多有一二十页。主题突出的意思是说，应该仅论述系统的最高层次结构和概括的设计原理。
如果我们拥有的仅仅是一份简短的系统原理和结构方面的文档，那么如何来培训新的团队成员，使他们能够从事系统相关的工作呢？我们会非常密切的和他们工作在一起。我们紧挨着他们坐下来帮助他们，把我们的知识传授给他们。我们通过密切的培训和交互使他们成为团队的一部分。
在向新的团队成员传授知识方面，最好的两份文档是代码和团队。代码真实地表达了它所做的事情。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是唯一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图。人和人之间的交互是把这份脉络图记在纸上并传授给他人的最快、最有效的方式。
许多团队因为注重文档而非软件，从而导致进度拖延。这常常是一个致命的缺陷。有一个简单的原则可以预防该缺陷的发生。
Martin 文档第一定律
直到迫切需要并意义重大时，才编制文档。
3、客户合作重于合同谈判
不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都将以失败而告终。有时，失败是惨重的。
告诉开发团队想要的东西，然后期望开发团队消失一段时间回来后就能够交付一个满足需要的系统，这对于公司的管理者来说是具有诱惑力的。然而，这种操作将导致低劣的质量和失败。
成功的项目需要定期且频繁的客户反馈。不是依赖于合同或者关于工作的陈述，而是让软件的客户和开发团队密切地工作在一起，并尽量经常地提供反馈。
一个指明了需求、进度以及项目成本的合同存在根本上的缺陷。在大多数情况下，合同中规定的条款远在项目完成之前（有时甚至是远在合同签署之前）就变得没有意义。那些为开发团队和客户的协同工作方式提供指导的合同才是最好的合同。
4、 随时应对变化重于遵循计划
随时应对变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的，并且易于适应商务和技术方面的变化。
计划不能考虑得过远。首先，商务环境很可能会变化，这会引起需求的变动。其次，一旦客户看到系统开始运作，他们很可能会改变需求。最后，即使我们知道需求是什么，并且确信他们不会改变，我们仍然不能很好地估算出开发他们需要的时间。
对于一个缺乏经验的管理者来说，创建一张优美的、关于整个项目的PERT或者GANTT图，并把它贴到墙上是很有诱惑力的。他们也许觉得这张图赋予了他们对项目的控制权。他们能够跟踪单个人的任务，并在任务完成时将任务从图中去除。他们可以将实际完成的日期和计划完成的日期进行比较，并对出现的任何偏差作出反应。
然而，实际发生的是：这张图的组织结构不再适用。当团队增加了对于系统的认识，当客户增加了对于需求的认识，图中的某些任务会变得没有必要。另外一些任务会被发现并增加到图中。简而言之，计划图的形状将会改变，而不仅仅是日期上的改变。
较好的做计划的策略是：为了下一周做详细的计划，为了3个月做粗略的计划，再以后就做极为简略的计划。我们应该清楚地知道下周要完成的任务，粗略地了解一下以后3个月要实现的需求。至于系统一年后将要做什么，有一个模糊的想法就行了。
计划中这种逐渐降低的细致度，意味着我们仅仅对于迫切的任务才花费时间进行详细的计划。一旦制定了这个详细计划，就很难进行改变，因为团队会根据这个计划启动工作并有了相应的投入。然而，由于该计划仅仅支配了一周的时间，计划的其余部分仍然保持着灵活性。
敏捷遵循的原则
纯正而传统的计划驱动开发常常称为“瀑布开发”。计划驱动的开发来源于人们总是希望计划和预测工作内容，确定最佳工作方式。它的思路是：计划制定得越好，对产品的理解就越好，执行就越好。计划驱动过程常称为“顺序过程”，因为每一个实际工作者按照顺序依次执行，在完整的需求分析后是完整的设计、编码、构建，然后是测试 。
SCRUM则奉行另一套不同的理念，该理念很好处理了高不确定性而导致很难作出宏观预测的问题。
1、可变性和不确定性
积极采用有帮助的不变性；
采用迭代和增加开发；
通过检验、调整、适用和透明利用可变性；
同时减少各种形式的不确定因素。
2、预测和适应
不到最后时刻、不轻易决定；
承认无法一开始就把事情做对；
偏好适应性、探索性的方法；
用经济合理的方法授受变化；
在预测型事前工作和适应型刚好工作之间做出平衡；
3、经验认知
快速验证重要的假设；
利用多个认知循环并行的优势；
组织工作流程以获得快速反馈；
4、WIP
使用经济合理的大小；
识别并管理库存以达到良好流动；
关注闲置工作而不是闲置人员；
考虑延期成本；
5、进度
适应实时信息并重新制定计划；
通过验证资产来测量进度；
专注于以价值为中心的交付；
6、执行
快速前进，但不匆忙；
以质量为魂；
选用最小，够用的仪式。
第一章 起步
1.1 敏捷教练的职责
敏捷教练的目标是培养高产出的敏捷团队，成员有自我判断能力，不依赖教练为他们制定敏捷法则。
留意：眼观六路，耳听八方，留意团队的工作方式，仔细思考他们为什么会这样做，想想有哪些诱因；
反馈：给予团队反馈，跟他们分享你观察到的情况。帮助他们利用这些反馈改进工作方式，做到可以自己发现的问题；
教育：想方设法鼓励他们学习。
引导：清理障碍，促进有建设性的沟通和协作，可以使团队更容易走向敏捷。
支持：团队受阻时要在场，鼓励他们继续前行，帮助他们保持动力。
1.2 养成教导的态度
以身作则
平衡心态
循序渐进--耐心是教练应该具备的最重要品质之一
谨慎言辞
边走边学
第二章 与人合作
2.1 倾听
教练应全神贯注地倾听。倾听团队的困苦和哀嚎。倾听过程中留意处于萌芽阶段的想法，它们需要支持才能成形。
营造空间；
保持开放；
表示关注；
肯定；
先倾听再建议
维系信任关系；
背景倾听。
2.2 给予反馈
2.3 化解矛盾
四个基本步骤：
观察：当你....的时候
感觉：你是否感觉到....
需求：因为你需要....
请求：你想让....做...吗？
2.4 达成共识
2.5 难关
会议中的情绪爆发
缺乏社交能力
文化差异
第三章 领导变革
指导原则：要想获得提升，人们首先必须学会用新的行为做事之道
3.1引入变革
授人以渔
教育团队
演示
公示
兜售问题
培养变革的主人翁意识
变革试验
3.2提问
问开放式问题
问什么
求助型问题
思考型问题
反思型问题
五问法
第一问：为什么我们昨天没有让软件上线？我们有太多的缺陷没能解决。
第二问：为什么 我们那么多没有解决的缺陷？因为测试人员发现后没有及时通知开发人员
第三问：为什么测试人员没有通知开发人员？因为开发人员在忙其它事情。
第四问：为什么测试和开发人员不在一起工作？因为测试人员要支持所有团队，不是只盯着其中一个团队。
第五问：为什么我们没有足够的人手保证每个团队都有自己的测试人员？
何时不要问问题
3.3 鼓励学习
创造学习机会
到组织外学习
3.4 引导会议
3.5 难关
3.6 检查表
分享你对敏捷的激情，但也不要过于狂热。
向团队兜售问题。帮他们理解为什么要改进；
遇到阻力，先查明源头；
通过提问的方式让团队参与改进他们自身的敏捷流程，用“求肋型问题”问题获得支持，用思考型问题引起反思。用五问法进行根本原因分析。
鼓励多渠道学习敏捷；
新形式的会议对团来说不容易开成功。
第四章 建设敏捷团队
4.1 帮助团队形成凝聚力
社会粘合剂
每日站会和回顾会，是促进彼此了解的重要机会；
创造机会让人们可以了解彼此
建立信任
缩小差距
4.2 营造团队空间
4.3 角色平衡
4.4 激励团队
不太容易，但不太难：卓越团队的秘诀在于，设定可达成却有挑战性的目标。
找一个能吸引人的目标
留出创新时间
庆祝成功
不要打击士气
谨防奖励
4.6 检查表
1、创造机会让团队成员相互认识，有助于团队形式凝聚力。定期举行非正式聚会，例如共同进餐或喝点小酒。
2、创建共享的工作空间可以帮助团队在同一地点好好工作。努力让整个团队坐在一起；
3、明确角色职责。
4、确保团队有一个可达成却有挑战的目标。确保工作别在太容易，但也不能太难。
5、准备食物和饮料庆祝发布。
第五章 每日站会
每天同一时间，聚集团队围成一个圈站立并让他们回答以下三个问题：
昨天我做了什么？
今天我要做什么？
我遇到了什么障碍？
5.1 站立
5.2 始于团队，服务于团队
团队务必了解，每日站会是他们用来同步他们的工作内容的。建立团队焦点，团队掌控流动。
5.3 处理问题
5.4 设定时间
5.5 择机辅导
5.6 检查表
1、寻找一片空间，可以让团队围着团队板开每日站会。
2、让团队来决定每日站会的时间；
3、鼓励团队做到答复简短而亲切。
4、保持每日站会顺畅进行；
5、请客户参加每日站会分享分的进展和信息更新；
6、收集问题并贴到白板上，让每个人都能看到。
7、回顾会议时评审每日站会的效率和站会形式的深度效果。
第六章 理解构建目标
Ron Jeffries用3C来概括用户故事关键的三大方面：
Card(卡片)
Conversation(交谈)
Confirmation(确认)
6.2 鼓励交谈
6.3 与卡片共舞
故事模板：
作为一名.....用户，我想要.....能力，这样是为了....好处
6.4确认细节
简单故事测试模板Given-When-Then
例如：给定用户正在浏览搜索页面并输入了“瀑布辅导”，如果用户点击“搜索”按钮，那么将提示一条消息：对不起，没有找到相关书籍。
6.6 检查表
1、教团队学会咒语“卡片、交谈、确认”，帮助他们记住用户故事的三个基本元素，包括交谈、卡片和确认。鼓励团队和客户进行交谈，并以此提炼用户故事。
2、亲自向团队示范如何写故事卡，然后停下来让团队自己写。
3、确保团队工作空间和会场充足的卡片或便事贴用于讨论故事；
4、用户故事模板作为一名.....用户，我想要.....能力，这样是为了....好处。
5、辅助客户在规划会议之前准备好故事细节。可以拉几个团队成员参与进来，他们的问题和提议的故事测试都有助于界定用户故事。
第十章 测试驱动开发
指导原则：确保代码已经过自动化测试并成功通过
10.1 引入测试驱动开发
10.2 持续集成
10.3 保持使用TDD
10.5 检查表
转为测试驱动开发需要有充足的时间。转变太大，团队无法一口气做完。用迭代的方式引入TDD。
全新项目可以测试先行起步；
得到整个团队认可的方式才行。
团队计划要计入学写自动化测试的时间因素；
团队一起商定测试策略。从中间层的单元测试入手比较有保障。
持续集成是一种态度，而不是一组工具
留意运行缓慢的测试。
第十一章 代码整洁
指导原则：日益提供软件设计
11.1 增量式设计
增量式设计很简单，就是拿点时间出来，一小步一小步地边做边改。
摆脱分析过度。
对前进的方向达成共识。
预留设计时间
重构
可读的代码
11.2 集体代码所有权
代码风格
与专家共事
结对编程
11.5 检查表
帮助团队找到平衡点，决定如何分配用于软件设计与实现代码的时间。
提醒团队为增量式设计预留时间；
鼓励团队每次签入代码前进行重构
商定公共的编码风格。
采用结对编程
引入乒乓编程。