在不进行“太多”设计的情况下，我们如何在Sprint计划期间提供有效的时间估算？

我的团队正在跟上Scrum的发展步伐，但是我们大多数人对非敏捷或“伪”敏捷方法更加熟悉。对我们来说，最大的障碍是召开高效的Sprint Planning会议，在会议中我们将积压的项目分解为任务，并估算工时。（我使用的是VS2010 Scrum模板中的术语；如果我在某处使用了错误的单词，则表示歉意。）

当我们试图确定一项任务需要花费多长时间时，我们经常陷入在代码级设计功能的陷阱（表布局，接口等），以便弄清该任务需要多长时间。 。

我很确定这不是进行这种设计的合适位置。我们应该在sprint期间安排这些设计会议的任务。但是，我们在弄清楚如何为任务提出有意义的估算时遇到了麻烦。

有实践习惯/技术/等吗？在不知道您打算如何实现某个功能的情况下做出判断需要花费多长时间的判断？如果设计完成后我们的时间估算值将发生显着变化，那么我们如何才能提前适当地预算Sprint待办事项？

编辑：

请澄清一下，因为一些评论/答案非常有效，但我认为解决的是错误的问题。

我们知道我们正在做的事情是不正确的，我们应该在此设计的sprint中花费时间。从概念上讲，所有开发人员都明白这一点。如果我们开始进入杂草丛生，我们还将招募具有Scrum经验的团队成员，以保持我们的正常运转。

问题在于，如果不经过这个设计过程，我们将很难为任何事情提供具体的时间估算。我们一直在说这样的话：“好吧，如果我们以此方式设计，可能会花费8个小时，但是如果最终不得不以其他方式这样做，那大约需要32个小时，但是一旦开始尝试编写，它可能不会那么糟糕...”。

我还假设一旦我们有了一定的历史速度，这个过程就会变得更好，但是我们正在使用的许多技术和架构模式对我们来说都是新的。但是，如果潜在的错误估计仅是适应此过程的自然组成部分，那么我们将只需要重新调整自身以接受：)

1. 安排一个定期的“修饰”会议，在这里进行这些设计讨论。我所在的团队在计划前一天，每个sprint都有一次。这样做的目的是使设计足够明确，以使团队可以就整个故事的时间估算达成一致。您可以考虑在本次会议中进行任务分解，以便计划纯粹是决定要筹集多少资金的一种练习。换句话说，在开始实际工作之前，应该先在sprint中进行设计。

2. 考虑使用计划扑克，即“努力”的点数/单位，而不是工时来估算任务。还请尝试尽可能地分解故事。故事越长/越复杂，估计的准确性就越小。

3. 在计划中，Scrum主管应通过停止任何超出“解决”范围的讨论来使计划保持正确。那时，团队成员需要迅速就估算达成一致，通常给出一个上限/最坏情况的编号。如果任务最终比您计划的要容易得多，那么接手更多的工作要容易得多，这比处理由于任务花费比计划更长的时间以及故事滚动成多个冲刺而导致的计划延误要容易得多。

4. 讨论在冲刺结束时回顾中如何得出估算值。特别是如果有任何相距遥远的地方。团队是否从故事的进行以及他们对故事的预期中学到了什么？Scrum主管应始终专注于可对您的设计/估算过程进行的可行更改。

我认为问题在于您正在尝试估计时间。别。

估计复杂度。查看需求（希望是用户故事），并评估团队认为相对于其他需求或用户故事而言，如何构建和测试需求的复杂程度。有时您会错，但通常您会对某些事情会变得多么困难有个好主意。您还会发现，复杂程度大致相同的项目往往需要花费相同的精力才能完成。

因此，复杂性排名成为与产品积压中的用户故事相关的“故事点”。在完成了一些冲刺之后，您将了解在一个冲刺中可以通过多少个故事点，这就是您的速度。届时，您将对每个项目花费多长时间有了更好的了解。

我强烈推荐Mike Cohn的“ 应用用户故事”。

我知道您的问题是关于在规划中避免设计的。但这有点像XY问题。

我去过你那里 我想给您提供一些中间状态，而不是给您可能会逐步改进的内容。

我们的团队在做与计划和执行工作特别相关的三件事。这些帮助我们避免了设计混乱，并避免了不正确的时间估算。

自动化验收标准

我们的故事是通过他们的自动接受标准的数量来指出的。这意味着，如果我们要编写自动化测试来确认故事已完成，那么它们将是什么？

例如，“当用户在运行iOS 6+的iPad上单击“播放”时，视频开始播放。” 实际上可能很难自动执行此测试，但这是故事的接受标准（AC），并且贡献了一点。

我们使用斐波那契标度，并且我们总是四舍五入。因此，如果一个故事具有四个可自动接受的条件，那么它就是一个五点故事。

我们最大的故事点数是8分，但我们很少有。如果故事具有五个以上可自动化接受的条件，我们将找到一种将它们拆分的方法。

美容前

我们在星期一举行开工会议，但是在进行团队整理的时候进行了美容会议。在进行修饰之前，团队成员将通过描述结果并按可自动接受的标准进行刺探来预先整理一个故事。

整理使团队的专业知识能够处理预先整理的故事，提出未指定的要求，分解故事等。

除接受标准外，有时我们还会列出任务，但这些任务不是时间估计的。我们从不估计时间。任务只是支持标准需要完成的工作陈述。

限制在制品

传统的Scrum尝试将工作时间限制为冲刺持续时间。我们发现，这是人为地导致我们急于赶紧冲刺的截止日期，因为冲刺在星期五结束，导致我们的周末丧命。

另一种方法是在任何给定时间限制正在进行的工作。我们已经迁移到后者，并为此感到非常高兴。

一旦故事从待办事项移至进行中，我们将其描述为处于以下几种状态之一：

• 暂停-无法进行团队合作，因为我们正在等待一些团队以外的活动
• 开发中-努力达到验收标准
• 需求测试-我们认为我们已经遇到了审核委员会，正在等待其他人进行验证
• 在测试中-正在根据交流评估故事，正在解决错误
• 准备部署-在下一个可用的机会上线

然后，我们使用每个州的故事数量来推动团队关注。例如，开发人员可能会接受新的故事，但是如果我们有很多故事正在测试中，那么最好是帮助他们解决现有故事。

首先，要认识到在这种情况下不可能进行准确的估计。如果做错了，请不要紧张。但是，您仍然需要一个粗略的想法来进行计划，并且真正解决完全不确定性的唯一方法是在估计中添加更多的故事点。如果您不知道它是5还是13，请使用13。

将故事分解得尽可能小也很有帮助。我们经常有一个研究/设计故事，其唯一目的是做足够的工作以更好地了解如何进行功能，然后功能故事本身进入后续冲刺。考虑一下为什么这样做。即使您不知道某件事情会有多困难，通常也可以从过去的经验中准确地知道要花多长时间才能找到答案。

您可以在这里做两件事。

首先有一个Scrum主管，他的角色是监视讨论并在出现问题时说“嘿，您正在重新设计”。这比想象中的要难，每天轮流让人们加入其中，最初让每个人都成为Scrum的主人，以便任何人都可以使用。

其次，如果要在sprint计划中进行设计，则需要能够区分两种情况：对任务持续时间的了解不足以进行呼叫，或者只是因为这样做比较有趣而只是在进行设计。

同样，Scrum管理员应该在这里介入，并告诉您将其放回原处，直到您知道足够的时间来安排它，或者让您停止设计并回答原始问题（需要多长时间）。

因此，如果您正在进行冲刺计划，那么有一个商业赞助商在那里与您一起审阅积压订单并优先考虑他们希望首先完成的工作就很有意义。如果这样做，您会发现在会话期间进行设计变得更加困难，因为它们会变得焦躁不安，并最终不想来。

我们仅根据一些有限的讨论来估计在sprint计划过程中的故事“冷”。尽管组建了重点相对狭窄的团队，但估计的确是非常不准确的……主要是由于存在大量未记录，未注释的遗留代码，对实际发生的事情并没有真正的全面了解。自原始文档撰写以来已发生重大变化的人员。

我们现在正在尝试的是在计划调查每个故事之前花一些时间-在这里，只有一个开发人员将调查一个故事...我们希望这将意味着调查的开发人员将能够为您提供一些澄清和见解。帮助估计。到目前为止，这在尝试过的场合有所帮助。

我尚未确信，额外的调查确实可以使估算值更加准确，足以证明费用合理，但我们将尝试一下，以期数分钟。