你是否在Sprint计划中计划技术债务?

Scrum是一个在复杂环境中开发复杂软件产品的简单框架，但很难实践。但是为什么呢?我不想详细说明原因，但我想强调开发团队存在的一个问题。

开发团队是指跨职能的、自组织的开发人员团队。但开发商是谁?不是每个人都在为软件开发做贡献吗?程序员、测试员、dba、UI设计师、内容作者和业务分析师?现在，看看你的团队。它是跨职能的吗?是的，你有，因为你有所有技能的技术人员，但这些技术人员是开发人员吗?也许不是。他们只是编码员、测试员、dba和UI设计师，正在等待与技能相关的任务。他们不是打算开发软件的开发人员，而是根据自己的技能来完成任务。

帮助您了解开发团队特征的关键事项。

假设L&D(学习与发展部门)即将组织一些培训并宣布如下。

第一个公告“我们计划为Scrum开发人员举办一个研讨会，所以请发送您的提名。”您会发现只有编码员订阅了这个研讨会。

另一个公告，“我们正在组织敏捷测试研讨会，所以请发送您的提名。”这次只有测试人员订阅。敏捷业务分析和UI/UX培训也是如此。

上面反映了什么?团队仍然根据技能编码、分析、UI/UX和测试进行划分。测试人员认为与测试相关的一切都是他们的领域，同样，编码人员认为所有的编码工作都是他们工作的一部分。

实际上，测试人员编写代码是为了测试产品代码，而编码员编写测试是为了执行代码的单元和集成测试。

让我们换个角度看。

在sprint期间，计划团队已经准备了以下sprint backlog。

它反映了什么?有任务，但这些任务是基于技能的，而不是基于组件的。这不是一种创建子任务的错误方式吗?如果不呢?然后阅读下面的情境。

假设Alex(编码员)和Martha(测试员)正在处理这三个故事。

Alex在2天内完成了故事1的编码部分，Martha已经开始测试，那么Alex接下来会做什么?

最有可能的是，Alex将开始编写故事2的编码部分。但它有用吗?为什么亚历克斯不能从同样的故事中找到其他作品呢?或者为什么Martha要等Alex完成编码后才开始测试?为什么她不能与Alex配对进行并行测试，或者至少开始测试api ?

很多人问我，如果Alex开始编写故事2的编码部分，会有什么问题。让我们看看下面的情况。

Alex完成了第一个故事的编码，并开始编码第二个故事。玛莎在故事1中发现了一个漏洞，那么她必须做什么?她联系了亚历克斯，想讨论一下，但亚历克斯很忙，让她晚点再来。

玛莎接下来会做什么?最有可能的是，她会打开一个bug跟踪工具，在那里记录一个新发现的bug。好吗?没有，但为什么不呢?我将单独写关于错误日志的挑战，但是现在主要关注它的其他方面。

Alex完成了故事2的编码，并开始查看Martha记录的bug。他确定了一个错误的根本原因，以及修复它所需的框架级代码更改。但这也会影响他刚刚完成的故事2的代码。

亚历克斯会怎么做?如果他改变了任何需要从根本上修复的东西，就会产生返工和延迟交付。另一个选项是修复错误的捷径(补丁)，所以它不应该影响到第二层代码。

大多数编码员选择第二种方法，因为编码员对他们的代码非常情绪化(开玩笑)。选择第二种选择有多种原因，但结果将是“技术债务．"

还有什么?

似乎你忽略了我在这段视频中强调的另一个大问题，所以要认识到并三思为什么避免基于技能的任务创建是必要的。

我们能做些什么来避免这种情况?

首先，不要像上面那样创建子任务，而是尝试将其划分为组件。最好的方法是不要创建子任务并保持故事较小．以一个整体的方式进行配对，而不是将故事从一个人传给另一个人。团队应该专注于完成一个已经在进行的工作，而不是开始一个新的工作。

感谢阅读!如果你有任何疑问，请联系我。我在我的专业Scrum开发人员培训。