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

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

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

2)过程改进(例如,“人们没有按时到达停机位……每当有人迟到,我们就开始1美元的慈善捐赠。

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

第二个类别应该由迭代经理、项目经理、Scrum经理等处理/驱动。我(作为Scrum主管或项目经理)通常将它们列在项目wiki上,并回顾性地讨论它们,在它们被寻址时对它们进行检查,并向团队报告状态。我把火点着。

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

我们还需要分解和确定技术任务的优先级(例如,也许“更好的集成测试”可以从定义当前集成覆盖范围的技术任务开始,或者评估可能被归咎于集成失败的错误百分比,以便在那里构建投资案例。

一旦确定了优先级,就可以传达高优先级项目的价值,并与产品所有者协商,以便有时间花在这些项目上。我不喜欢预先定义好的桶花在任何事情上…但是,与产品所有者进行清晰的需求、投资回报率和接受标准的对话是关键。

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

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

Crystal Methods 将反射研讨会的概念作为调整开发过程的一种方法。团队定期开会(可能比开发周期少一些)讨论流程的改进和状态。提出我们这次尝试过的0-3件有用的和我们会保留的事情,1-3件不管用的事情,以及1-3件下次尝试的事情。我们的想法是在过程和产品上都有逐步的改进。

去年,我为最早的敏捷(XP)采纳者/顾问/培训师之一工作。我认为他有一个很好的方法。

我们每个星期五都会见面,只是讨论什么有效,什么无效。我们会把它们写在两张大纸上(他真正喜欢纸和画架,而不是白板,因为它更持久,更容易重新定位)。

工作的事情可能很简单——我们之间的互动很好,团队合作很顺利,等等。

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

每周我们都会回顾过去的“不工作”,看看我们是否解决了这些问题——如果是这样的话,它们将一直列在本周的“工作”列中。

尽管我们会讨论具体的解决方案,但将问题公开出来往往会产生非常积极的影响。如果他们在“不工作”列表上停留3或4周,我们将讨论不同/更好的解决方案,并更仔细地尝试实施它们。

当一个项目在“工作良好”栏中花费了一两周后,我们就会放弃它,因为它或多或少已经成为了预期(除非它继续改进)。

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

我会用一个“钉子”来做这样的事情。内部/流程改进不能是一个用户故事,但它会产生一个完美的峰值。

这里我没有什么可补充的,但是我觉得应该有一个专门的资源来处理这些与环境改善相关的问题,并且这些任务不应该包括在消耗图表中。如果它是这个项目所需的额外硬件,那么它应该是在高级中添加和预算的。因此,最终这些不应该影响Scrum上的时间分配,但是,由于这些问题而受影响的任何工作都应该考虑到合理性。

不,一个人应该 不 创建技术用户案例:理论上,由于它们通常不会给客户带来直接价值,所以在迭代中选择它们的机会非常少。说服产品所有者是缓解这种情况的一种选择,但这里还有另一个可以使用的工具:slack。

松弛是 小的 为这些改进任务留出的迭代时间的一部分。如果在迭代过程中一切都进展顺利,那么您将能够利用这段时间进行这些改进。另一方面,如果团队对迭代的过度投入(或者任务被低估,如预期的那样困难),您将有另一个机会实现您的承诺。

使用slack的另一个好处是,这将降低速度的变化,因为您可能更经常地履行承诺,而不需要加班。

请咨询Tom DeMarco Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency (亚马逊链接)-ISBN 0767907698。