1.敏捷开发

概述

关于敏捷开发，Wiki给出如下解释：

Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.

　　可以这么理解：一种以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。亦可理解为在一个高度协作的环境中，不断地使用反馈进行自我调整和完善，持续交付用户想要的软件的过程。敏捷开发提倡通过多种工程实践来提高交付质量，如自动化测试、持续集成、重构、结对编程、代码的集体所有权等，比传统的设计-开发-测试-修改流程有更高的成效。

在介绍敏捷之前，先回顾一下传统的开发流程。

传统瀑布式开发流程

瀑布式开发流程（Winston Royce 1970）是最早得到广泛承认的开发流程。这是一个线性的模式，只有完成了前一个步骤才能开始下一个步骤。比如说，在开始设计之前，必须先完成需求分析。如果发现了问题，就得返回上一个阶段并进行适当的修改。

　　瀑布模型是最典型的预见性的开发方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行实施。步骤成果作为衡量进度的标准，例如需求规格，设计文档，测试计划等。

　　瀑布式开发流程的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，适应变化代价高昂。瀑布式方法在需求不明确并且在项目进行过程中可能变化的情况下基本是不可行的。

　　而敏捷开发的一个核心理念便是：”Fix time, Flex Scope”——固定时间，弹性范围。这就使团队具有更高的灵活性去适应未来需求的变化。

　　敏捷方法在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早、尽量小的交付可用的功能，并在整个项目周期中持续优化。

敏捷开发宣言

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值：

1. 个体和互动胜于流程和工具
2. 工作的软件胜于详尽的文档
3. 客户合作胜于合同谈判
4. 响应变化胜于遵循计划

虽然右项也有价值，但我们认为左项具有更大的价值。

敏捷的12原则

1. 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
2. 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
3. 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
4. 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
5. 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
6. 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
7. 可以工作的软件是进度的主要度量标准。
8. 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
9. 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
10. 简单——尽可能减少工作量的艺术至关重要。
11. 最好的架构、需求和设计都源自自我组织的团队。
12. 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

敏捷核心实践和原则

包括但不限于以下：

在迭代中尽早演示交付的价值
用户故事反映商业价值和优先级
客户持续改进
所有需求的验收测试 回顾
可持续的节奏或速度 沟通
高度可视化
敏捷不包含什么

预先的设计和需求收集
项目完工预测
死亡行军项目：项目团队为弥补估算差距无偿加班
强迫使用工具，例如任务管理工具
自上而下管理和控制
大量文件，特别的状态报告，软件架构图，软件需求规格说明书，测试计划

敏捷教练

它是指掌握了敏捷知识和经验的人员其在组织和团队转型中能够发挥培训、辅导和指导的作用。
敏捷教练可以是内部教练或外部教练，教练需要：
1）跟不同团队共事时具备平衡视角；每个团队具备不同的进展节奏，可能会面临制约，需要帮助去克服；
2）忠于团队成员价值；
3）认识社会心理及团队复杂性；
4）运用有效方法解决团队面临的问题；
5）开发方法进行非侵入型干预从而改变团队动力；
6）学习真正需要什么才能让人们作为一个团队去工作。

敏捷团队工具

所谓“工欲善其器，必先利其器”，优秀的工具有助于及早交付有价值的软件使客户满意。

站会：主要目的是给团队讨论每日的承诺和Sprint目标的进度的机会，每个团队成员在会议中都必须回答以下三个问题：

过去24小时做了什么？
接下来的24小时机会要做什么？
有没有什么问题阻碍了进度？
看板：被用来共享项目的状态并将之可视化

演示：适合于小团队的协作和优化反馈方式

用户故事：用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

角色：谁要使用这个功能。
活动：需要完成什么样的功能。
商业价值：为什么需要这个功能，这个功能带来什么样的价值。
持续集成：随时高质量交付的基础，有利于应对变化剧烈的市场

可以用它们来帮助规划，跟踪，分析和整合工作， 这些工具在敏捷开发中扮演着不可或缺的角色。

仆人式领导

仆人式领导是一种为团队赋权的方法。仆人式领导是通过对团队服务来领导团队的实践，它 注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。仆人式领导的作 用是促进团队发现和定义敏捷。仆人式领导实践并传播敏捷。仆人式领导按照以下顺序从事 项目工作：
1） 目的
与团队一起定义“为什么”或目的，以便他们能围绕项目目标进行合作互动。整个团队在项目 层面而不是在人员层面优化。
2）人员
目标确立后，鼓励团队创造一个人人都能成功的环境。要求每个团队成员在项目工作中做出贡献。
3）过程
不要计划遵循“完美”的敏捷过程，而是要注重结果。如果跨职能团队能够常常交付完成的价 值并反思产品和过程，团队就是敏捷的。团队将其过程称作什么并不重要。
4）特征
以下仆人式领导的特征让项目领导变得更加敏捷，促进团队的成功：
A. 提升自我意识；
B. 倾听；
C. 为团队服务；
D. 帮助他人成长；
E. 引导与控制；
F. 促进安全、尊重与信任；
G. 促进他人精力和才智提升

3、优先级技术-MoSCoW
MoSCoW 技术是进行需求优先级排序的敏捷方法。在这种技术下，需求基于以下方面排序：
1）Must 必须有-这些需求是强制性的
2）Should 应该有-这些需求不是强制性的，但是高度渴望的
3）Could 可以有-这些需求如果满足会很好
4）Won ’t 不会有-当下可以不去满足，但是将来可以加入
在开始新一轮时间箱前，会有一个新的 MUSTs 加入。这些可能是新的需求，或者现有需求 被调整优先级进而转移成为 MUSTs。

Kanban 看板

看板在项目实施期间作为信息发射源运用，它有助于相关干系人去了解冲刺或迭代的当下状 态。
1）看板是一个跟精益和及时制生产相关的概念。

任务板被细分成段来反映关键活动。
故事是由索引卡或代表的便利贴来表示。
卡的状态由它在任务板上的位置来表示，并随着项目进展从开始到结束变化。
看板帮助团队意识到他们是如何工作以及下一步要做什么。让团队形成自我指挥。
2）kanban 卡片
Kanban 任务板上的每一张卡片就是 kanban 卡片。
Kanban 卡片用来显示迭代过程。
Kanban 任务板上的卡片呈现在开发周期的不同环节中移动的工作部件。
Kanban 卡片反映所有需要被跟踪的事物。例如：用户故事，缺陷，任务。
在用户故事定义完整前，相关干系人需要对用户故事必须经历的部分进行评估。
3）简化的看板面板简化的看板面板有 3 列:
待完成
进展中
已完成
任务用卡片表示，卡片状态展示在其中一列的下方。

信息发射源

信息发射源概念由 Alistair Cockburn 发明。根据他的理解，信息发射源的定义是：一个信息 发射源在任何人都可见的地方显示信息。有了信息发射源，大家不需要问任何问题。
信息发射源的特征有：
让团队成员可以看见项目和项目进展的当前状态； 大部分敏捷团队在过程中不同程度使用它。
最受欢迎的信息发射源有：
任务板；大型可视化表格，包括燃尽图；持续集成构建健康指标，包括街灯等。 信息发射源有助于对于成功验收、交付物的共识。
信息发射源用来促进干系人期望管理，对当下进行的工作可见、透明。 他们提供团队日常进展、工作质量、障碍和风险的视图。
敏捷项目中运用的一些信息发射源有：燃起图；燃尽图；看板或任务板；障碍日志

WIP（在制品）

在敏捷开发中，W IP 限制决定了每种情况下的工作流中可以存续的最大工作量。限制进行中 的工作数量可以更容易辨识团队工作流中的无效工作。在情况变得更糟前，一个团队在持续 交付通道中的瓶颈是非常容易辨别的。
W IP 限制通过强制让团队聚焦在更小的一套任务中来改善吞吐量和减少“将要完成 ”的工作 量。从根本上来讲，W IP 限制鼓励的是“完成 ”的文化。更重要的是，W IP 限制可以让阻碍 和瓶颈显而易见。当有明确指示现有工作遇到瓶颈时，团队可以聚焦在阻塞问题上尽快的理 解、实施和解决。一旦消除阻塞，团队中的工作将再次开始流动。这些优势可以确保在最短 的时间内向用户交付有价值的增量，从而使得 W IP 限制成为敏捷开发中一个非常有价值的 工具。

敏捷度量指标

　　Ron Jeffries建议使用可工作的经过测试的特征数量（Running Tested Features，简写为RTF，下同）：

所需的软件被分解为给定名称的特征（需求、故事等），它们组成了需要交付的整个系统。
对于每个给定名称的特征，至少有一个或者多个自动化验收测试，（当它们都通过了），反映了特征已经全部完成。
RTF指标表示了项目在各个时刻有多少特征通过了各自的全部验收测试。
Scrum教练Peter Hundermark建议可工作的自动化测试数量（Running Automated Tests）也是度量指标。

敏捷开发技术体系及原则

测试驱动开发（TDD）

　　测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。一种软件开发过程中的应用方法，由极限编程中倡导，以其倡导先写测试程序，然后编码实现其功能得名。测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。

测试驱动开发可以有效的避免过度设计带来的浪费，让开发者在开发中拥有更全面的视角。

重构（Refactor）

重构改进软件设计
　　如果没有重构，程序的设计会逐渐腐败变质。当人们只为短期目的，或是在完全理解整体设计之前，就贸然修改代码，程序将逐渐失去自己的结构，程序员愈来愈难通过阅读源码而理解原本设计。重构很像是在整理代码，你所做的就是让所有东西回到应该的位置上。代码结构的流失是累积性的。愈难看出代码所代表的设计意涵，就愈难保护其中设计，于是该设计就腐败得愈快。经常性的重构可以帮助代码维持自己该有的形态

重构使软件更容易理解
　　所谓程序设计，很大程度上就是与计算机交谈：你编写代码告诉计算机做什么事，它的响应则是精确按照你的指示行动。你得及时填补“想要它做什么”和“告诉它做什么”之间的缝隙。这种编程模式的核心就是“准确说出我所要的”。除了计算机外，你的源码还有其他读者：几个月之后可能会有 另一位程序员 尝试读懂你的代码并做一些修改。我们很容易忘记这第二位读者，但他才是最重要的。计算机是否多花了几个小时来编译，又有什么关系呢?如果一个程序员花费一周时间来修改某段代码，那才关系重大—如果他理解你的代码，这个修改原本只需一小时。

重构帮助找到bug
　　对代码的理解，可以帮助我找到bug。我承认我不太擅长调试。有些人只要盯着一大段代码就可以找出里面的bug，我可不行。但我发现，如果对代码进行重构，我就可以深入理解代码的作为，并恰到好处地把新的理解反馈回去。搞清楚程序结构的同时，我也清楚了自己所做的一些假设，于是想不把bug揪出来都难。

重构提高编程速度
　　我强烈相信：良好的设计是快速开发的根本──事实上，拥有良好设计才可能做到快速开发。如果没有良好设计，或许某一段时间内你的进展迅速，但恶劣的设计很快就让你的速度慢下来。你会把时间花在调试上面，无法添加新功能。修改时间愈来愈长，因为你必须花愈来愈多的时间去理解系统、寻找重复代码。随着你给最初程序打上一个又一个的补丁，新特性需要更多代码才能实现。真是个恶性循环。

一些常用的重构方法

封装成员变量（Encapsulate Field）—将仅限于本类使用的变量重写成私有（private）成员变量，并提供访问方法（accessor method）。这种重构方式可以将与外部调用者无关的变量隐藏起来，减少代码的耦合性，并减少意外出错的概率。
提取方法（Extract Method）—意思是将大段代码中的一部分提取后，构成一个新方法。这种重构可以使整段程序的结构变得更清晰，从而增加可读性。这也对函数通用。
一般化类型（Generalize Type）—将多个类/函数共用的类型抽象出可以公用的基类，然后利用多态性追加每个类/函数需要的特殊函数。这种重构可以让结构更加清晰，同时可以增加代码的可维护性。
函数归父（Pull Up）—或译函数上移，指的是方法从子类移动到父类。
函数归子（Push Down）—或译函数下移，指的是方法从父类移动到子类。
方法更名（Rename Method）—将方法名称以更好的表达它的用途。
……

　　重构在敏捷开发过程中重构是一个常用的和必要的实践，它让我们反思过去所为，扫除敏捷开发道路上的障碍。

持续集成

　　持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

　　持续集成通常借助于一个工具或者脚本来实现，这些工具或脚本会注意到有代码检入版本控制系统。可以采用Cruise Control工具，它可以根据需要运行尽可能多的测试，并且可以自动发送通知给破坏构建的开发人员或者整个团队。

结对编程

　　结对编程是指两个开发人员一起写代码。结对编程的想法来源自：如果偶尔的代码检查会带来好处，那么持续进行代码检查会更好。通过结对编程产出代码，会创造出集体所有权的感觉。其次如果有另外一个开发人员坐在你旁边的时候，更容易让代码比你在检出修改前更干净。