Continuous integration Scrum/敏捷：您如何计划内部改进？

在过去的两年中，我已经在两个使用敏捷/Scrum方法的不同团队中工作过，这两个团队都渴望改进他们进行软件开发的方式。在第一个团队中，我们可以很容易地说服我们的产品负责人为内部事务争取时间，如改进构建系统、设置更好的集成测试、制定更好的发布策略等。现在PO也愿意给我们时间，但他更愿意后退，这是合理的，因为他也必须完成他的工作

---

不管怎样，我现在的问题是，其他团队如何处理这个问题？您是否创建了一个改进故事并在规划期间将其放在桌面上，或者您是否为这些事情保留了一段“时间”？根据您的经验，说服产品负责人争取时间进行改进有多困难？在所有这些改进之后，团队将受益，但prodcut所有者/企业不会直接或立即受益。

我会使用“钉子”来解决这些问题。内部/流程改进不可能是一个用户故事，但它会成为一个完美的尖峰。

改进应该是sprint的一部分，就像新功能一样。由团队向产品所有者证明这些改进对于即将到来的sprint是必要的。这可能会减慢新特性的生成速度，但最终对产品是有用的

---

另一方面，我对只包含改进的sprint有一些问题。每个sprint都应该产生可以向产品所有者演示的输出。

将反射车间的概念作为调整开发过程的一种手段。团队定期开会（可能比您的开发周期要少），讨论流程的改进和状态。想出我们这次尝试过的0-3件有效的事情，我们会坚持下去，1-3件不起作用的事情，还有1-3件下次尝试的事情。这个想法是在过程和产品上都有渐进的改进。

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

我们每周五见面，只是讨论什么有效，什么无效。我们会把它们写在两张大纸上（他真的很喜欢纸&画架而不是白板，因为它更持久，更容易重新定位）

工作起来可能很简单——我们作为一个团队互动良好，配对顺利，等等

那些不起作用的事情同样简单和随机。有些人可能会抵制裁员，甚至“老板没有像承诺的那样带我们上船”

每周我们都会重温过去的“不工作”，看看我们是否修复了它们——如果是的话，它们将一直列在本周的“做了工作”专栏中

虽然我们会讨论具体的解决方案，但仅仅公开问题往往会产生非常积极的效果。如果他们在“不起作用”列表上停留3或4周，我们将讨论不同/更好的解决方案，并更仔细地尝试实施这些解决方案

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

---

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

好问题。我认为回顾中有几种不同的“行动项目”值得采用不同的方法

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

2） 流程改进（例如，“人们不能按时到场……让我们在有人迟到时开始一美元的慈善捐款”。）

第一类可以是重要的工作，也可以是简单的工作。我展示的例子很简单。。。但可能会生成需要计划的其他任务（例如，删除发现数据库调用的5个位置中的数据库调用）

第二类应该由迭代经理、项目经理、scrum经理等来处理/驱动。我（作为scrum大师或项目经理）通常在项目wiki上列出它们，并在回顾中讨论它们，在处理它们时检查它们，并向团队报告状态。我把火一直点着

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

我们还需要对技术任务进行细分和优先排序（例如，也许“更好的集成测试”可以从定义当前集成覆盖率的技术任务开始，或者评估可能被归咎于集成失败的bug的百分比，以构建投资案例

一旦您确定了优先级，您就可以传达高优先级项目的价值，并与产品负责人协商在这些项目上花费的时间。我不太喜欢在任何事情上花费预定义的费用……但与产品负责人就清晰的要求、投资回报率和验收标准进行对话是关键。

不，一个不应创建技术用户故事：理论上，由于它们通常不会给客户带来直接价值，因此在迭代中选择它们的机会非常少。说服产品所有者是缓解这一问题的一种选择，但我