01/24 : Agile Development (ZT)

敏捷开发过程的方法很多，主要有：SCRUM，Crystal,特征驱动软件开发（Feature Driven Development，简称FDD），自适应软件开发(Adaptive Software Development，简称ASD)，以及最重要的极限编程(eXtreme Programming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物Kent Beck首先倡导的。

 

极限编程，通常成为XP，是一种针对业务和软件开发的规则，它的作用在于将两者的力量集中在共同的、可以达到的目标上。XP团队以可持续的步调生产优质软件。

XP属于轻量开发方法中较有影响的一种方法。

XP方法强调客户参与和测试。在XP中，客户与程序员的角色有明显的界定。他们在同一个团队，但他们要做不同的决定。客户决定“他要什么功能”，程序员决定“成本是多少”。你能明确的分清该谁做什么决定。

XP程序员使用测试先行的增量编程方法编写代码。一次编写一部分单元测试用例，然后编写满足测试要求的代码。总是有测试用来证明新增代码的正确性。以增量的方式编程，并且测试先行。

一个程序能够运行并不说明它已经完成了。XP尽力通过保持系统尽可能简单从而保持系统最大的适应性。在代码通过所有测试后用重构进一步改进代码。越简单代码生命周期会越长久。

极限编程使用集体的代码所有权。XP实践试图降低集体的代码所有权带来的以下风险。个人骄傲：XP实际上没有处理这个问题，除了可能鼓励将其转换为以团队为骄傲。罚不责众：结对编程和100％运行单元测试将有助于确保没有人能够私底下进行“污染”。专业知识不足：结对编程在团队中传播了知识。阅读其他人代码：编码标准有助于减少这种问题。踩脚：持续集成保证了人们即使没有重返主线也不会走得太远，测试将确保不会出现倒退。

XP使用持续集成。每次开发人员完成了一段时间的工作，就会对他们所作的工作进行集成。XP中的集成由测试支持。开发人员必须保持所有单元测试100％运行。

对于加班，XP认为每周工作40小时更合适。XP团队需要的是可以承受的生产率水平。如果该团队重复出现无法完成自己的承诺，他们就会将问题退回来，而不是采取加班的方式。XP团队遵循“昨天的天气”规则：估计完成下一个迭代所需时间大约与本次的估计工作日相同。此规则有助于团队找到其正常的生产力水平。你无法改变时间，但是你可以改变你的任务。

XP指定了开放的工作区，通常是小的私人空间围绕着一个中心区域。

XP推荐小而频繁的发布。XP团队一直在尝试学习，他们得到的反馈越多越好。数月或者甚至数年没有发布的项目会积累许多风险，小版本将减少风险。版本应该小，但必须由意义，至少应该包括所有的特性。

对于编码标准，XP团队必须共享一个标准。

结对编程是一种技巧。它需要实践，不是对每个人都很容易开始。结对编程是XP中极其重要的一种技巧，因此值得培养这种习惯来利用它的好处。

体系结构体现在探究中，体现在隐喻中，体现在第一次迭代以及别的地方。

XP通过以下机制处理体系结构：探究，隐喻，第一次迭代，小版本，重构，团队实践。

隐喻提供了一种共识和一套公共词汇表。它有助于形成对问题和系统的全新理解，并有助于指导系统的结构。

极限编程（XP）团队不是在最后的“一刹那”中完成所有的事，而是采用一系列的迭代。迭代间隔是固定的，为一到三星期。迭代是有时间限制的：如果团队无法完成每件事情，他们将放弃某些特性，而不是拖延迭代的最后期限。在每个迭代结束时，客户能够看到准备发布的系统，并对所选择的故事进行验收测试。

作为极限编程（XP）软件的客户，你将在全部时间里与团队一起编写测试，回答问题和定义优先级。客户与团队一起是帮助团队尽快完成工作的重要影响因素。

迭代期间，客户有四项主要工作：回答问题，编写验收测试，运行验收测试，知道迭代。以及在版本做好时的一项准备工作（几次迭代后）：接受版本。

XP本身没有分析员这个角色，客户直接与程序员一起工作。XP争取实现让提问的人直接与可能解决问题的人交流的高效机制。

经理的几项主要工作：应付外部的团体，组建团队，获取资源，管理团队和处理团队问题。

跟踪者将跟踪三件基本的事情：版本计划，迭代计划和验收测试。你可以轻松的用简单的电子表格进行跟踪。

XP中的教练角色已经发展成为“当场”帮助团队保持进度的人。监控，执行和改变过程；指导；提供玩具；处理问题。

XP并不是一成不变的，它也是在不断的发展完善过程中的。

 

极限编程
设计和编程都是人的活动。忘记这一点，将会失去一切。

-- Bjarne Stroustrup

极限编程(XP)是敏捷方法中最著名的一个。它是由一系列简单却互相依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。
下面是极限编程的有效实践：

1. 完整团队 XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。
2. 计划游戏计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。
3. 客户测试作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。
4. 简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。
5. 结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。
6. 测试驱动开发编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。
7. 改进设计随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。
8. 持续集成团队总是使系统完整地被集成。一个人拆入（Check in）后，其它所有人责任代码集成。
9. 集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。
10. 编码标准 系统中所有的代码看起来就好像是被单独一人编写的。
11. 隐喻 将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。
12. 可持续的速度团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。极限编程是一种优良的、通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再采用。

敏捷开发
人与人之间的交互是复杂的，并且其效果从来都是难以预期的，但却是工作中最重要的方面。

-- Tom DeMacro和Timothy Lister

敏捷软件开发宣言：

• 个体和交互     胜过 过程和工具
• 可以工作的软件 胜过 面面俱到的文档
• 客户合作       胜过 合同谈判
• 响应变化       胜过 遵循计划

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

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

当软件开发需求的变化而变化时，软件设计会出现坏味道，当软件中出现下面任何一种气味时，表明软件正在腐化。

• 僵化性： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。
• 脆弱性： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
• 牢固性： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。
• 粘滞性： 做正确的事情比做错误的事情要困难。
• 不必要的复杂性： 设计中包含有不具任何直接好处的基础结构。
• 不必要的重复性： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
• 晦涩性： 很难阅读、理解。没有很好地表现出意图。

敏捷团队依靠变化来获取活力。团队几乎不进行预先设计，因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。为了改变上面软件设计中的腐化味，敏捷开发采取了以下面向对象的设计原则来加以避免，这些原则如下：

• 单一职责原则(SRP)
  就一个类而言，应该仅有一个引起它变化的原因。
• 开放-封闭原则(OCP)
  软件实体应该是可以扩展的，但是不可修改。
• Liskov替换原则(LSP)
  子类型必须能够替换掉它们的基类型。
• 依赖倒置原则(DIP)
  抽象不应该依赖于细节。细节应该依赖于抽象。
• 接口隔离原则(ISP)
  不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
• 重用发布等价原则(REP)
  重用的粒度就是发布的粒度。
• 共同封闭原则(CCP)
  包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。
• 共同重用原则(CRP)
  一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
• 无环依赖原则(ADP)
  在包的依赖关系图中不允许存在环。
• 稳定依赖原则(SDP)
  朝着稳定的方向进行依赖。
• 稳定抽象原则(SAP)
  包的抽象程度应该和其稳定程度一致。

上述中的包的概念是：包可以用作包容一组类的容器，通过把类组织成包，我们可以在更高层次的抽象上来理解设计，我们也可以通过包来管理软件的开发和发布。目的就是根据一些原则对应用程序中的类进行划分，然后把那些划分后的类分配到包中。
下面举一个简单的设计问题方面的模式与原则应用的示例：
问题：
选择设计运行在简易台灯中的软件，台灯由一个开关和一盏灯组成。你可以询问开关开着还是关着，也可以让灯打开或关闭。
解决方案一：
下面图1是一种最简单的解决方案，Switch对象可以轮询真实开关的状态，并且可以发送相应的turnOn和turnOff消息给Light。

解决方案二：
上面这个设计违反了两个设计原则：依赖倒置原则(DIP)和开放封闭原则(OCP)，DIP原则告诉我们要优先依赖于抽象类，而Switch依赖了具体类Light，对OCP的违反是在任何需要Switch的地方都要带上Light，这样就不能容易扩展Switch去管理除Light外的其他对象。为了解决这个方案，可以采用ABSTRACT SERVER模式，在Switch和Light之间引入一个接口，这样就使得Switch能够控制任何实现了这个接口的东西，这也就满足了DIP和OCP 原则。如下面图2所示：

解决方案三：
上面图2所示解决方案，违返了单一职责原则(SRP)，它把Switch和Light绑定在一起，而它们可能会因为不同的原因而改变。这种问题可以采用 ADAPTER模式来解决，适配器从Switchable 派生并委托给Light，问题就被优美的解决了，现在，Switch就可以控制任何能够被打开或者关闭的对象。但是这也需要会出时间和空间上的代价来换取。如下面图3所示：

敏捷设计是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净和富有表现力。

 

 

极限编程（ XP ）

极限编程（ XP ）的主要目的是降低需求变化的成本。它引入一系列优秀的软件开发方法，并将它们发挥到极致。比如，为了能及时得到用户的反馈， XP 要求客户代表每天都必须与开发团队在一起。同时， XP 要求所有的编程都采用结对编程（ pair-programming ）的方式。这种方式是传统的同行审查（ peer review ）的一种极端表现，或者可以说是它的替代方式。

过程：

XP 定义了一套简单的开发流程，包括：编写用户案例，架构规范，实施规划，迭代计划，代码开发，单元测试，验收测试等等。

思想：

像所有其他敏捷方法一样， XP 预期并积极接受变化。它具有以下的价值观或原则：

Ø 互动交流。团队成员不是通过文档来交流，文档不是必须的。团队成员之间通过日常沟通，简单设计，测试，系统隐喻以及代码本身来沟通产品需求和系统设计。

Ø 反馈。反馈是一种信息的交流，能使系统更加完善。反馈与交流密切相关，客户使用或功能测试，单元测试等都能为开发团队提供反馈信息。同时，开发团队也可以通过估计和设计用户案例的方式将信息反馈给客户。

Ø 简单。 XP 提倡简单的设计，简单的解决方案。 XP 总是从一个简单的系统入手，并且只创建今天，而不是明天，需要的功能模块。因为它认为，创建明天需要的功能模块可能会由于需求的变化而成为浪费。

Ø 勇气。 XP 在这一点所要达到的目的（我们认为）是鼓励一些有较高风险的良好的做法。例如，它要求程序员尽可能频繁地重构代码，必须删除过时的代码，不解决技术难题就不罢休，等等。

Ø 团队。 XP 提倡团队合作，相互尊重。 XP 以建立并激励团队为一项重要任务。同时它把互相尊重和实际的开发习惯相结合。比如，为了尊重其他团队成员的劳动成果，每个人不得将未通过单元测试的代码集成到系统中。因此，每个人的代码质量必须过关。

核心做法：

Ø 小规模，频繁的版本发布，短迭代周期。

Ø 测试驱动开发（ Test-driven development ）。

Ø 结对编程（ Pair programming ）。

Ø 持续集成（ Continuous integration ）。

Ø 每日站立会议（ Daily stand-up meeting ）。

Ø 共同拥有代码 Collative code ownership.

Ø 系统隐喻（ System metaphor ）。

Scrum

Scrum 是一个敏捷开发框架，它由一个开发过程，几种角色以及一套规范的实施方法组成。它可以被运用于软件开发，项目维护，也可以被用来作为一种管理敏捷项目的框架。

在 Scrum 中，产品需求被定义为产品需求积压（ product backlogs ）。产品需求积压可以是用户案例，独立的功能描述，技术要求等。所有的产品需求积压都是从一个简单的想法开始，并逐步被细化，直到可以被开发。

过程：

Scrum 将开发过程分为多个 Sprint 周期， Sprint 代表一个 2-4 周的开发周期。每个 Sprint 有固定的时间长度。首先，产品需求被分成不同的产品需求积压条目。然后，在 Sprint 计划会议（ Sprint planning meeting ）上，最重要或者是最具价值的产品需求积压被首先安排到下一个 Sprint 周期中。同时，在 Sprint 计划会上，将会对所有已经分配到 Sprint 周期中的产品需求积压进行估计，并对每个条目进行设计和任务分配。在 Sprint 周期过程中，这些计划的产品需求积压都会被实现并且被充分测试。每天，开发团队都会进行一次简短的 Scrum 会议（ Daily Scrum Meeting ）。会议上，每个团队成员需要汇报各自的进展情况，同时提出目前遇到的各种障碍。每个 Sprint 周期结束后，都会有一个可以被使用的系统交付给客户，同时进行 Sprint 审查会议（ Sprint review meeting ）。审查会上，开发团队将会向客户或最终用户演示新的系统功能。同时，客户会提出意见以及一些需求变化。这些可以以新的产品需求积压的形式保留下来，并在随后的 Sprint 周期中得以实现。 Sprint 回顾会随后会总结上次 Sprint 周期中有哪些不足需要改进，以及有哪些值得肯定的方面。最后整个过程将从头开始，开始一个新的 Sprint 计划会议。

角色：

Scrum 定义了 4 种主要的角色：

Ø 产品拥有者（ Product Owner ）：该角色负责产品的远景规划，平衡所有利益相关者（ stakeholder ）的利益，同时确定产品需求积压的优先级等。它是开发团队和客户或最终用户之间的联络点。

Ø 利益相关者（ Stakeholder ）：该角色与产品之间有直接的利益关系，通常也是由客户或最终用户代表组成。他们负责收集编写产品需求，审查项目成果等。

Ø Scrum 专家（ Scrum Master ）： Scrum 专家负责指导开发团队进行 Scrum 开发与实践。它是开发团队与产品拥有者之间交流的联络点。

Ø 团队成员（ Team Member ）：即为项目做实际开发工作的开发人员。

Scrum 提供一个敏捷开发框架，其他许多敏捷方法都可以被集成到 Scrum 中。比如测试驱动开发（ test-driven development ）和结对编程（ pair programming ）等都可以被整合到 Scrum 中。

精益开发（ Lean Development ）

精益软件开发模式是从丰田公司的产品系统开发方法中演化而来。它主要包括两个部分：一部分是核心思想及原则，另外一部分由一些在相应的工具构成。

精益开发的核心思想是查明和消除浪费。在软件开发过程中，错误（ bugs ），没用的功能，等待以及其他任何对实现结果没有益处的东西都是浪费。浪费及其源头必须被分析查明，然后设法制止。精益开发的其它原则包括 :

Ø 强调学习。软件开发过程是一个不断学习的过程。每个团队成员都需要从日常的失败，互动，交流以及信息反馈中学习，不断改进所开发的产品和效率。

Ø 不做长久的计划。尽量不要在可能改变的事情上做无谓的努力，这样才能有效的避免浪费。

Ø 尽量缩短迭代周期。较短的迭代周期能够加速产品的开发及交付，加快交流，提高生产力。

Ø 充分的自主权。激励团队并让所有团队成员自我管理始终是所有敏捷方法获得成功的基本因素之一。

Ø 完整性。确保整个系统正常工作，同时真正满足客户的需求是整个团队需要努力实现的完整性。

Ø 全局观。精益开发强调整体优化的系统。无论开发的组织还是被开发的产品， 从整体上考虑优化比从各个局部去优化更高效。

对于上述的每个原则，都有一些相应的工具对其加以实现。这些工具包括价值流图（ Value Stream Mapping ），基于集合的开发（ set-based development ），拉系统（ pull system ），排队论（ queuing theory ），等等。

精益软件更重要的是不断完善开发过程的一种思维方式。因此，将精益模式与其他敏捷开发模式一起使用将会取得很好的效果。

其它敏捷方法

动态系统开发方法（ DSDM ）是由快速应用程序开发（ RAD ）方法演变而来的敏捷开发模式。 DSDM 在普遍的敏捷价值和原则的基础上，定义了更加详细的流程，以涵盖更完整的项目生命周期。它们包括项目前期活动（ pre-project activities ），项目可行性研究，功能建模，设计和开发，实施或部署，项目后期维护（ post-project maintenance ），等等。同时，每个过程都定义了诸如如何将每个功能模型转化为实际代码，如何将原型交付最终用户使用并审查，如何处理反馈信息等的详细步骤。因此， DSDM 相比于其它敏捷方法在过程上显得比较繁重。

特征驱动开发（ FDD ）是另一种敏捷开发方式，它将用户的功能需求划分成更小的功能特征，然后逐步地在每个迭代周期中开发实现这些产品特征。与 DSDM 方式一样， FDD 仍然会在项目初期对整个项目做较大的规划和建模，以获得对该系统的全面了解。但是相比较 DSDM 来说， FDD 在这些方面更简捷。

Crystal Clear 是另一种形式的敏捷方法。 Crystal Clear 更专注于人。相比于其他的敏捷方法，它可使人获得更大的解放。据称这种方法更适合于较小规模的开发小组（由 2-8 个人组成）和非关键项目。 Crystal Clear 定义了七种属性。前 3 个属性 - 频繁的交付（ frequent delivery ），渗透交流（ osmotic communication ），反思提高（ reflective improvement ） - 反映出基本的敏捷开发做法和价值，如周期较短的迭代式开发，自我管理的开发团队和反馈带动增量发展等等。另外的 4 个属性分别是：个人安全（ personal safety ），集中（ focus ），容易接触专家用户（ easy access to expert users ）和技术环境（ technical environment ）。其中，容易接触专家用户实际就是敏捷方法中提到的客户持续参与，但 Crystal Clear 对此要求较宽松。 Crystal Clear 也提供了一些通用的做法，比如，它提供了三种回顾分析的方法：访谈，问卷调查和工作组。 Crystal Clear 的过程也是相当简单，其中涉及短的迭代周期，日常会议及持续集成等。

还有其他一些敏捷方法如敏捷统一过程（ Agile Unified process ），上下文驱动开发（ Context Driven Development ）， Getting Real 等。敏捷方法都是增量和迭代开发过程，并且强调人多过于整个过程。各种敏捷方法的区别在于它们对敏捷的不同阐释和不同侧重。理解他们可以帮助我们从多个角度理解敏捷开发，并且搜集更多的最佳应用。

如何选择一种敏捷方法

选择一种合适的方法取决于多种因素。在做出决定之前，我们需要充分考虑以下这些方面：

Ø 方法的复杂度。确保你的团队或组织能够应付这种复杂度。

Ø 社区支持。流行的方法可能并不是你最理想的选择，但流行的方法至少有较多的社区及行业支持，可以使你受益匪浅。

Ø 实用工具。选择一种可以为你提供许多支持工具的方法。一个良好的自动化工具可以帮助团队有效的处理日常工作，促进团队协作，并减少管理成本。

Ø 你目前的开发方式和你目前团队关于敏捷方法的认识程度。选择一些与你当前开发方式比较接近的敏捷方法将有助于推动该方法的实施。

Ø 你的团队规模。较小规模的团队最好从简单的方式入手。当然，这并不意味着你必须选择那些本身就比较简单的方法如 Crystal Clear 。你可以选择一些相对比较全面的方法，但从简单入手。当你的团队规模逐渐扩大，再增加相应的细节。

Ø 你不需要只遵从一种方法。你可以为团队选择一个主要的方法（如 Scrum ），然后从其他方法中借鉴对你的团队或组织有所帮助的其他方式加以整合。

敏捷总是在不断发展演变，因此，没有一个人能保证目前的敏捷方法都是正确的。每个采用敏捷开发的团队都可以通过发现并形成自己的想法和最佳实践，对敏捷开发做出自己的贡献。