敏捷开发中Scrum方法

现代软件开发肯定是复杂的，因为到目前为止，还没有一种方法从根本上消除软件之前的依赖，软件随着规模的扩大，需求的不精确和不停的变更以及需求调研人员限于领域知识所限，无法抽像出客户的需求。从技术上来说，虽然现在随着平台、框架、模式等帮助消除组件依赖的各种技术的应用，从技术上来说是在提高，但技术提高带的负面效果就是学习成本高昂。从软件工程角度来说，需求、技术、人员是一个软件产品的利益方。如下图所示：

如上图所示，在决定一个产品是否复杂（也就是成功）的标志与你的需要是否确定和技术是否稳定有很大的关系，显然，选择一个稳定可行的技术和一个确定的需求开发过程相对简单。但这是理论上如此，实际上你进行产品开发，你是无法选择需求，你可以选择技术。比喻说一般的WEB产品，都是SSH框架，比较成熟。对需求来说，传统的瀑布模式是先将能固定的需求先写好，可变的需求采用变更方式进行开发。形成了目前绝大部分软件产品的开发模式。如下图所示：

从上图上可以看出，传统的瀑布模式的一个比较让人诟病的就是周期长，在这个产品出现在客户面前时有可能需要半年或者一年的时间，因此它不适应用于需求变化非常快的项目。敏捷开发就是采用迭代的方式在很短的时间实现客户最关心的需求，让客户参与到开发中去。那为什么不直接称之为迭代模式呢？这是因为敏捷的行为不仅仅限于迭代，它通过设置不同的ROLE来确定迭代的准则。这一点在SCRUM中是非常重要的。SCRUM的思想来源于这样一段话“It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. when the process is too complicated for the defined approach, the empirical approach is the appropriate choice.”这段话简而言之就是在没有成型的固定流程可以实施的开发模式下，经验法则也是非常重要的。采用经验法则不仅直观、可适配还可以随时变更。Scrum就是一种采用经验法则的敏捷工程方法。通过Scrum思想，不仅可以利用经验进行软件开发，也可以利用经验进行组织的自管理从而达到软件产品的自提高。避免过多的外在干预。但显然经验是不可控的。怎样将经验进行可控呢？Scrum通过重新定义角度和流程来规范经验的使用。这就决定了它不是一个普通的迭代方法。在角度划分上，Scrum将传统软件自上而下的管理角色改成平行角色，这种平行角色基于这个角度在这个软件产品中是INVOLVE还是COMMIT。常见角度如下所示：

从上图可以看出这三种角度之间不再于传统的上下级关系，而是平等关系，它是以Backlog和rule用为驱动。最终就是一个SCRUM FLOW。如下图所示：

从上图可以看出，围绕Scrum开发的流程中主要三种活动MEETING，是Sprint Planning meeting\Daily scrum meeting/sprintreview meeting.从这里可以看出Sprint是一种很重要的概念，在Scrum中借用sprint这个词一方面来说明它是一种短期的活动，但又不等同迭代活动，因为迭代容易让人产生一种固定周期的感觉。Sprint它是以BACKLOG作为触发。首先sprint planning meeting会在produce backlog上确定 sprint tasks.这些sprint task作为sprint backlog（衡量每个任务的大小是4-16个小时作为基准的）。用来控制这个task的每日standup meeting称之为scrum，这种方式可以快速的回答一天的任务完成进度。由此可形成如下的开发模式：

在这种开发模式下，它允许我们可以快速和可重复的观察到实际工作软件（每两个星期到一个月时间内），并且在团队内部实际自管理去决定发布高优先级的功能的最好方法。通过SCRUM可以达到在最短的时间发布出最高商业价值的产品。