敏捷式开发

一、敏捷开发的工具：Leangoo；Teambition

二、Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。

(1) Scrum团队中包括三个角色，他们分别是产品负责人、开发团队和 项目的直接管理者（Scrum Master）。

Scrum角色之：产品负责人

产品负责人负责最大化产品以及开发团队工做的价值。实现这一点的方式会随着组 织、Scrum 团队以及单个团队成员的不一样而不一样。

产品负责人是管理产品待办事项列表的惟一责任人。产品待办事项列表的管理包括:

● 清晰地表达产品代办事项列表条目

● 对产品代办事项列表中的条目进行排序,最好地实现目标和使命

● 确保开发团队所执行工做的价值

● 确保产品代办事项列表对全部人可见、透明、清晰,而且显示 Scrum 团队的下一步工做

● 确保开发团队对产品代办事项列表中的条目达到必定程度的理解

产品负责人能够亲自完成上述工做,也可让开发团队来完成。然而,产品负责人是 负责任者。

产品负责人是一我的,而不是一个委员会。产品负责人可能会在产品代办事项列表中 体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。

为保证产品负责人的工做取得成功,组织中的全部人员都必须尊重他的决定。产品负 责人所做的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发 团队按照另外一套需求开展工做,开发团队也不容许遵从任何其余人的指令。

Scrum角色之：开发团队

开发团队包含了专业人员,负责在每一个 Sprint 的结尾交付潜在可发布的“完成”产 品增量。只有开发团队的成员才能创造增量。

开发团队由组织构建并受权,来组织和管理他们的工做。所产生的协同工做能最大化 开发团队的总体效率和效力。开发团队有如下几个特色:

他们是自组织的,没有人(即便是 Scrum Master 都不能够)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能。

开发团队是跨职能的,团队做为一个总体拥有创造产品增量所须要的所有技能。

Scrum 不承认开发团队成员的头衔,不管承担哪一种工做他们都是开发者。此规则无一例外。

开发团队中的每一个成员能够有特长和专一领域,可是责任归属于整个开发团队

开发团队不包含如测试或业务分析等负责特定领域的子团队。

Scrum角色之：Scrum Master

Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。

Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。 Scrum Master 经过改变这些交互来最大化 Scrum 团队所创造的价值。

Scrum Master 服务于产品负责人

Scrum Master 以各类方式服务于产品负责人,包括:

● 找到有效管理产品代办事项列表的技巧

● 清晰地和开发团队沟通愿景、目标和产品表明事项列表条目

● 教导开发团队建立清晰简明的产品表明事项列表条目

● 在经验主义环境中理解长期的产品规划

● 理解并实践敏捷

● 按需推进Scrum活动

Scrum Master 服务于开发团队

Scrum Master 以各类方式服务于开发团队,包括:

● 指导开发团队自组织和跨职能

● 教导并领导开发团队创造高价值的产品

● 移除开发团队进展过程当中的障碍

● 按需推进Scrum活动

● 在 Scrum 还未彻底被采纳和理解的组织环境下指导开发团队

Scrum Master 服务于组织

Scrum Master 以各类方式服务于组织,包括:

● 领导并指导组织采用 Scrum

● 在组织范围内计划 Scrum 的实施

● 帮助员工及干系人理解并实施 Scrum 和经验性产品开发

● 发起能提高Scrum 团队生产力的变革

● 与其余 Scrum Master 一块儿工做,帮助组织更有效的应用Scrum

四个会议

四个会议指的是Sprint计划会议、每日例会、Sprint评审会议和Sprint回顾会议。

Sprint计划会议（Sprint Planning）

在Scrum中，Sprint计划会议有两部分：

1. 决定须要完成哪些工做？

2. 决定这些工做如何完成？

第一部分：须要完成哪些工做？

参会人员：团队、项目负责人（Scrum Master）、产品负责人（Product Owner）

第一部分的会议，产品负责人向开发团队介绍排好序的产品待办事项，由整个Scrum团队共同理解这些工做。

Sprint中须要完成的产品待办事项数目彻底由开发团队决定。作多少工做只能由开发团队决定，产品负责人或任何其它人都不能给开发团队强加更多的工做量。

第二部分：如何完成工做？

参会人员：Team 、Scrum Master

第二部分的会议，开发团队须要根据当前的“完成的定义”一块儿决定如何实现下一个产品增量。他们进行足够的设计和计划，从而有信心能够在Sprint中完成全部工做。

决定如何完成工做是开发团队的职责，决定作什么则是产品负责人的职责。

Sprint计划会议最终须要Scrum团队对Sprint须要完成工做的数量和复杂度达成共识，最终产生的待办事项列表就是“Sprint待办事项列表（Sprint Backlog）”。

Sprint待办事项列表是一个须要在当前Sprint完成的且梳理过的产品待办事项，并包括了一个团队完成这些工做的计划。

每日站会（Daily Scrum）

开发团队是自组织的，经过每日站会来确认他们仍然能够实现Sprint的目标。

每个开发团队成员须要提供如下三点信息：

● 从昨天的站立会到如今，我完成了什么；

● 从如今到明天的站立会，我计划完成什么；

● 有什么阻碍了个人进展。

每日Scrum一般不超过15分钟。

每日Scrum中可能有简要的问题澄清和回答，可是不该该有任何话题的讨论。

每日Scrum既不是向管理层汇报，也不是向产品负责人或者ScrumMaster汇报。它是一个开发团队内部的沟通会议，来保证他们对现状有一致的了解。

只有Scrum团队的成员，包括ScrumMaster和产品负责人，能够在会议中发言。其余感兴趣的人能够来旁听。

Sprint评审会议（Sprint Review）

Sprint结束时，Scrum团队和相关人员一块儿评审Sprint的产出。全部Scrum会议都是限定时长的，Sprint评审会议的推荐时长是Sprint中的每一周对应一个小时（好比，一个Sprint包含2个星期，则Sprint评审会议时长为2个小时）。

每一个人均可以在Sprint评审会议上发表意见。产品负责人会对将来作出最终的决定，并适当地调整产品待办事项列表（Product Backlog）。

Sprint评审会议向每一个人展现了当前产品增量的概况。一般都会在Sprint评审会议中调整产品待办事项列表。

Sprint回顼会议（Sprint Retrospective）

在每一个Sprint结束后，Scrum团队会聚在一块儿开Sprint回顾会议，目的是回顾一下团队在流程、人际关系以及工具方面作得如何。团队识别出哪些作得好，哪些作得很差，并找出潜在的改进事项，为未来的改进制定计划。全部的Scrum会议都是限定时长的，Sprint回顾会议的推荐时长是Sprint中的每一周对应一个小时（译者注：好比，一个Sprint包含2个星期，则Sprint回顾会议时长为2个小时）。

Scrum团队老是在Scrum的框架内，改进他们本身的流程。

SCRUM的三个物件

三个物件指的是产品待办事项列表（Product Backlog）、Sprint Backlog和燃尽图

Product Backlog – 产品待办事项列表

产品待办事项列表是一个排序的列表,包含全部产品须要的东西,也是产品需求变更的惟一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

产品待办事项列表是一个持续完善的清单, 最初的版本只列出最初始的和众所周知的需求。 产品待办事项列表根据产品和开发环境的变化而演进。待办事项列表是动态的,它常常发生变化以识别使产品合理、有竞争力和有用所必需的东西。只要产品存在,产品待办事项列表就存在。

产品待办事项列表列出了全部的特性、功能、需求、改进方法和缺陷修复等对将来发布产品进行的改变。产品待办事项列表条目包含描述、次序和估算的特征。

产品待办事项列表一般以价值、风险、优先级和必须性排序。它是一个按照优先级由高到低排列的一个序列，每一个条目有惟一的顺序。排在顶部的产品待办事项列表条目须要当即进行开发。排序越高,产品待办事项列表条目越紧急,就越须要仔细斟酌,而且对其价值的意见越一致。

排序越高的产品待办事项列表条目比排序低的更清晰、更具体。根据更清晰的内容和 更详尽的信息就能作出更准确的估算。优先级越低,细节信息越少。开发团队在接下来的 Sprint 中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过,所以,任何 一个条目在 Sprint 的时间盒内均可以被“完成”。开发团队在一个 Sprint 中能够“完 成”的产品待办事项列表条目被认为是“准备好的”或者“可执行的”,能在 Sprint 计 划会议中被选择。

随着产品的使用、价值的获取以及市场的反馈,产品待办事项列表变成了更大、更详 尽的列表。由于需求永远不会中止改变,因此产品待办事项列表是个不断更新的工件。业 务需求、市场形势和技术的变化都会引发产品待办事项列表的变化。

若干个 Scrum 团队经常会一块儿开发某个产品。但描述下一步产品开发工做的产品待办事项列表只能有一个。那么这就须要使用对产品待办事项列表条目进行分组的属性。

经过产品Backlog地梳理来增添细节、估算和排序。这是一个持续不断 的过程,产品负责人和开发团队协做讨论产品表明事项列表条目的细节。在产品待办事项列表梳理的时候,条目会被评审和修改。然而, 产品负责人能够随时更新产品代办事项列表条目或酌情决定。

梳理在 Sprint 中是一项兼职活动,在产品负责人和开发团队之间展开。一般,开发 团队有自行优化的领域知识。然而,什么时候如何完成优化是 Scrum 团队的决定。优化一般占用不超过开发团队 10%的时间。

开发团队负责全部的估算工做。产品负责人能够经过协助团队权衡取舍来影响他们的 决定。可是,最后的估算是由执行工做的人来决定的。

SPRINT BACKLOG

Sprint 代办事项列表是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付 产品增量和实现 Sprint 目标的计划。Sprint 代办事项列表是开发团队对于哪些功能要包 含在下个增量中,以及交付那些功能所需工做的预计。

Sprint 代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量 所须要执行的工做。Sprint 代办事项列表使开发团队肯定的、达到 Sprint 目标所需的工 做清晰可见。

Sprint 代办事项列表是一份足够具体的计划,使得进度上的改变能在每日例会中获得 理解。开发团队在整个 Sprint 中都会修改 Sprint 代办事项列表,Sprint 代办事项列表也 会在 Sprint 的进程中慢慢显现,好比开发团队按照计划工做并对完成 Sprint 目标所需的 工做有更多的了解。

当出现新工做时,开发团队须要将其追加到 Sprint 待办事项列表中去。随着任务进 行或者被完成,须要更新每项任务的估算剩余工做量。若是计划中某个部分失去开发的意 义,就能够将其除去。在 Sprint 内只有开发团队能够对 Sprint 待办事项列表进行修改。 Sprint 待办事项列表是高度可见的,是对团队计划在当前 Sprint 内完成工做的实时反 映,而且,该列表只属于开发团队。

Product Backlog 功能点被放到Sprint的固定周期中，Sprint Backlog 会由于以下缘由发生变化:

❶随着时间的变化，开发团队对于需求有了更好的理解，有可能发现须要增长一些新的任务到Sprint Backlog中。

❷程序缺陷作为新的任务加进来，这个都作为承诺提交任务中未完成的工做。

Product Owner也许会和Scrum team一块儿工做，以帮助team更好的理解Sprint的目标，ScrumMaster和team也许会以为小的调整不会影响sprint的进度，但会给客户带来更多商业价值。

燃尽图（BURN-DOWN CHART)

Sprint燃尽图（Sprint Burn-down Chart)

Sprint Burndown Chart 显示了Sprint中累积剩余的工做量，它是一个反映工做量完成情况的趋势图。 图中Y轴表明的是剩余工做量，X轴表明的是Sprint的工做日。

在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint须要完成的详细的任务。全部这个Sprint中须要完成，但没有完成的任务的工做量是累积工做量，团队会根据进展状况天天更新累积工做量，若是在Sprint结束时，累积工做量下降到0，Sprint就成功结束。

因为在Sprint的刚开始的时候，增长的任务工做量可能大于完成的任务工做量，因此燃尽图有可能略微呈上升趋势。

发布燃尽图（Release Burn-down Chart）

在Scrum项目中，团队经过每一个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工做量的变化趋势。X轴表明的项目周期，以Sprint为单位， Y轴表明的是剩余工做量，一般以用户故事点、理想人天或者team-days为单位。