In general, how does one evaluate the workload?
- Analogy estimation: estimate the workload of similar projects, and then adjust the estimated value according to the actual situation.
- Parameter Estimation: Our company may lack data support in this aspect. For example, we can estimate the number of lines of code that a project may have and the skills of its members. For example, a project may have 10000 lines of code. A general-skilled development engineer can complete 500 lines of code in a day, so the development may take 20 person-days.
- Three-point estimation method: aims to minimize the uncertainty of estimation. Estimate the most pessimistic, optimistic, and possible values for a function point, the final estimated value = (the most pessimistic estimate + the most optimistic estimate + 4 * the most likely estimate)/6.
- Delphi Method: A group of experts estimate the project.
The specific steps are as follows:
1. The organizer sends each expert a software system specification statement in a form that records the estimated value. Ask the expert to estimate the value.
2. After the expert studies the software specification in detail, the most optimistic estimation value, the most likely estimation value, and the most pessimistic estimation value are presented for the software.
3. The organizer sorts out the answers in the expert table and calculates the average E = (the most pessimistic estimate + the most optimistic estimate + 4 * the most likely estimate) of each expert. 6, then calculate the expected value: E = (E1 + E2 + .... + EN)
4. After the conclusion of the process, an expert is assigned an anonymous form to compare the estimated deviation and find the cause.
5. the above process is repeated multiple times, and eventually a software scale agreed by most experts can be obtained.
- Team Estimation Method: similar to the Delphi method, but the form is loose. The team members involved in the evaluation include the roles of the project team. The team puts forward their own estimates for a function, if the comparison is close, an average value is calculated as the estimate value. If the difference is large, each person gives an opinion on the reason for the evaluation, and then carries out the second round of evaluation until the evaluation value is close.
- Planning poker: an evolution of the Delphi method. Each color of agile poker is an estimated playing card consisting of 13 cards. The cards are printed on the front of the card with numbers and symbols for estimation. The numbers are 1/2, 1 ~ 10 and 20, with the symbol "!", Represents unknown situations, such as failure to provide accurate estimates. Generally, we recommend four to eight people to make an estimation. If the number of people is too small, the estimation result may be greatly different. If the number of people is too large, the estimation time will be extended to reduce the estimation efficiency. During estimation, we often estimate relative values instead of absolute values. Be careful not to study the code writing details in depth. These are issues that will be solved after actual development. Generally, a unified opinion can be obtained in at most three rounds. If you still don't get a unified opinion after three rounds, for example, the result of the fourth round is still 2, 5, 5, 8; then scrum
Muster should immediately interrupt the estimation of this item, and take the average value or other acceptable values as the estimation result. No estimation is highly reliable, and poker is no exception. The purpose of poker estimation is to be as short as possible, this gives Team members a better understanding of what they need to do, along with an acceptable estimation result.
In fact, every estimation method is only estimation, and the estimation results may be inaccurate. Therefore, we should not first make sure that the conceptual estimation results are consistent with the actual results. During estimation, the project manager should flexibly use various estimation methods based on specific situations, and integrate the strengths of various methods to make the estimation results as close as possible to the actual values.
How can I evaluate the workload when the requirements are unclear?
- Given the magnitude of the evaluation, the demand is not clear, so the estimation is not accurate, the error is likely to be relatively large.
- Reserve: the reserve must be sufficient, and the more unclear the demand, the more reserve.
- After all: there must be a limit for unclear requirements. The overall scope of the project and the overall framework must be determined before the project can be taken over.
- It is inevitable to accept the change of the plan. Since the demand is not clear, the possibility of the change of the plan is very large. We need to communicate with you in advance.
How can I evaluate the workload across departments?
- Each department is responsible for providing its own workload evaluation.
- A dedicated contact person is responsible for coordinating resources and providing evaluation results.
- Trust. In many cases, we do not understand the work and process of the other party. Therefore, trust is very important.
- At the same time of trust, you can learn as much as possible about the work of the other party, accumulate experience, and prepare for future judgment.
How to arrange the schedule?
Theoretical Basis: PDM (single-code network diagram), Key Path Method and key chain method, time advances and lags.
Procedure:
- First, we will detail each function point of the project and work out what we need to do for the function points.
- Organize the logical relationship between each task to form a network diagram.
- Evaluate the workload of each job.
- Arrange the owner of each task.
- Adjust the Network Diagram based on the specific owner and workload.
- Discharge specific progress plans
How to deal with demand changes?
- Beforehand:
The change process is still required.
The change process can be divided into the scale of demand changes, and different processes can be formulated based on big, medium, and small changes.
- In-process:
The implementation process may need to be flexible, and the priority and urgency of the requirements need to be grasped. It cannot be changed, but it is still necessary to stick to the process. Otherwise, it is only possible to mess up the process. If the release time cannot be changed and the demand must be fulfilled, we can only find a solution from other aspects. Refer to the hexagonal.
- Afterwards:
We will summarize things for people. In the future, for similar things, we will need to consider more risks of demand changes.
How can we control the scope of requirements for projects with unclear preliminary requirements?
- The details of the preliminary requirements can be unclear, but the scope of the entire project needs to be determined.
- It is best not to iterate the overall design of the project, or do not intend to iterate, and make a unified planning for the overall design at the beginning.
- After the overall design is complete, let's look at the functions of each part separately. Divide the system functional points of each part, the priority between each functional point, whether the requirements are clear, and whether there is a correlation with other functional points.
- For clear functional points that are not closely related to other functional points, develop and test functions first. At the same time, it also refines the unclear functional points.
- Focus on controlling demand changes.
- This depends on the overall view of the Project Manager, whether the overall design of the project, the association between functional points have a good grasp.
