敏捷团队 Jira 管理最佳实践

作为 After Digital 团队的敏捷教练及之前的角色（如：“消除障碍”），我处在开发团队和产品团队之间，他们有各自的优先级。但是，清晰的流程和好工具能够很大程度地缓解这种不平衡，进而提高生产力和生产效率。

在过去的一些年里，我听到了以下这些困扰：

.我在被项目经理催着更新进度，但是今天还有很多开发工作要完成；

.我不知道 TA 的这些工作完成到哪里了，所以我需要更新以便同步给客户；

.我感觉自己在这个项目中被“微管理”了；

.在 Sprint Review 前，我们能否找点时间看下是否偏离了 Sprint 目标？

.我担心没有足够时间来完成这个任务，感觉是无法实现的“截止日期”。.

这一切都是合理的担心，并且经常在组织中看到。 这些问题除了都与沟通有关外，还有一个共同点：在我的经历中，当我们恰当地使用 Jira时，这些问题都不复存在了。

爱因斯坦在这个引用里概括了敏捷实践的本质：“Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning.”

作为一个敏捷的企业，我们的目标是不断地迭代和改进。但是，要做到这一点，我们需要使用对工作最有效的工具。这就是为什么我喜欢 Jira 的原因。

也许你没使用 Jira ，而使用其他工具跟踪数字化开发工作。这也是 OK 的，但是下面这些技巧也是有用的（虽然我是一个忠实的敏捷主义者，敏捷和 Jira 的搭配就像豆子配土司），它们会帮助你充分利用你的工具，并确保你在“敏捷游戏”中处于领先地位。

创建良好的用户故事：比如：项目经理添加用户故事，开发团队对其拆分任务，直到这些任务能够解释如何实现这个故事：

用户故事及与之关联的任务：如果做得好，它们能作为项目最好的技术规范，也能鉴别出需求收集阶段的空白，这些空白可能变成整个故事的阻塞，使得故事不够完整，进而被放到积压工作的最后。

好的用户故事及与之关联的技术任务能够减少信息的分散，让所有信息都放在同一个地方。这能让其他成员有信心认为：完成任务所需的信息已经足够，从而敢于认领一开始没有打算由他来做的任务。

总是提供估算：总是估算任何进入 Sprint 的内容，且在执行过程中更新估算。这有助于看到他们如何跟踪 Sprint 的目标。记住，你总是会做“估算”。

使用过滤器进行改善：Jira 简化了不同的过滤方式，用户可以创建定制的仪表盘和项目视图。这是个很有用的技巧，特别当你同时参与多个项目，并且在为如何排列你的任务优先级而困扰的时候。避免注意力分散，从创建你自己的“问题”、“阻塞项”、“关键项”和“高优先级项”或“必须修复项”的过滤器作为开始吧！

使用“备注”来更新 Ticket 和其他团队成员：创建一个清晰的 Ticket 记录可以减少项目经理“不断要更新”的需求。如果 Jira Ticket 能定期更新，包含相关备注信息，且明确了每个任务，那么你就不再需要让项目经理追着你更新任务了，我们跟踪 Sprint 目标的方式随之清晰可见。

为开发人员和设计师附加尽量多的信息：一个 Ticket 的信息越多越好。将任何有阻塞的工作项重新指派给你的项目经理，并增加一个"阻塞旗子"，直到你得到了完成该任务所需的帮助。另外，向你的敏捷教练指出比较差的 Ticket 管理 Case ，他们的任务是停止这个情况继续下去。

确保你有一个清晰的“完成”定义：这应该在 Sprint 计划内作为 Sprint 目标加以说明。“已完成”（ DoD：Definition of done ）是一个清晰且简明的需求列表，项目输出物必须遵守该团队称之为完成的要求。通常，DoD 适用于积压工作里的所有条目，“验收标准”涉及到特定的用户故事。为了完成这个故事，DoD 和验收标准都必须满足。只有这样，我们才能将该故事移动到“已完成“栏中。

建立一个现实的 Sprint 目标：在你开始 Sprint 计划时，你应该有一个 Sprint 目标。待办事项的梳理和拖到新 Sprint 中的任务都要满足这个目标。这应该给团队一个现实的视角，让他们感受到能在这个 Sprint 中完成什么样的目标。

当你准备做某个 Ticket 时，将其移动到“进行”中（并把它作为承诺），让你的项目经理和敏捷教练知道如何跟踪 Sprint 目标，他们负责保持燃尽图和速度报表看起来不错。

如果一个团队中有一个以上的成员时，在”待办”栏中的任何内容都应该被将看作是一个“公平的游戏”。所以，一旦做出决定，你的意图就应该被识别出来，而不是过了几个小时后再开始做它，这时其他成员很可能也在做同一个任务。

一旦对时间有顾虑时，你就应该给问题（ Jira Issues ）做个“标记”，而不要等到截止日期或阻塞发生时再标记。如果这些问题能被快速打上“标记”，你的敏捷教练可以很快地介入处理，这样可以最小化项目风险。没有什么比“在 Sprint 评审或计划时发现一些无法完成的事情刚刚被标记”让敏捷教练更沮丧的了。

开发团队应该对 Sprint 负责：他们应该主导 Sprint 计划环节，对 Sprint 目标、待办列表的梳理给与充分的输入，当然这取决于他们有多么想提高工作效率。

致力于持续做积压工作的梳理：有必要跟踪整个项目，产品负责人和其他成员需要 Review 积压工作，以确保积压工作包含合适的条目，它们应该是排过优先级的，且在积压工作最顶层的条目是准备交付的。

创建一个可视化的物理看板：让你的看板对所有人清晰可见，在理想情况下，将打印的 Tickets 贴到墙上，物理看板会比电子看板更难让大家忘记 Sprint 任务。

从心理学角度看，移动物理的 Tickets 比虚拟的 Tickets 更有助于赋能一个开发团队，它激励着大家像玩游戏一样向 Sprint 目标前进。

使用优先级别：Jira 提供的标准图标都很相似，所以，要么减少优先级个数，以便最显著的优先级被快速且高效地使用和识别，要么 Jira 确实允许你上传或导入你自己的图标，所以你可以更具创造性。

使用一个容易识别的个人资料图片：这听起来很愚蠢，但当你有一个疯狂且繁忙的积压工作，且多人工作在同一项目上时，如果能认出你的团队成员，那么你将很容易找到、移动或修改他们的 Tickets 。例如：下面这个企鹅是我（我是一个爱企鹅的极客，所以这很适合我）。

一旦做出决定，你的意图应该被标识出来，而不是再等几小时，等到其他成员也开始做同样的任务。

关注重复项：当客户能访问 Jira 时，这点尤其会成为问题。你可以让客户通过单点联系人将 Bug 等内容录入到 Jira 中来避免重复。你的敏捷教练也应该密切关注所有 Jira 活动，以“保持卫生”。

Jira 可能不适合所有人，但是在我们这里是一个必不可少的工具。如果想打造一个真正有效的敏捷团队，那么你需要建立最适合你的工具和流程，并没有一个工具和流程适合各种情况。但是，我希望通过上面技巧的介绍，你可以像我们一样享受敏捷，同时提高生产力。