好问题。我认为回顾展中有几种“行动项目”值得采用不同的方法。
1) 解决技术债务或基础设施改进等问题的技术任务——比如“我们应该确保我们的应用程序的视图层中没有数据库调用,因为这导致我们在过去的迭代中浪费了时间......有人应该做一个搜索代码以确保我们没有在其他地方这样做。”
2) 流程改进(例如,“人们没有准时参加站立会议......让我们开始为慈善捐款捐款 1 美元,只要有人迟到了”。)
第一类可能是重要的工作,也可能是直截了当的。我展示的示例非常简单……但可能会生成其他需要安排的任务(例如,删除发现它们的 5 个位置的数据库调用)。
第二类应该由迭代经理、项目经理、Scrum 经理等处理/驱动。我(作为 Scrum Master 或项目经理)通常将它们列在项目 wiki 上并在回顾中讨论它们,当它们出现时勾选它们'被解决,并向团队报告状态。我一直点燃火。
我认为第一类——技术任务——的错误在于我们没有定义验收标准。您的示例包括“改进构建系统、设置更好的集成测试、制定更好的发布策略”。这些是非确定性的,需要用清晰的术语进行枚举(必要时使用尖峰)。所以 - 改进构建系统可能会从技术任务或评估选项的尖峰开始。
我们还需要分解技术任务并确定优先级(例如,也许“更好的集成测试”可以从定义当前集成覆盖率的技术任务开始,或者评估可归咎于集成失败的错误百分比,以构建案例在那里投资。
一旦确定了优先级,您就可以传达高优先级项目的价值,并与产品负责人协商花费时间。我不喜欢花在任何东西上的预定义存储桶……但是与产品负责人进行明确的需求、投资回报率和验收标准的对话是关键。