敏捷开发scrum模型

一、 什么是敏捷？

Agile在中文的字面意思是敏捷、灵活、利落。相应的“敏捷开发”也可以通俗地理解成为快速高效地进行开发。但敏捷不是开发的具体方法，它是一套能够指导企业进行高效开发的价值观与原则。

二、产生

瀑布模型

瀑布开发就相当于服务员将所有的菜在最后一起端上来。它将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。虽然瀑布模型提供了按阶段划分的检查点且前一阶段完成后，只需要去关注后续阶段，但是这种方法要求产品规划必须早于后续工作完成，一旦规划中有失误，很有可能使整个项目重新规划。 且各个阶段到结束后发现问题再返回上一阶段往往导致产品开发耗费非常多的时间。

瀑布开发模式的项目周期往往比较长，一般为3-6个月，甚至更长时间。

当项目开发完成后，最后交付成果往往不是产品经理或是客户真正想要的，最后只能重新从项目的需求开始。

经过一系列的建设、测试、部署等过程，那样的话，项目周期就会更长，然而又需要尽快投入市场，最后只能是稍微改动一下，差不多接近项目需求就行。

使用瀑布开发模式很容易出现这样的结果，开发周期很长，不可控的因素和风险很大，最终会偏离最初想法。

敏捷开发

敏捷开发相当于先把主菜给你上来，然后在上一些小菜。

为了使开发过程更加高效，在传统的开发模式下，出现了新的模式。 2001年在美国犹他州雪鸟滑雪胜地，17位程序员凑在一起同起草了敏捷软件开发宣言及敏捷12条原则，给软件开发提供了新的思路，组织可以灵活地使用许多可用的框架来进行高效的工作，如利用Scrum，看板，精益，XP等等进行工作。

三、敏捷开发-Scrum方法

敏捷开发中比较具有代表性的就是Scrum，本文以Scrum为例子像大家讲述敏捷思想。

在英文中Scrum原指橄榄球运动中队伍成员一起合作争球，而在软件开发中则是指敏捷开发的一种具体的方式。它包含“3个角色”、“3个可视化文档”、“5种不同形式的会议”以及“5个价值观”核心要点，简称“3355”。

在了解Scrum之前，要先知道Sprint,它原本是短距离赛跑的意思，而在Scrum中相当于迭代（Iteration），每一个迭代周期通常为4个星期左右，这个周期我们称为Sprint。根据项目得情况，Sprint数量不等，完成一个Sprint再进行下一个，每一个Sprint都会产生一个交付物，然后不断重复进行直到完成开发。

1. 三个角色(roles)：

PO(Product Owner) ：即产品负责人，在接到客户的需求后，产品负责人会将需求进行整合排序，持续定义最优先的任务并交付给团队进行工作，并对每个迭代的产品进行判定，是一个领导者的角色；
Scrum Master：即敏捷教练，了解并熟悉敏捷理念和Scrum运作，在工作的过程中帮助团队遵循Scrum 框架,按照框架进行工作，同时协调各个成员，保证敏捷开发的实施，引导大家又好又快的工作；
Team团队成员：是一个跨职能的小团体，包含研发、测试、设计等不同角色，共同客户需求努力，在PO的领导下阶段性工作，人数一般在5~11人左右；

2. 三个可视化文档（Artifacts）：

Product Backlog(代办项/产品需求列表)：由产品负责人维护，通过优先级排序来制定迭代计划，其中User Story(用户故事)是一种最佳实践，PO可以根据用户故事确定优先级并分配任务。
Sprint Backlog:优先级别最高的用户故事会进入到Sprint Backlog,而Sprint Backlog则构成本次冲刺周期内要完成的任务。Team成员再根据Sprint Backlog进一步划分职能分工，来完成代办项。
Burndown：即燃尽图，显示Sprint期间团队总的任务剩余时间，每天都重新估算，准确跟踪记录任务变化。

3. 五种不同形式的会议：

Sprint Planning:即计划会，在工作开始前需要明确工作计划，Sprint Planning就是Team与PO的内部会议，在会议中讨论且PO罗列出最重要的任务，以此来确定接下来的Sprint中Backlog有哪些，Team分工是什么。

Daily Scrum:即站会/晨会，每天在固定的时间集中在一起开小会，Team用15分钟左右的时间相互报告各自工作进度使每个人对大体工作进度有一个概念。 每名队员都要总结他昨天做了什么、今天将要做什么，以及是否遇到了障碍。被称为站会是因为要求站着开日会，但并不是强求，形式有很多种，最主要的是为了简化会议流程。

Sprint Review:即评审会议，**每个Sprint结束时团队召开Sprint评审会议，向产品负责人和其他有兴趣了解的人演示可工作的产品增量。这个会议应该是现场演示，而不是作报告。**项目负责人应当检查完成情况，并对未完成的任务重新放入Product Backlog。

Retrospective：即回顾会议，发生在Sprint的最后，由Scrum Master负责召集团队召开。会中大家回顾和小结这个Sprint做的好的地方以及有哪些不足。保证团队能够持续改进，不断提高。

Backlog Refinement：即列表维护，在执行Sprint过程中团队对于Product Backlog上面的东西进行评估与拆分，清楚地拆分比较大的条目，可以发生在整个Scrum周期的任何时间，为下一阶段Sprint做准备，可以提高效率，节约时间。

4. 五个价值观

勇气Courage：有勇气面对在工作中遇到地各种挑战与困难并勇于解决。
专注Focus：每个Sprint只专注于提前制定安排好的任务。
承诺Commitment：在Sprint开始前对制定目标做出承诺
尊重Respect：团队是一个整体，任何目标都要相互尊重与合作才可以完成。
开放Openness：每个人的工作进度、困难与成果都是公开透明的，成员之间没有隐瞒。

过程

实施Scrum的过程简单介绍

1. 将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。
2. 召开sprint planning meeting，划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算。
3. 进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。
4. 整个sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner.
5. 团队成员最后召开Sprint retrospective meeting，总结问题和经验。
6. 这样周而复始，按照同样的步骤进行下一次Sprint.
   

优点

• 在每一次迭代周期结束后，都可以产出一个可以交付给客户的产品，这样客户可以先体验这些产成品，并给予一定的反馈，而Team则可以随时根据客户的需求与反馈进行灵活改变。
• 在整个开发的过程中，将大的项目拆分成一定数量的Sprint来完成，客户可以随时查看工作进度，使过程可视化。
• 与传统瀑布式开发不同，当外在地环境市场与客户地需求发生变化时，不用将所有地工作都返工重新设计并进行，而是通过每个迭代与客户需求紧密相连，灵敏地应对现有地变化。
• 面对面地交谈方式与每日总结一方面较传统工作方式更灵活，另一面也加强了团队人员之间地协作与沟通效率。