敏捷项目管理流程及工具

​

在了解敏捷项目管理之前，我们先看下敏捷和传统项目管理有什么区别。

传统项目管理：阶段式项目管理模式。

制定详细的计划和步骤，按计划执行，直到所有的计划执行全部结束。

 敏捷项目管理模式，从愿景和高价值的目标出发，它将整个项目过程拆分为若干个迭代，每个迭代交付一个完整可交付的功能，小步快跑，不断确认和调整，到目标达成结束。

敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。

​

敏捷的背景

•20 世纪 90 年代初，一些轻量级的软件开发方法越来越受到公众的关注，这些方法包括：

•1991, Rapid Application Development（RAD）

•1994 Dynamic systems development method (DSDM);

•1995, Scrum

•1996, Crystal Clear ，Extreme Programming (XP)

•1997, Feature-driven development（FDD）

•这些方法论强调了开发团队和业务干系人之间的密切合作；商业价值频繁交付；紧密合作的自组织团队，以及代码匠艺、验证和交付代码的巧妙方法。

•2001 年，17 位软件开发人员（大牛）聚集在犹他州的 Snowbird，讨论他们的共同想法和各种软件开发方法。经过讨论他们达成了在价值观和原则的共识，并共同发布了敏捷软件开发宣言和相应的十二条原则，宣告了敏捷开发运动的开始。

•会议之后，敏捷联盟成立，鼓励业界从业者进一步探索和分享想法和经验。

敏捷软件开发宣言：

我们一直在实践中探寻更好的软件开发方法，身体力行，同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具

 可工作的软件 高于 详尽的文档

客户合作 高于 合同谈判

响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷开发十二原则：

1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。 

2. 拥抱变化——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

4. 项目过程中，业务人员与开发人员必须在一起工作。

5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能

  够完成任务。

6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。 

7. 可用的软件是衡量进度的主要指标。

8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持

恒久稳定的进展速度。 

9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。 

10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。 

11. 最佳的架构、需求和设计出自于自组织的团队。 

12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

什么是 Scrum

Scrum 是用于开发、交付和持续支持复杂产品的一个框架，是一个增量的、迭代的开发过程。

Scrum 起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。Scrum 目前已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶、学校、政府、市场、管理组织运营，以及几乎我们（作为个体和群体）日常生活中所使用的一切。

在这里总结一下 Scrum 的要点（以下信息来自：Scrum中文网）：

SCRUM 理论基础

透明性（Transparency）

过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些关键环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解。

例如：

• 所有参与者谈及过程时都必须使用统一的术语。

• 负责完成工作和检视结果增量的人必须对“完成”的定义，有一致的理解。

检视（Inspection）

Scrum 的使用者必须经常检视 Scrum 的工件和完成 Sprint 目标的进展，以便发现不必要的差异。检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤勉地执行时，效果最佳。

适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。

SCRUM 框架

Scrum 框架包括 3 个角色、3 个工件、5 个事件、5 个价值：

3 个角色:

产品负责人（Product Owner）：Scrum Master 开发团队

3 个工件:

产品 Backlog（Product Backlog）SprintBacklog 产品增量（Increment）

什么是产品 backlog？产品 backlog 是一个按照价值排序的需求清单。为了达成产品目标，所有的需求都需要放到产品 backlog 中进行管理和规划。由产品负责人负责管理和维护。

什么是 Sprint Backlog？Sprint Backlog 是当前 Sprint 需要完成的产品 Backlog 条目，以及为了实现这些条目拆解出的任务。这些条目是从产品 Backlog 中挑选出的优先级最高的条目。

什么是产品增量？增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum 团队“完成”的定义的标准。增量是在 Sprint 结束时支持经验主义的可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。

5 个价值观：

承诺 – 愿意对目标做出承诺专注 – 把你的心思和能力都用到你承诺的工作上去开放 – Scrum 把项目中的一切开放给每个人看尊重 – 每个人都有他独特的背景和经验勇气 – 有勇气做出承诺，履行承诺，接受别人的尊重

5 个会议

• 产品 Backlog 梳理：

目的：对下个 Sprint 的需求进行需求细节梳理和精化，识别技术风险和依赖，完成估算和优先级排序。

• Sprint 计划会议

目的：1、确定 Sprint 目标和 DoD。2、确定 Sprint Backlog：用户故事、任务拆分。3、识别 Sprint 中的问题和风险，确定应对措施。

• 每日站会

目的：1、回顾昨天团队目标和每个人的任务的完成情况。2、明确今天的团队目标和每个人的任务。3、识别障碍和问题。

• Sprint 评审会

目的：向 PO 和干系人演示已经完成的用户故事，获得干系人的反馈，并确定已经达到可上线标准的用户故事

• Sprint 回顾

目的：识别本 Sprint 的开发过程中存在的工作方式、方法问题，并确定下迭代改进计划。

Scrum 敏捷开发工具

Scrum 中非常强调公开、透明、直接有效的沟通，这也是“可视化的管理工具”在敏捷开发中如此重要的原因之一。通过“可视化的管理工具”让所有人直观的看到需求，故事，任务之间的流转状态，可以使团队成员更加快速适应敏捷开发流程。

所以，有敏捷工具的支撑是非常必要。

Leangoo 基于 Scrum 框架提供了一系列的流程和模板，可以帮助敏捷团队快速启动 Scrum 敏捷开发。

这里可以介绍一下在 scrum 中单团队敏捷开发如何管理，单团队敏捷开发主要是针对 10-15 人以下，只有一个 Scrum 团队的小型产品或项目的敏捷开发

首先创建一个产品路线图

产品路线图是一个高层次的战略计划，它描述了产品在未来一段时间可能会如何发展和壮大。

•产品路线图确保整个产品团队持续关注产品的目标，帮助产品负责人把握产品的战略方向，调整产品的优先级和产品规划。

•里程碑是产品路线图上达成产品愿景的一个个阶段性目标，产品路线图上包括了多个里程碑 。

​

里程碑规划

•史诗故事通常都是比较大的故事，所以我们需要将史诗故事规划到产品 Backlog 中，以便让团队在产品 Backlog 中对史诗故事进行拆分，将其拆解为更小的用户故事，从而让团队在后续的 Sprint 迭代中去逐步完成。

•建议团队为每个里程碑创建一个对应的产品 Backlog，以便可以更好的在一个较小的产品 Backlog 内围绕当前里程碑史诗故事进行用户故事拆分和 Sprint 规划

•点击“里程碑规划”按钮，打开里程碑规划弹框，将“里程碑 1”列表内的史诗故事拖拽至“里程碑 1-产品 Backlog”内，这样这些史诗故事便会被引用到产品 Backlog 看板内，即完成里程碑规划。

​

在产品 Backlog 中进行用户故事拆分 

•里程碑规划完成后，点击进入“里程碑 1-产品 Backlog”看板

•在里程碑看板中，我们已经将史诗故事通过规划的方式引入并放置在独立泳道内，用泳道横向对应用户故事拆分的任务。

•团队将这些史诗故事进行拆分，拆解成更小的用户故事，然后准备进行后续 Sprint 规划。

​

用户故事梳理

•用户故事拆解完成后，团队可以对优先级较高的用户故事进行梳理。可以将完成用户故事需要的任务项添加到卡片内的检查项中，以便后续用户故事规划到 Sprint 中后，方面拆解成更小的任务卡片。

•通过列表流转，让团队直观的了解需求的优先级和规划安排

 迭代规划

•迭代开始前，我们需要将已梳理完成且优先级高的用户故事规划到迭代看板内，以便准备迭代中需要完成的内容。

•迭代规划前，团队需要对将要做的用户故事进行估算并添加工作量，然后大家根据过往的团队速度来决定迭代需要完成多少工作量的故事。

•点击“Sprint 规划”按钮，将计划在“Sprint1”内做的用户故事拖拽到“Sprint1”看板内。

​

缺陷管理

•在 Sprint 冲刺过程中，我们不仅需要做相关用户故事，也需要解决这过程中出现的缺陷问题。所以，我们可以用一个缺陷类型的看板来管理日常产生的缺陷，然后在 Sprint 规划时，也将缺陷规划到 Sprint。

•当前迭代的缺陷，建议放到当前迭代的迭代看板上，在迭代结束前修复完成。

•“缺陷看板”通常存放发布后遗留的缺陷，客户反馈的缺陷等。

•打开任务卡片可记录缺陷的详细信息

•打开缺陷任务卡片，可关联需求或文件等

​

 Sprint 执行

•Sprint 规划完成后，点击进入 Sprint1 看板，我们可以看到上一步已规划的用户故事已分别放置在独立泳道中，泳道可横向对应用户故事和拆分的任务。

•Sprint 开始后，团队根据这些用户故事相关信息（比如检查项、描述内的信息），将其拆解为更小的任务，然后大家各自领取开发。•

通过列表流转，体现任务的进展及完成情况。

​

Sprint 回顾

在敏捷开发中，我们每个迭代团队都会开回顾会议，这时团队可以将回顾的事项放到 Sprint 回顾 看板内，然后在后续的 Sprint 迭代中保持高效协作的同时、逐步解决需要改进的问题。 

​

查看迭代进度

每个迭代类型看板中都有一个重要的 Sprint 进度统计 – 燃尽图。

燃尽图是 Scrum 中的一个简单实用的团队进展跟踪的工具，能形象地展示当前迭代中的剩余工作量和剩余工作时间的变化趋势，一般在每日站会时团队会通过燃尽图来了解当前 Sprint 冲刺速度情况。

​

迭代完成率

迭代完成率是统计项目内每个迭代看板的完成情况。

配置好看板周期和燃尽图，Leangoo 会自动统计每个迭代看板的完成情况，并且自动生成可视化统计图表，以便管理层可以一目了然的看到每个迭代完成进度。

​

查看团队速率

团队速率是 Scrum 团队在一个 Sprint 中实际完成的工作量（通常使用故事点作为团队速度的单位）。

每个 Sprint 结束后，Leangoo 会自动记录当前 Sprint 完成的工作量，并且自动生成团队速率的可视化统计图表，以便团队可以了解团队效率变化的趋势并进行分析。 

​

查看看板任务分布

Scrum 团队是一个自组织的团队，团队每天的目标和工作安排由团队讨论决定。

通过任务分布统计帮助团队快速直观的了解团队成员每个人负责的工作负荷及工作进展状态，帮助团队进行更高效的协作。

查看缺陷分布

缺陷分布统计可以通过不同维度(工作量、卡片数)展现项目中缺陷看板内每个列表下的任务分布情况 

​

查看测试用例分布

测试用例分布可以通过不同维度(工作量、任务数)展现项目中测试计划看板内的任务分布情况。

​

产品 Backlog 进度统计

根据看板周期、燃尽图配置信息，统计项目下产品 Backlog 看板进度

​

成员任务数量统计

成员任务数量统计是统计项目成员在该项目中的所有看板中的任务分布情况 

​

成员项目工作占比

成员项目工作占比统计项目中每个成员在该项目所占比重。（可手动调整项目占比）

​

项目成员及权限管理

项目内成员可统一管理，可直接从企业内将成员导入项目，为项目设置项目角色、设置项目占比、查看成员参与项目数量及成员所在项目等。

​

项目文件管理

Leangoo 中提供了文件存储，便于团队沉淀经验、共享资源。

•多人共享项目文件

•实时同步上传

•支持文档、图片、视频等资料上传

•可深度关联工作任务，看板中打开任务卡片，可关联文档。

​

卡片 ID

为了能更好的分配任务、查找任务以及快速定位某个任务卡片，Leangoo 提供了卡片 ID，在项目页面直接开启即可。

​

项目共享脑图

在项目内除了可以创建多个任务看板之外，也可以创建多个共享脑图，可以用来做多级需求分解等。

​

脑图节点

Leangoo 脑图的每个节点可以打开，和看板上的卡片一样，可以为节点添加成员、附件、标签、开始截止时间等，高效共享协作。

​