敏捷开发

敏捷联盟官方网站：http://www.agilealliance.org/

敏捷scrum中文网 <u>http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-1</u>

敏捷开发由来

2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一 份简明扼要的《敏捷宣言》传递给世界，同时即宣告了敏捷开发运动的开始。

《敏捷宣言》

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：

** 个体与交互 重于 过程和工具**

** 可用的软件 重于 完备的文档**

客户协作 重于 合同谈判

响应变化 重于 遵循计划

在每对比对中，后者并非全无价值，但我们更看重前者。

敏捷开发模式

  敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调以人为本，专注于交付对客户有价值的软件。在高度协作的开环境中，使用迭代式的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善.

  敏捷开发，相对传统软件开发模式，它主要是针对快速变化的需求，不断优化管理流程，最终推出优质软件.

敏捷开发的宣言

一：个体及交互比流程与工具更具价值 二：可用的软件比冗长的文档更有价值 三：与客户的协作比合同谈判更有价值

四：对变化的响应比遵循计划更有价值

5个价值

1. 承诺 – 愿意对目标做出承诺

2. 专注– 把你的心思和能力都用到你承诺的工作上去

3. 开放– Scrum 把项目中的一切开放给每个人看

4. 尊重– 每个人都有他独特的背景和经验

5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

Scrum的重要名词 Backlog - 可以预知的任务集，包括功能性的和非功能性的所有任务。

Sprint - 一次迭代开发的时间周期，一般最多以30天为一个周期。在这段时间内，开发团队需要完成一个制定的Backlog。

Product Owner - 这个角色被称为产品经理。他负责定义产品并向开发团队提出需求，最终验收开发团队的工作成果。

Scrum Master - 负责监督整个Scrum进程、修订计划的一个团队成员。 **研发项目管理经理 流程经理 敏捷教练 ** 开发主管

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

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

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

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

**PBI ** Product Backlog Item 产品待办清单条目,简称PBI

敏捷开发成员架构

Scrum Master

负责管理Scrum流程， 确保Scrum正常运转。Scrum Master是教练， 是牧羊犬，是Scrum项目秩序的维护者。

· 负责监督整个Scrum项目进程，调整项目计划

· 确保开发团队成员的能力能够胜任产品的开发；

· 促进团队中不同角色的成员间充分交流和沟通，并负责为项目的进行扫除障碍；

· 保证开发团队不受外力的干扰和阻挠；

· 掌握产品开发进度，参与每日Scrum会议、Sprint计划会议和Sprint评审会议。

· Scrum Master最经常的情况就是由过去的项目组长(Team leader)来担当

产品负责人 Product Owner

负责管理产品Backlog 并使游戏项目价值最大化，代表项目的全体利益相关者。

Product Owner的角色通常由市场部门的人员或开发部门内部主要使用该产品的人来担任，他的主要工作是根据市场需求，确定产品的功能，列入Product Backlog中，并为这些功能确定优先级别。 Scrum团队按照功能的优先级，将它们从高到低分配到各个Sprint中进行开发，这些被分配到一个Sprint中完成的功能就形成了Sprint Backlog。

   在产品的整个开发过程中，Product Owner对于产品的需求可能会发生改变。他可以修改Product Backlog，增加某些功能需求、删除某些功能需求、修改优先级等等，但这些行为只能在各个Sprint之间进行

**团队 **

团队是负责开发软件的跨职能小组。团队是自我管理的，在Scrum Master 的帮助下，团队提出承诺，完成自己的承诺，实现软件价值。

一般由5-10个能全职工作的成员组成较为理想；团队成员横跨各个职能，通常包含开发，测试，文档设计人员等等。

敏捷开发团队原则

最大的分歧

最大的分歧在于开发人员和测试人员之间。作为敏捷团队的成员，测试人员被期望能编写一点代码，同时开发人员可以做一 些测试。各自的强项还是很重要：新的角色要求每个成员成为大家所谓的“通才”。测试人员大多数时间作测试，开发人员大都编写代码，但所有人都分享他们的工 作，而且有能力承担他们面前的任务。

发现中立点

团队决定作为一个团队需要做什么，如何最好地分配工作。第一步是让团队成员说说他们自己的技能集、优点和缺点。但却不希望他们根据以前角色（如，软件测试员或开发员）来定义自己。所以找到一个中立点，列出了小型离线会议，和每周工作之外的小时集体活动所需的事项。

正确执行应用程序

团队找到了让自己感到舒服的新水平。整个项目的工作流程顺利进行，只做一个待办的事情，而不是四个。

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。

敏捷开发流程

wpsA544.tmpf9ff457c-a945-4346-87fc-510945f1f1cc.jpg

敏捷开发模型流程图
从敏捷开发流程模型图当中可以看出，在敏捷实施过程当中，有四种会议，分别是计划会，每日站会，回顾会，评审会，其中数计划会最为重要。 在敏捷开发模式中，每种会议都有其特殊的职责和使命，不同的会议上所讨论的内容是不一致的，只要把握住会议的关键点，就可以为团队的敏捷模式服务。

wpsA555.tmped26ceaf-1447-4919-a985-78829ff96246.jpg

Sprint Planning敏捷迭代计划会议

1 Sprint Planning 敏捷迭代计划会议
在每个敏捷迭代开始之初，由产品负责人讲解需求，并由开发团队进行估算工时的计划会议。 在会议上需要：排列需求优先级；分析和评估产品Backlog并确定该迭代的目标；计划会议上还需要制定迭代计划，包括： 根据产品Backlog（功能点）创建Sprint Backlog（即迭代任务）；然后为Sprint backlog中的任务做估算；团队成员从产品Backlog中挑选他们承诺完成的条目。
敏捷的迭代实现始于计划会议，所以一个好的计划会议是每个迭代成功的基础，一般分两个阶段进行，两个阶段参与会议的人员会不一样；
计划会议的目标：
1、基于敏捷规划产生的Product Backlog以及优先级，通过计划会议，确定迭代的目标、团队成员、形成Sprint Backlog，明确评审会、回顾会时间；
2、分解Sprint Backlog并确定相应的完成时间，并由团队成员共同挑选这些Sprint Backlog；
阶段一参与人员：产品经理、Product Owner、Scrum Master、团队成员，有业务人员的话还可以邀请业务人员一起参加。
会议时长：1-4小时
一般参考进程安排如下：
1、Scrum Master公开迭代时间表；
2、产品经理和Product Owner讲述Product Backlog，对应的业务价值和优先级；
3、团队针对Sprint Backlog和优先级达成一致；
4、Scrum Master和团队成员共同确定Sprint Backlog；
阶段二参与人员：Scrum Master、团队成员，其他人员选择性参加
会议时长：1-4小时
一般参考进程安排如下：
1、团队成员针对Sprint Backlog共同分解任务；
2、团队成员共同进行工作量评估(每个Task不超过2天)，确定开始时间和完成时间；
3、团队成员共同认领任务；
4、共同确定DoD，团队达成一致；
5、团队共同确认迭代目标和价值；

如果单个迭代内安排的Product Backlog安排的比较多的话，一般迭代计划会议需要开一个整天，虽然时间有点长，但这个会议会确认整个迭代的详细计划和安排，因此也是值得的。

一个典型的Sprint计划会议时间表
Sprint 计划会议：13:00 – 17:00 （建议每小时休息10分钟）
13:00 – 13:30 产品负责人对Sprint目标进行总体介绍，概括产品Backlog。定下演示的时间地点。
13:30 – 15:00 团队估算时间，在必要的情况下拆分Backlog条目——把“故事”进一步拆分成“任务”。 产品负责人在必要时修改重要性评分。理清每个条目的含义。所有重要性高的Backlog条目都要填写“如何演示”。
15:00 – 16:00 团队选择要放入Sprint中的故事。计算生产率，用作核查工作安排的基础。
16:00 – 17:00 为每日Scrum会议（简称每日例会）安排固定的时间地点——如果和上次不同的话。
Sprint应该多长才好？
时间短就好。公司会因此而变得“敏捷”，有利于随机应变。
短的Sprint = 短反馈周期 = 更频繁的交付 = 更频繁的客户反馈 = 在错误方向上花的时间更少 = 学习和改进的速度更快

绘制任务版
任务版中的任务是分解到手头的实际的工作

把要做的任务,正在做的任务和已经完成的任务,用简单的贴士贴在白板上.不同的颜色表示不同的重要程度.

开发人员选择任务帖在规定时间内完成任务


敏捷开发遇到的扑克牌（ 计划纸牌 ）
每个人都会得到如上图所示的13张卡片。在估算故事（任务）的时候，每个人都选出一张卡片来表示他的时间估算（以故事点的方式表示），并把它正面朝下扣在桌上。所有人都完成以后，桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考，而不是依赖于其他人估算的结果。
如果在两个估算之间有着巨大差异，团队就会就此进行讨论，并试图让大家对故事内容达成共识。他们也许会进行任务分解，之后再重新估算。这样的循环会往复进行，直到时间估算趋于一致为止，也就是每个人对这个故事的估算都差不多相同。
2 Daily Stand-up Meeting每日站会
团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名，团队成员通常会在会议上讲述如下3点内容：

1.  昨天我做了什么
   

2.  今天我计划要做什么
   

3.  我遇到了什么问题，妨碍了我尽可能有效地工作
   

Scrum Master记录会议上提出的问题，但是不要在会议上讨论和解决问题，而是要会后在找相关人员进行讨论和解决。
3 Sprint Review 敏捷迭代评审会议
在迭代结束前给产品负责人演示并接受评价的会议，并根据反馈结果，提出新的产品Backlog
参与人员：产品经理、Product Owner、Scrum Master、团队所有成员
会议时长：1-4小时，视演示内容而定
主要是检验迭代成果，检查是否完成迭代计划中的迭代目标，有可能的话要求用户参与测试流程，并得到用户对产品的认可，鼓励用户自己进行测试设计和进行破坏性测试，充分暴露产品的设计和功能问题。
由Scrum Master来推进会议进程，Product Owner记录用户反馈，根据结果维护产品 backlog，一般在迭代结束前做一次。
4 Sprint Retrospective 敏捷迭代回顾会议
在每个迭代结束后召开的关于自我持续改进的会议，围绕如下三个问题进行讨论：

1.  本次迭代有哪些做得好；
   

2.  本次迭代我们在哪些方面还能做得更好；
   

3.  我们在下次迭代准备在哪些方面改进；
   

团队确定问题优先级，并根据优先级确定团队能够解决的Top问题；团队讨论Top问题的措施，并选择在下一个迭代可以完成措施，分配责任人进行跟踪。
参与人员：Scrum Master，Product Owner，团队成员。
会议时长：0.5-1.5小时
主要针对当前迭代，团队成员自由讲述可以需要保持的做法，改进的点以及持续跟踪计划。
Scrum Master将团队讨论以及行动计划形成会议纪要，并发送给整个团队和有关同事。需要按照回顾会议的结论，维护一份待办事项列表，在下次回顾会议上进行跟踪。
案例分析
案例一：某Team在每日站会中，Scrum master准时组织大家开始晨会，成员一个接着一个说，昨天做了什么事情，今天计划做什么事情，遇到什么问题，成员A说昨天遇到了一个问题未能解 决，Scrum master问遇到的是什么问题，成员A详细说明了该问题，这时成员B说这个问题他也遇到过，他是通过XX方式解决的，讨论后成员A明白了，然后继续晨 会，由于小组成员有10个人，整个会议开下来大概花费了30分钟。
问题分析：Scrum master不应该在每日站会上询问详细的问题细节，而应该转移到会下询问，当团队成员之间进行讨论的时候，Scrum master需要及时拉回来，讨论应该转移到会下进行，晨会要在固定的时间固定的地方并且在固定的时间内完成。会议时间需要控制在15分钟之内。
案例二：某Team在开回顾会议中，Scrum master详细总结了本次迭代中有哪些做不够好的，并指出了对应的事和人，接着对应的责任人开始述说哪些地方确实是做的不够好及其原因，最后给出改进措施然后结束会议。
问题分析：回顾会不是批斗会，不应该只说做的不好的，做的好的也要说，Scrum master主要是鼓舞大家的士气，应该先从做的好的方面开始说起；并且做的不好的方面都只对事，不对人，做的不好是整个Team的责任，不仅仅是某几个 人的责任；最后的改进措施需要给有后续跟踪的责任人和有效性的反馈。

在敏捷的迭代执行过程中，上述四种会议会随着每个迭代一直进行，基本上形成了一个闭环，可以让团队在每个迭代的执行过程当中去学习和总结，从而正确的按照敏捷的要求去做，使团队真正的敏捷起来。

敏捷开发的6个实战经验分享

总结了6个实施敏捷开发的技巧：快速迭代、让测试人员和开发者参与需求讨论、编写可测试的需求文档、多沟通&尽量减少文档、做好产品原型、及早考虑测试等。

1. 快速迭代

相对那种半年一次的大版本发布来说，小版本的需求、开发和测试更加简单快速。一些公司，一年仅发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。

由一年发布2个版本转到一个月发布2个版本，这也不太可能。但是现在来看，快速迭代已经成为事实标准，关键是要比目前的版本发布速度更快一些。

快速迭代，可以逼迫团队不断优化流程、提升工作效率，不要在无足轻重的事情上浪费时间。如果离deadline还有6个月，那么整个工作 节奏必然悠哉。如果每月发布一个版本，那么较以前效率必然会更高。如果发布周期过长，导致无法尽快发现用户需求，进而无法及时改进产品。

2. 让测试人员和开发者参与需求讨论

需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。

同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。

确定需求时，不要过度盯在细节上。需求报告过于详细，就是一种不敏捷的习惯，还浪费大家的时间。当然，不能错过好点子，但就是不要太细，因为项目真正实施起来时需求将会产生很大的变动。

3. 编写可测试的需求文档

开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早的提及技术实施方案，会降低对需求的注意力。

规划业务需求，可以采用“3W模板”，也就是：
· 谁（Who）
· 是什么（What）
· 为什么（Why）
上面的3W实际上就是描述了相关利益者是谁，他们想要什么，他们为什么有这种需求。下面举一例子进行说明：

wpsA577.tmpf9fc27bc-131a-4288-9fcf-766426245a0c.jpg

为了更加接近“用户故事”，我们可以改写为：

wpsA578.tmp1ba609b1-520c-4b46-ba98-a859df547df4.jpg

敏捷项目中编写用户故事有一个常用模板：作为一名[用户类型]，我想要[需求]，以便于[原因]。应用到这个例子，就是：作为一名用户，我想要将归档程序数字化，以便于增强沟通、提高分享效率。

多数情况下，需求内容需要更加充实和详细，这一步要放到后面做，开始不要这样。用户故事的方法有时会因过于简短、不断重复而受到批评。这 里我们必须明白：需求文档不是散文或诗歌，应该清晰、简明地描述用户需求；需求文档的重点也在于此，不要管形式多变或内容是否重复这样的问题。

4. 多沟通，尽量减少文档

任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。

团队要确保日常的交流，面对面沟通比邮件强得多。

敏捷开发鼓励日常的协调会议和碰头会，5~7人参与的会议尽量控制在10分钟内。碰头时，要过一遍昨天完成了什么，今天要做什么，哪些问题仍待讨论。可以用Burndown Chart（燃尽图）来形象展示工作进度。每次迭代的时候也都要开一个计划会议和评审会议，一般需要的时间可能会长些，比如半天。这些会议的目的就是对工作查缺补漏。

评审会议很重要，传统开发模式往往略过该环节，导致一些错误做法不断重复，好的做法无法推广。

开会时，可以将原先的分组打散，让整个团队都参与到项目的需求讨论和测试中来，这样可以突出成员个人，让大家更乐意参与。

5. 做好产品原型

建议使用草图和模型来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。

一个常见的问题是软件新的功能与用户想要的不一致。为了避免这一问题，可以模拟真实操作，改进模拟操作过程中难以理解和不清楚的操作行为。

6. 及早考虑测试

及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。

敏捷开发中一个常见问题就是开发者没有对已有的代码库进行充分的回归测试。迭代周期很短，从开始到交付就是4周的时间，这样可以对迭代的设计、实现和底层测试一块进行回归测试。

一系列迭代之后，可以只针对测试活动再补充一个迭代。这个迭代可以将重点放在系统测试、与其他系统的集成度、性能等方面。敏捷开发过程中，可能会导致过少的测试文档。如果迭代周期为1个月左右，可以不必对测试文档过于要求，但要制定好测试策略。

wpsA588.tmpf67ce141-a577-473b-97db-46fe1e10a27f.jpg