敏捷开发：从宣言到实战

敏捷的背景和动机

有数据显示有70%采用瀑布式开发开发方法的软件开发项目均以失败告终。软件项目现在有了新的挑战：市场的需求瞬息万变，很难实现项目需求的明确且完整的收集；技术的发展也日新月异，对于所定义功能的可实现性也面临着多重不确定性的因素。基于这些新的挑战，敏捷开发方法孕育而生。

上图展示的是一个敏捷模型和瀑布模型的一个对比，瀑布模型是趋于一个稳定的需求范围，就是在项目前期根据需求确定人员和开发时间，他是一个规划驱动的模型。敏捷开发是确定时间，根据需求不断迭代来不断提高和不断修正。瀑布模型是以规划为导向的，而敏捷模型是以价值为导向的，价值作为交换的优先级，价值作为整个项目的最终目标。

敏捷宣言

2001年初，由于许多公司的软件开发团队陷入了不断增长过程的泥潭，一批业界专家聚焦在一起概括出一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则。他们称其为敏捷联盟。这个联盟有个宣言，虽然听上去可能有些高大上，但却是很实际。敏捷的转型不仅仅是方法论的转变，更重要的是公司自上而下整个架构理念的改变。所以理解宣言内容是很重要的，第一条是个体和互动高于流动和工具。这里强调的是团队中个体和个体互动，大家更积极的去做事情。高于流程和工具，并不是排斥他们，流程和工具本身就是经验的总结，我们仍然需要他们去规范我们的软件；工作的软件高于详尽的文档，这里的工作软件指的是我们不断迭代交互出来的产品，必须是完整的、独立可运行的软件，这里所说的高于详尽的文档也不是排斥文档，而是相对而言，当然文档作为项目的一部分资产，也是比较重要的；客户合作高于合同谈判，强调的是把客户引导到我们的软件开发环境，让他们对软件有更详细的了解，而不仅仅是把精力全放到合同谈判上；响应变化高于遵循计划，对于需求的不断改变，我们要积极的去响应，而不能单单的去遵循计划。

敏捷开发的12个原则

具体内容如上图，在这做简单的介绍。我们要尽早地交付有价值的软件，对于客户来说这无疑是最重要的。敏捷开发的优点就在于到了后期客户也可以根据需要更改需求。业务人员和开发人员天天在一起工作有利于提高人员之间的交互能力。一个软件的开发周期是很长的，这就需要开发人员要保持一个恒定的开发速度。简单化是根本，这体现了软件开发的高效性。

敏捷是一种方法论，而敏捷方法是将这些理论应用于实践。目前敏捷开发的七种主流方法如下：极限编程、scrum、水晶方法族、特性驱动开发、自适应软件开发、动态系统开发方法和轻量型RUP。大家比较熟悉的是SCRUM，

SCRUM精讲

简介

它是一个用于开发和维持开发产品的一个框架，是一个增量的、迭代的开发过程，在这个框架中，软件开发由若干个短的迭代的周期组成。每个短的迭代周期被称为Sprint，每个sprint的建议长度为2到4周。

看上图，会发现每个sprint都由分析、设计、测试、构建、集成五部分组成。通过每个sprint进行回复和评审的一个环节，来达到一个反馈，总结错误的地方和需要达到的一个高度，来更好的交付我们的软件成果。在scrum中使用产品Backlog来管理产品的需求，backlog是按照商业需求标准来排序的需求列表，列表体现形式通常是用户故事。Scrum总是想开发对用户有高价值的需求。从sprint中的backlog挑选优先价值最高的需求进行开发。在sprint计划会议上我们要进行讨论、分析和估算得到相应的任务列表，把它当作sprint backlog来搞。

下面的表格是sprint不同迭代周期会对scrum产生哪些影响。我们可以看到它影响事务成本、对业务变化的响应、透明性、反馈周期、陷入为瀑布的风险和适配性。

在这里我们建议大家在第一个甚至第二个迭代周期的时候，沿用两周的迭代周期，恰巧我们可以测试一系列的因素在我们的项目里是怎样的一个反馈，这样我们在接下来的迭代周期才会有一个更好的改善。

Scrum框架

它包括三个角色（产品负责人、scrum主管、开发团队）、四个仪式（sprint计划会议、每日站会、sprint评审会议、sprint回顾会议）、三个工件（产品订单、冲刺订单、冲刺燃尽图）三部分组成。下图是scrum的流程，可以看到Product Owner从客户、团队那里拿到需求来做成product backlog列表，团队通过sprint计划会议建立相关的冲刺订单，scrum master通过每日站会对团队的冲刺订单进行审核，判断完成情况，在每个迭代周期的结束还会有评审会议和回顾会议。评审会议是对软件是否合格进行审核，回顾会议对上一周期的不足等进行总结，以达到团队的持续进步。

Scrum仪式中的sprint计划会议大概分为两个部分，第一部分由PO、SM和Team参加，主要是从产品的backlog中挑选出需要放到当前sprint下的既定产品backlog；另一部分是SM、Team参加，把既定产品的backlog拆分成任务进行估算，PO也可以参加这一部分来了解具体的开发细节。这里有一个相关的例子，作为一个博客作者，我想上传我的照片以便读者认识我，那么需要制作照片上传页面、开发照片上传后台程序、写单元测试、更新自动化测试脚本等。

Scrum中每日会议，如果条件允许的话，应该在同样的时间和地点，要求团队成员站立进行会议。会议时间应该在早晨，不宜过长，控制在15分钟左右，如果时间太长不利于工作效率，有利于团队成员安排自己的工作，只有团队成员可以在会上发言，其他人可以旁听，但不可以发言。会议由scrum主管来主持，每个成员轮流回答下面三个问题：昨天我做了什么、我今天打算做什么，都遇到了哪些问题或困难。

Scrum中的sprint回顾会议就是团队的自我检视，发现什么是好的，什么是不好的。会议时间一般控制在15-30分钟，每个sprint都需要去做，主管、负责人、团队人员、相关客户等全体都要参加。

Scrum中的product backlog分为几个元素：Epic、feature、user story、Task。Epic又称为史诗故事，规模和复杂性非常大，难以估算。Feature代表产品的特性，代表一个产品可以做什么，可以提供什么样的服务。User story 通常都一个模板，作为一个角色，采用某种操作，以便能够完成某种特定的目标，它进一步拆分就会拆分成几个task。

在敏捷开发中是通过用户故事来讲需求具体化可以迭代开发的一个个现实的可见的开发任务。在用户故事的划分中有三个要素：card、conversation和confirmation。具体格式和例子如下：

作为一个角色，通过某项操作以便完成特定的目标。

As a < user >, I need to < action > in order to < reason >

作为一个博客作者，我通过我的博客发布我的照片，以便我的读者能认识我。

作为一个国足的球迷，通过点击官网的新闻栏，以便能够了解最新的国足时态。

一个良好的User-story应该包括下面的一些原则：独立性、可评估、可协商、短小、有价值、可测试性。我们需要通过测试来确定软件是否可正常工作。

   还记得上面的那个博客的例子吗，我们接下来用这个例子来讲一下冲刺订单。如下图，通过十天的迭代周期来记录sprint backlog的完成情况。第一天就是所有任务的一个初始值，开发照片上传需要四个小时，我们第一天剩下的工作量就是需要完成的工作量，sprint需要每天更新。在这里我们需要注意的是管理sprint的backlog是团队人员自己挑选任务而不是分配任务，对于每个任务每天都要更新剩余工作量，每个成员都可以更改sprint backlog。

使用DevCloud实践

Product owner负责把product backlog的信息随着项目迭代的进行持续录入项目规划中。在spring plan meeting阶段，团队可以对story进行任务拆分和估算，在daily standup meeting上，对相关信息进行更新。这里的‘E’对应的就是主菜单中的epic。文档提供了项目归档和资产管理的项目管理。我们可以把线下的项目文档都上传到云端。百科可以实现对知识库FAQ的管理，项目内的成员可以更好的了解项目的知识库资源。同样看板也是实现项目管理的一种，通过它我们可以对图形进行更好的设计，达到更好的统计效果和最终效果。