为小型团队规划编程的最佳方法？[关闭]

我是一家小型创业公司的总监。当前，我们有两名正在构建Web应用程序平台的程序员（一名经验丰富，一名经验较少）。

迄今为止最大的挑战之一是规划过程。程序员通常负责计划自己的工作，但我们不断超出自己设定的期限。例如，他们估计一项任务需要2天，而最终需要8天。

对我而言，很难为他们提供计划支持，因为我缺乏准确估算某个任务将持续多长时间的技术知识。

你有什么主意吗：

1. 这是什么原因，对于程序员来说这很常见吗？
2. 我可以做些什么来支持他们的计划？有没有对小型团队的程序员有用的方法或工具？

通用技术有些常识，要知道的重要一点是，它们不需要太多的技术知识。

计划的出发点是确定需要解决的确切问题，并且有明确而明确的要求。如果没有，您的估计将是不正确的。在任何人开始编写代码之前以某种功能规范记录了该文档，这意味着在编码开始之前会先问过任何需要问的问题。这是一个出乎意料的有效节约时间。回过头来澄清需求，会破坏程序员的工作流程，等待响应会阻碍进度。

确定需求后，您需要确定解决需求所涉及的工作任务。这是一个经典的分而治之的练习-任何可以进一步分解的任务都需要进一步分解。

在更大的团队中，您可以使用估算扑克根据每个参与者的经验来估算。在较小的团队中，这种方法不太有效，但是从开发人员那里获得独立的估计，或者也可以从您自己那里获得一个估计仍然很有用，因为缺乏专业知识可以为您提供帮助，因为在向您解释什么时从他们的角度来看，任务涉及到，开发团队可能会更好地解决问题。

在规模较小的团队中，它可以帮助您为每个任务获得最佳/预期/最坏的情况下的估算值，从而为您提供一系列价值，但是如果您获得大量的超支估算值，则可以倾向于最坏的情况，直到您的开发人员学习更准确地估算。

在一家小商店中，开发人员经常以系统管理员，支持团队乃至测试人员的身份最终加倍（尽管他们可以做的一切，但是测试是您应该不惜一切代价避免的一种方法），因此您需要考虑到这一点。找出您的开发人员实际在开发新功能上花费的时间，并将其纳入估算。如果一项任务估计需要2天，但是您的开发人员只能在60％的时间内进行新开发，那么您将需要4天才能完成它。您可能还可以通过控制它们需要处理的其他任务的管道来帮助解决这些问题，以便非紧急的管理或支持任务可以以某种方式分批处理，而不是临时处理。很多程序员（当然包括我在内）都不是很好的时间管理者，因此，您可以在这方面采取任何措施都将有所帮助。对于程序员来说，单任务总是比多任务更容易。白天安排时间也可以帮助您。

保留记录 -每次进行计划会议时，都要记录估算值和实际值。然后，您可以将其用作以下内容：a）指导他们在计划过程中增加多少估算值； b）帮助他们完善估算技能。在每次迭代结束时（或您拥有的等效工具），整个团队应检查所做的工作，并弄清楚为什么花了比预期更长的时间，以便可以将其合并到将来的估算中。这应该是一项无可指责的任务-您在这里似乎有正确的态度，但是这个答案可能需要一段时间，因此我将进行观察。如果有人说“我在这里犯了一个错误”，您可以将其变成“您可以做得更好的事情”，但是告诉别人他们太慢或做错了事只会使情况变得更糟。

我知道没有这类问题的灵丹妙药，但最大的因素是沟通-实际上，对于较小的团队来说，沟通更容易-使用反馈来完善您的集体技能。

[他们估计2天需要8天]的原因是什么？对于程序员来说这很常见吗？

是，如果：

• 实际上还不清楚他们应该做什么，所以他们需要更多的时间来解决问题（然后他们应该这样说，而不是猜测要花多长时间）
• 他们不熟悉手头的任务（那么，他们应该提及并在估计中包括研究内容）
• 将完成的任务与较大的产品集成所需的时间比预期的要长（这可能意味着产品的体系结构较差）
• 开发人员喜欢重新发明轮子，因此偶然发现了别人可以解决的问题，可以在库中免费获得
• 在执行任务时，产品所有者将进行更改，这需要采用不同的方法并且已经完成了重做的工作
• 开发人员无法在生产环境中工作（因此，在家里他们可能会花两天的时间，但是在工作中，他们需要八天才能弥补所有的干扰）

仅举几例。

也许最好问问您的开发人员为什么他们认为自己的估算值相差甚远。:-)

您不会长远地尝试着找出规划开发时间的最佳方法。这部分是由于难以量化您实际上看不到的东西，部分是由于神话般的人工月，这与直观的想法直接相反，如果您有2位程序员，则应该能够比拥有1个程序员的开发速度快两倍。

正如您可能已经意识到的那样，它要复杂得多。估计开发时间的一种方法是将一组高素质的人围成一团来解决软件开发方面的问题，并要求他们估计完成项目所需的时间（尽可能详细地解释）。您采用所有估计中的最高者，并将其加倍。是的，您没有看错。你加倍最高的估算值，您应该有一个合理准确的估算值。我知道，因为随着时间的流逝，这就是我能够准确地告诉老板们我做某事需要多长时间的方式。我收集了我的同伴和我自己的程序员的意见，并将最高估计数加倍。如果这看起来太有价值了，请考虑测试新功能至关重要，然后考虑潜在的错误修复，这似乎是一个更合理的数字。

以我作为程序员的亲身经历，我可以告诉你，这有助于将项目分解为里程碑。到达里程碑1，然后从里程碑1到里程碑2，然后从里程碑2到里程碑3，等等需要多长时间？像这样分解时，答案通常比试图估计整个项目的准确性要高得多。奇怪的是，如果将所有这些里程碑的估算值相加，那么它通常会比整个项目的原始估算值大（如果程序员无论如何都要诚实），这只会让我认为细节是关键这里。

也许您缺乏技术知识，但是您仍然应该尝试从更一般的角度进行学习。程序员在重复方面没有问题。曲折一直困扰着开发程序。因此，最有可能的是，您希望包含的功能越多，程序将变得越复杂，并且假设此新功能对代码的先前实现部分没有影响，则开发工作将根据所需的工作量而线性化。完成。新功能很可能会严重影响先前实现的部分，因此开发不仅涉及实现新功能，还涉及修复旧代码，从而使开发时间成指数增长。

我对您的建议是，在不告诉程序员如何做工作的情况下，尝试掌握该程序在一般级别上的工作方式，并且您应该很快就能看到新功能如何修改该行为并从而提供估计需要多长时间。将其与他们的估算值（最高的两倍）结合起来，您将对如何估算开发时间有了更好的了解。

希望对您有所帮助！

估算经常无法实现的原因之一是，因为估算实际上非常困难，并且需要有关系统更改的经验和知识。通常，将较大的步骤分解成较小的步骤会很有帮助。

现在您有很多可能性，我将提到两种：

• 规划扑克
• PERT（程序评估和审查技术）

规划扑克

在小型敏捷团队中，这非常有效。

维基百科摘录：

• 不参加会议的主持人主持会议。
• 产品经理提供了简短的概述。团队有机会提出问题并进行讨论，以澄清假设和风险。讨论摘要由项目经理记录。
• 每个人将一张卡片朝下放置，代表他们的估计。使用的单位会有所不同-它们可以是持续时间，理想天数或故事点数。在讨论过程中，绝对不能提及与特征尺寸有关的数字，以避免锚定。
• 每个人都将他们的卡同时翻过来。
• 高估计值和低估计值的人会得到一个肥皂盒，以为其估计提供理由，然后继续进行讨论。
• 重复估计过程，直到达成共识。尽管主持人可以协商达成共识，但可能拥有可交付成果的开发人员拥有很大一部分“共识投票”。
• Egg计时器用于确保讨论的结构化；主持人或项目经理可随时移交鸡蛋计时器，当计时器用完时，所有讨论都必须停止，并再玩一轮扑克。对话的结构由肥皂盒重新引入。

这里的重要部分是澄清，讨论，同时调用估计，以便不引入偏差，并达成共识。

PERT

通常很难给出一个准确的估计。更容易的是给可能性。PERT使用3个值进行估算：

• 最乐观的完成时间（如果出现的问题少于预期）
• 最悲观的完成时间（如果一切出错，则不包括重大灾难）
• 最有可能完成的时间（如果一切按预期进行）<-这是您的开发人员目前最有可能估计的时间

通过加权这三个估计，您可以获得更可靠的估计。

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

和/或您可以使用这三个值来构建概率分布，该概率分布甚至可以更多地反映现实世界的不确定性。Beta分布和Triangle分布是突出的选择。现在，您可以使用此方法应用统计信息，例如“在x给出当前估计的日期x结束的可能性”或“如果我希望95％的确定性，它将在什么时间结束”。

实际上，PERT不仅包含这里提到的这些方面，为简洁起见，我将其省略。

事实上，如果您不保留历史指标，那么您甚至无法接近以合理的准确性给出合理的估计。询问其他公司/人员需要多长时间也无济于事。问题在于每个公司和开发人员都有自己的处事方式。因此，每个公司将有不同的时间长度来执行完全相同的任务。每个开发人员将有不同的时间长度来执行完全相同的任务。

最好的做法是开始跟踪时间，并以某种方式弄清楚如何对任务的难度进行分类。一些公司使用代码行，一些使用功能，有些只是凭直觉。此外，您还必须考虑这是否类似于开发人员已经构建的东西或新的东西，例如新技术，团队之前从未构建的新功能等。此外，如果它是嵌入式的或真实的，时间系统的复杂性通常会上升很多。

除非您收集实际数据，否则无论您的开发人员给您多少次估计，他们实际上只是在您每次询问时都从他们的背后获取数字。是的，收集真实数据很麻烦，起初它并不能提供很多有用的信息，但是随着时间的流逝，它确实开始提供合理准确的估计。

我还想指出，估计通常仅在总体上是好的，而不是短期的。例如，开发人员估计需要2天，但要花费8天。开发人员没有考虑必须设置测试环境和开发模拟器，也没有考虑必须学习一种全新的技术，或者陷入了错误之中。他们无法弄清楚，或者功能需要对现有系统进行重构。您不能总是为小型任务预测这类事情。但是，在整个项目过程中，多余的6天可能会被其他任务淘汰，而所需的时间要少6天。

我一直是我自己的几个小项目的唯一开发人员，并且在与大型团队合作方面具有一定的行业经验。我注意到，大公司使用的技术不一定适用于小团队。有一次，我正在做更多的计划和文档编制工作，而不是编写代码。我建议您尝试通过尝试不同的技术（其他答案提供一些很好的见解）和工具来找到一种工作的好方法，这将花费您一些时间和精力，但稍后您会从中受益。我发现有用的一些工具/技术是：

-Pivotal Tracker-跟踪故事并鼓励分解任务的好程序-它减轻了输入故事的负担，并自动推断出速度。https://www.pivotaltracker.com/。

-Gdocs文档，因为很容易让多个用户同时编辑和讨论。

-在我曾经工作过的一家公司中，我们过去每次召开会议都会召开一次会议，这次会议必须包括一位高级程序员，因为他会更好地判断一项任务需要多长时间。他还将更好地判断任务中可能存在的困难部分。

总而言之，我相信在小型团队中工作的关键是要有一个快速，灵活的可靠计划体系。同样，故事的任何困难都可以尽早发现，以便计划任务时要牢记这一点（这可能导致构建不同的内容）。

希望这可以帮助