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