敏捷项目管理大串讲－转载

工作十余年来，接触过大小互联网公司四五家了，几乎每家做项目时必谈敏捷，但对敏捷的理解和实践都不一致。笔者曾经一度被敏捷层出不穷的各种概念闹的头昏眼花。最近一个月利用闲暇时间系统性的学习了敏捷项目管理，并结合之前的工作经验，借知乎平台把敏捷项目管理整个串讲一遍，也算作为自己学习和工作的总结。

本文思维导图

敏捷宣言和敏捷原则

谈敏捷开发之前，不得不说一下什么是瀑布开发。传统的软件开发使用的是瀑布开发的模式，这种模式把整个开发过程分为问题定义、可行性研究、需求分析、软件设计、编码、测试、维护等阶段。每个阶段之间是串行的、线性的，也就是前一个阶段实现之后，才能进入下一个阶段。瀑布开发是一种计划性强、开发质量高的软件开发模式。

瀑布开发模式

但是，这种开发模式的缺点也很明显。随着市场和用户需求瞬息万变，很难在项目开始之前就能把需求完全收集并定义清楚。同时，技术发展也日新月异，在开发阶段面临着很多不确定性因素。在这样的背景下，敏捷开发就应运而生了。

美国犹他州的雪鸟城，这是一座以滑雪圣地闻名的小城，是盐湖城内滑雪者的天堂。2001年2月，一群具有反叛精神的软件开发人员，聚集在这座一点也不像科技创新中心的城市里，经历了为期三天的讨论，他们制定并签署了行业历史上最重要的文件之一：敏捷宣言。

敏捷宣言

• 个体和互动 高于 流程和工具
• 工作的软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划

其中前一项称为敏捷的第一价值，后一项称为敏捷的第二价值。需要注意的是，虽然前一项更有价值，但并不是说完全不重视后一项。笔者经历过很多玩敏捷的公司，完全不重视文档和流程，开口闭口就谈敏捷，结果项目失败的概率就很高。

在这4条敏捷宣言的基础上，又引申出12条敏捷原则。

敏捷原则

1. 尽早、持续地交付有价值的软件，让客户满意。
2. 欣然面对需求变化，即使在开发后期。
3. 频繁地交付可工作的软件，从数周到数月，交付周期越短越好。
4. 在团队内外，面对面交谈是最有效，也是最高效的沟通方式。
5. 在整个项目过程中，业务人员必须和开发人员每天都在一起工作。
6. 以受激励的个体为核心构建项目。为他们提供所需的环境和支持，相信他们可以把工作做好。
7. 可工作的软件是衡量进度的首要标准。
8. 敏捷过程倡导可持续开发。
9. 坚持不懈的追求技术卓越和良好的设计，以此增强敏捷的能力。
10. 简单是尽最大可能减少不必要工作的艺术，是敏捷的根本。
11. 最好的架构、需求和设计来自自组织的团队。
12. 团队定期反思如何提升效率，并依此调整自己的行为。

敏捷宣言和敏捷原则是最重要的敏捷理念，还有其他一些关于敏捷的原则性的理念，罗列如下。

• 敏捷计划：发布计划、迭代计划、每日计划。
• 敏捷阶段：构想、推测、探索、适应、结束。
• 敏捷社区价值：前景、信任、协作、诚实、好学、勇气、开放、适应力、透明化、领导变革、仆人式领导力。

敏捷开发框架

有了敏捷这么一个高大上的东西，各路豪杰纷纷举起敏捷大旗，开始建立自己的门派。各大门派对敏捷都有自己的一套理论，这就是敏捷开发框架。常见的敏捷开发框架有：Scrum、极限编程、精益软件开发、水晶方法、特征驱动开发、动态系统开发方法、敏捷统一过程等。

Scrum

Scrum的中文意思是橄榄球赛中的争球，是由Jeff Sutherland和Ken Schwaber于1995年第一次提出。Scrum是一种迭代式增量软件开发过程，其整体框架包括3种角色、5个仪式和3个工件。

3种角色：

• 产品负责人（Product Owner）：定义项目愿景、需求、优先级，对产品成功负责。
• 敏捷专家（Scrum Master）：团队负责人，帮助团队实现产品负责人所设定的目标。
• 开发团队（Dev Team）：自组织、跨职能。他们协同工作，以满足产品负责人的目标。

5个仪式：

• 计划会议（Sprint Planning Meeting）
• 每日站会（Daily Scrum Meeting）
• 评审会议（Review Meeting）
• 回顾会议（Retrospect Meeting）
• 待办事项梳理会（Backlog Grooming Meeting）

3个工件：

• 产品待办事项（Product Backlog）
• 冲刺待办事项（Sprint Backlog）
• 产品增量（Product Increment）

极限编程（XP，Extreme Programming）

极限编程是由KentBeck在1996年提出的，是一项以编程人员为中心的敏捷框架。它注重小而迅速的发布，强调集体所有、持续集成、结对编程。一般认为，极限编程是用户故事的发明者。关于用户故事，后文会有详细的介绍。

这里又引出了三个概念：集体所有、持续集成、结对编程。集体所有容易理解，那么什么是持续集成和结对编程呢？

所谓持续集成是一种软件开发实践，即团队开发成员经常把他们的工作集成到产品代码库中。每次集成都通过自动化的编译和测试来验证，从而尽早地发现缺陷，也确保随时都有可工作的产品。如果你用过git和jenkins这样的工具，会对持续集成有更深刻的理解。

结对编程是一种敏捷软件开发的方法，是指两个程序员在一个计算机上共同工作，一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员。两个程序员经常互换角色。

精益软件开发（Lean）

精益软件开发一词起源于Mary Poppendieck 和Tom Poppendieck写的一本同名书籍。它强调尊重一线人员、消除浪费、增强学习、延迟决策、嵌入质量、快速交付、整体优化。

水晶方法（Crystal）

水晶方法是由Alistair Cockburn和Jim Highsmith建立的敏捷方法系列。其首要原则是渗透沟通，渗透沟通是沟通的一种，指的是信息在团队成员之间无意识地进行共享。

水晶开发的特征包括：渗透沟通、经常交付、反思改进、个人安全、聚焦、与专家和用户保持联系。水晶开发的纲领包括：建设团队、探索性360（即评估项目可靠性）、为团队定义实践标准、建立初始项目计划。

动态系统开发方法（DSDM，Dynamic Systems Development Method）

动态系统开发方法倡导以业务为核心，快速而有效地进行系统开发。其基本观点是，任何事情都不可能一次性圆满完成，应该用20%的时间完成80%的有用功能，以适合商业目的为准。

动态系统开发方法提出项目的5个阶段包括：可行性研究、商业论证、功能原型、创建迭代、实施迭代。

敏捷统一过程（AUP，Agile Unified Process）

敏捷统一过程把项目分为4个阶段：创始、细化、建立、转变。

上面讲了这么多敏捷开发框架，每种框架之间有相同之处，也有不少差异。如果是非专业人士，不需要分的特别清楚。在实际工作中，往往是综合使用，各取所长，能解决问题就好。

敏捷开发流程

上面啰啰嗦嗦讲了不少敏捷的理论性的东西，那么到底在项目管理中怎么实施敏捷呢？我们以Scrum框架为例，看一下敏捷项目管理的整体流程。

Scrum整体框架

上图是在一个软件版本周期内，敏捷开发的实施流程、相关人员以及产出物。首先，产品负责人（PO）提出产品创意，并以用户故事的方式列在产品待办事项（Backlog）中。其次，通过冲刺（Sprint）计划会议，从产品待办事项中选择一些事项放到下一个冲刺中。然后，由开发团队进行开发、测试、发布。

一个冲刺的持续时间通常是2至4周，一个版本往往需要经过多个冲刺才能开发完成。在每个冲刺期间，团队需要召开每日站会，并定期对产出物和产品负责人一起进行迭代评审，以确保产品符合用户需求。在每个冲刺结束后，还要召开迭代回顾会议，提出需要改进的地方。

以上只是敏捷开发流程的整体描述，其中还有很多细节没有涉及到。下面通过几个概念的介绍，把整个流程再梳理一遍。

立项

在项目正式开始前，领导们往往会召开立项会议，也就是项目动员会。在立项会议上，需要宣布项目的背景、意义、目标，也就是给整个团队描绘项目成功后的愿景，激励大家好好干活。

立项往往还包括版本发布计划，比如这个版本包含几个冲刺、发布的时间、完成的标准等。

冲刺（Sprint）

冲刺和迭代这两个概念往往混用。一个冲刺的持续时间通常是2至4周，一个版本通常由多个冲刺组成。在冲刺之间，需要召开冲刺计划会议，确定在下面的冲刺中要具体做哪些工作。在冲刺期间，团队将产品负责人等召集在一起，召开冲刺评审会议，对已经完成的工作进行展示和验收。在冲刺结束之后，团队一起召开冲刺回顾会议，通过反思的方式提出下一步的改进措施，从而提升团队整体效率。

用户故事（User Story）

那么，产品负责人如何描述用户需求呢？为了规范用户需求的表达，用户故事包括角色（Role）、活动（Activity）、商业价值（Business Value）三个要素。通常用以下格式来表达：As a <Role>, I want to <Activity>, so that <Business Value>。

一个好的用户故事需要符合INVEST原则，即Independent（独立的）、Negotiable（便于沟通的）、Valuable（有价值的）、Estimated（便于评估的）、Small（小的）、Testable（可测试的）。

用户故事往往不会跨冲刺开发，开发一个用户故事理想的时间是2至5天。通常，开发团队会把用户故事再分解为更小的易于处理的子任务，这个过程称为解聚。

需求价值

用户需求复杂多样，产品待办事项中往往堆积了大量的需求，那么如何决定把哪些需求放到下一次冲刺中呢？自然是价值高需求优先处理。那么问题来了，如何定义需求价值呢？一般有下面几种方法。

1、MoSCoW方法：把需求分为Must（必须有）、Should（应该有）、Could（可以有）、Won't（不会有）这四类。

2、KANO模型：根据具备程度和用户满意度之间的关系，把需求分为必备属性、期望属性、魅力属性、无差异属性和反向属性五类。

KANO模型

估算

除了评估需求价值之外，还需要评估需求实现的成本。估算是指对交付产品所需要的成本、投入或者技能进行的预算，通常用故事点来表示。故事点是一种相对工作量的表示，和“人/天”的表示方式不同，故事点关注的是需求的复杂度，以便让所有人对同一个用户故事有相同的复杂度认知。

故事点

计划扑克

计划扑克是用于估算产品待办事项的工作量的一种方法，其估算单位是故事点，通常使用斐波拉契数列（0,1,2,3,5,8……）来作为故事点的相对工作量。使用方法如下：

• 参加估算的开发人员每人各拿一叠扑克牌，牌上有不同的数字。
• 产品负责人为大家挑选一个用户故事，并简单解释其功能，以供大家讨论。
• 每个开发人员按自己的理解来估计完成这个用户故事所需的故事点，从自己手里的牌中选一张合适数字的牌，同时亮牌。估计时间限制在2-3分钟。
• 每个开发人员各自解释自己选择这个数字的原因，数字最大和最小的人必须发言。
• 根据每个开发人员的解释，重新估计故事点并再次出牌，直到大家的估计值比较平均为止。

计划扑克

每日站会

在每日站会上，每个成员会分享他已完成的事项、正在进行的事项，以及遇到了什么困难或阻碍。每日站会的时间不应超过15分钟，站立的目的也就是确保会议的效率。

敏捷项目管理工具

在实施敏捷项目管理的过程中，需要确保团队中的每个人信息相互同步，因此一种任何人都能方便查看的工具——看板（KanBan），成为敏捷项目管理的标配。看板源自日语，是丰田公司精益生产的核心管理工具，其本质是一个即时的（JIT）库存控制调度系统。

除了看板之外，燃尽图（Burndown Chart）也是常用的信息展示工具。燃尽图显示了一次迭代中的剩余工作量，用来追踪实际剩余任务和理想剩余任务的对比，从而评估项目是否会提前完成或延期。

另外，市面上有一些在线项目管理工具，便于团队人员随时随地查看并管理项目，同时提供项目进度的可视化展示工具，已经成为互联网公司敏捷团队的首选。下面介绍四款常用的敏捷项目管理工具。

JIRA

JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

Teambition

Teambition是国内团队协作工具的创导者，通过帮助团队轻松共享和讨论工作中的任务、文件、分享、日程等内容，让团队协作焕发无限可能。2019年3月26日Teambition被阿里巴巴全资收购。

Tower

Tower帮助你更高效的安排工作任务，管理项目进度，沉淀团队知识，让每个人走得更快，让团队走得更远。

Worktile

Worktile是企业协作办公平台，致力于解决企业员工工作效率，加强团队成员之间协作与沟通，进而提升企业核心竞争力。

推荐书单

最后，关于敏捷项目管理，再推荐几本系统性的书籍。敏捷项目管理是一套实践性很强的项目管理方法，通过具体项目的磨练，会对敏捷有更深刻的认识。

• 《敏捷实践指南》
• 《敏捷估计与规划》
• 《敏捷项目管理》
• 《用户故事与敏捷方法》
• 《scrum指南》
• 《看板实战》
• 《看板方法》
• 《精益敏捷项目管理》
• 《敏捷回顾》