Preamble
This article will introduce how to spend effort on working.
What is Effort?
Effort means the total estimated time until a task is completed at work. It is different from the meaning of the phrase TAT (Turnaround time) that appeared during the FE exam.
For example, in case there is a task that takes 40 hours to complete, it can be said that effort is “40 hours”. If an 8-hour working day, you can understand that “40 hours” is 5 man-day. Also, if a 20-month workday, 40 hours would equal 0.25 man-month.
Usually man-day and man-month will be the units used to calculate effort.
When you were a student, you didn’t pay much attention to effort, but if you become an IT engineer working in a company, you need to know about effort.
Why need a sense of effort?
There is a need to have a sense of effort because the working time that employees can do is limited.
According to the Labor Law, employees working at a company, not the company operator, will have a maximum working time limit. In 2015, due to the overtime incident in a large enterprise, the overtime regulations became stricter. People who die from overwork are due to over 80 hours of overtime.
Also, partly because of budget issues. Normally, office workers are paid by working hours, so even if they meet the standards of labor law, if the company budget is not enough, they still have to limit overtime.
Under the bubble economy more than 20 years ago, which had no phrase “reform of the way of doing things”, the company also had a lot of money so employees considered abnormal extra work to be a normal thing. But that era is over.
C in QCD
IT engineers need to be aware of QCD when working.
- Q = Quality
- C = Cost, that’s effort
- D = Delivery
This article will talk about C in QCD.
The importance of effortless estimation
Before starting the task, you must first make an estimate effort to do that task.
As I mentioned above, if an IT engineer works professionally, there will be no infinite time on the task, but must limit the time that can be spent on that task. In addition, a task may have to be done in parallel with another task, if more effort is spent to make one task, then it is not enough effort to do another task, and as a result, the task schedule will be slow.
So first you must lock the “Estimated value” for effort to do the task. In addition, it is necessary to make this estimate (effort est) not excessively effortless to use in practice, so this estimate job is actually a difficult task that many people find difficult.
In short, it is important to achieve:
|
1 |
Actual Effort <Estimated Effort |
If missed as effort actually exceeds effort estimation, there will only be a way to continue until completion, effort to complete other tasks will be reduced but no more effort will be made, then dev will be put in a difficult position. .
In general effort estimate is the protection of yourself so it is important not to make it bigger than the actual effort. If effort actually exceeds effort estimate, then roughly the responsibility belongs to the person who made estimation.
Cases without needing effort (?)
Pay attention when not estimating effort but receiving requests from higher levels like:
- Folding project, please do in MM / DD offline.
The possibility is to prioritize delivery so it must be done with fixed effort until release. If it is okay to follow the wobbly way, then maybe not needing a real estimate, but I do not recommend this.
How to estimate
Essential
It is very important to express the estimation by formula in a logical manner. The worst is estimate arbitrarily. For example, the job of an IT engineer is a programmer, let him estimate for “fix software bug”. For example, with this way of estimating like this: “In general, we don’t know yet but it is probably about 3 days”.
3 days so effort estimate will be 3 man-day (24h). However, this number does not have any basis, so there is no trust. But if this is the conclusion of an experienced engineer, then there is no problem. Because trust comes from the intuition of a person on experience, not an arbitrarily given number. In order to conduct a high-precision estimate, it is not necessary to pay attention to the following important points.
- Break down tasks and give each small number
- Feedback on past achievements
- Add buffers
- Thanks to the superior check cross
Split tasks
If hobby software development is often very focused on code, there will basically be flow as follows:
- Investigate the cause of the bug
- Fix the code with a bug
- For operation to confirm editing
However, when working seriously, the stages will have many changes. Depending on the company and the project, the culture will be different, but the flow is often as follows:
- Investigate the cause of the bug
- Fix the code with the bug
- Run the program, confirm editing If it is a job, the steps will change quite a lot. Depending on the company, depending on the project, it will be different but usually follow the flow as follows:
- Investigate the cause of the bug
- Guess whether the root cause is. If not then go back 1.
- Evaluate why there is a bug
- Review method of fixing bugs. Correct so that the scope of influence is minimal
- If it is a bug in structural design, it is necessary to modify the design
- Edit source code
- Cross review. Do 5.6 times before completing.
- Perform unit test with the edited place
- Conduct test funtion in the editing place
- Conduct regression test at the editing place As above, you must understand that it is not only easy to edit the source code. Only one word “fix bug” but broken down into multiple items. I will have to estimate for each item.
| Item | Effort (H) |
|---|---|
| Investigating the cause | 8 |
| Consider how to fix | 3 |
| Edit design | 2 |
| Edit the code | 2 |
| Create TCs | 2 |
| Review | 2 |
| Unit test | 3 |
| Funtion test | 5 |
| Regression test | 3 |
| total | 30 |
(continue)