敏捷软件开发（Agile Software Development）

极限编程实践

• 完整团队

  XP项目的所有参与者(开发人员、业务分析师、测试人员等等)一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。

• 计划游戏

  计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。

  当你能够度量你所说的，并且能够用数字去表达它时，就表示你了解了它；若你不能度量它，不能用数字去表达它，那么说明你的知识就是匮乏的、不能令人满意的。 - 凯尔文勋爵(英国物理学家)

• 客户测试

  作为选择每个所期望的特性的一部分，客户定义出自动验收测试来表明该特性可以工作。

• 简单设计

  团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。

• 结对编程

  所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。

• 测试驱使开发

  程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。测试用例循序渐进的对代码的编写进行指导。

  程序中的每一项功能都有测试来验证它的操作的正确性。

  迫使我们使用不同的观察点，可以设计出便于调用的软件。

  迫使我们解除软件中的耦合。

  测试可以作为一种无价的文档形式，这份文档是可编译、可运行的。它保持最新，不会撒谎。

• 改进设计

  随时改进糟糕的代码。保持代码尽可能的干净、具有表达力。

• 持续集成

  团队总是使系统完整的被集成。

• 集体代码所有权

  任何结对的程序员都可以在任何时候改进任何代码。

• 编码标准

  系统中所有的代码看起来就好像是被单独一个——非常值得信任的——人编写的。

• 隐喻

  团队提出一个程序工作原理的公共景象。

• 可持续的速度

  团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作。他们保存精力，他们把项目看做是马拉松长袍，而不是全速短跑。

为什么称为"极限"编程？

因为XP将常识性的原理和实践用到了极致:

• 如果代码评审是好的，那我们会始终评审代码（结对编程）。
• 如果测试是好的，那么所有人都应该始终进行测试（单元测试），甚至包括客户（功能测试）。
• 如果设计是好的，那么我们将把它当作每个人日常事务的一部分（重构）。
• 如果简单是好的，那么我们始终把系统保持为支持当前功能的最简单的设计（有效的最简单的设计）。
• 如果体系结构重要，那么所有人都将不断进行定义和完善体系结构的工作（隐喻）。
• 如果集成测试重要，那么我们将走一天内多次集成并测试（持续集成）。
• 如果迭代周期短些好，那么我们将使迭代时间非常非常短--秒，分或小时，而不是周，月或年（计划游戏）。

极限编程中的富足心态

在《The Forest People and The Mounted People》中，人类学家 Colin Turnbull 描绘了两个社会的明显反差。在山区，资源稀缺，人们总是处于饥饿的边缘。由此形成的文明是非常可怕的。一旦小孩有了任何幸存的机会，母亲们就丢弃他们，让他们与野生的孩子一起流浪。暴力。残忍和背叛是社会的公理。相反，森林中有丰富的资源。一个人每天只需花费半个小时就能满足自己的基本需要。森林文化是山区文化的反面。成年人共同养育孩子，在孩子们能完全照顾自己之前，他们一直受到养护如果一个人不小心杀死了另外一个人（蓄谋犯罪的概念还没有），他会被放逐，但也只是走到附近的森林中，并且只是几个月的时间，即使在这种情况下，其他部落的人也会给他食物。 XP 可以作为一个回答“如果你有足够的时间，你将如何编程”这个问题的试验。但是，你不可能有额外的时间。因为这毕竟是商业，而无疑我们都想成功。但是如果你有足够的时间，你会编写测试，你会在学到一些东西后重新构建系统的结构，你会与程序员同事或客户进行大量讨论。 与那种强加了不可能的期限的。无情而让人难以忍受的苦差事不同，这样的“富足心理”是符合人性的。富足心理是一件好事。 它创造出了它特有的效率，正如匮乏心理会造成特有的浪费。

XP项目控制

• 从控制变量系统建立的软件开发模型中有四个变量：成本，时间，质量和范围。其中，范围的控制最有价值。
• 你不能在第一天就使用40个程序员，你们必须从一个人的团队开始，然后增加到两个，然后是4个。两年后你就可以拥有40个程序员，但不是现在。
• 传统软件开发模型中，解决一个软件中的问题的成本（变化的成本）随时间的推移而以指数方式上升。XP方法尝试将变化成本-时间曲线变得平缓。
• 软件开发过程就像开车，客户就是软件项目的司机，程序员的职责是向客户提供反馈。
• XP的四个准则是：沟通，简单，反馈和勇气。
• 顺着人类的本能（而不是逆着他们）工作--人们喜欢胜利。他们喜欢学习，喜欢与别人交流，喜欢成为团队的一部分，喜欢将事情置于掌控之中，喜欢受到信任，喜欢出色地完成任务，喜欢使他们的软件发挥作用。XP尝试成为“完全符合程序员的理念“的编程方法。
• XP团队应该是智慧的游牧人，随时准备迅速收起帐篷，跟随牧群到处流浪。这里的牧群可能是与预期不同方向的设计、客户， 离开的团队成员，突然升温的技术，或者是不断变换的商业环境。

什么是最简单的设计？

• 最佳设计是能够运行所有测试用例的最简单的设计。
• 最简单的设计的四种约束，按优先级排序：
  1. 系统（代码和测试一起）必须能够沟通任何你希望沟通的内容。
  2. 系统不能包含重复的代码（1和2一起构成了“一次且只有一次”规则）。
  3. 系统拥有尽可能少的类。
  4. 系统拥有尽可能少的方法。
• 今天就够麻烦的了，尽量不要为明天设计，因为你无法对明天发生事情的成本进行估算。
• XP不是在鼓吹零设计的理念，只是说：“不要作任何无必要的设计“。

XP测试

• XP的功能测试用例和单元测试用例分别由客户和程序员编写。
• 单元测试只需要测试可能出错的部分，不太可能出错的部分不需要编写测试。
• XP团队无论大小都至少配有一名专职测试员。

其他

• 什么时候应该使用XP？在需求比较模糊或需求不断变化的时候使用XP。
• XP团队人员的角色包括：程序员，客户，教练，跟踪者，测试员，顾问，大老板。
• 有时复杂的工作确实比简单的工作容易一些。不要在有人（比如你）完成了很复杂的工作时觉得有什么了不起，相反，你必须学会对复杂不满，不停地探索，直到想出最简单的方法为止。

什么是Scrum方法？

Scrum(英式橄榄球争球队)是一个轻量级的软件开发方法。

Scrum是一个敏捷开发框架，是一个增量迭代的开发过程。在这个框架整个开发周期由若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的长度2到4周。在每个Sprint中，Scrum的开发团队拿到一个排列好优先级的需求列表，我们称它为用户故事或者叫Sprint backlog， 所以我们先开发的是对客户具有较高价值的需求。 在每个迭代结束后，都会开发完成可交付的产品。

Scrum由三个角色，三种活动，3种交付物组成。

三个角色：

• Product Owner
• Scrum Master
• Scrum Team

三种活动:

• the sprint planning meeting
• daily scrum meetings
• sprint review meetings

3种产物:

• the product backlog
• the sprint backlog
• a burndown chart

Scrum的基本假设是：

开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。

Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。

Scrum名词

backlog: 可以预知的所有任务， 包括功能性的和非功能性的所有任务。

sprint:一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。

sprint backlog:一个sprint周期内所需要完成的任务。

scrumMaster: 负责监督整个Scrum进程，修订计划的一个团队成员。

time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。

sprint planning meeting: 在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。

Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目：今天完成了什么？　是否遇到了障碍？　即将要做什么？通过该会议，团队成员可以相互了解项目进度。

Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为４小时。

Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为３小时。

Misc

• Most three significant complexity dimensions in software development: requirements, technology, and people.
• Scrum Characteristics
  • Self-organizing, Self-managing teams
  • Product progresses in a series of month-long ― sprints
  • Requirements are captured as items in a list of ― product backlog
  • No specific engineering practices prescribed
  • Uses iterative & incremental rules to create an agile environment for delivering projects
  • Fully Business driven
  • Timely inspect, adapt and remove impedance
• Product Owner
  • Possibly a Product Manager or Project Sponsor, a member of Marketing or an Internal Customer.
  • Responsible for representing the interests of everyone with a stake in the project and its resulting system.
  • Create the project‘s initial overall requirements, return on investment (ROI) objectives, and release plans. The list of requirements is called the Product Backlog.
  • Responsible for frequently prioritizing the Product Backlog to queue up the most valuable requirements for the next iteration.
• Scrum Master
  • Represents management to the project
  • Typically filled by a Project Manager or Team Leader
  • Responsible for enacting Scrum values, process and practices
  • Main job is to remove impediments and protect ―Scrum team‖ from external threat during each ―Sprint
  • Responsible for presiding over ―Daily Scrum Meeting
• Scrum Team
  • Typically 5-10 people
  • Cross-functional: QA, Programmers, UI Designers, etc.
  • Members should be full-time. May be exceptions (e.g., System Admin, etc.)
  • Teams are self-managing, self-organizing.
  • Membership can change only between sprints
  • Responsible for figuring out how to turn Product Backlog into an increment of functionality within an iteration and managing their own work to do so
  • Collectively responsible for the success of each iteration and of the project as a whole.
  • Two administrative responsibilities during the Sprint: attend the Daily Scrum meeting, and keep the Sprint Backlog up-to-date and visible to all.
  • Pigs VS Chickens
• Scrum doesn‘t specify any specific engineering practices
• Other engineering practices are up to you. Automation, code inspection, pair programming, static analysis tools, RUP, CMM, etc.
• However, each sprint is required to produce ready-to-use code. Heavy in-sprint testing is usually applied
  • Some teams have dedicated testers
  • Others have programmers test everything