今日推薦開源項目：《黑白時代 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/
