敏捷团队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。例如：下面这个企鹅是我（我是一个爱企鹅的极客，所以这很适合我）。

Open

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

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

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

备注：感谢田莹在本文翻译中给予的帮助和建议。