如何更好地估计软件开发时间
如何更好地估计软件开发时间
能够准确地估计开发一个给定的产品或特性所需的时间对于每个开发人员来说都是一项至关重要的技能，也是一项必须通过深思熟虑和努力不断磨练的技能。作为一个行业，我们经常受到软件超支的困扰。一项研究估计，多达 66%的企业软件项目存在成本和工作量超支。
评估贯穿于开发过程的所有阶段。项目通常都有时间限制。然后，项目可能被分解成具体的里程碑，每个里程碑都有指定的交付日期。此外，开发人员可能会使用一些直觉将任务分解成更易管理的块，这些块可以在更短的时间间隔内完成，即在一天、半天、一周等内完成。这些阶段中任何一个阶段的挫折都会向上蔓延，导致整个项目逐渐偏离计划。
很多时候，我们对某些任务的估计是由个人启发和过去的经验引导的。如果你过去曾经使用过某项技术，你更有可能意识到它的复杂性和潜在的复杂性。这使您能够更好地估计开发所需的时间。
但另一方面，作为软件人员，我们也在不断寻找新的挑战，并与我们可能几乎没有经验的领域合作。在这种情况下，利用过去的经验不仅会产生误导，还会适得其反。
同样，在个人层面上，你的生产力可能每天都在变化。某些日子比其他日子更有效率，让你完成更多的工作。认识到这一点可以让你更好地计划你的工作日/周，更好地掌握你实际上能完成多少工作。
尽管如此，像所有的决策一样，我们的直觉也容易产生某种程度的偏差。虽然这无法完全避免，但意识到存在的潜在盲点并知道如何避免它们无疑有助于改进评估过程。以下是其中的一些:
1。构建软件是一个发现的过程
软件开发区别于其他工程相关学科的一点是，随着项目的进展，需求有多大的发展空间。这在很大程度上要归功于软件产品的无形本质。需求在一开始并不总是一成不变的，即使是这样，通常也有一些余地在以后修改它们。在较晚的阶段对代码进行修改通常被认为比实际上更容易。
从某种意义上来说，这是一个古老格言的变体，“顾客不知道他们真正想要什么，直到他们看到它”。这对于面向用户的产品来说尤其如此，在用户开始使用或尝试之后，他们通常会发现他们真正想从产品中得到什么——导致需求发生变化。
这是几个组织广泛使用敏捷开发过程的原因之一。我们的目标是在整个开发过程中纳入健康的客户反馈，以更好地了解产品的发展方向，并以最大限度减少以后浪费的方式编写代码。这显然有一个额外的好处，即开发评估可以随着产品需求的变化而被频繁地修改。
对于不一定面向用户的项目来说，经常与团队交流需求并保持对任何即将到来的变化(计划的或其他的)的了解仍然是有价值的。
2。帕金森定律:工作扩大占用分配给它的时间
到目前为止，大多数讨论都围绕着识别和最小化软件开发过程中潜在的低估的。虽然这显然极其重要，但理解高估特定产品或功能的开发时间的问题也同样重要。
为了避免出现承诺但没有实现的情况，通常会大量增加预算，以考虑到过程中遇到的任何不可预见的延迟。少承诺多兑现总比多承诺少兑现好，对吗？
这种方法的问题是，很多时候，如果你为一项特定的任务分配了一整天的时间，你很可能会花掉一整天的时间，即使你可以在更短的时间内完成这项任务。这纯粹是心理上的，但也是非常重要的。尽管结果可能不是非常激烈，但是简单地给自己更多的时间并不一定是减少错误估计的最好方法。
幸运的是，很多团队已经认识到了这个问题。这在一定程度上导致了基于敏捷的“冲刺”的采用，在这种情况下，工作被划分为一周/两周一次的循环。每一到两周，团队会重新组合，并为下一个周期提出新的路线图。保持周期短对评估的质量有巨大的影响，因为有更多的即时反馈。
一般来说，任务必须尽可能细化，以便更好地掌握完成任务所需的时间——无论是团队还是个人。众所周知，截止日期远在未来的大型任务和项目很难评估。
3。上下文切换
开发人员经常遇到的一个场景是需要同时平衡多个独立的项目。这通常是不可避免的，也通常是非常可取的。项目进度是不可预测的，在等待团队其他成员的时候，一个人经常会在某个阶段被“阻塞”。在这种情况下，为了最大限度地利用开发人员的时间，有一堆任务或一个备选项目需要处理，这对每个人都有好处。
但是任务之间的频繁切换也带来了实实在在的认知成本。这是因为编程可能对智力要求很高，要求程序员处于正确的顶部空间，也就是所谓的“区域”。这个区域是一种难以捉摸的精神状态，在这里生产力被提高，大量的工作通过纯粹的专注被抽出。唯一需要注意的是，达到这种流动水平通常需要相当长的时间，一旦打破，就很难恢复。
一天中任务之间的频繁转换，以及其他干扰，会导致整体生产力的降低。一般来说，为每项任务留出预先确定的时间块要好得多，每个时间块都足够长，以便在其中真正高效。
更重要的是，在每一点上，努力确保你有一个好的工作组合，它具有更高的优先级，并且作为模糊定义的工作，你可以在你的休息时间继续工作。
4。评估不能在团队成员之间转移
要认识到的一件重要的事情是，程序员在天赋和经验方面千差万别——无论是在一般意义上，还是在特定的语言和技术方面。与背景完全不同的人相比，在相关领域有更多经验的人可能对任务的难度有着截然不同的看法。因此，在进行评估时，牢记每个开发人员的个人技能水平是很重要的。
通过借鉴每个人的经验，可以实现更好的评估。让更多的人参与评估过程可以让开发人员更好地了解预期的挑战。游戏化的方法，如计划扑克也很受欢迎，并且在让每个人的意见被听到方面做得很好。
5。通信开销
最后，当涉及到有效的项目评估时，还必须考虑所有以通信开销形式消耗的时间。对于更大规模的团队来说尤其如此。
在经典的神话人月中提出的一个关键论点是，在一个团队中加入更多的开发人员，超过某个点，会有减慢它的无意效果。这主要是因为团队中的新人需要花费大量的时间来熟悉代码库。
新来的人不仅在一段时间内无法做出重大贡献，而且这也占用了那些让他们接受教育的人的宝贵时间。这使得评估项目的总体进展和做出估计更加困难，因为资源被如此频繁地转移。
同样，团队中加入更多的人也会成倍地增加沟通联系的数量。对于高度协作的项目，有很多人在重叠的组件上工作，每个人都在同一页上是绝对关键的。因此，让每个人都了解最新情况可能会带来某种形式的开销，主要是通过会议。随着人数的增加，通信开销也增加，估计的不确定性也随之增加。
显然，一个解决方案是保持团队规模小且合理，通常为 4-5 人。对于较大的团队，工作应该在重叠最少的子团队之间分配。
此外，虽然不能完全替代，但有效的异步沟通工具，如Slack/Chime/ms teams在最大程度上减少了面对面会议的时间，进而减少了团队的沟通开销。
我想用一个类比来结束我的演讲，我认为这个类比很好地抓住了软件评估的问题。对于评估，就像项目管理领域的其他事情一样，魔鬼存在于细节中。如果我让你估计一下从旧金山到洛杉矶的时间，你的回答可能是大约 2 小时，如果是坐飞机的话。如果我问你如果我们开车去需要多长时间，假设一切顺利，你会把你的估计更新为 6 小时。显然，你不可能真正计划好旅程的每一分钟。每一次意想不到的迂回都会增加和降低你的评估质量。
软件开发估计没有什么不同。他们凭借直觉和更多的信息变得更好，但永远不可能完全完美。几乎不可能为需要完成的所有步骤制定一个简洁的路线图，并假设一切都会按计划进行。我们能做的最好的事情就是运用我们的判断力，与他人合作，并意识到我们可能存在的一些盲点。希望这篇文章有所帮助:-)
如果你觉得这篇文章有用，一定要留下一些👏👏👏。请在下面的评论中告诉我你希望看到讨论的其他话题。请随时在 LinkedIn 上与我联系。