在过去的两年里，我曾在两个使用敏捷/Scrum 方法的不同团队工作，两个团队都渴望改进他们处理软件开发的方式。在第一个团队中，我们可以很容易地说服我们的产品负责人花时间进行内部工作，例如改进构建系统、设置更好的集成测试、制定更好的发布策略等。现在 PO 也愿意给我们时间，但是他更加推后，这是合理的，因为他也必须完成他的事情。
无论如何，我现在的问题是，其他团队如何处理这个问题？您是否创建了一个改进故事并在计划期间将其放在桌面上，或者您是否为此类事情保留“一桶”时间？根据您的经验，说服产品负责人花时间进行改进有多难？毕竟，所有这些改进都会使团队受益，但不会直接或立即使产品所有者/企业受益。
【问题讨论】：
标签： continuous-integration agile scrum
很好的问题。我认为回顾展中有几种“行动项目”值得采用不同的方法。
1) 解决技术债务或基础设施改进等问题的技术任务——比如“我们应该确保我们的应用程序的视图层中没有数据库调用，因为这导致我们在过去的迭代中浪费了时间......有人应该对代码进行搜索，以确保我们没有在其他地方这样做。”
2) 流程改进（例如，“人们没有准时参加站立会议......让我们开始为慈善捐款 1 美元，只要有人迟到”。）
第一类可能是重要的工作，也可能是直截了当的。我展示的示例非常简单……但可能会生成其他需要安排的任务（例如，删除发现它们的 5 个位置的数据库调用）。
第二类应该由迭代经理、项目经理、Scrum 经理等处理/驱动。我（作为 Scrum Master 或项目经理）通常将它们列在项目 wiki 上并在回顾中讨论它们，检查它们当他们被解决时关闭，并向团队报告状态。我一直把火点着。
我认为第一类——技术任务——的错误在于我们没有定义验收标准。您的示例包括“改进构建系统、设置更好的集成测试、制定更好的发布策略”。这些是非确定性的，需要用清晰的术语进行枚举（必要时使用尖峰）。所以 - 改进构建系统可能会从技术任务或评估选项的尖峰开始。
我们还需要分解技术任务并确定优先级（例如，“更好的集成测试”可以从定义当前集成覆盖率的技术任务开始，或者评估可归咎于集成失败的错误百分比构建在那里投资的理由。
一旦确定了优先级，您就可以传达高优先级项目的价值，并与产品负责人协商花费时间。我不喜欢花在任何东西上的预定义存储桶...但是与产品负责人进行对话以明确要求、投资回报率和验收标准是关键。
【讨论】：
改进应该是冲刺的一部分，就像新功能一样。团队有责任向产品负责人证明这些改进对于即将到来的 sprint 是必要的。这可能会减慢新功能的产生速度，但最终对产品很有用。
另一方面，我对仅包含改进的 sprint 有疑问。每个 sprint 都应该产生可以向产品负责人展示的输出。
【讨论】：
Crystal Methods 将反思研讨会的概念作为调整开发过程的一种手段。团队定期开会（可能比您的开发周期少）讨论流程的改进和状态。想出我们这次尝试的 0-3 项有效的东西，我们会保留，1-3 项无效的东西，以及下次尝试的 1-3 项。我们的想法是在流程和产品上进行渐进式改进。
【讨论】：
去年，我为最早的敏捷 (xp) 采用者/顾问/培训师之一工作。我认为他的方法很好。
我们每周五见面，只是讨论什么有效，什么无效。我们会将它们写在两张大纸上（他真的很喜欢纸和画架而不是白板，因为它更永久，更容易重新定位）。
有效的事情可能非常简单——我们作为一个团队进行了良好的互动，配对顺利等等。
不起作用的事情同样简单和随机。有些人可能会抗拒结对，甚至“老板没有按承诺带我们上船”。
每周我们还会回顾过去的“没用”，看看我们是否修复了它们——如果是这样，它们将始终列在这周的“没用”列中。
虽然我们会讨论具体的解决方案，但公开提出问题往往会产生非常积极的影响。如果它们在“不起作用”列表中停留 3 或 4 周，我们将讨论不同/更好的解决方案，并更加刻意地尝试实施它们。
在某个项目在“运行良好”列中停留一两个星期后，我们会删除它，因为它或多或少符合预期（除非它继续改进）。
这也让周五下午变得更有趣，因为这是一个每个人都可以参加的相当有趣的会议。
【讨论】：
我会使用“尖峰”来处理这些事情。内部/流程改进不能是用户故事，但它会成为一个完美的高峰。
【讨论】：
我在这里没有太多要补充的，但是我认为应该有专门的资源来解决这些与环境改善相关的问题，并且这些任务不应该包含在燃尽图上。如果它是该项目所需的额外硬件，那么它应该已经被添加并提前预算。所以最终这些不应该影响 Scrum 上的时间分配，但是任何因这些问题而受到影响的工作都应该说明理由。
【讨论】：
不，应该不创建技术用户故事：理论上，由于它们通常不会为客户带来直接价值，因此在迭代中被选中的机会很少。说服产品负责人是缓解这种情况的一种选择，但这里可以使用另一种工具：slack。
Slack 是您为这些改进任务留出的迭代时间的一小部分。如果迭代期间一切顺利，那么您将能够利用这段时间进行这些改进。另一方面，如果团队过度承诺迭代（或任务被低估，如预期的那样更难......），您将有另一个机会兑现您的承诺。
使用 slack 的另一个好处是，这将降低速度的变化，因为您可能会更频繁地履行承诺，而无需加班。
请参阅 Tom DeMarco Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency（亚马逊链接）- ISBN 0767907698。
【讨论】：