Turn: planning is more important than planning-agile progress grasp

Bytes ?"

 

When asked, the project may be finalized, only the approximate functional modules are known, non-functional requirements are vague, and even the team members are not in place. However, superiors, sales personnel, and customers are eager to know when the project will be completed?

 

When asked, the project may be nearing the end, or the planned delivery date. However, there are still a bunch of functions to be completed.BugThere are a lot of new requirements raised by the customer, and the team is about to leave..... However, superiors, sales personnel, and customers are eager to know when the project will be completed?

 

This is not bad. The biggest headache is: "should the project be completed in three more weeks ?"

 

Because the latter is not a problem, but a command. The project manager must be able to reasonably explain why the project cannot be completed within three weeks, or explain what can be done within three weeks.

 

We usedMS ProjectBut the beautiful table above does not help with such a dilemma. On the contrary, it isProjectThe Gantt chart and calendar in the table are buried in the trap. Because, inProjectIt cannot predict how many working days it will take to complete the ambiguous demand, or reflect the impact on the progress after the actual situation changes.

 

When we discuss the progress, there are actually two unknownVariable. The first is the workload required to complete the requirement, including the requirement definition and development content boundaries. The second is the team's ability to work, including the members' industry knowledge and professional skills, communication skills between members, members, and external parties.

 

The key lies in that both are variables. If the task is to move one thousand bricks, each person can move each minute10The result is obvious.

 

In Agile developmentRelative EstimationAndIteration refinementTo handle the project progress.

 

The first is the workload. EstimationCodeThe number of rows or interface elements, likeAbout selling booksThe same applies only to the crude software production process. What users need is not code or button, but a reliable and easy-to-use function.

 

In agile mode, users and designers first roughly estimate the relative scale and difficulty of each function module and give a certain score. The score does not represent the specific person-month,Play a relatively comparative role. For example, there are three modules: Query, display, and modification. If the workload of the display module is10The query module may be15And change20Points.

 

Next, select a module with the lowest workload evaluation score, for example, the display module, and further consider its workload. For example, you need to prepare the database, design the interface, execute the query, and display the content. Assume that this round of estimation is required for this module.10Man-day, so that the person-day corresponding to the unit score is1; Then, the entire project needs45Man-day.

 

This estimation is based on a preliminary understanding of the project and mainly relies on the experience of the Project Manager. Is there any deviation? It doesn't matter. Next, we will refine the performance through iteration. First, implement the display module.12Man-day, according to the proportional relationship, the estimation of the remaining content is about42Man-day.

 

Of course, the proportional relationship is not static. As the modules are completed one by one, the project manager's understanding of the project is also deepened, and he can adjust the relative score of the remaining modules.

 

In practice, the Project Manager first lists the functional modules by priority. Next, we will divide the modules with a higher priority as much as possible, and then select the module with the smallest score to start development. When calculating the total workload, add the workload of other modules in proportion and add a certain adjustment coefficient, because the complexity of the modules does not increase linearly. After each iteration, the adjustment coefficient is gradually reduced. Usually4 ~ 5After the next iteration, you can set the adjustment coefficient to zero.

 

In the above example, the initial result of the first estimation is45Man-day, because it is based entirely on experience, it is necessary to give a large adjustment coefficient, such0.4Therefore, the estimated workload range is[45*0.6, 45*1.4],That is27To63Between Man and day. For the sake of insurance, the workload reported by the project manager is70Man-day.

 

For the second estimation, the initial estimation of the remaining content is42, The adjustment coefficient is reduced0.3Therefore, the estimated range is30To50Between Man and day. So far, through continuous iteration, the estimation of the remaining workload will become more accurate.

 

What are the benefits of this estimation?

 

First, a large part of workload variables exist in non-functional requirements, such as the appearance of the interface. Different modules of the same project often have the same non-functional requirements and are relatively estimated.AlgorithmThis layer of complexity is filtered out. The same is true for the team capability variable. Of course, as the project progresses, the development capability of members should be increased to a certain extent. However, with overtime and other factors, the investment may also decline, which will offset each other. In short, in the cycle6In projects of less than a month, the team's work ability rarely changes dramatically. Therefore, relative estimation also filters this complexity.

 

Secondly, the iterative refinement method makes the project manager more confident about the estimated time. Deviations are inevitable at first, but as long as the team is stable and there are no major changes in demand, the scope of estimation will be quickly reduced. This is more accurate than the one-time report.

 

Its additional advantage is that agile development follows the priority level. Even if the estimation of the remaining time (that is, the development time of the low-priority module) is not very accurate, the impact is not very great.

 

Compared with Gantt chart, the development time of each module should be estimated at the initial stage of development to count the total amount. This is the waterfall development mode.

 

On the other hand, the Progress problem is how the project manager understands the development speed of the team and each developer. After a task is assigned, the project manager knows how to estimate the actual task completion time.

 

In the agile development process, developers can estimate the time required to complete the task. Of course, each person has different abilities. Each person has a different mentality. Some people are conservative and others are optimistic. It doesn't matter, but it depends on iteration to improve gradually.

 

At daily meetings, developers are required to reevaluate the remaining development time of the current task. Different fromProjectCount the time spent by each person in the task every day. The agile method only cares about the time required for the task to be completed until it returns to zero, and then calculates the actual working time.

 

Why? Because the time spent in statistical development is meaningless. This is different from bricks. It may have been used yesterday.8There is no progress in an hour. If you think about it today, you will get twice the result with half the effort.What we really care about is how much time is needed to complete the task, rather than the unrecoverable time cost.