【原创】敏捷开发的介绍及应用

一.  敏捷开发思想

1)      个体与交互胜过过程与工具

2)      可以工作的软件胜过面面俱到的文档

3)      客户协作胜过合同谈判

4)      响应变化胜过遵循计划

二.  敏捷开发介绍

敏捷开发是一个统称，早在20世纪60年代初的美国，航天局水星计划就曾引入迭代和增量开发，后来17位在动态系统开发方法（DSDM）、极限编程（XP）、Scrum等领域的专家制定并宣布了敏捷开发宣言，随着敏捷宣言的签署，市场上出现了许多敏捷开发方法，包括Scrum、极限编程、精益开发（Lean Development）、动态系统开发方法、特征驱动开发（FeatureDriver Development）、水晶开发（Crystal Clear），我们项目将会使用Scrum方法。

Scrum有明确的最高目标，熟悉开发流程中需要具备的最佳技术，具有高度自主权，紧密地沟通合作，以高度的弹性解决各种挑战，确保每天、每个阶段都明确地朝目标推进。

三.  敏捷开发基本原则

所有敏捷开发方法都具有以下共同特征和原则：

1)      迭代式开发：即整个开发过程被分为几个迭代周期，每个迭代周期持续的时间一般较短，通常为1到6周。

2)      增量交付：产品是在每个迭代周期结束时被逐步交付使用，每次交付的都是可以被部署、能给用户带来即时效益和价值的产品。

3)      开发团队和用户反馈推动产品开发：敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。

4)      持续集成：新的功能或需求变化总是尽可能频繁地被整合到产品中。有些是在每个迭代周期结束的时候集成，有些则每天都在这么做。

5)     开发团队自我管理：人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。

四.  敏捷开发的优势

满足用户不断变化的需求是软件开发面临的最大难题之一，经典的瀑布开发模式在一个迭代周期内表现优异，然而一旦需求发生变化，瀑布模式却显得无能为力。敏捷方法的出现就满足了这个要求，它在每一次迭代周期结束时，都能交付用户一个可用的、可部署的系统，用户使用并体验该系统并反馈意见，在随后的迭代周期这些意见和需求的其他变化一起在产品中实现和集成。每次迭代周期应尽可能短，以便能及时地处理需求变化和用户反馈。

总体而言，敏捷开发方式能给企业和用户带来以下好处：

ü 精确：瀑布模式通常会在产品起点与最终结果之间规划出一条直线，然后沿着直线不断往前走。然而当项目到达终点时，用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑，每走完一步再调整并为下一步确定方向，直到真正的终点。

ü 质量：敏捷方法对每一次迭代周期的质量都有严格要求。一些敏捷方法如极限编程 (XP) 等，甚至使用测试驱动开发（Test-Driven Development），即在正式开发功能代码之前先开发该功能的测试代码。这些都为敏捷项目的整个开发周期提供了可靠的质量保证。

ü 速度：敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外，较短的迭代周期使团队成员能迅速进入开发状态。

ü 丰厚的投资回报率：在敏捷开发过程中，最具价值的功能总是被优先开发，这样能给客户带来最大的投资回报率。

ü 高效的自我管理团队：敏捷开发要求团队成员必须积极主动，自我管理。在这样的团队中工作，每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。

五.  敏捷开发方法Scrum的应用：

1)     Scrum基础模型

Scrum是一个敏捷开发框架，它由一个开发过程、几种角色以及一套规范的实施方法组成。在Scrum中，产品需求被定义为产品需求积压（Product Backlogs）。所有的产品需求积压都是从一个简单的想法开始，并逐步被细化，直到可以被开发的程度。Scrum将开发过程分为多个Sprint周期，每个小的迭代周期称为一个Sprint，每个Sprint的长度约2至4周。在每个Sprint中，Scrum开发团队会得到一个排好优先级的需求列表，这个列表称为SprintBacklog，所以我们先开发的是对客户具有较高价值的需求。在每个迭代结束后，都会开发完成可交付的产品。

Scrum是一个简单的框架，它由三个角色、三种活动、三种交付物组成：

1)     三个角色

a)      ProductOwner

作为产品的总负责人，他确定产品的所有功能，决定发布的日期和发布内容，为产品的Return On Investment (ROI)负责，以及根据市场价值确定功能优先级。一般来讲，在项目中他需要在30天内调整功能和功能优先级，并且有权力接受或拒绝接受开发团队的工作成果。他需要参与Scrum 的计划。这里需要说明的是，Product Owner并不是Scrum团队中的一员，实际上他在Scrum过程中只充当客户的角色并不是实际Scrum过程的一部分，但是必须考虑他。事实上，软件是为了用户而创建的，假如软件没有被使用，那么这个软件就等于没有开发。敏捷方法的一个重要方面是让用户和Stakeholders参与到过程中，参与每一个冲刺的评审和计划并提供反馈，对于这些人来说这是非常重要的。

b)      ScrumMaster

Scrum Master是Scrum过程的守护者，Scrum Master负责在团队中正确、完整地贯彻Scrum流程。虽然在实施开始的时候必须做一些折衷，而且因为实施环境的限制不得不放弃某些实践，但是ScrumMaster在脑海中始终要铭记实施完整的Scrum所带来的好处和价值，渐进地推动团队和组织走向完美状态。简单地说，就是服务团队，保护团队。具体是：

§ 保证团队资源完全可被利用并且全部是高产出的；

§ 保证各个角色及其职责的良好协作；

§ 解决团队开发中的障碍；

§ 作为团队和外部的接口，屏蔽外界对团队成员的干扰；

§ 保证开发过程按计划进行，组织DailyScrum、Sprint Review和Sprint Planning Meetings。

Scrum Master 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，哪些估计可能已经发生变化。Scrum Master 需要根据以上的情况更新每天完成的工作量，以及还有多少没有完成的燃尽图。

Scrum Master还需要找出阻碍Scrum的障碍和依赖。他们需要排列优先次序和跟踪，根据优先级制定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要通过团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队实施其生产力。

c)       ScrumTeam

具有不同特长的团队成员，人数一般控制在7个左右，包括我们开发小组中的开发人员、架构师、测试人员等等，由他们共同来确定每个Sprint目标和具体的工作成果。在执行过程中，他们在项目向导范围内有权利做任何事情以确保达到Sprint的目标。团队人员要具有高度的自我管理能力，共同促进每个冲刺的顺利完成。笔者在很多使用敏捷方法的项目中体会到，敏捷开发对于团队人员的综合素质有很高的要求。团队人员除了能够完成好自己的工作外，还有一个重要的职责就是向ProductOwner演示产品功能。这里需要注意，在编写User Story的时候要尽可能地写清楚如何进行演示，否则会达不到预期的效果。

2)     三种活动

a)      SprintPlanning Meeting（Sprint规划会）

根据Product Owner制定的产品或项目计划在Sprint开始时做准备工作。Product Owner可以是客户或者客户代表或代理。对于产品型的公司，客户就是市场，ProductOwner扮演市场代理的角色。一个Product Owner需要一个确定产品最终目标的远景，规划出今后一段时间产品发展的路线图，以及根据对投资回报的贡献确定产品特性。他要准备一个根据商业价值排好序的客户需求列表。这个列表就是ProductBacklog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级。

当为一个Sprint定义好足够多的ProductBacklog并且排列好优先级后，Scrum就可以开始了，Sprint规划会是用来细化当前迭代的开发计划的。规划会开始的时候，ProductOwner会和Scrum team一起评审版本、路线图、发布计划，以及Product Backlog。Scrum Team会评审ProductBacklog中功能点的时间估计并确认这些估计尽可能的准确。Scrum Team会根据资源情况，看有多少功能特性可以放在当前的Sprint中，然后，ScrumTeam按照优先级的高低来确定开发顺序。

当Sprint Backlog确定后，ScrumMaster带领Scrum Team去分解这些功能点，细化成Sprint的一个个任务. 这些任务就是细化的实施这些功能点的活动。Sprint Planning的这个阶段需控制在4个小时左右。

b)      DailyScrum Meeting（每日站会）

一旦计划阶段结束，30天周期的Sprint就开始了。Scrum Master需要组织团队成员每天开站会，这个会议是用15分钟的时间来让大家过一下Scrum的状态。在会上，每个团队成员需要问三个问题：我昨天做了什么，今天做什么，遇到哪些障碍。谁都可以参加这个会议，但只有Scrum团队成员有发言权。这个会议的目标是得到一个项目的全局观，用于发现任何新的问题，定位项目成员的要求，实时地调整当天的开发计划.

c)       SprintReview Meeting（Sprint评审会）和Sprint 回顾会议（Retrospective)

在Sprint结束的时候召开Sprint评审会和Sprint 回顾会议，加起来最多不超过4个小时。Sprint评审会用来给ProductOwner演示在这个Sprint中开发的产品功能。Product Owner会组织这阶段的会议并且邀请利益相关者参加。由ProductOwner来决定Product Backlog中的哪些功能已经开发完成 ，还要和Scrum Team及利益相关者讨论下一个Sprint中Product Backlog的优先级。同时，下一个Sprint的目标也在这个时候被确定下来。

接下来是Sprint回顾会议，是由ScrumMaster和Scrum Team一起回顾当前的Sprint。团队评估大家在一起的工作方式，找出好的方式以后继续发扬，找出需要做得更好的地方、想办法提升。

Sprint回顾会议结束后，新一轮的迭代又继续开始，迭代会一直继续，直到开发了足够多的功能去交付一个产品。

3)     三种交付物

a)      产品订单 (Product Backlog)

产品订单是整个项目的概要文档，包括所有所需特性的粗略的描述。产品订单也是关于将要创建的什么产品，包括粗略的估算，通常以天为单位。估算将帮助产品负责人衡量时间表和优先级。

在Scrum开发中，Product Backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含了客户想要的东西，并用客户的术语加以描述，通常把它叫做故事(Story)，有时候也叫做Backlog条目。

b)      冲刺订单 (Sprint Backlog)

冲刺订单是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单位，一个任务不可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而由团队成员签名认领他们喜爱的任务。

c)       燃尽图 (Burn Down Chart)

燃尽图是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。

六.  其他敏捷开发方法XP的比较：

1)      XP介绍：

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

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

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

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

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

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

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

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

2)      核心行为：

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

§  测试驱动开发（Test-drivenDevelopment）

§  结对编程（Pair Programming）

§  持续集成（ContinuousIntegration）

§  每日站立会议（Daily Stand-upMeeting）

§  共同拥有代码（CollativeCode Ownership）

§  系统隐喻（System Metaphor）