Scrum / Agile：您如何计划内部改进？ [关闭]

Question

我现在已经在两个不同的团队中工作过，这两个团队在过去两年中使用了Agile / Scrum方法，两个团队都渴望改进他们处理软件开发的方式。在第一个团队中，我们可以轻松地说服我们的产品所有者花时间处理内部事务，例如改进构建系统，设置更好的集成测试，更好的发布策略等。现在PO也愿意给我们时间，但是他更加努力，这是合理的，因为他也必须完成他的事情。

无论如何我现在的问题是，其他团队如何处理这个问题？您是否创建了一个改进故事并在规划期间将其放在桌面上，或者您是否保留了“桶”信息。这些事情的时间到了吗？在您的体验中说服产品所有者有时间改进是多么困难？经过所有这些改进将使团队受益，但不会直接或立即产生所有者/业务。

Answer 1

好问题。我认为有几种风格的“行动项目”。从回顾中得出不同的方法。

1）解决技术债务或基础设施改进等问题的技术任务 - 比如“我们应该确保在我们的应用程序的视图层中没有数据库调用，因为这导致我们在过去的迭代中浪费时间......有人应该通过代码进行搜索，以确保我们不会在其他地方进行搜索。“

2）流程改进（例如“人们没有准时到达立场......每当有人迟到时，我们就可以为慈善捐赠开1美元”。）

第一类可能是重要的工作，也可能是直截了当的。我展示的示例非常简单......但可能会生成需要安排的其他任务（例如，在发现它们的5个位置删除数据库调用）。

第二类应该由迭代管理器，项目经理，Scrum管理员等处理/驱动。我（作为Scrum Master或项目经理）通常将它们列在项目wiki上并在回顾中讨论它们，检查它们当他们被解决时关闭，并向团队报告状态。我点火了。

我认为第一类中的错误 - 技术任务 - 是我们没有定义验收标准。您的示例包括“改进构建系统，设置更好的集成测试，具有更好的发布策略”。这些是非确定性的，需要用清晰的术语列举（必要时使用尖峰）。因此 - 改进构建系统可能从技术任务开始，也可能是峰值来评估选项。

我们还需要分解并确定技术任务的优先级（例如，可能“更好的集成测试”可以从定义当前集成覆盖率的技术任务开始，或者评估可能归咎于集成故障的错误的百分比。建立投资案例。

设置优先级后，您可以传达高优先级项目的价值，并与产品所有者协商花费时间。我不是花在任何事情上的预定义桶的忠实粉丝......但是与产品所有者的对话具有清晰的要求，投资回报率和验收标准是关键。

Answer 2

改进应该是sprint的一部分，与新功能相同。团队需要向产品负责人证明这些改进是即将到来的冲刺所必需的。这可能会降低新功能的生成速度，但最终会对产品有用。

另一方面，我遇到了仅包含改进的sprint问题。每个sprint都应该产生可以向产品负责人展示的输出。

Answer 3

Crystal Methods 将Reflection Workshop的概念作为一种手段调整你的开发过程。团队定期会面（可能比您的开发周期更少），以讨论流程的改进和状态。想出这次我们尝试过的0-3件事，我们会保留，1-3件不起作用的东西，以及下次要尝试的1-3件事。我们的想法是逐步改进流程和产品。

Answer 4

去年，我为最早的敏捷（xp）采用者/顾问/培训师之一工作过。我认为他有一个很好的方法。

我们每个星期五都会见，并讨论了哪些有效，哪些无效。我们会把它们写在两张大纸上（他真的是用纸和画架而不是白板，因为它更永久，可以更容易地重新定位）。

有用的东西可以很简单 - 我们作为一个团队很好地互动，配对顺利等等。

不起作用的事情同样简单随机。有些人可能会拒绝削减，甚至“老板没有按照承诺将我们带到他的船上”。

每周我们都会重温过去的“没有工作”。并看看我们是否修复了它们 - 如果是这样的话，它们将始终在本周列出“确实有效”。列。

虽然我们会讨论具体的解决方案，但只是公开解决这些问题往往会产生非常积极的影响。如果他们仍然在“没有工作”列出3或4周，我们将讨论不同/更好的解决方案，并更多地尝试实施它们。

项目在“工作良好”中花费一周或两周后专栏，我们放弃它，因为它或多或少已经预期（除非它继续改善）。

这也使周五下午更有趣，因为这是一个每个人都可以参加的相当有趣的会议。

Answer 5

我会用'尖峰'来做这些事情。内部/流程改进不可能是一个用户故事，但它会成为一个完美的峰值。

Answer 6

我没有太多要补充的内容，但是我觉得应该有一个专门针对这些环境改善相关问题的资源，这些任务不应该包含在烧毁图表中。如果它是该项目所需的额外硬件，那么它应该已经添加并预先编制预算。所以最终这些不应该影响scrum上的小时分配，但是由于这些问题而受到影响的任何工作都应该被认为是合理的。

Answer 7

不，一个人不创建技术用户故事：从理论上讲，由于它们通常不会给客户带来任何直接价值，因此他们很少有机会在迭代中被选中。说服产品负责人是一个减轻这种情况的选择，但还有另一种工具可以在这里使用：松弛。

Slack是为这些改进任务留出的迭代时间的小部分。如果在迭代期间一切顺利，那么您将能够利用这段时间进行这些改进。另一方面，如果团队过度承诺迭代（或任务被低估，更难按预期......），您将获得另一次机会来履行您的承诺。

使用松弛的另一个好处是，这会降低速度的变化，因为您可能会更频繁地履行您的承诺，而不会诉诸加班。

请参阅Tom DeMarco Slack：过去倦怠，忙碌和总神话效率（亚马逊链接） - ISBN 0767907698.