4个可能破坏你的冲刺的技术细节以及如何解决它们
对于新组建的敏捷团队，期望值（尤其是）很高。这种方法对于许多公司来说仍然是新的，一旦他们终于有勇气转变，他们会对变革寄予很多期望。
scrum team很容易不能实现其承诺，而且失败可能有很多变种，都同样可能发生 😀。
现在，本文不会详述敏捷过程本身。相反，我想集中讨论（任何）团队的最终目标 – 按时提供并具备质量的协议内容。在这种情况下，重点将放在团队内部的更多技术活动上，这些活动可能导致失败的迭代，并探讨如何有效地处理这些问题。
现在，我们将讨论可能破坏您的迭代的技术问题以及如何修复它们。
无明确路线图目标的待办事项生成
根据交付内容的技术难度以及客户对主题的理解程度，待办事项可能是团队遇到的第一个问题。这可能导致一些严重的问题，例如：
- 故事可能几乎是随机生成的，而没有遵循逻辑线，而是基于某个层级重要人物的闪念想法，而不是基于某个时间顺序计划。
- 然后敏捷团队为了保持一致性而添加了自己的故事，以补充已有的故事。但最终结果将是并行的几个大主题在待办事项中。
- 由于客户需求始终是首要任务，一些重要但过于技术性的故事将被推迟，以交付客户要求的功能。
- 团队将尝试交付，但不可避免的结果是迭代内容交付感觉不完整（甚至有错误），技术债务正在扩大（导致进一步的故事进入待办事项）。
再经过几个迭代周期，这个问题将呈指数级增长，因为已经不再关心待办事项中有什么内容，因为很明显，排在较低位置的内容永远不会被解决。在每个迭代中，都会生成一批新的故事（并具有更高的优先级）。
如何解决待办事项生成问题
在这里找到解决方案并说服合作伙伴进行更改尤其困难，因为这是组织层级具有相当大影响力的领域。
然而，有一些行动可以启动，即使它们不会立即得到批准，但定期提醒并与当前待办事项的情况以及如何解决该问题可以久而久之地导致成功：
#1. 要求团队明确的路线图目标
这应该从短期和长期的角度来考虑。明确说明在接下来的几个月内必须完成哪些功能，并说明产品一年后应该是什么样子。清晰的愿景应该被彻底展示，并与具体的路线图目标相结合。
#2. 挑战时间轴上功能的优先级排列
绝不能让团队在同时处理几个高优先级和高复杂度的故事之间权衡。这只会导致一切进展缓慢，而不是在重要主题中展示实质性的增量进展。
#3. 定期回顾旧故事
定期回顾旧故事，并确认它们是否仍然有效，以及这些故事的优先级是什么。如果它们仍然有效，请将它们映射到具体的路线图目标中。避免在待办事项中出现未映射的故事 – 这表明这些故事没有明确的业务价值，或者随着时间的推移，它们的优先级丢失了。
技术债务的推迟
技术债务是在开发的软件中，由于将交付速度优先于质量而产生的代码（或其部分）的状态。有时，在Sprint中发布新功能是一个紧急的话题，所以团队可能决定不完美地完成用户故事。
然而，这样做仍然能够满足业务需求的主要要求。如果不正确地及时识别，它甚至可能会在项目后期出现问题时被遗忘，并且只有通过遇到问题时才重新发现。
团队本身是在途中创建的技术债务的故事最有能力定义的。不幸的是，这些故事通常被客户或产品负责人放在优先级图表的末尾。
技术债务的积累对于Scrum团队来说是一个严重的问题。它从小问题开始，随着时间的推移呈指数增长：
- 新的故事开始受到过去未完成问题的影响。
- 在存在高技术债务的系统中修复新的错误通常会导致非常复杂的解决方案，因为为了修复新的错误，需要解决几个其他问题，以使处理进入可以进行修复的阶段。
- 开发团队的挫败感增加，因为他们看到在一个充满未解决技术问题的系统中实现新功能变得更具挑战性，这使得新功能扩展变得不必要地复杂。
如何解决技术债务的推迟
这里的关键是一致性。每个Scrum团队都应该开发适合其用例的流程，并坚持不懈。所讨论的过程可以是类似以下任何内容：
制定一个规则，从技术债务积压中至少挑选1或2个用户故事。
保留一定的百分比的Sprint，专门用于与技术债务相关的任务。然而，这可能会有些棘手，因为很难跟踪这种承诺。如果选择这条路线，最好是在Sprint中定义一个具体的特定日期，专门用于技术债务活动。
定义每5个Sprint或更多的时间用于追赶技术债务故事。在该Sprint中填写尽可能多的相关技术债务内容。如果随着时间的推移，目前没有足够的技术债务故事可以处理，那么用其余的Sprint能力填充新功能内容。无论如何，这个具体的Sprint首先应保留给技术债务故事。
在Sprint结束之前，内容更改过于灵活
Scrum团队应该灵活并准备好变化，因为这直接从Scrum团队的核心预期中得到体现。
但是想象一种情况，Sprint内容每2-3天就在变化：
- 用户故事被重新排序，新的用户故事进入Sprint，其他用户故事很少被移除。
- 内容不仅在变化，而且在Sprint期间还会增加。
- 优先级的更改会导致团队失去动力，因为他们需要从一个话题跳到另一个话题，增加了压力，最终导致无法交付内容。不仅限于在Sprint计划期间同意作为Sprint一部分的用户故事，而且经常包括新添加的用户故事。
如果我们能够给予Scrum团队自由，并看到他们如何完成用户故事，那将是很好的。然而，经验表明这是行不通的。团队会因为内容而分心和不堪重负；随着时间的推移，Sprint承诺将变得毫无意义。
团队不完全在迭代期内完成故事将成为标准；同样，将在迭代之间转移故事也将成为标准，这是一种直接的后果。
然后客户会抱怨在迭代期内放入的故事无法保证在该迭代期内交付。这将导致功能和路线图目标的规划不准确。
如何解决迭代灵活性问题
我相信为了限制迭代的灵活性而放弃一些自由，将极大地提高迭代交付的可靠性。这样的过程包括以下步骤：
- 不允许将新故事无序地添加到现有迭代中。即使只是一个非常简单的审核流程，也要有一个确认点，确认新故事的相关性并且优先级高于已经在迭代中的任何其他事项。
- 对于添加到迭代中的每个新故事，从迭代中删除一个同等复杂度的故事。理想情况下，它应该是一个在迭代中尚未开始或者刚刚开始的故事。
- 不要自动将在迭代期内发现的临时性错误添加到迭代待办事项中。这些错误是要进行估算和计划的新故事，要具体安排在特定的迭代中。
未充分定义的故事会留下太多未解决的问题
所以你为下一个迭代期定义故事，团队进行了澄清和细化、估算和任务拆分，一切都准备好了，可以进行明确的开发了，对吗？实际上，不清晰的故事出现在迭代期内。
即使故事已经被细化，团队也会对估算达成一定的共识，即使没有人对故事的不清晰进行沟通。如果故事定义不清楚，团队很容易就能识别出来，会反复讨论迭代期内的故事。
这不仅自然延长了团队的细化时间，还导致估算完成并由团队承诺迭代内容后，进一步改变范围。
因此，故事会变得比最初的估算更大更复杂。此外，由于需要进行所有额外的澄清工作，这样一个故事的真正开发工作将在迭代开始之后很久才开始。
在大多数情况下，这最终导致迭代期内存在未完成的故事。
如何解决迭代期内未完成的故事
如果团队面临太多不清晰的故事，随着时间的推移，情况将变得难以管理，人们只能想知道为什么每个迭代期都有未完成的故事。
解决这个问题可能是一个复杂的问题。它主要取决于产品负责人对开发团队的了解程度以及他们是否能理解团队对故事明确定义的需求。
通常，产品负责人是非常功能导向的人，与开发团队的联系很浅薄。在其他情况下，产品负责人的角色与业务分析师的角色合并，这更加混淆了情况。那么在这种情况下该怎么办呢？
安排每月电话会议进行故事准备，在将要引入迭代期的功能事项上进行提前深入讨论。拥有明确的路线图是这个过程成功的基础条件。
提前准备分析页面，为这样的复杂故事做好准备（在将故事放入迭代之前），这样产品负责人就可以为开发团队轻松定义内容丰富的故事。
在非常复杂的情况下，最好在主题到达敏捷团队之前，为设计准备专门的时间。团队中的特定专家应该负责这个活动。
不管怎样，不要让准备不足的故事走到关键阶段。从内容的角度坚持完成它。这将给相关利益相关方施加额外的积极压力，以便更好地为团队准备好故事。
最后的话
长期来说，关注每个故事的好内容会带来巨大的回报。对于大多数Scrum团队来说，产品积压管理是一个未定义的领域。将故事映射为具体目标，并将其置于更高层次目标的背景中，这是一个被低估的活动。
这个列表旨在为这些技术细节提供一些帮助，并希望如果以上问题中有一些熟悉的话，能对您的导向有所帮助。
接下来，看看适合初创企业到中型企业的最佳链接。
