比较全的敏捷概念知识总结

• 敏捷开发理念的提出

1. 敏捷理念提出

千禧之初，美国在计算机行业已经走了几十年，瀑布流、螺旋模型、快速迭代...各种各样的软件开发流程雨后春笋各领风骚一段时间。虽然不断变化和完善，但互联网的加速发展让传统方法显得笨重，难以快速适应变化。有十七个程序员（程序员改变世界）在美国犹他州的一个风景区开了个碰头会，找到了一个团队耦合度高，流程极其灵活的方法，他们把它称为agile program development。

1. 《敏捷宣言》

通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：

 

个体与交互 重于 过程和工具

可用的软件 重于 完备的文档

客户协作 重于 合同谈判

响应变化 重于 遵循计划

 

在每对比对中，后者并非全无价值，但我们更看重前者。

3、《敏捷开发十二原则》

在敏捷开发中，我们遵循以下十二条准则：

 

1、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

3、要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

4、项目过程中，业务人员与开发人员必须在一起工作。

5、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

6、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

7、可用的软件是衡量进度的主要指标。

8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。

9、对技术的精益求精以及对设计的不断完善将提升敏捷性。

10、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。

11、最佳的架构、需求和设计出自于自组织的团队。

12、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

 

• 敏捷开发是什么

敏捷并不是一门具体的技术，而是一种理念或者说是一种思想。它可以指导我们更加高效的开发。敏捷开发都具有以下共同的特征：迭代式开发、增量交付、开发团队和用户反馈推动产品开发、持续集成、开发团队自我管理。而这种开发的主要驱动核心是人，它采用的是迭代式开发。我们可以从三个角度去理解：

1. 敏捷开发是一种过程控制论

通俗地说，就是一种做事情的方法

1. 它适用于软件，可以改。如果是硬件，改起来就没那么方便了。

2. 它适用于客户不知道自己要什么的情况，其实这样的客户占大多数。因为客户不知道要什么，所以我们需要不断帮客户弄明白他到底要什么。也就是说，需要和客户沟通，合作，倾听，反馈，持续改进等等。

3. 它适用于竞争激烈的市场，这样的情况下，赶在竞争对手前交付一个不完美但至少能用的产品非常重要。

4. 它适用于快速变化的市场，你在埋头造一辆汽车的时候，客户已经想开飞机满天飞了，这就需要你能一步步地把汽车改成飞机，还能保证按时交付。

5. 它适用于在一个地方办公的小团队，一般7到9个人。这样使得敏捷中主要的沟通方式F2F是可行的。

 

1. 敏捷开发是一套工具集

 

里面有形形色色的工具，你可以不搞敏捷，但可以用那么一两个工作来提高效率。

比如：

1. stand meeting： 我昨天干了啥， 今天准备干啥，中间碰到什么问题，三个问题，简洁有效的小团队沟通方式。

2. KANBAN：直观地反映工作进度，反映流程遵守情况，反映流程缺陷。

3. plan meeting，retrospective meeting：适合小团队的写作和优化反馈方式。

4. user story: 站在用户的角度讲需求

5. 持续集成：随时高质量交付的基础，有利于应对剧烈变化的市场。

（3）敏捷开发是一种企业管理方式

比如：

1. 一线员工可以同时是架构师，ScM, 开发工程师，测试工程师。这样可以发挥他的主观能动性，有利于提高效率和创新。

2. 敏捷不专注于团队中个人的绩效考核，而更多侧重于整个团队的绩效。

3. 把大项目拆分成小项目去做，每个sprint都是一个迭代，需要输出一个高质量的版本，相当于完成一个小项目。bug的生存周期也被控制在一个迭代以内，降低了风险，也减少了后期改bug的工作量。

4. 把数十人的大team分成几个敏捷团队，这几个敏捷团队的ScM、OPO再组成一个更高一级的敏捷团队，利用stand meeting，retrospective meeting，Knaban等敏捷元素，可以避免数十份邮件也不能解决一个小问题，互相踢皮球，沟通不畅等大企业病。

5. 老板可以是最大的opo， 他给下面的高管将idea（user story），定期检查Demo，把控产品的用户体验，负责与外界的沟通和合作。

 

而在敏捷这种理念下，具体的开发方式有Scrum，极限编程（XP），精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。其中较为普遍的为scrum和XP。

 

• scrum和XP

1、scrum是什么

以管理角度来讲，Scrum是一种灵活的敏捷软件开发管理过程。这个名词来源于英式橄榄球。Scrum方法由Ken Schwaber和 Jeff Sutherland 提出，而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作，全队有明确的最高目标：发布产品的重要性高于一切。团队高度自治，队员们熟悉开发过程中涉及到的各种技术，紧密合作，确保每个迭代都朝着最高目标推进。而且每隔2至6周，每个人都能看到能实际工作的软件，并且据此决定是发布这个版本还是继续开发以加强它的功能。

以技术角度来讲，Scrum是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。

1. scrum框架的3355

SCRUM框架包括3个角色、3个工件、5个活动、5个价值

3个角色：产品负责人（Product Owner）、Scrum Master、Scrum团队

3个工件：产品Backlog（Product Backlog）、SprintBacklog、燃尽图（Burn-down Chart)

5个活动：Sprint计划会议（Sprint Planning Meeting）、每日站会（Daily Scrum Meeting）、Sprint评审会议（Sprint Review Meeting）、Sprint回顾会议（Sprint Retrospective Meeting）、产品Backlog梳理会议（ Product Backlog Refinement）

5个价值：

承诺– 愿意对目标做出承诺

专注– 把你的心思和能力都用到你承诺的工作上去

开放– Scrum 把项目中的一切开放给每个人看

尊重– 每个人都有他独特的背景和经验

勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

1. scrum的作用：

Scrum团队总是先开发对客户具有较高价值的需求。

更好的管理软件开发项目，它同样可以用于管理运行软件维护团队，或者作为计划管理，或者作为计划管理方法。

提高团队的开发效率，降低项目的开发周期，最大限度的发挥团队的作用，更好的满足用户的需求。

1. 极限编程（XP）

极限编程ExtremeProgramming是由KentBeck在1996年提出的，是一种软件工程方法学，是敏捷软件开发中可能是最富有成效的几种方法学之一。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。

XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于：

1. 在更短的周期内，更早地提供具体、持续的反馈信息。
2. 在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。
3. 依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
4. 依赖于口头交流、测试和源程序进行沟通。
5. 倡导持续的演化式设计。
6. 依赖于开发团队内部的紧密协作。
7. 尽可能达到程序员短期利益和项目长期利益的平衡。

XP的核心是其总结的沟通（Communication）、简单（Simplicity）、反馈（Feedback）、勇气（Courage）四大价值观，它们是XP的基础，也是XP的灵魂。

1. 极限编程的4个商业实践：

测试驱动开发—TDD是你的商业安全网。因为测试是在编码之前完成的，所以写完的测试一定会运行失败，接下来再写代码使测试可以通过。TDD保证你的产品功能，不管公司和技术团队实现的是大规模的变更还是小规模的变更。

结对编程—让2名开发人员写同一段代码，使用同一个键盘和同一台显示器。因为结对大大降低了浪费的时间和缺陷，所以能带来更高质量的代码，并带来高水平的协作。

集体代码所有制和持续集成—如果每段代码不只有一个人熟悉，那么就不会有什么交流瓶颈了。把代码持续集成到一个主干可以避免重复和不匹配的代码。

重构—在当时的情况下，写的代码是解决已知问题的。通常，团队巧妙地解决了他们的问题，然后持续重构和修改代码，确保代码库能以最为高效的方式不断满足业务最新的需要。

1. scrum和XP关系

1. 在开发的过程中，你可以采用Scrum方式也可以采用XP方式；

2. Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。

 

• TDD、BDD

1、TDD测试驱动开发

在敏捷开发里一直都有一种说法叫“代码即文档”，而且测试代码也成了功能代码的使用文档。敏捷里强调的TDD(Test-driven developmenet, 测试驱动开发)，就主要体现了这种思想：根据设计编写测试-> 实现设计的功能 -> 用测试代码验证 -> 重构实现代码 -> 改善设计 -> 再次回到根据改善的设计编写测试。反复循环下去，就是TDD所倡导的流程。

（1）TDD的好处：1. 能驱使系统最终的实现代码，都可以被测试代码所覆盖到，也即“每一行代码都可测”。2. 测试代码作为实现代码的正确导向，最终演变为正确系统的行为，能让整个开发过程更加高效。

（2）TDD的不足之处或者说还不够完善的地方，是对设计和测试的编写没有一个明确的方针。作为整个循环中的向导部分，如何保证根据设计编写的测试就是最终用户所期望的系统行为？如果这一部分模糊了，那么后续所有环节几乎都要受到影响。

2、BDD行为驱动开发

因为TDD存在的不足，在此基础上，敏捷社区又有人提出了BDD的概念，即“行为驱动开发”。

BDD(Behavior-driven development)把TDD中模糊的那一部分给明确了，强调开发、测试、BA、客户等所有项目相关人员都用自然语言来描述系统的行为。大家看到的描述一致，读到的内容一致，于是最终测试驱动开发产出的结果也应该是最符合用户期望的。所以在BDD的倡导下，介绍了一种简洁的类似自然语言叫Gherkin Language。

随着BDD的出现和发展，使用大家都能轻易理解和认知的语言来描述系统的行为并创建User Story，TDD的反复循环的流程也就能更顺利的进行下去了。BDD的核心价值是体现在正确的对系统行为进行设计，所以它并非一种行之有效的测试方法。它强调的是系统最终的实现与用户期望的行为是一致的、验证代码实现是否符合设计目标。但是它本身并不强调对系统功能、性能以及边界值等的健全性做保证，无法像完整的测试一样发现系统的各种问题。

3、TDD与BDD的关系

   TDD的迭代反复验证是敏捷开发的保障，但没有明确如何根据设计产生测试，并保障测试用例的质量，而BDD倡导大家都用简洁的自然语言描述系统行为的理念，恰好弥补了测试用例（即系统行为）的准确性。（不管以上理念是否先进，切忌盲从和滥用）。

• CI、CD

1. CI持续集成

保证新提交的代码和已有的代码进行集成，使所有人的代码保持同步，编译和测试签入的代码是否通过。

CI过程中，每次产生的构建物（artifact）都放在仓储（Repo）中。

优点：

快速得到代码质量的快速反馈。

自动化生成二进制文件，并进行版本控制。

可以从已部署的构建物回溯到相应的代码。

2、CD持续交付

我们狭义上说的CD是Continuous Deployment持续部署，但广义上讲还有Continuous Delivery持续交付这层意义，持续部署是可以全自动化的，而持续交付由于业务上的要求往往需要人工干预。整个过程应该是：研发开发--持续集成--持续部署--持续交付。

CD中，每次检查提交是否达到了部署到生产环境的要求，并持续地把信息反馈出来，把每次的提交当成候选发布版本来对待。

CD是构建流水线过程中的一种有效的策略。

构建流水线可按阶段划分：

运行快速测试——针对运行快、涉及范围小的测试。

运行耗时测试——针对比较耗时、涉及范围较大的测试。