依托TAPD的敏捷实践

源起

在互联网浪潮下，不可能一直墨守成规，保持一成不变的项目管理方法。在公司的飞速发展研发队伍不断壮大的情况下，对项目经理的管理方法提出了新的要求和挑战。在对既定的整体项目流程无法作出进一步优化和改革时，首先想到了敏捷转型。在各方的支持下，迎来了敏捷教练，在敏捷教练的带领下积极学习敏捷理论并进行了相互学习和交流后开始了敏捷试点。于是有了后面的故事，让小编给你娓娓道来。

敏捷实践之迭代

需求梳理

需求梳理的目的是确保产品待办列表（Product Backlog）顶部的需求已准备好排入下一个迭代。包括需求的增删改查、估算、调整优先级等，以便更适合排入迭代。

Tapd 的需求板块可以用来管理产品待办列表；需求优先级通过“优先级”字段进行排序。我们把一个季度要做的事情放在需求池里，通过优先级进行区分事项的优先级。

这个阶段的时间盒我们大概控制在1-2小时（双周迭代）；出席的人有项目成员（这里指部门内参与试点的项目经理们），PO（这里特指部门负责人），SM（这里指大家推举的迭代跟进人）；
本阶段的输出物是：

• 我们梳理后的待办列表。

迭代计划

Sprint 计划用来从产品待办列表中选择下一 Sprint 中要做的工作，并就工作如何交付增量达成一致。

我们在 Tapd 迭代板块创建好迭代，然后在需求池里直接可以把需求分配到迭代里。是不是很简单，有没有发现新大陆的感觉。也可以从迭代里去进行规划需求，这里就不多描述了，毕竟我们不是来介绍 Tapd 怎么用的。

规划好之后我们就可以在迭代模块里看到每个迭代，并可以看到每个迭代里需求。

这个阶段的时间盒我们不超过4个小时；出席的人有项目成员（这里指部门内参与试点的项目经理们），PO（这里特指部门负责人），SM（这里指大家推举的迭代跟进人）；

本阶段的输出物是：

• • 更新后的待办列表（整个需求池）

  • 迭代目标：在当前Sprint中实现的目标；

  • 迭代待办列表：预计可在当前迭代中交付的待办事项。

  • 拆分后的任务：待办事项由团队成员拆分为任务。

  • 完成定义（DoD，Definition of Done）：这是一个检查清单，当一个待办事项被称作“完成”时，可以使用这份清单来确实工作是否完成。

每日站会

每日站会是一个简短的、团队成员同步工作、寻求协作的每日事件。

每日站会本来应该有个任务板，最好是线下物理看板，但是因为不可抗力大家经常居家办公就没有启用物理看板；想使用 Tapd 在线看板，但是 Tapd 目前的看板和需求是没有对应关系，要用 Tapd 的看板就要重新去创建看板上的任务，出于工作量考虑，我们前期没有引入在线看板。所以我们直接通过迭代里的高级筛选按人把需求任务筛选出来，然后每个人快速过下各自的内容。

 这个阶段的时间盒我们不超过15分钟；出席的人有项目成员（这里指部门内参与试点的项目经理们），PO（这里特指部门负责人），SM（这里指大家推举的迭代跟进人）；

本阶段的输出物是：

• 更新后的迭代任务列表
• 障碍/风险列表：并非所有问题都可以在站会上立即解决，障碍/风险列表在这里有助于跟踪在每日站会中提出的问题。

迭代评审

迭代评审是用来检视所交付的增量并按需调整待办列表的事件。

迭代评审需要的输入物是满足 DoD 的需求列表，在评审开始时，我们会通过迭代清单展示本次已完成的需求以及迭代目标。

 在迭代评审结束后，有可能需要对待办事项列表进行更新，也有可能会产生下一个新的优化事项。PO（这里特指部门负责人）就会把待跟进项录到TAPD需求池里，这些基本会安排在下个迭代进行跟进。

这个阶段的时间盒我们不超过2个小时；出席的人有项目成员（这里指部门内参与试点的项目经理们），PO（这里特指部门负责人），SM（这里指大家推举的迭代跟进人）；

本阶段的输出物是：

• 更新后的待办列表：根据迭代评审会上反馈，PO会将潜在的需求搜集起来，它将为下一个迭代提供可能的待办列表项。

迭代回顾

迭代回顾是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。

迭代回顾需要的输入物我们基本上是通过 Tapd 里的数据来收集和分析得到的；比如迭代完成的需求数、需求完成率、完成的工时点数（你可以理解等同于故事点数），任务完成的趋势图，每个成员的任务跟踪，需求个数燃尽图工时燃尽图等数据或者进度图。下面拿燃尽图示例。

工时燃尽图：

需求个数燃尽图：

 这个阶段的时间盒我们不超过3个小时；出席的人有项目成员（这里指部门内参与试点的项目经理们），PO（这里特指部门负责人），SM（这里指大家推举的迭代跟进人）；

本阶段的输出物是：

• 团队将对其工作方式进行的改进列表。
• 行动项：在回顾会中确定改进并制定计划以实施这些改进。

上述的迭代，我们循环执行了十几次，当然也做十几次的回顾会，我们基本都是通过经典三问题模型（1. 在这个迭代里，什么事情做的不错可以继续保持？2. 什么事情做的不好，需要避免？3. 还有哪些方面可以改进？）进行回顾。在后期我们也尝试了其他模型，比如帆船模型、海星模型等，这里对这些模型就不做赘述。

在前几个迭代的回顾会上我们团队成员都积极思考，踊跃发言，每次经典三问题都所获满满，同时也制定了2-3个改进的行动项在下个迭代进行跟进。有意思的是到了十次之后回顾会上大家犹如江郎才尽，大家提出的问题和建议寥寥无几。对以上的现象我们进行一些分析思考，得出主要原因有：

1. 前面的很多问题都反馈和提出来了；
2. 再者是因为我们迭代的内容不是开发一个产品而是对我们项目管理部一个季度要完成的事项，这可能是后期大家不能再提更多建议的原因之一；
3. 还有可能因为迭代已经跑的比较顺利了，大家形成惯性了，就没有什么问题提出，或者有些问题无法解决，也就不再提了。

在循环迭代过程中，我们发现在执行周期中各个成员需要处理很多不确定的工作（这可能项目经理工作的特性吧）。这时我们就想到了是否开始试下看板方式，经过调研之后我们觉得看板挺适合我们，于是我们开始了尝试引入看板。

敏捷实践之引入看板

看板VS迭代

看板和迭代两者差异之处在于看板方法是连续不间断的而迭代是不断重复一个流程，所以看板更适合那些在执行周期中处理很多不确定的工作团队。在 Tapd 里看板和迭代是两个完全隔离的功能，没有交集，迭代的需求池是不能和看板共用。那么，如何把看板和迭代结合？

迭代引入看板

我们的看板使用的很简洁，就三个状态：待处理、进行中、已完成。下面且看我们是怎么执行的。

我们首先进行需求梳理，迭代计划，这些是和需求梳理和迭代计划是一样的。我们不同的是把看板引入到的每日站会里，因为Tapd看板和需求池是不相通的，基于这个点，我们的策略是把迭代里的需求进行拆分，每个需求事件拆出若干个任务，并且每个任务必须有一个跟进负责人，拆完之后录到看板上。站会期间我们投屏对着在线看板进行，任务状态可以通过拖拽，并且可以直接在任务上进行备注情况，站会过程简单高效。站会结束后，负责人负责把进度汇总到迭代需求里。

对于看板，很多做过敏捷实践的教练都建议最好是有线下物理看板，并且项目成员最好集中办公，但是目前在受疫情影响的情况下，很多人会出居家办公的情况，在线看板个人认为是大势所趋了。

言归正传，每日站会后就是我们的迭代评审和迭代回顾，这两个阶段大致和迭代评审以及迭代回顾一致，不一样的是看板可以給迭代回顾提供更多的数据统计。如下 Tapd 的看板可以提供的统计内容，当然你也可以把看板内容导出自行分析。

结语

对于 Tapd 工具的功能和流程设计，可有些地方不能契合部分使用场景。但是工具是死的，人是活的，我们都知道没有一个工具能够迎合所有场景，这就是所谓的众口难调吧。思考如何把工具结合实际场景进行应用是每个使用工具的人深入了解工具的必经之路。毕竟平台型工具不是迎合一个人的习惯而实现的，当然实在无法结合就寻找其他的工具，不能在一棵树上吊死。

就我们的敏捷实践案例而言，总结了几个敏捷推广成功的必要条件，谨代表个人见解：

1. 团队的领导愿意学习并支持敏捷，部门Leader的OKR至少要有个是与成功推广敏捷实践相关。
2. 团队成员应长期固定合作，而不是为特定项目临时组成。
3. 团队成员愿意学习和尝试敏捷。

有些人会认为做敏捷的要求怎么这么高！其实要求说高也不高，就是要至上而下的支持敏捷和了解敏捷，敏捷学习可以培训，入门不难。如果团队不学习和不支持敏捷，那说明你们没有做好转敏捷的准备。不是所有团队都适合敏捷，不能赶鸭子上架，不然只能是事倍功半的效果收场，打击推广敏捷的信心，要理性的思考和分析后再试点。以上的经验希望对大家有所帮助。

转载：依托TAPD的敏捷实践