团队是否应该在具备新技能后减少未来的估计，因为在学习过程中，估计值增加了吗？

Question

我最近一直在推动单元测试。这是我的团队的一项新技能。我有过10+年编写单元测试的经验，但我基本上是团队中唯一有过这方面经验的人。最近，我一直在为如何预算学习这些技能而苦苦挣扎。强迫人们(包括我)在工作时间之外学习所有新技能是行不通的。我们有家人。工作的时候。家在家里。我们每个季度都有训练时间，这是很棒的。然而，博客文章、YouTube视频和PluralSight教程只会给你带来更多的好处。

我有这个头脑发热的想法来增加故事中需要单元测试的故事点。这有效地减少了我们可以提供的每个故事点的功能数量。当时感觉很好，因为我们正在加大努力。在我看来，这种增长是由编写单元测试的“未知数”所证明的。我还希望在我们的团队成员能够胜任单元测试之后，故事点估计值会下降。

我最初从另一个发脑想法中得到了这个想法，以增加对需要用Selenium编写自动端到端测试的故事的故事点估计。这就产生了以前是一个故事爆炸成6+故事的特性。故事1包括开发和编写一个单一的自动化测试。这通常是一个13点的故事。通常情况下，球队在3周的短跑中能轻松地完成8分的报道。任何更高的东西，我们的信心都会指数下降。一个13点的故事是令人担忧的。一个短跑20分的故事？是的，我们在一起的时候，我也想要一匹小马。

所以第一个故事是13分，然后我们会有4-5个故事，估计每个3到5个点。较小的故事实际上是编写自动化测试所需的工作，包括添加任何测试基础结构代码，比如Selenium页面模型。这些测试都验证了不同的、可测试的最终用户行为。

车队的速度最初受到了影响，但最终还是上升了。故事点估计永远不会回来。我们继续我们的故事分解了一个单一的13点故事，然后一堆3到5点的故事来编写自动化测试。

现在我们来看看我目前的学习单元测试情况。该团队再次估算了13+故事点的一个故事，没有办法将这个故事分解成任何更小的故事。对于我们的团队来说，“故事”基本上是终端用户可以与之交互的东西。非常普遍，但如果最终用户无法看到或与其交互，那么它就不是用户故事。

我要求我们进行单元测试，这些测试需要在用于发送电子邮件的接口上模拟单个方法。我们使用邮政 NuGet包创建和发送电子邮件，这使得发送电子邮件比呈现带有视图模型和剃须刀模板的网页更加复杂(我们的团队在ASP.NET MVC方面有丰富的经验)。

单元测试将涵盖从业务客户帐户中删除人员时调用的“服务”类。任何被删除的人都应该收到电子邮件通知。新的单元测试应该涵盖一个事实，即电子邮件发送给每个被删除的人。他们不需要断言电子邮件的内容，只是电子邮件被发送了。这涉及到模拟IEmailService.Send(Email)方法。

这个13点的故事让我很紧张。我们已经进行了三周的冲刺，我仍然得到一些关于单元测试基本原理的基本问题。恐怕我们会错过这次冲刺的目标，这就是为什么这个故事得到了13分的估计。每次我尝试引入单元测试，即使是在更小、更简单的故事中，团队总是给我一个13+点估计。我担心，一旦考虑到开发、自动化测试和单元测试，任何故事都不足以满足单个sprint的需求。这对这个团队的速度和技能水平来说太大了--我已经注意到了我领导这个项目的整整4年的趋势。我只是撞到一块砖墙而已。

我们不是根据谁被分配的故事来做调整故事点的。老实说，不管怎么说，没有一个人在写故事。我读过学习新技能在哪里适合敏捷？，但在某些时候你必须使用新的技能，这是我的难题。由于我是这个项目的团队领导、scrum大师、业务分析师、平面设计师、BDD实践者和架构师，所以我经常没有时间与团队中的每一个人配对程序。这大量的责任也不会很快改变。

看来我们必须处理速度降低的问题，或者增加估计数。我从这两个人中选择了后者。

在增加故事点估计以学习单元测试之后，团队是否应该根据学习编写单元测试的“未知数”不再未知的假设，减少对类似工作的未来故事点估计？

Answer 1

到2020年，你可能会想到，到现在为止，所有的开发人员都已经登上了单元测试列车。

就点和估计而言，我想说的是，你正被细节问题所困扰。您知道，从长远来看，单元测试将加速开发，并已将其作为一项要求来接受。

有一个“完成的定义”，其中包括单元测试，并让开发人员估计任务。不要质疑或担心他们的估计，只要跟踪速度，并使用它来预测结束日期。我敢打赌，你的压力超过了估计，推高了他们，在会议上浪费了时间

我还想说，如果8分=3周的话，积分似乎有点大。我会推荐一周短跑和几天内的估计。让团队设定他们自己的目标。

故事的定义也可能是问题的一部分。“让鼠标上方的绿色按钮”可以是一个故事。

Answer 2

我担心，一旦考虑到开发、自动化测试和单元测试，任何故事都不足以满足单个sprint的需求。

我认为这就是问题的根源--你的故事实在太大了。我很难相信你不能把一个13点的故事--这代表着你整个团队大约5周--分成三到四个小故事。

我的建议是挑战团队写出更好、更小的故事。随着较小的故事将出现更准确的估计。根据你在你的帖子中给出的数字，我建议任何故事都不能超过4分，包括对这个故事进行所有测试的时间。如果它比那更大，就把它分成两层。

在增加故事点估计以学习单元测试之后，团队是否应该根据学习编写单元测试的“未知数”不再未知的假设，减少对类似工作的未来故事点估计？

团队不应该人为地减少故事点数。但是，如果你是在人为地添加额外的故事点，你就应该停止这样做。

随着团队技能的发展，故事点自然会下降。故事点应该反映团队对完整完成一个故事的诚实意见，包括所有的测试、文档等等。当他们变得更精通测试时，时间自然会减少。

Answer 3

您在评论中写道:我理所当然地担心，要求devs为方法编写单元测试需要超过3周的时间，但可能需要一天的工作时间才能完成单元测试。

听起来，团队不想做单元测试，因此任意地增加了估计的工作量。使用培训预算来做单元测试车间。说服他们在强迫他们之前想要单元测试。

创建单元测试将增加故事的复杂性。因此，点数将增加，而每次冲刺的功能将减少。在开始的时候，效果会更大(虽然不像你经历的那么大)。

由于单元测试，未来的重构将变得更容易。释放努力可能会下降或消失。版本中可能会出现更少的bug，从而减少错误修复的工作量。这些安全时间可以用来实现特征，从而提高速度。