今日推荐开源项目：《黑白时代 gameboy.live》
今日推荐英文原文：《Software Estimation: the art of guessing》
今日推荐开源项目：《黑白时代 gameboy.live》传送门：GitHub链接
推荐理由：一个 Go 的学习过程中产生的复古产物，可以让你重新体验一下复古的黑白老游戏。说真的，现在的塞尔达，口袋妖怪和马里奥的画面和以前已经可以说是两个世界的产物了，但是在很久以前，兴许我们更看重的是游戏性。不管怎么说，尝试一下在没有精美画面的加成下体验游戏性兴许会找到不同的乐趣。
今日推荐英文原文：《Software Estimation: the art of guessing》作者：
原文链接：https://medium.com/@katrinaprieto/software-estimation-the-art-of-guessing-f7f1c8228d69
推荐理由：没有人能预知未来，所以回答类似于“完成它还需要多久”这样的问题的时候需要一些技巧
Software Estimation: the art of guessing
As a software developer, you will oftentimes be asked the dreaded question of “How long will it take?” Software Estimation is a necessary skill in this profession and it happens to be one of the my least favourite task.Throughout my 4 years of experience being a developer (I know it’s not a long time), I find that I still haven’t perfected the “art” of software estimation. I find myself constantly asking my managers for guidelines on how to do it properly or what thought process I should follow, in order to come up with an accurate software estimate. Well here’s the thing, it’s called an estimate for a reason. It’s never going to be accurate.
But there are several things that I’ve learned throughout the process that helped me provide an estimate that closely represents the efforts required to execute and complete a project.
It’s all in the details
Get as much details as you can about the project. Always ask questions and clarifications on the requirements. Sometimes it’s unavoidable to have assumptions and base your estimate on it. But obviously, you’ll have a much more accurate estimate if you get rid of all ambiguities.Sizing
Your estimates aren’t necessarily going to be directly proportional to the size of the team. For example, if your initial estimate is 4 weeks to build a feature; adding one more developer doesn’t necessarily mean that the feature can be completed in 2 weeks time. The estimates should actually grow exponentially with respect to the team size. With larger teams, there tends to be a lot more time spent in communication between developers, or ramping up a new developer, and familiarizing themselves with the code base.Break it down
It’s easier to provide an estimate for several small tasks than one big task. You’ll get a much clearer picture of the work involved if you break the requirements down into smaller components.Historical data and personal heuristics
Chances are, there is already an existing project that is similar to the project you are estimating for. Use this as a reference and and ask the previous team members about their experience with this project. They could potentially give you an idea of how long it took them and what challenges they encountered along the way.Typically, the estimators are chosen to provide the estimates because they are qualified or have a similar previous experience. However, there could be a time where you are unfamiliar with the technology or platform that will be used. In this case, refer to your personal heuristics i.e. make note of your learning and development style.
Someone once told me that providing estimates for a project that you are unfamiliar with, is actually to your advantage because you would be able to provide a number that already accounts for some extra padding.
Account for possible tangents to the project
Changes to the project requirements are inevitable. They happen more often than they should during the entire project lifecycle. Customers don’t usually know exactly what they want until they see what has been built. Sometimes your customer wants additional features or completely change a design which could drastically shift the priorities, and cause for the overall project direction to go off at a tangent. These changes can introduce new parameters and impact the level of effort required for development. Always give some leeway to accommodate these possible changes.Don’t be too optimistic
Having too much optimism can lead to a highly inaccurate estimate. You need to take into account the unhappy paths. It’s better to anticipate that things might not go according to plan.Double up
Finally, once I have my initial estimates, I usually double up the number. For example, if you estimate 1 week, then double it up to 2 weeks.It’s common and likely that you will not be the developer working on the project that you are estimating for. Your estimates are not transferrable to other developers because everyone does things differently and perhaps the dev that will work on this, does not have as much experience as you do. Hence, other devs may take more time than what you had estimated. So it’s always good practice to add some padding and scale up your numbers.
Keep in mind that software estimates are never accurate. They are almost always wrong, so just exercise your judgement and do your best with the information that you have access to.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
