详谈agile开发中scrum、3355、四个仪式、十二原则、TDD、BDD、CI、CD等相关概念

敏捷过程概述
敏捷强调适应而非预测。
敏捷过程以人为中心，而非以过程为中心。

1、敏捷性软件过程类别：
极限编程（eXtreme Programming,XP）、SCRUM、动态系统开发方法（Dynamic System Development Method, DSDM）、水晶系列方法（Crystal Methodologies）、适配性软件开发（Adaptive Software Development ,ASD）、特征驱动开发（Feature Driven Development, FDD）等

1、敏捷过程的价值观
1） 个体和交互胜过过程和工具
人是软件项目获得成功最为重要的因素
合作、沟通能力以及交互能力比单纯的软件编程能力更为重要
合适的工具对于成功来说非常重要
团队的建构要比环境的建构重要得多，不能期望团队自动凝聚在一起。应该让团队基于需要配置环境。
2） 可以工作的软件胜过面面俱到的文档
过多的面面俱到的文档往往比过少的文档更糟
如何控制和把握软件创建与文档编制
软件开发的主要和中心活动是创建可以工作的软件
直到迫切需要并且意义重大时，才进行文档编制 （Martin’s first law of document）
如何衡量？
编写并维护一份系统原理和结构方面的文档
用户手册
新员工培训手册
编制的内部文档应尽量短小并且主题突出
3） 客户合作胜过合同谈判
客户不可能做到一次性地将他们的需求完整清晰地表述在合同中
为开发团队和客户的协同工作方式提供指导的合同才是最好的合同
4）响应变化胜过遵循计划
变化是软件开发中存在的现实
计划必须有足够的灵活性与可塑性
没有计划的项目肯定是要失败的
较好的做计划的策略是：
为下两周做详细计划，为下三个月做粗略计划，再以后就做极为粗略的计划。即仅仅对于迫切的任务才花时间进行详细的计划
但是在某个阶段内仍然是相对固定的

1、敏捷过程的基本原则

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

Scrum的详解【3355】
1、3角色

Product Owner：决定每个冲刺的任务，决定选择做什么和为什么做这些。

Scrum Master：Scrum团队教练和带头人，扫除实施障碍。

Team：是任务执行团队，可以是研发团队，也可以是跨职能团队，能够切实提供一个可用产品的团队。

2、3工件

Product Backlog：产品待办事项集合，我理解也是 用户故事，相当于当前版本所要做的所有需求。

Sprint Backlog：迭代功能开发列表，理解为一个冲刺目标阶段内的需求列表。例举如，当前版本总共要完成40需求，是我们的Product Backlog；我们把当前版本拆分4个冲刺阶段，即是4个Sprint。第一个Sprint需要完成10个需求，则这10个需求为当前Sprint的Sprint Backlog。

Burndown chart：燃尽图，确定需求实现阶段后，随时间往后推进，时间剩余消耗，同时任务列表也随工作的推进而消耗。即是，迭代显示剩余工作时间和任务的完成情况。

3、5价值观

Focus 专注：将故事拆解为冲刺阶段，目标细化，同时也是集中绝对的团队能力，解决既定目标，体现当前的专注，也排除其他插入时间的消耗。

Courage 勇气：在整个敏捷过程中，需要效率的提升，同时，面临的技术、环境、团队等一系列的问题并不会变少，就需要有勇气，有决断的阔步向前，用最优势的精力、资源解决当前最迫切的问题。

Openness 公开：团队内信息的完全公开，让问题无所隐藏，同时也让优秀和战绩能够很好地展示及引导，公开，从而大家平等，从而大家尊重。

Respect 尊重：在敏捷过程中，因为公开我们搭建了尊重的基础；同时因为效率的要求和冲刺任务的明确性，我们做自己最擅长的事情，从而让整体效率最大化。尊重他人，信任他人。

Commitment 承诺：构筑团队内部共同解决问题，最高效率突击任务环境，是因为我们信守承诺，敢于给出承诺；同时，也因为我们为别人为团队的承诺，我们必须是最好的处理我们的任务，对于我们承担的责任敢于承诺，也直面承诺的责任。

4、5工作

sprint planning meeting：冲刺前计划会议，决定并生成sprint Backlog。—类似需求评审

sprint：冲刺，由冲刺会议决定了我们的目标，从而确定了冲刺的阶段，人员及任务安排。—类似于计划

daily standupdo meeting：每日站会，主要用于跟进进度，确定当前任务的情形，同时沟通是否有异常情况。要将异常在开始阶段进行良好控制。

sprint review：冲刺回顾。一个冲刺完成，对冲刺进行回顾，整理有益处，执行良好的部分；规划检查不好的地方，可以做的更好的方面。优化中不断前行。

retrospective meeting：回顾会议。完成当前版本，需要对整体进行回顾，对经历经验进行整理归档，形成有效的成长型文档，便于团队更好的成长。

深深触动，本科的专业总结了一句话：先控制，后碎部，步步检核。学科本身的内核或许是有相似之处的。

在自我的理解中，Scrum中，Product Owner 和 Scrum Master是两个核心关键人物，ProductOwner 决定产品的需求，算是高级的产品经理（PM），Scrum Master是教练，也是整个团队良性运行的核心人物。

敏捷的12条原则

1、最优先要做的是尽早、持续地交付有价值的软件，让客户满意。
2、欣然面对需求变化，即使在开发后期。敏捷过程利用变化为客户维持竞争的优势。
3、频繁地交付可工作的软件，从数周到数月，交付周期越短越好。
4、在团队内外，面对面交谈是最有效，也是最高效的沟通方式。
5、在整个项目过程中，业务人员必须和开发人员每天都在一起工作。
6、以受激励的个体为核心构建项目。为他们提供所需的环境和支持，相信他们可以把工作做好。
7、可工作的软件是衡量进度的首要标准。
8、敏捷过程倡导可持续开发。
9、坚持不懈的追求技术卓越和良好的设计，以此增强敏捷的能力。
10、简单是尽最大可能减少不必要工作的艺术，是敏捷的根本。
11、最好的架构、需求和设计来自自组织的团队。
12、团队定期反思如何提升效率，并依此调整自己的行为。
客户总是对的吗
一个好的开发团队要交付给客户真正需要的东西，而不是提供给他们要的东西。亨利.福特曾经说过一句话“如果我问人们想要什么，他们肯定会说想要更快地马（而不是汽车）”。这个事情说明客户无法在一开始就告诉你他想要的是一辆汽车而不是一匹更快地马。敏捷所说的12条原则的初衷就是让团队构建用户真正需要的产品，有价值的软件。但是每个人都会看到软件中不同的价值，那么就要求每个人都想想其他利益相关人，想他们各自关心的事情，想想软件会给他们带来的价值。任何新产品在第一次面市的时候都是功能不全面的，尤其市面上没有同类产品的时候，随着时间以及版本的更替，产品会解决越来越多的问题，以及会变的越来越好用，我们现在去看当初的产品肯定很容易就看出来其中的问题，但是在项目刚刚开始的时候是很难思考全面的。

按我现在说的做，而不是按我之前说的做
很多公司，包括我现在所处的公司也是同样，做一个项目或者产品的时候会在一开始组织专门的人员找齐全部利益相关人开会讨论，然后将所有的信息整合到一起形成一份说明书，然后再发送到各利益相关人那里进行评审，然后再开会讨论，再出一份更好的说明书，一次一次的可能要耗费好几天，最终形成一份各方面都满意的说明书。拿给开发团队评估工期，综合各方面可能要12个月之久，但是各利益人都觉得很不错，因为一年之后就可以拿到一个非常棒的产品。经过一年的奋斗，开发团队终于交付了产品，产品与说明书相差无几，准确地展现了各利益人所要的功能。但是结果呢，往往一年的时间市场已经变化，一年前很被市场需要的软件并不被当前的市场所需要。

市场存在着变数，一些变数在项目初期是可以被发现的，但是更多的变数都是在项目开始的时候无法被发现的。但是说明书已经制定了，而开发团队又不喜欢自己做的东西不停的变化。所以团队要快速地响应市场以及各利益相关人的变化，敏捷的几项原则就是帮助团队应对这种变化的。

原则1：最优先要做的是尽早、持续地交付有价值的软件，让客户满意
敏捷团队最重要的事情就是给客户交付可工作的软件。而这条原则就包含三点，尽早发布软件、持续交付价值以及让客户满意。

没有什么事情的完美的。尽管在项目一开始每个人都想一次性的提出全部的需求，但是问题在于客户在真正拿到可工作的软件之前，都不清楚应该提什么样的需求。所以就要求开发团队尽早的交付，尽早的给客户一个可工作的软件，即便是仅交付了一个可工作的特性，也是一种突破。这对整个团队都是有益的，因为客户可以给出有价值的反馈，这样开发团队才能朝着正确地方向推进项目。

尽早交付也有一个缺点，就是最初交付给客户的软件完成度非常的低。很多客户很难忍受一个仅有部分功能，还有可能存在大量BUG的软件，这些客户往往认为既然交付就要交付完整地产品。敏捷的核心价值观里有一句，客户协作高于合同谈判。这就要去客户也要能够和开发团队一起成长，一起协作，共同逐步完善产品。如果客户非常官僚，那么团队就必须全新的变更管理流程，这要去与客户重新进行一轮合同谈判。真正与客户协作的团队可以在开发过程中任意进行任何有必要地改变，这也是持续交付的意义所在。而团队确定哪些特性能交付价值的唯一方法就是与客户协作，并利用前一次迭代收到的反馈。从短期看，团队可以通过尽早交付价值让客户满意，从长期看，交付最终产品的时候可以使得价值最大化。

原则2：欣然面对需求变化，即使是在开发后期。敏捷过程利用变化为客户维持竞争优势
我以前的工作是数据安全，公司比较小，是给别人做项目的，而做项目的弊端就是会面临着大量的变化，尤其是老板不会顾及工作量，也不会改变截止时间，当这个样子有大量的变化时，开发人员就一定会有情绪，从而形成恶性循环。

为什么会使得开发人员抱怨不止，因为在需求变更之前，开发人员会认为项目进展的很好，而且可能做了很多决策：如何规划产品结构，要开发什么产品，向客户承诺交付什么。结果一个项目外的人突然告诉你这个计划里有错误，而且是你的锅。给开发人员说它错了，是很难接收的。尤其说的人还享受着他的服务，就好比，你做了一盘菜给别人吃，那个人一边津津乐道的吃，还一边骂你做的菜难吃如屎。开发人员对自己所做的工作都是有一种自豪感的：我们交付的产品我们能负责，而且能满足用户的需求。而变化就是在质疑这种自豪感。瞬间就会感觉自己的努力没有得到尊重。

而开发人员如何才能够接收变化。简单地说就是站在客户的角度去看待问题。其实客户也不愿意给开发人员提出变化，因为这就是要求他们承认自己在一开始犯了错误，让开发人员白做了很多事情。正因如此，往往客户都是很晚才来告诉开发人员变化，因为他们知道自己带来的是坏消息，这是让人很难堪的行为，客户还要为整个变化买单。所以，将心比心，开发和客户都要做一些不可能的事情，开发人员被要求读懂客户的心，客户被要求能预测未来。

要做到能够欣然接收变化，就要意识到以下几点：

不要认为有变化就要有人要倒霉。每个人都要求知道犯错了以后就立即改正而不是期待一开始就做到完美。
我们是一条绳上的蚂蚱。每个人包括客户都要对全部需求以及变化负责，争论谁对谁错是没有意义的，抱怨变化是没有意义的。
我们不把变化拖到最后。谁都不愿意犯错误，但是这是难免的，那么就要尽早修复，将损失降到最低。
我们不要再把变化当做犯错。在当时的信息环境下，能做到那个程度已经很好了，出了错事才会让路变得更加明朗。
我们通过变化学到东西。变化才是团队成长最有效的方式。
原则3：频繁交付可工作的软件，从数周到数月，交付周期越短越好
对于敏捷实践者来说，传统的实践方法被称作“命令-控制”。这种方式与军事的命令-控制的方式是一致的。“命令”指的是项目经理给团队分配任务的方式。尽管并不是所有成员都向项目经理汇报，但是项目经理仍然可以控制所有人的任务分配。“控制”指的是项目经理管理变化的方式。无论是项目内的变化还是员工休假、机器故障，亦或是其他一些无关的变化，都在项目经理的监控之内。当变化时对其进行评估，更新项目计划，在进度安排和文档中引入变化带来的改变，给团队分配新的任务，管理利益干系人的期待，不要让人感到意外。使用敏捷的传统项目负责人不愿意欣然接受变化的原因就是害怕变化引起的混乱。

那么，如何才能又能欣然的接受变化，又能不引入混乱？关键在于频繁发布可工作的软件。团队将迭代的周期缩短，在每一轮迭代结束的时候，都可以交付一个可以使用或者演示的软件，然后计划下一个迭代要干什么，这样一个可预测的进度安排和持续检查可以帮助团队尽早掌握变化，同时也创建了一个没有责备的氛围。传统项目经理最大的困难就是监视变化，每日审查和迭代回顾相当于让整个团队帮助项目经理尽早的发现变化，避免将变化放在项目的晚期，从而防止这些变化对项目造成更严重的影响。

传统的瀑布式流程一旦定义好需求就把开发团队和客户完全隔离开，而敏捷团队采取的则完全不同，后者始终与客户交互。这样就可以及时响应变化，开发出更好地产品。但是每当发现项目确实需要修改的时候，都有一半人返回去更新规格说明书，以保证计划保持最新的状态。越来越多的人觉得文档太多，但是每当想砍掉一些内容的时候，就会有人说如果不写某项功能、需求、设计或测试用例，那么就会有人产生误解。如果最终的实现不正确，他们就会因此遭到谴责。于是，文档中的任何一部分看上去都是必要地，因为少了任何一部分团队都有可能开发出错误的软件。

自古以来，各个团队都对文档写多少而感到困惑，一直都在努力找到一种平衡。那么对于敏捷团队来说，文档写的够项目开发用就可以了，具体要参看团队要解决的问题以及沟通的情况。一个原则就是如果某种文档不能给团队开发软件带来帮助，而且也没有必须写的原因，那么敏捷团队就不写这种文档。例如监管的要求、投资者的要求、高级经理的要求或者其他利益干系人的要求。不过在传统瀑布式项目中，完整文档的全部意义就在于更好地应对变化，但是遗憾的是对于大部分团队来说，完整地文档往往给管理变化带来阻碍。团队在项目开始的时候要花大量的时间努力预测未来会发生什么，并完整地记录下来。项目执行的时候，他们需要不停地维护已经写好的文档，并记录所有新开发的内容。如果对于正在开发的产品有了新的理解，他们还需要返回去修订所有受影响的文档。随着时间的推移，过时的文档就会越来越多，团队需要花很大的功夫去维护这些过时的文档。况且各个人去编写的时候又会把视角割裂引进去。

原则4：在团队内外，面对面交谈是最有效、也是最高效的沟通方式。
我们为什么要写文档，并不是因为要写出来一份东西，而是要把我的想法告诉你，使得我脑子里地想法和你脑子里地想法仅可能的接近。为什么面对面的交谈是最有效的，而且大于文档。因为我们都知道，一份完整地文档是很难实现的，而且是非常耗时的，到最后完成的文档又不一定在项目中有用。然而面对面去交谈，就很容易形成头脑的风暴，很容易让大家的思想达到统一，这正是交谈的良好方式，一有什么变化就可以立即进行讨论。

团队沟通的终极目标是形成一种集体意识，在成员之间建立不必直说也能领悟的共同知识。一个团队能够形成集体意识，越能共享同样地视角，就越容易对同样地问题形成一致的答案。这酒为团队构筑了处理变化的坚实基础，可以跳过冲突，立即编写代码，而且不会因为维护文档而分心。

原则5：在整个项目中，业务人员和开发人员必须每天在一起工作。
为了完成出色的软件，开发团队需要与业务人员进行大量面对面的讨论，业务人员了解需要什么软件，因为他们在没有软件的情况下开展了同样地工作，有了业务人员的陪伴，研发人员可以及时更改自己的开发方向，但是业务人员往往希望开上一两次会就解决剩下的问题，因为他们同样也有自己的工作。

如何解决这个问题，首先双方要都认识到，团队要给公司开发带来价值的软件。完成后的软件应该值得公司的投入。如果软件带来的价值超过了开发软件的成本，那么公司就值得在这项开发上面投入资金。一个好的项目应该有足够的价值让业务人员赶到值得投入精力。所以业务人员应该与开发人员坐在一起工作，尽早的处理变化，因为后期修改的成本会很高。而业务人员应该很喜欢跟敏捷的团队一起合作，因为传统的开发团队把业务人员看做谈判的客户，而敏捷团队则是与客户合作的，在项目进行过程中客户具有平等的发言权。

原则6：以受激励的个体为核心构建项目，为他们提供环境和支持，相信他们可以把工作做好。
如果团队里地每一个人都认为自己开发的软件是很有价值的，是能够给公司带来利益的，那么这个团队就会越来越好。相反，如果团队成员看不到软件的价值，或者他们没有因为开发优秀软件而得到奖励，那么在这种情况下，项目就会失败，因为项目中最重要的是人。现在大多数公司的考核与绩效往往不利于员工开展高效的敏捷方法。

大多数公司的问题为：
1、在代码审查中，如果不断发现bug，那么这个程序员就会得到糟糕的评价，如果没有发现bug，那么这个程序员就会得到奖励。（这会导致程序员在代码审查中不愿意去寻找bug。）

2、根据发现bug的数量去奖励测试人员。（这会导致测试人员挑刺并且奖励报告的质量。这种方式还会使得程序员和测试人员之间产生敌对情绪，会阻碍程序员和测试员之间的合作。）

3、根据业务分析员产出的文档量去判定其绩效评级（而不是根据他们与团队分享的知识量评评级）

所以以这种绩效去考核程序员，最终出来的内容肯定不会好，一个很好的团队应该根据成员对团队的贡献去进行考核，鼓励贡献多的人员。比如认识到软件并没有解决的某个业务问题并将其修复的程序员，以及能够发现代码或架构中的问题并提交给团队的测试人员。

不好的氛围容易引发一种一心自保（Cover Your Ass，CYA）的态度，在这种态度下，测试人员会努力确保每一项需求都有测试覆盖，而不去考虑测试到底能不能对软件的质量有所帮助。程序员会严格遵循需求文档中的每一个字，而不去认真想一想自己开发的功能是不是真正给用户带来价值。在这样的公司经理自然想找一个“始作俑者”为那些因变化而产生的额外工作量而负责。当这种趋势不可避免的时候，团队里的成员会逐渐转向编写“防御性文档”以保护自己。为了避免糟糕的考核或惩罚，他们可以把责任撇向他们所遵循的那部分文档。

过于详尽的文档会增加需求含糊以及团队成员之间误解和沟通的风险。敏捷团队最有效的沟通方式就是面对面的沟通，并且输出最少的文档，让开发人员和业务人员每天工作在一起，尽快的交付最大价值的产品，并且在团队中每一位成员都会有项目的责任感，因为他们都要对项目负责，并且他们都可以为项目做出正确地决定。

原则7：可工作的软件是衡量进的的首要标准
好的团队合作会确保所有人在任何时刻都了解项目的进展。

在传统的“命令-控制”项目经理眼中，要想掌控项目的进展就要让成员经常更新项目的状态。但是状态汇报是很难获得项目的真正状态。汇报本身就不是一种完美的沟通工具，而且还带有很浓重的政治色彩，而且所有的项目经理到知道有时候需要在状态汇报中略去一些会让经理和团队主管难堪的东西，而别人常常需要用这些信息进行决策。

所以，最好的汇报方式就是一个可工作的软件，只要真切的看到了软件在眼前工作，那么你就“得到了”项目的进展。当看到软件中缺少或者不满意的部分，相关人员就会主动去沟通下一步的计划了。敏捷团队在每一轮迭代结束的时候交付可工作的软件，通过真实地产品向大家展示具体成果，团队可以让大家掌握项目进展的最新情况，而且这种方式几乎不可能让人产生误解。

原则8：敏捷过程倡导可持续开发。赞助商、开发人员和用户要能够共同、长期维持其步调，稳定向前
很多团队就会出现一种现象，每当截止日期临近的时候，就会出现拼命的加班，尤其是在晚上和周末。这种做法是不可靠的，一个团队可以拼命工作几个星期干更多地活，但是团队的工作效率一般都会再这段时间过后一落千丈。人们会感到疲劳，而且由于加班而耽误的事情，最终都会找上门来，然后就会付出更多的时间和精力去处理。因此敏捷团队要做的就是可持续的开发节奏。会预留时间，并且制定一个切实可靠的计划，通过迭代。因为每次预估的都是接下来一周、两周的公布工作内容，而且承诺的仅是可以交付的内容，所以就不会动不动的加班，从而形成一种良性循环。

可持续的开发节奏就是给予团队足够的开发时间，让成员不需要工作到深夜，也不需要周末加班的节奏。

原则9：坚持不懈的追求技术卓越和设计优越，以此增强敏捷的能力
计划做的太夸张并不是老加班的唯一原因，有的时候看起来是一个很简单地功能，当做起来就觉得有点难度，而随着越做越深入，就觉得这是一个坑。然后发布了以后本来可以轻松的转向其他的事情，但是却要不停的修复这个功能的bug以及打补丁。所以从长久来看设计良好的代码会大量减少后续的维护工作。但是这并不是意味着在软件一开始就进行完整地设计。而一个良好的程序员会再编写的时候不停的寻找设计和代码的问题，一旦发现问题，就会立即进行修复。在项目的开发过程中，只需要在当下多花一点点时间编写可靠的代码并及时修复问题，那么留下来的这份代码库在未来就会非常好的维护。

原则10：简单是尽最大可能减少不必要工作的艺术，是敏捷的根本
在开发软件的时候，要尽量的简单，解除耦合性，因为如果项目比较复杂，那么在向项目中添加新的代码的时候就会让项目变得越来越复杂，因为有了依赖关系，变化导致系统另一部分发生变化的可能性会提升，后面还有可能导致第三个变化，到最后就会形成多米诺效应。而产出好的代码的方式就是以最少计划启动项目，但是人们往往认为没有良好的计划，那么将来面对变化的时候就会很头疼，因为如果现在就开始编码的花，那么以后遇到变化的话，就有可能删除现在的代码。

避免这种现象的方法就是迭代式的编程，每轮迭代都开发没有太多依赖或者不必要依赖的代码系统。编码的时候如果团队仅基于一些智能实现单一功能的小型自包含单元进行设计，那么就可以很好地避免多米诺效应。那么哪些单元是很有必要的，就要去业务人员与开发人员经常的进行沟通，确保只开发有价值的特性，因为后期维护一些没有价值的特性往往比这些特性给公司带来的价值要高。

原则11：最好的架构、需求和设计来自自组织的团队
有大量事前设计的团队非常容易做出过于复杂的设计。因为在设计和架构的阶段就要尽全力就必定意味着要构建可以做到的最棒的架构。如果提出的需求比较少而且设计太简单，那么从直觉上就会给人一种偷工减料的感觉。只有他们拿出一份巨大的需求文档和一个复杂的设计才不会让人质疑。过于复杂的设计又会舍得后期做变化的时候陷入恶性循环。

那么一个比较好的方式就是组织自组织的团队（self-organizing team），没有明确地需求和设计环节。这个团队会一起对项目进行规划，并且会作为一个团队进行改进计划，没有明确地领导，也就没有很多的干预项，他们会把项目分解成多个部分，从能给公司带来最大价值的部分着手，然后再考虑详细的需求、设计和架构。这样的团队所有人都会对架构进行设计，每个人都有责任，每个人都说的算。这样的团队就很容易循序渐进，从而设计出一个增量式的方案。

原则12：团队定期反思如何提升效率，并依此调整
一个敏捷团队如果不能持续地改进构建软件的方式，那么团队就不算敏捷。敏捷的团队会不断的对项目进行检查，不断的进行优化，他们会从项目中学习，通过检查的结果对未来进行改造。而且他们并不只是在项目结束的时候这么做，他们会每天都在寻找需要改进的地方。增强团队实力的唯一方式就是经常回顾自己已经做的事情，然后评估作为一个团队这些事情做得怎么样，最后提出改进的计划。要经常回顾过去，看看哪些事情做对了，哪些事情做错了。这需要揪出具体的问题和错误，而很少有人会对公然指出其他的错误而感到自在。随着时间的推移，团队中的成员会对这件事情感到越来越自然。最终，大家会认为这是提意见而不是挑刺。

很多团队认为他们并没有时间去进行这件事情，他们在一个项目结束了以后就会立即投入下一个项目中，认为与其花时间在这个上面还不如投入到下一个项目中。那么就要求团队在制定计划的时候就给项目结束后预留一些时间来进行回顾，因为这件事情很重要，团队成员可以从这其中吸取教训，提高效率。

整合所有的原则
一个好的敏捷团队是要整合所有的原则，而不是从中寻找几个实践，整合这些实践的关键在于团队的思维方式，敏捷的价值观和原则是思维背后的动力。敏捷团队不仅要诚实的回顾开发软件的方式，还要回顾成员交流的方式，以及与公司其他同事交流的方式。首先要理解原则，然后要理解其中的原理，还要在工作中不断的评估和改进。

一些比较牛的开发人员往往遇到这样的事情：本来开发了一段很棒的代码，结果某个根本不懂编程的人要求做出一个修改，你就不得不把这段代码弄乱然后打上补丁，之后就进行了一个沮丧的恶性循环。这个时候开发人员就会很容易被敏捷的团队所吸引。在敏捷团队中，会不断的与客户沟通，不断的做计划，在计划与沟通中，就过滤到一些棘手的问题，并且不断改变自己的编程方向，编写一些耦合性低得代码，以及一些价值高的产品，从而就可以在后期从容的面对变化。

并且敏捷团队的沟通方式可以让开发人员真正的进步，因为他们的团队很可能是自组织团队，每个人都会去进行自主的学习，因为团队的知识决定了项目的宽度，并且团队成员自己会决定让团队正常运转的沟通内容，这不仅可以开发出更好地产品，而且你还可以向坐在身边的开发人员取长补短。

四大仪式

Sprint Planning敏捷迭代计划会议

在每个敏捷迭代开始之初，由产品负责人讲解需求，并由开发团队进行估算工时的计划会议。 在会议上需要：排列需求优先级；分析和评估产品Backlog并确定该迭代的目标；计划会议上还需要制定迭代计划，包括： 根据产品Backlog（功能点）创建Sprint Backlog（即迭代任务）；然后为Sprint backlog中的任务做估算；团队成员从产品Backlog中挑选他们承诺完成的条目。

敏捷的迭代实现始于计划会议，所以一个好的计划会议是每个迭代成功的基础，一般分两个阶段进行，两个阶段参与会议的人员会不一样；

计划会议的目标：

1、基于敏捷规划产生的Product Backlog以及优先级，通过计划会议，确定迭代的目标、团队成员、形成Sprint Backlog，明确评审会、回顾会时间；

2、分解Sprint Backlog并确定相应的完成时间，并由团队成员共同挑选这些Sprint Backlog；

阶段一参与人员：产品经理、Product Owner、Scrum Master、团队成员，有业务人员的话还可以邀请业务人员一起参加。

会议时长：1-4小时

一般参考进程安排如下：

1、Scrum Master公开迭代时间表；

2、产品经理和Product Owner讲述Product Backlog，对应的业务价值和优先级；

3、团队针对Sprint Backlog和优先级达成一致；

4、Scrum Master和团队成员共同确定Sprint Backlog；

阶段二参与人员：Scrum Master、团队成员，其他人员选择性参加

会议时长：1-4小时

一般参考进程安排如下：

1、团队成员针对Sprint Backlog共同分解任务；

2、团队成员共同进行工作量评估(每个Task不超过2天)，确定开始时间和完成时间；

3、团队成员共同认领任务；

4、共同确定DoD，团队达成一致；

5、团队共同确认迭代目标和价值；

如果单个迭代内安排的Product Backlog安排的比较多的话，一般迭代计划会议需要开一个整天，虽然时间有点长，但这个会议会确认整个迭代的详细计划和安排，因此也是值得的。

Daily Stand-up Meeting每日站会

团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名，团队成员通常会在会议上讲述如下3点内容：

1. 昨天我做了什么

2. 今天我计划要做什么

3. 我遇到了什么问题，妨碍了我尽可能有效地工作

Scrum Master记录会议上提出的问题，但是不要在会议上讨论和解决问题，而是要会后在找相关人员进行讨论和解决。

Sprint Review敏捷迭代评审会议

在迭代结束前给产品负责人演示并接受评价的会议，并根据反馈结果，提出新的产品Backlog

参与人员：产品经理、Product Owner、Scrum Master、团队所有成员

会议时长：1-4小时，视演示内容而定

主要是检验迭代成果，检查是否完成迭代计划中的迭代目标，有可能的话要求用户参与测试流程，并得到用户对产品的认可，鼓励用户自己进行测试设计和进行破坏性测试，充分暴露产品的设计和功能问题。

由Scrum Master来推进会议进程，Product Owner记录用户反馈，根据结果维护产品 backlog，一般在迭代结束前做一次。

Sprint Retrospective敏捷迭代回顾会议

在每个迭代结束后召开的关于自我持续改进的会议，围绕如下三个问题进行讨论：

1. 本次迭代有哪些做得好；

2. 本次迭代我们在哪些方面还能做得更好；

3. 我们在下次迭代准备在哪些方面改进；

团队确定问题优先级，并根据优先级确定团队能够解决的Top问题；团队讨论Top问题的措施，并选择在下一个迭代可以完成措施，分配责任人进行跟踪。

参与人员：Scrum Master，Product Owner，团队成员。

会议时长：0.5-1.5小时

主要针对当前迭代，团队成员自由讲述可以需要保持的做法，改进的点以及持续跟踪计划。

Scrum Master将团队讨论以及行动计划形成会议纪要，并发送给整个团队和有关同事。需要按照回顾会议的结论，维护一份待办事项列表，在下次回顾会议上进行跟踪。

案例分析

案例一：某Team在每日站会中，Scrum master准时组织大家开始晨会，成员一个接着一个说，昨天做了什么事情，今天计划做什么事情，遇到什么问题，成员A说昨天遇到了一个问题未能解决，Scrum master问遇到的是什么问题，成员A详细说明了该问题，这时成员B说这个问题他也遇到过，他是通过XX方式解决的，讨论后成员A明白了，然后继续晨会，由于小组成员有10个人，整个会议开下来大概花费了30分钟。

问题分析：Scrum master不应该在每日站会上询问详细的问题细节，而应该转移到会下询问，当团队成员之间进行讨论的时候，Scrum master需要及时拉回来，讨论应该转移到会下进行，晨会要在固定的时间固定的地方并且在固定的时间内完成。会议时间需要控制在15分钟之内。

案例二：某Team在开回顾会议中，Scrum master详细总结了本次迭代中有哪些做不够好的，并指出了对应的事和人，接着对应的责任人开始述说哪些地方确实是做的不够好及其原因，最后给出改进措施然后结束会议。

问题分析：回顾会不是批斗会，不应该只说做的不好的，做的好的也要说，Scrum master主要是鼓舞大家的士气，应该先从做的好的方面开始说起；并且做的不好的方面都只对事，不对人，做的不好是整个Team的责任，不仅仅是某几个人的责任；最后的改进措施需要给有后续跟踪的责任人和有效性的反馈。

在敏捷的迭代执行过程中，上述四种会议会随着每个迭代一直进行，基本上形成了一个闭环，可以让团队在每个迭代的执行过程当中去学习和总结，从而正确的按照敏捷的要求去做，使团队真正的敏捷起来。

TDD：测试驱动开发（Test-Driven Development）
测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。

BDD：行为驱动开发（Behavior Driven Development）
行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。主要是从用户的需求出发，强调系统行为。BDD最初是由Dan North在2003年命名，它包括验收测试和客户测试驱动等的极限编程的实践，作为对测试驱动开发的回应。

持续集成CI（Continuous Integration）
基本概念
持续集成（Continuous Integration）简称CI，持续集成强调开发人员提交了新代码之后，立刻自动的进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

持续集成过程中很重视自动化测试验证结果，对可能出现的一些问题进行预警，以保障最终合并的代码没有问题。

持续交付CD（Continuous Delivery）
基本概念
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。