敏捷估计–我们缺少什么吗？

任何发展集团的荣誉成员都在增进人们的知识和专业技能。 但是，它通常位于艾森豪威尔矩阵中臭名昭著的“重要/不紧急”区域，因此注意力不足。 即使组织对此进行了投入，也将与开发过程分开进行管理。

在这篇文章中，我将提出一种敏捷方法，用于在敏捷环境中测量和监视团队成员之间的知识转移。 我相信实施此技术还将对团队评估质量产生积极影响。

敏捷团队的日常工作围绕“任务”展开。 我们计划，估计和执行任务。 它们中的大多数是在用户故事崩溃期间创建的，但是还存在许多其他问题，例如错误，合并，重构等。

在典型任务上花费的时间可以大致分为两部分。 花时间学习和工作。 给定任务，您能否说明任务的哪一部分花在学习上，哪些花在工作上？ 好吧，您也许可以给出一个粗略的估计，但它当然并不简单。 这让我想知道是否有简单的方法。 这是您的一项智力锻炼。 假设您以完全相同的方式执行了两次任务。 每次从完全相同的点开始。 只有第二次您才有了第一次获得的经验和知识。

第二次完成您需要多少时间？

第二次您不需要学习。 因此可以肯定地说，第二次花费的所有时间都是“工作时间”。 这给我们以下正式定义：

给定团队成员M和任务T ，将任务T关于团队成员M的学习因子定义为M第一次执行任务所花费的时间除以他所花费的时间完成第二项任务。

我为您的手续表示歉意。 让我们看一下虚构任务形式的两个示例，这些示例属于虚构的经验丰富的Java开发人员团队。 然后，我们将尝试估计学习因素。

示例1：使用Xtream Java库将大约50个XML映射到Java类。

这里的学习因素是什么？ 好吧，如果您相信他们的教程（并且应该），那么大约需要10分钟的时间来学习如何使用XTream。 因此，此处的学习因子约为〜1。 如果您再次开始执行此任务，则大约需要花费相同的时间。

示例2：将使用Google帐户登录的选项添加到网站。

好吧，假设您在这里大部分时间都没有花时间进行学习。 实际的实现只是几行代码。 因此，我大概会带着〜8去这里。

好。 现在我们有了一个不错的新定义。 我们该怎么办？ 首先，让我们看一下规划估算的现有方法。

剧透警报：以下段落可能被某些人视为异端。

敏捷方法旨在促使所有成员就给定任务所需的努力达成共识 。 这通常是通过玩Planning Poker来实现的。 在这个游戏中，每个玩家都会在与其他玩家完全相同的时间展示自己对任务的估计。 然后讨论估计数以便达成一致。 如果您停下来想一想，您会不禁想知道为什么吗？

实际上，我们知道这是不正确的。 一个人从事某项任务的持续时间高度取决于该人的身份。 那么为什么我们都应该就任务估计达成共识？ 特别是当我们仍然不知道哪个人将执行任务时？ 只有完全相同的任务对不同的人花费不同的时间才有意义。 在大多数开发小组中，人们具有不同的技能和专长。 知识差异可能存在于技术，代码，业务领域等方面。因此，即使团队成员就所需的解决方案达成共识，某些人仍然需要花费更多的时间来执行。

我们如何做得更好？

如果我们仅更改计划扑克方法怎么办？ 从现在开始，每个人都会声明两个数字。 第一个是对工作部分的估计，第二个是对学习部分的估计。 学习部分是个人的。 所有团队成员仅应就工作部分达成协议。

为什么会更好？

它为我们提供了一种衡量和监控团队学习情况的好方法。 我们已经测量出人们花在工作上的时间。 那学习呢？ 使用建议的方法，在每个冲刺中，我们都可以衡量人们在学习上花费的时间。 我们可以称它为学习图 。 这就像“消耗图表”，仅在这里我们测量随着时间推移花费在学习上的要点人数。 与“分解图表”一样，我们使用计划阶段给出的点。

这里有一些学习图表的例子，它们告诉我们的是：

考虑大多数学习因素较低的任务所产生的非常水平的学习图。 这是什么意思？ 这意味着团队效率很高，每个人都在做自己擅长的事情。 这也意味着他们没有在学习新事物，知识也没有在团队成员中充分传播。

另一方面，非常陡峭的学习图可能表明团队效率较低，工作质量可能较低，因为大多数时候人们都在做一些自己不了解的事情。

那么什么是好的学习因素呢？

我实际上不知道答案。 我认为这至少是2，所以平均而言，人们将一半的时间花在学习上。 这也可能与满意度相关，并挑战团队成员的日常工作经验。

下一步是什么？ 尝试一下我的新想法，看看它是否真的有意义。 我会及时通知你的…

翻译自: https://www.javacodegeeks.com/2015/06/agile-estimation-are-we-missing-something.html