今日推薦開源項目：《車還有多久啊 mini-tokyo-3d》
今日推薦英文原文：《Estimating a Software Deadline Is Really Hard — Let』s Talk About Why》
今日推薦開源項目：《車還有多久啊 mini-tokyo-3d》傳送門：GitHub鏈接
推薦理由：這個項目使用 3d 的方式展現了東京地圖，準確地講是東京的交通運輸地圖。從開放 API 中讀取數據就能夠讓這些方塊作為地鐵火車什麼的跑起來，觀賞性還是相當高的，倒不如說看著地球上某個地方在運作什麼就是一個有趣的事情——最大的原因大概就是因為人類總是因為這樣那樣的原因不能隨便出去玩吧……
今日推薦英文原文：《Estimating a Software Deadline Is Really Hard — Let』s Talk About Why》作者：Costas Andreou
原文鏈接：https://medium.com/better-programming/estimating-a-software-deadline-is-really-hard-lets-talk-about-why-44687a6baf9d
推薦理由：你需要一個計劃，雖然它永遠趕不上變化
Estimating a Software Deadline Is Really Hard — Let』s Talk About Why
The 5 laws you need to know for planning
As you progress through your career, you might find yourself taking on more and more responsibilities until you find yourself in a managerial role. You will be responsible for the delivery and often quality of work that is outputted by the team.To ensure that the team remains fully occupied and that the team members are efficiently and effectively utilized, you will be required to plan for the future.
「If you have to forecast, forecast often.」 — Edgar FiedlerPlanning for the future often sounds easier than it is. Every planning decision made, every forecast completed, is made on the back of a significant number of assumptions. If any of those assumptions are wrong, you can wave your plan goodbye.
As you become experienced in the dark arts of estimating the work required for each task necessary to complete a project, you will identify areas of improvement and you will begin implementing your own laws.
That is, you will come up with some rules that will help enable you to have more accurate estimates.
In this blog, we are going to cover some widely accepted laws that are out there, which could potentially help us plan better.
1. Hofstadter』s Law
「It always takes longer than you expect, even when you take into account Hofstadter』s Law.」This law was coined in 1979, and it is as true today as it was back then. It is a widely accepted law in the software community, highlighting the difficulty involved in estimating how long work will take upfront.
To battle this problem, there have been many techniques developed by different teams and organizations. A quick Google search will provide you with more ideas than you can ever use.
My favorite technique is something called Planning Poker. Planning Poker is a team-based activity that takes estimates from the whole team.
Each person in the team is given a deck of cards typically following the Fibonacci sequence and then are asked to estimate a task. Once each person has chosen their estimate, they put their card on the table, face down.
When everybody has done that, each person turns their card around and announces their estimate. This is then followed by a team discussion, attempting to converge to the widely accepted estimate.
The beauty of this method lays in its sub-components. Being a team-based activity ensures that the overall consensus wins, decreasing the chances of missed aspects to the work, and increases the team』s sense of ownership to the estimates.
Using the Fibonacci sequence means that the distance between each available number increases as we move up the sequence. This helps cater for the additional complexity introduced by larger pieces of work.
2. Murphy』s Law
「Whatever can go wrong, will go wrong.」This is a famous adage that you may have come across before. It is applicable to every walk of life and certainly applicable to the estimation process of software development work.
Murphy』s law fits nicely with Hofstadter』s law that we』ve seen previously. When coming up with estimates, people tend to be optimistic and may not cater for any big surprises.
Even if we were to change our estimates to cater for this fact, Hofstadter's law reminds us that we might still be under-estimating.
To ensure a level of comfort in our estimates, I suggest that we always build in some level of contingency. Generally, a 10–20% contingency over the original estimate is not only recommended, a lot of the time it is expected.
3. Parkinson』s Law
「Work expands so as to fill the time available for its completion.」Parkinson』s law is actually something that can be observed on a personal level.
Deadlines have a funny way of shaping how we approach problems and the work we do. When we have a long deadline, we may get distracted, (read: procrastinate), and we may approach problems in a different way.
Strict deadlines tend to focus us, and allow us to cut through the unnecessary. It is true that quality might suffer to meet the deadline, but worth keeping in mind.
How then do we use Parkinson』s law to our advantage?
Following our earlier conclusion of building in a contingency into our estimates, we need to ensure we keep this extra time separate from the original estimates.
If we were to distribute this extra time to each task, we would end up suffering from Parkinson』s law and burn through our contingency without any benefit.
4. Sturgeon』s Law
「Ninety percent of everything is crap.」Sturgeon』s law often helps simplify things when it comes to estimation.
Whenever there is an unknown as to the quality of the existing solution or the availability of tools, one could simply refer back to Sturgeon』s law. It is a great starting point, because things very rarely can be or get worse than that!
Armed with what we have seen so far, we can easily deal with the unexpected. To further make things easier for ourselves, we can ensure that the tasks we are estimating they are as small as possible.
We don』t want to go too granular, otherwise, we will never finish this process, but we don』t want to be estimating too large of tasks either.
5. Brooks Law
「Adding manpower to a late software project makes it later.」This law was coined in the popular software engineering and project management book The Mythical Man-Month. It is one to keep in mind when dealing with estimates and planning on how to meet deadlines.
This law has its basis in the economics law of diminishing returns, where at some point of adding a new resource to a task, the output starts to decrease rather than increase.
This law, of course, is an oversimplification, as there are many cases where it does not hold true. For example, if the resource joining the project is already familiar with the codebase and the project, they could hit the ground running and have an instantaneous benefit.
Additionally, if the deadline for the final deliverable is many months down the line, the extra resource might have time to turn things around. Usually, onboarding someone new into a project will take time off of existing resources to help answer questions and get them settled in at the beginning.
Summary
In this article, we have started with the premise that you will be responsible for estimating and planning ahead for the project. However, as you may have seen from the article, everyone in the team will have something to add to the process.Let us quickly summarize some of the key takeaways:
- Involve the team as a whole when it comes to estimating upcoming work to increase the sense of collective ownership and better validate the estimates.
- Always try to estimate smaller pieces of work (within reason), to have better estimates.
- Always add some contingency to project work to cater for the unexpected.
- Keep the contingency separately from the rest of the estimates and do not distribute it to each piece of work.
- Be careful when adding extra resources to an already-late project as they can lead to the project being delayed further.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
