软件编程 工作量 估算_如何估算编程时间

软件编程 工作量 估算

I really want to tell everyone how I estimate the time needed to build software projects.

我真的很想告诉大家我如何估算构建软件项目所需的时间。

In the past 10 years I’ve been asked this hundreds of times.

在过去的十年中，我被问过数百遍了。

• “We need to implement this feature. How long is it going to take you?”
  “我们需要实现此功能。 您需要多长时间？”
• “Give me a detailed overview of how much time this project is going to take in terms of time. 1 month? 2 months?”
  “就时间而言，请详细概述该项目需要花费的时间。 1个月？ 2个月？”
• “I want you to ship this. 50 hours of billable time are enough?”
  “我希望您发货。 50小时的计费时间够了吗？”

The answer to those questions have either been a bet, in the most optimistic case. Or a leap of faith, knowing that if I promised a number, that would probably have been my paycheck regardless of the actual time it took.

在最乐观的情况下，这些问题的答案要么是打赌 。 还是信心的飞跃 ，知道如果我答应了电话号码，那可能是我的薪水，而与实际花费的时间无关。

Sometimes with long term clients I was able to amortize the projects that exceeded my estimations with projects where I completed the work earlier than I expected, letting the client know.

有时，对于长期客户，我可以用比我预期更早完成工作的项目来摊销超出我的估计的项目，并告知客户。

Ultimately I ended up saying “I can’t estimate”.

最终我最终说“ 我无法估计 ”。

So, the answer to “I really want to tell everyone how I estimate the time needed to build software projects” is: I don’t.

因此，“我真的想告诉所有人我如何估算构建软件项目所需的时间”的答案是： 我不知道 。

But I can estimate that no one is really able to estimate when it comes to building software, because of the inner complexities that this field can put against you.

但是我可以估计，在构建软件方面， 没有人真正能够估计 ，因为该领域可能会对您不利。

“Real engineers” are going to find this hard to admit, but I’ve never been your typical real engineer type.

“真正的工程师”将很难被接受，但是我从来都不是您典型的真正的工程师类型。

Estimating is probably the hardest thing when working as a developer.

作为开发人员，估算可能是最难的事情。

Here’s a cool reference table you can use when you need to estimate a task

这是一个很酷的参考表，可在您需要估算任务时使用

Task	You Estimate	You Forgot	Actual Time Needed
A small bugfix	2 minutes	We need to find the function that has the bug in the source code, git pull, check that we didn’t break any other function, we need to add some tests, run the tests, fix the tests we broke, deploy, update the bug tracker	2 hours
A minor feature	2 hours	You need to fix that TODO left in the code in the function you are going to edit, and see why there is a //don't touch this comment. You need to carefully do manual testing, plus browser testing, and check why on Edge is not working like expected. Oh we need to update all the screenshots in the docs	10 hours
Improve the performance of an endpoint	10 hours	You need precise benchmarks which you can use to prove your new implementation is working correctly, and add 10 more tests that were not present before, otherwise you risk breaking production code used by 10000s of clients	5 days
Rewrite the whole frontend code	3 weeks	You just start with the new more scalable framework you were experimenting with, without touching the UI, but you run into a whole new set of issues but this time there is no StackOverflow or Google to help, as the framework is too new. You are having unique problems, and you’d need to hire the library maintainer to work with you, but he already moved on to the next great thing. While you are at it, the UI team decides to work on a complete rewrite of the interface, 2 times. The product managers at mid time wants to pivot to a slightly different product	12 months

任务	你估计	你忘了	实际所需时间
一个小错误修正	2分钟	我们需要在源代码中找到具有错误的函数git pull，检查是否没有破坏任何其他函数，我们需要添加一些测试，运行测试，修复我们破坏的测试，部署，更新错误追踪器	2小时
次要功能	2小时	您需要修复要编辑的函数中代码中剩余的TODO，并查看为什么没有//don't touch this注释。 您需要仔细进行手动测试以及浏览器测试，并检查为什么Edge无法正常运行。 哦，我们需要更新文档中的所有屏幕截图	10个小时
改善端点的性能	10个小时	您需要精确的基准，可以用来证明您的新实现正常工作，并添加之前不存在的其他10个测试，否则您就有可能破坏10000个客户使用的生产代码	5天
重写整个前端代码	3周	您只是从正在尝试的， 更具扩展性的新框架开始，而不涉及UI，但是遇到了一系列全新问题，但是这次，由于该框架太新，因此没有StackOverflow或Google可以提供帮助。 您遇到了独特的问题，您需要聘请图书馆维护人员与您合作，但是他已经着手进行下一件伟大的事情。 在您使用时，UI团队决定对界面进行两次完整的重写。 中段时间的产品经理希望转向稍有不同的产品	12个月

This might be a good estimation of our lack of estimation, but of course things can also work in the reverse: a thing you estimate might take 5 days might only take 1 day because you find everything is already in place to add it, and it takes much less than anticipated.

这可能是对我们缺乏估计的一个很好的估计，但是当然事情也可以相反：您估计的一件事情可能需要5天，可能只需要1天，因为您发现已经添加了一切，并且已经添加花费比预期少得多。

Some might overestimate, projecting they might have difficulties, adding a 30% more of what they think.

有些人可能高估了，预测他们可能会遇到困难，他们的想法增加了30％。

Team projects estimation is even harder, I won’t even try.

团队项目估算更加困难，我什至不会尝试。

What to do then?

那该怎么办？

Instead of detailed estimating, I propose continuous communication with the client or boss or whoever commissioned your work, and do weekly checkups on the project progress. Without pre-defining when the process will end.

我建议不与客户或老板或委托您工作的人进行持续沟通，而不是进行详细估算，并每周对项目进度进行检查。 无需预先定义过程何时结束。

Because after all the process will never end.

因为毕竟这个过程永远不会结束。

翻译自: https://flaviocopes.com/estimating/

软件编程 工作量 估算