Scrum团队如何在计划会议中说明基础架构任务?


33

Scrum团队如何在计划会议中解决开发/基础架构任务?

乍一看,它们似乎不像用户故事,因为它们无法传递最终用户价值。

但是,将它们作为任务附加到特定用户故事有时也没有意义。例如,说任务是:“安装竹子”。不需要完成该任务即可完成任何用户案例,因为团队可以手动构建和部署。因此,将其附加到用户故事没有意义,因为不需要完成此任务即可完成用户故事。

因此,这表明这些任务成为了用户故事。但是,如果团队故事指向他们,那么这将改变速度,这是奇怪的,因为产品负责人想知道积压的速度,而不是积压了大量技术用户故事的积压速度。

Answers:


25

它们实际上不是用户故事。他们是利益相关者的故事。除非该软件实际上是由用户直接付费购买的,否则很少有故事完全是为了他们的利益而创建的。

我举几个例子:

  • 关键字文章,使广告客户可以获得更有效的广告
  • 验证码,可以阻止主持人手动处理垃圾邮件。

实际上,大多数技术案例都可以带来商业利益,但对于用户而言却很少。用不同的方式对它们进行措辞会有所帮助。我通常使用Chris Matts的功能注入模板:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

这明确认可了各种利益相关者,包括开发团队。现在,您也可以说出您的技术故事,并指出业务收益:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

我为此写了几篇博客文章:它们不是用户故事而是功能注入和处理技术故事。希望他们能帮上忙。


3
语义...恕我直言,这与敏捷哲学背道而驰;在没有任何其他实际价值的情况下添加所需的分隔,只有温暖的模糊感觉。
亚伦·麦克弗

5
您是从经验上讲还是从理论上讲?我之所以问,是因为我已经与许多团队一起使用了此模板,并且发现将目标放在首位确实有助于确定实现项目愿景所需的条件。Mike Cohn可以选择使用“这样”。我不相信。
鲁尼武尔2011年

1
我看到此模板有助于将要执行的技术任务的价值传达给非技术订单。“作为一名质量检查分析师,我需要一个连续的集成服务器,以便每天自动测试该应用程序”与“为了减少项目结束时所需的手动测试量,以及错误滑入生产阶段,作为质量检查团队,我们要测试连续集成服务器”。显示隐藏的业务将为OP提供足够的信息,以决定是否将其包括在内。
2011年

1
@Soronthar到哪里结束?“为了减少挫败感,作为一个开发团队,我们希望制定自己的规则”。这就是您一直专注于用户的原因之一,就是这样。任务应从采购订单中隐藏;因为采购订单不必担心这些细节。
亚伦·麦克弗

9
哦,以防万一还不清楚-我关心的是完成有用的工作,而不是Scrum。或精益。或BDD。我还认为,软件中最有用的工作与学习和管理风险有关。当方法论妨碍了进行有益的工作时,我倾向于进行有益的工作。
鲁尼武尔2011年

12

速度是衡量团队完成有用工作的能力的指标(与Drag相对)。通过长期提高团队效率,基础架构任务仍然可以间接地为最终用户带来价值。我毫无疑问地将这些事情作为用户故事进行跟踪(在这种情况下,用户就是开发团队)并适当地确定它们的优先级。与客户保持良好沟通的产品负责人应该能够确定这些任务可以放在哪里,而不会影响交付成果。


3
我认为对于团队来说,模糊对用户直接有价值的事物与希望提供间接价值的事物之间的区别是危险的。特别是,“我们喜欢的一切都是有价值的”方法鼓励开发人员在基础设施方面镀金和基础设施。我强烈建议人们只将具有直接业务价值的故事视为对速度的关注,因为这是客户要为现金支付的唯一内容。
威廉·皮特里

3
华尔兹熊。您所做的所有真正有价值的事情都是有价值的,因为以前没有人做过(否则,还有其他更便宜的实现方法)。我们所做的大部分有价值的工作都是学习如何做新事物。基础结构任务可帮助我们获得有关新事物的反馈,并更快地学习。如果可以帮助我们更快地学习,我会与@Kristo在一起。
鲁尼武尔(Lunivore)2011年

@Lunivore-区别在于没有人付钱给您学习。他们为您所做的学习付费。团队应该总是花一些时间来改善他们的工具和知识。但是将其视为速度会使它与团队要做的工作混淆。
威廉·皮特里

这不仅仅是关于工具和知识。阿什利·约翰逊(Ashley Johnson)的思想实验:考虑您所做的最后一个项目。想一想用相同的人,相同的要求,相同的技术,但学到了所有学到的知识后,再做一次需要多长时间。项目经理的报价大约占25%到33%-剩下的就是我们在软件项目中学到的知识。阅读Dan North在“故意发现”上的帖子:dannorth.net/2010/08/30/introducing-deliberate-discovery
Lunivore 2011年

11

逐步做。

如果没有利益相关者想要它,那就不要讲故事了。只需一点一点地照顾它。例如,第一次手动部署。第二次,您将其自动化。第三次,您可以实现更多自动化。最终,您的构建不是最大的问题,因此您将重点放在其他方面。

在一开始,您将有更多这些以开发人员为中心的任务,这很好。您的速度(按故事衡量)将更低。这是对情况的正确表示。但是您总会拥有一些东西,因此对于团队来说,养成做必要的事情以改进流程的习惯非常重要。


+1:第一次使用Spike解决方案,然后第二次将其重构为更好和更可靠的解决方案。
S.Lott

因此,如何确定以开发人员为中心的任务不会接管sprint,尤其是当您尚未建立良好的速度指标时?我不想错过早期交付的产品,因为我们花了太多时间在可以长期使用的东西上。
克里斯多(Kristo)

无论如何,您应该花时间进行常规思考并进行流程改进。
迈克尔

@Kristo,我认为您的客户/产品经理不会让您摆脱这个。即使没有确定的速度,您也将做出一个很好的猜测,并协商要为那些初速冲刺提供的价值。另外,如果您像@ S.Lott这样飙升,则建议您还是不要交付。
迈克尔

@Kristo:您可以确保逐步进行并定期进行反思。当您开始时,您所知道的就是您肯定做错了数量。每个星期,讨论您是否应该增加或减少基础架构,以及是否专注于最高价值的东西。这始终是一种平衡行为。
威廉·彼得里

6

恕我直言,理想的方法是将基础架构的工作作为任务,在它首先具有价值的用户故事下进行;正如您所提到的。

以你为榜样;手动构建和部署意味着这是一项持续的工作,没有完成的形式。它无限期地存在。

对于使以前手动完成的典型应用程序中的任何工作自动化的代码,也可以这样说。将这种努力定义为用户故事下的任务就可以定义完成;从本质上来说,这对最终用户具有价值。

您当然可以构建和部署每个sprint的应用程序,但是那将成为日常任务的一部分,而这些任务不会通过积压工作进行正式跟踪,因此所有这些都变得毫无意义。


感谢您的回答。最后,它阐明了应如何进行:“理想的方法是将基础架构工作作为首先具有价值的用户故事下的任务。”
伊戈尔·波波夫

实际上,此基础结构工作应该是“完成的定义”的一部分。
伊戈尔·波波夫

4

用户故事从用户角度定义了商务价值。因此,通常将任务视为“浪费”。这并不意味着他们不需要。这意味着执行更多基础架构任务将带来更少的业务价值。因此,不应将任务视为用户存储,也不应将其附加到任何用户故事中。

在计划会议上,团队必须考虑在下一个冲刺期间绝对必要的基础设施任务。承诺将在考虑这些基础结构任务的情况下完成。这将影响团队的速度,这是正确的结果,因为速度可以衡量团队可以交付多少业务价值。


2

我从未将用户故事等同于必须交付最终用户价值。这可能很常见,但不是我们如何处理用户故事。有时,这些类型的任务被认为是高峰,但是我们也有常规的用户案例,其估计点与其他任何用户案例一样。


一些团队以这种方式工作,但是这使得衡量交付价值变得更加困难。就个人而言,我建议团队仅创建具有商业价值的故事。(穗具有商业价值,因为产品人员正在购买有关未来期权及其成本的信息。)
William Pietri

但是什么是商业价值?它是一个广义术语,任何允许企业早/更好/等发布软件的内容对该企业都有价值。
安迪·维森丹格2011年

我要区分的是主要对团队具有直接价值的事物与主要对您实际上要服务的人员具有直接价值的事物之间的区别。我认为您应该仅将后者算作速度,因为这是最终重要的唯一值。通过提高长期速度来解决速度问题,以帮助改善价值创造。马上算出它会扭曲激励,并重复计算收益。
威廉·彼得里

2

从我所看到的来看,许多基础设施都被认为是既定的。这包括以下内容:

  • 修订控制系统;
  • 自动化的构建系统;
  • IDE和其他开发人员工具;
  • 开发服务器;
  • 部署过程;和
  • 项目流程和标准。

我使用过的大多数方法都没有过多地关注它们。这些构成了我所谓的Release0。在开始开发之前,这些东西应该已经存在。一旦您开始处理故事,就可以跟踪这些方面的任何变化以改进流程。

尽管开发团队可能会提供意见,但大多数项目应由项目支持团队处理。跨多个项目标准化这些项目应该为组织带来可观的回报。


1
+1:如果没有做到这一点,敏捷真的很难。稳定,可靠的基础架构和平台是敏捷性的先决条件。
S.Lott

1

考虑以下:

  • Scrum团队在现有产品套件中添加了主要功能。

  • 有必要根据工程最佳实践升级开发技术/工具/实用程序,使其保持最新状态。

  • 提前将发布工作与此工作配合使用是有意义的,以便在发布过程中可以解决Sprints问题。

  • 因为企业从这些项目中获得间接价值,所以我建议出于透明度的考虑,这些是产品待办事项(PBI)。

  • 团队调整这些项目的大小,并像对待任何PBI一样对待它们。

对我来说,这个问题归结为以下事实:我不想浪费时间试图找出如何将这项工作隐藏为其他以业务为中心的PBI之下的任务。

我不希望此类基础结构工作影响PBI规模。我想看看正在做什么,并了解我要支付的费用。

我还认为,通过投资于交付高质量解决方案所需的基础架构,使团队了解业务做出的承诺是有价值的。


0

XP 建议建议在所有工具和基础结构都已设置的位置进行“零迭代”。为这些故事编写故事是可选的,但可能是一个好主意。能够测试您的基础架构(增量构建,自动化测试和部署,通知等)是有益的


2
XP不建议这样做。有人这样做,但是绝对不是Beck等人所定义的极限编程的一部分。我个人认为零迭代是一个坏主意。
威廉·皮特里

另一个问题是,您不一定总是从0开始,您可能会意识到现在或下一个冲刺中需要一些东西。
安迪·维森丹格

@William:详见“规划极限编程”由Kent Beck,第15章,第66页
史蒂芬答洛韦

这不是建议。他们说这是个主意,然后说:“如果您以前从未使用过该技术,请考虑花两周的时间在开始编程之前就正确地使用该技术。” 他们不建议“所有基础结构”,而只是基本的自动化测试,构建和部署脚本。
威廉·皮特里

@威廉:啊哈,我明白你在说什么。我并不是说所有软件基础架构,而是您提到的内容
Steven A. Lowe

0

在我们的团队中,我们执行以下操作:

  1. 假设聚焦系数较低
  2. 尝试将此类任务包括在实际上需要实现它们的用户故事中。
  3. 如果某些任务是完全必要的,但没有直接的业务价值(例如,将单元测试从一个框架迁移到另一个框架),则在sprint的开头,我们将创建一个“连续任务”列表。这些是与开发相关的任务,不是故事,但开发团队希望它们完成。我们在黑板上列出了这些任务,但仍将其与故事分开。在冲刺期间,在每天的例会上,我们都会回顾完成这些任务的过程。

步骤2是最重要的。与敏捷实践一样,在Scrum中,您尝试完成任务的次数尽可能少。用它来避免浪费时间从事不必要的工作:我的经验表明,从长远来看,多达50%的“本来就很酷”的东西最终会被遗弃和维持。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.