敏捷项目管理的基本概念

许多项目成员对敏捷开发中的一些基本名词概念模糊，造成了项目管理过程和内部交流上的一些困难。在此对一些容易混淆的基本概念做解释。

1 Agile——敏捷

在软件工业界，敏捷开发已成为众多高效开发团队的制胜之道。它不仅被许多中小公司青睐，在全球一百强的企业中，敏捷开发也已大行其道，受到许多资深项目管理者和开发人员的推崇。例如，腾讯内部几乎所有的开发团队都在实施敏捷。
    敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括：极限编程（XP），Scrum，精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。所有这些方法都具有以下共同特征：

1. 迭代式开发。即整个开发过程被分为几个迭代周期，每个迭代周期是一个定长或不定长的时间块，持续的时间较短，通常为一到四周。
2. 增量交付。产品是在每个迭代周期结束时被逐步交付使用，而不是在整个开发过程结束的时候一次性交付使用。每次交付的都是可以被部署到用户应用环境中被用户使用的、能给用户带来即时效益和价值的产品。
3. 开发团队和用户反馈推动产品开发。敏捷开发方法主张用户能够全程参与到整个开发过程中。这使需求变化和用户反馈能被动态管理并及时集成到产品中。同时，团队对于用户的需求也能及时提供反馈意见。
4. 持续集成。新的功能或需求变化总是尽可能频繁地被整合到产品中。一些项目是在每个迭代周期结束的时候集成， 有些项目则每天都在这么做。
5. 开发团队自我管理。拥有一个积极的、自我管理的、具备自由交流风格的开发团队，是每个敏捷项目必不可少的条件。人是敏捷开发的核心。敏捷开发总是以人为中心建立开发的过程和机制，而非把过程和机制强加给人。

2 Scrum——橄榄球式开发模式

Scrum 是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程，是敏捷开发的一种实现机制。Scrum以经验性过程控制理论（经验主义）为理论基础，主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个冲刺（Sprint）。
    在Scrum中，使用产品Backlog来管理产品需求和开发任务。产品backlog是一个按照商业价值（或实现优先级）排序的事项列表，列表条目的体现形式通常为用户故事。在规划Sprint时，Scrum团队从产品Backlog中挑选最高优先级的需求，在Sprint计划会议上经过讨论、分析和估算得到相应的任务，并分配给具体的成员去实现。
    当前Sprint需要完成的任务会展现在特别设计的面板上，清晰地展示每个任务的负责人、当前状态、实现过程中的问题和变更等等信息。项目团队和各利益攸关方能清晰地把握每个任务的开发进度和遇到的问题，并以此分析、控制项目的进度、成本和风险。
    Scrum以站立会作为项目规划、过程控制和资源分配的内部交流协商机制。
    在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。

    作为敏捷开发的实现机制，Scrum拥有以下重要特征：

1. 迭代开发。在Scrum的开发模式下，我们将开发周期分成多个1-4周的迭代，每个迭代都交付一些增量的可工作的功能。迭代的长度是固定的，如果我们选择了1周的迭代，那么保持它的长度不要发生变化，在整个产品开发周期内每个迭代都是1周的长度。这里需要强调的是在每个迭代必须产出可工作的增量功能，而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。
2. 增量交付。增量是一个 Sprint 及以前所有 Sprint 中完成的所有产品待办事项列表条目的总和。在 Sprint 的结尾，新的增量必须“完成”，这意味着它必须可用并且达到了 Scrum 团队 “完成”的定义的标准。无论产品负责人是否决定真正发布它，增量必须可用。增量是从用户的角度来描述的，它意味着从用户的角度可工作。
3. 自组织团队。Scrum团队是一个自组织的团队，传统的命令与控制式的团队只有执行任务的权利，而自组织团队有权进行设计、计划和执行任务，自组织团队还需要自己监督和管理他们的工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式。
4. 高优先级的需求驱动。在Scrum中，我们使用Product Backlog来管理需求，Product Backlog是一个需求的清单，其中的需求是渐进明细的、经过优先级排序的。Scrum团队从Backlog最上层的高优先级的需求开始开发。在Scrum中，只要有足够1-2个Sprint开发的细化了的高优先级需求就可以启动Sprint了，而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求。

3 Sprint——冲刺

组成整个开发过程的一个短的迭代周期成为一次冲刺。一个Sprint是指一个1周－4周的、有明确生产计划和产出的迭代周期，由Sprint 计划会议、每日站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成，并产出可交付的产品增量。也就是说，每个Sprint结束即可向需求方提交一次版本更新。
    Scrum采用迭代增量的方式，是因为需求是涌现的，我们对产品和需求的理解是渐进式的，Sprint长度越长，我们需要预测的越多，复杂度会提升、风险也会增加，所以Sprint的长度最多不超过4周。越来越多的团队使用2周的Sprint，很多市场变化快、竞争激烈的领域，比如互联网和移动互联网产品开发团队也会使用1周的迭代。
    每次冲刺可在超前完成工作计划时提前结束，但必须在到期时结束。关闭冲刺时，已完成的任务需要评审以确定是否真的完成，未完成的任务则须退回到待办事项列表中。

4 Backlog——待办事项列表

Scrum软件开发是一个循序渐进的过程，而用户需求和技术实现通常具有相当的不确定性。项目团队通常需要反复对需求进行识别分析，创建工作分解结构，估算工作量，并及时响应需求和技术的不确定性。Scrum利用Backlog来管理用户需求和任务，并通过及时梳理来响应需求变更。
    Scrum的产品Backlog是一个按照商业价值（或实现优先级）排序的事项（需求）列表，记录经过识别、分解和估算的用户需求和任务。Jira系统提供的Backlog如下图所示。

5 Issue——事项

在Scrum中，经过识别解析得到的用户故事、开发任务、测试得到的BUG等等统称为事项（Issue）。

5.1 Story——用户故事

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1. 角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事以故事点（Story point）作为其相对大小的衡量单位。故事点一般是指相对于某个标准故事而言，当前故事所需付出的努力。由于故事点往往由相对比较法估算得出，因此其大小只有比较意义没有绝对意义，也并不对应具体工时。

5.2 Epic——史诗

在Scrum项目中，Epic是指从用户需求中识别出来的在一定程度上相互独立、而内部则相对联系的需求集合，例如系统管理模块、用户认证模块等等。
    也就是说，一篇史诗是由一系列用户故事组成的故事集。通常用Epic大致描述系统模块的功能概要或需求范围，但不应描述细节。

5.3 Task——任务

Task是明确定义了输入输出、技术指标和其他具体要求的任务说明。对于从Story中具现的任务，一般直接从Story中开出Sub-task。如果Story足够小，则不必再开出Sub-task，可直接将Story作为任务交给具体人员去完成。

5.4 Improvement——改进

Improvement指改善性的微小需求变更，是对已完成的用户故事的细微优化调整。这些调整一般不涉及具体功能的变更，而是基于用户体验的细节优化，不足以形成新的用户故事。

5.5 New feature——新特性

新增的用户需求。并非对已有用户故事的细化或者完善，而是指新的用户故事。尽量杜绝在一次冲刺中间插入新特性，应当把他作为用户故事规划到Backlog里，再根据其优先级安排到以后的冲刺中。所以在JIRA中，尽量不要创建New feature。

5.6 Bug——缺陷

测试人员在项目测试过程中发现的任何缺陷，都需要在JIRA系统中开设BUG，详细说明缺陷细节，确定其优先级和负责人。由于公司的JIRA与测试管理系统TestLink相关联，测试人员可以利用TestLink自动创建Bug并生成缺陷说明。

6 Priority——事项优先级

事项优先级定义事项基于用户需求、技术实现或其他利益攸关方的要求所确定的实现先后顺序。包括：

1. Blocker：最优先实现。在Bug中指阻碍开发或测试工作，无法继续运行，需要立即修复并且部署。
2. Critical：重要。在Bug中指崩溃、数据丢失、严重的内存泄漏。
3. Major：主要。在Bug中指主要的功能丧失。
4. Minor：次要。在Bug中次要功能丧失，或其他问题，即存在简单问题。
5. Trivial：不重要。在Bug中指如单词拼写错误或文字对齐美观问题等。

7 Burn-down Chart——燃尽图

燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示，向项目组成员和相关方提供工作进展的一个公共视图。

7.1 冲刺燃尽图

Sprint燃尽图用于展示冲刺周期内故事点的变动情况，理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，Sprint故事点“烧尽”至零。然而实际上，每个迭代都有很多待开发的Story，在敏捷开发中，工作量的评估是以Story为单位的，一个迭代Story的数量会影响到燃尽图的Y轴。如果Story的数量过少，绘制出来的燃尽图就会呈明显的折线形状，也会对速度和风险的判断带来影响。所以，曲线未必能真的代表剩余的工作数量，也不能完美地作为管理层进行项目可视化管理和绩效管理的工具。但它可以反映出项目冲刺规划、管理和进度控制上的一些问题。
    以下是某项目某个冲刺周期的燃尽图：

    图中曲线在第二周时有三个时间段比较集中地下降，说明团队在这三个时间段比较集中地确认任务已完成；图中没有比较大的向上的突起，说明冲刺策划工作还算不错，Scrum Master对冲刺有较强的控制力，没有在冲刺周期内引入过多的新特性；最终曲线没有到达零点，说明冲刺周期内有任务未完成，需要反思是否存在一个冲刺内工作量过多还是、引入了新特性还是存在别的工作效率或团队协作的问题。
    而下面这张图反映了项目团队对冲刺的策划和控制可能存在更多的问题：

7.2 交付燃尽图

对于PMO而言，交付燃尽图可能比冲刺燃尽图更具有实际意义。
    冲刺燃尽图反映了一个Sprint内工作的“燃尽”情况，而交付燃尽图则展示了在更长的、可能跨越很多个Sprint周期的情况下，软件是否能如期交付某个版本或某个模块。以下是某项目的某个版本的交付燃尽图。

交付燃尽图中，浅绿色的柱状代表这个Sprint完成了的故事点数，所以前面加了个减号；
    浅蓝色的柱状代表，在这个Sprint开启之前就存在的故事点数，在这个Sprint结束时还剩下多少；
    深蓝色的柱状代表，在这个Sprint开启后到下个Sprint开启前这段时间，版本中增加了多少故事点数，所以用加号。
以下通过2个图例说明如何解读交付燃尽图。

1. 较正常的交付燃尽图，可以预测这个版本可以在什么时候交付
   
   两条预测线，上面那条的由来是，浅蓝色柱状的顶部中点，用最小二乘法计算的拟合直线；下面那条则是深蓝色柱状的底部中点，用最小二乘法计算的拟合直线。两条线斜率的意义是，每个Sprint故事点数完成的速率和故事点数新增的速率。两条预测线的交点对应的横坐标代表这个版本预计会在哪个冲刺内完成。
2. 存在较大的无法按时交付甚至永远无法交付的风险
   
   上图两条预测线，纵坐标轴的右侧没有交点，代表这个版本恐怕存在较大的交付风险，需要注意。如果发现版本无法可能无法交付的时候可以选择的策略，一般是增加开发的速率，或者是减少一些当前版本的故事点数，放到下一个版本中去。

8 Fist-of-five——举手表决

举手表决（Fist to five，fist of five）是敏捷软件开发团队用于调查团队成员并帮助达成一致意见的一种技术。使用举手表决技术，Scrum Master或PO重申该团队也许会采取的行为，并要求团队成员展示他们的支持级别。每个团队成员通过举起紧握的拳头或竖起对应支持级别的手指数来回应。如果一个团队成员举起的手指少于3，他有机会陈述其反对意见，团队会给出回应。Scrum Master或PO继续举手表决过程直到达成一致意见（每个人都举起的手指都不小于3）或同意转移到下一话题。

• 紧握拳头：不，我完全不同意。
• 1根手指：我非常担心。
• 2根手指：我想讨论一些小问题。
• 3根手指：我不完全同意但我可以接受意见通过而不须进一步讨论。
• 4根手指：我认为想法不错且愿意为其工作。
• 5根手指：想法棒极了，执行时我愿意带头。

9 需求空间、开发空间和测试空间

通常，一个项目的开发过程，可以通过3个空间来进行表达：需求空间、开发空间和QA测试空间。3个空间相互间应当是完全整合的，使得整个团队的不同职能能够相互协作。其中：

1. 需求空间：存放、描述项目所有待实现的需求，表现为Product Backlog，由PO主导并管理，所有团队成员参与梳理。
2. 开发空间：包含项目正在开发实现的所有事项，表现为Sprint Backlog和Scrum Board，由Scrum Master主导和管理。
3. 测试空间：管理项目的测试计划和测试用例，是项目的一系列质量目标和验收标准，由QA主导管理。当Sprint开始后，QA根据User Story编写对应的测试用例，加入QA空间；当开发人员提交到To QA后，QA根据测试用例执行测试，反馈测试结果。此外，还包括其他不同级别的测试计划和用例。

未经允许不得转载：Leafer » 敏捷项目管理的基本概念