Trial experience of key chain project management software agilecc

At the invitation of wingy, I used the agilecc key chain progress management software. Before using the service, I had two most important questions: the first was the degree of support for the preparation of the progress plan under resource constraints, and the second was the calculation and analysis of the connection buffer and project buffer.

First, assume a simple software development project plan, which has only one requirement, one designer and two developers in addition to the project manager. The requirement can only undertake the requirement development task, the design can only do the design, the encoding can only complete the encoding task, and cannot be a string of roles between each other.

The entire task is divided into three iteration cycles. Specifically, there is no clear requirement at the beginning. There is a mandatory dependency between the design and coding tasks in each iteration cycle. System tests can be performed only after all codes are complete. After a task is created, the most likely and pessimistic periods of the task are set to facilitate the calculation of the buffer size. After the schedule is set, resources are allocated to each task. After the resources are allocated, the experiment is conducted through automatic resource balancing. The results of automatic resource balancing are quite satisfactory. The whole progress plan is re-calculated and sorted based on resource constraints. Both requirements and design are subject to one resource constraint, the system serializes the original parallel tasks according to resource constraints, and automatically calculates which of the three iteration cycles starts first to obtain the shortest project duration.

For the connection buffer and project buffer length, agilecc supports two common calculation methods. One is "SRSS". To use this method, you must enter the average and worst-case time periods of the task. agilecc uses the sum of the squares of the two difference periods of each task in the task chain and then square them, the buffer length after the task chain. This calculation method assumes that the schedule changes of each task are independent of each other, sometimes the error is large, and the buffer length obtained is too short. This method is generally not recommended. Another method is to set the ratio. This is a very simple calculation method. Multiply the length of the task chain by a proportional coefficient, and the result is directly used as the buffer length. The proportional coefficient is usually 50%, you can also adjust the proportional coefficient according to the uncertainty of the project period.

After the automatic calculation is complete, we re-analyze the key chain, add project buffering, and highlight the key chain to get the table.

You can see that the project automatically calculates the project buffer that requires 5 days based on the possible time and pessimistic time. When any task in the critical link in the project network diagram is delayed, the project buffer is consumed. Tasks marked in red as on the key chain, marked in orange, yellow, and green:

Tasks marked as orange. tasks with IDs of 8 and 9, although not critical tasks, do not have a long enough gap (connecting to the buffer zone) between these tasks and key tasks ), in the worst case, these tasks will be postponed and hit the key chain, leading to project buffering erosion. In addition, tasks marked as orange immediately advance to the earliest possible start time, and there is no way to set a long enough gap to protect the key chain. These tasks should also be closely monitored during project implementation, and it is best to arrange these tasks to start as early as possible during planning.

Tasks marked as yellow, such as tasks with ID 15, although not critical tasks, do not have a long enough gap (connection buffer) between these tasks and key tasks ), in the worst case, these tasks will be postponed and hit the key chain, leading to project buffering erosion. Unlike tasks marked as orange, if you move these yellow tasks some time in advance or insert a connection buffer task, there will be enough gaps to protect the key chain. When preparing the plan, you can consider these tasks in advance or add a connection buffer to fully protect the key chain.

Tasks marked as green do not run into the key chain in the worst case.

The calculation of these tags is achieved by comparing the actual buffer size with the pessimistic time of the task, which has a strong guiding significance. The connection buffer has not been tested yet, and the tracking of the buffer consumption during the actual execution of the task has not yet been tested. The software improves the time buffer, resource buffer, and capability constraint buffer. It also supports key chain Progress Management among multiple projects, which requires further research and use.