IT project management-panel management

ArticleDirectory

• 2.1 How to reduce the waste caused by Rework
• 2.2 how to avoid multi-task Parallelism
• 2.3 How to Reduce the inventory of semi-finished products and shorten the delivery cycle
• 2.4 measurement, planning and other aspects of iterative Production Capacity

As the manager of a development team, for example, when you are a project manager of a team, the completion of tasks is usually one of your most concerned content, for example, whether the assigned task can be completed by time, whether the progress of the entire project is still under planning, whether all the people in the team are working efficiently, and whether there are any difficulties, these are issues that you will always pay attention. In a software development team, task allocation, tracking, and management are usually an important task for the team manager.

1. Start with the question

I have met a project manager who manages a team to develop a web application. There are about 10 developers in the team, 3 testers, and 1 business analyst. This is what she does for task management. In general, she will divide the requirements obtained by the demand analyst. Then everyone promises her a rough time point after receiving the task. The delivery plan of the entire project is managed in an Excel table, based on the delivery time point requested by the customer, and considering the integration test relationship between some requirements, the general delivery time points for each requirement are determined. As long as each developer promises little difference between the time point and expectation, she can accept it. Every developer knows at what time point they should deliver something.

Everything should have been perfect, but the problems of discord keep emerging. The most common thing is that you cannot deliver the service on time when the promised time is approaching. Every time she asks about the progress, she will be told that it is almost done. The general saying is that "the bottom layer has been completed, or the page can be done even if the page is still poor". However, the actual situation is that it takes quite some time to complete. Of course, this is not a requirement for delivery on time, but she found that it may be because everyone often works overtime and is tired. Sometimes it is very easy to fulfill the requirements in advance, the test was only delivered at the last moment.

Some developers will work in batches after obtaining their own batch of requirements, and implement all the underlying logic of several similar requirements, and then implement the upper layer content. She chose this approach by default, as the developer said, "These requirements are almost the same. as long as the underlying layer is done, it is almost done ". Although this part of work will be better done early in integration testing with others, it can only be pushed back to the integration testing time point. Fortunately, we promised that the delivery time for the test team would be one month later, as long as these needs could be fulfilled within one month.

There are also some other problems. For example, some new people often encounter problems. However, when a problem occurs, they do not take the initiative to ask other people. Instead, they waste time trying. Another developer in the group is very radical and often spends time refactoring.CodeThe progress in pursuing a perfect architecture design is worrying. Developers in the group are often disturbed by other projects, because several of them have just been called from the previous project. Some Problems of the previous project are only familiar with and capable of solving them. She found more than once that a developer often fixes bugs in other projects.

She will ask every developer about the development progress from time to time. When the planned delivery time point of the requirement approaches, this kind of check will become more and more frequent and developers will feel the pressure, sometimes you even need to work overtime to complete development. However, although she spent a lot of energy tracking and checking the fulfillment of each requirement, there are still many unexpected things happening. Although she has always believed that as long as developers can complete the task, she does not intervene in what method, and the specific time is allocated by themselves. However, she gradually felt that the tasks were getting increasingly uncontrollable and that the plans could not be completed on time. The daily inspection of everyone took most of the time, but it could not reveal the real problem.

Projects that run well are similar, and the problems of problematic projects are different. Although each team may have different problems, it is not difficult to find common problems, such as multi-task concurrency, when we examine the operation and management methods of these projects, these problems cause various waste to software projects. When a team adopts the waterfall development model, the testing staff will introduce the development activities after the development phase ends. During a long development phase, waste in various development activities, inaccurate estimation, and member delays, interruptions, and problems blocking are all concealed. As long as all the development can be completed before the final time point, whether it is loose and tight, or working overtime and staying up late, it has become the norm of project development. The Project Manager can only see the final delivery time point, and the problem cannot be exposed in time. When the problem is exposed, the adjustment methods can be used very limited.

Such a team's survival status requires a short delivery cycle in the external environment, and the demand allows frequent changes, it shows extremely inapplicable. Changes in the market environment drive changes in software requirements, which lead to demands for shortening the delivery cycle. A short delivery cycle makes it unnecessary for people to anticipate too long-term demands, ability to quickly develop and adjust software requirements based on market changes. When the delivery model is transformed from a waterfall model of several months to an iteration model of weeks or even shorter, we talked about various waste, inefficiency, and accumulation of semi-finished products in the team, it will burst out.

Readers familiar with agile methods may know that agile methods include a series of practices to help teams achieve fast delivery in a short cycle and better respond to demand changes. For example, the user story method organizes requirements from the perspective of user value to avoid dividing requirements from the perspective of function modules. Small-granularity user stories can complete development and testing (parallel development) within one or two weeks, which can shorten the delivery cycle. The problem is, in an agile team, how can we effectively manage a large number of small-granularity user story while avoiding problems in the above project management? Next we will use the Panel tool in Agile development to see how agile teams manage tasks.

2. Visual dashboard Task Management

Kanban originated from lean production practices. agile draws on the visual management concepts behind it. After some transformation, it forms a visual management tool with its own unique style. Someone once summarized the use of scrum and Kanban [1], and many times we call it an iteration status wall.

Let's take a look at how we can use this status wall to manage iteration tasks. It is actually a very simple thing.

The status wall of an iteration usually reflects the plan and task progress of an iteration. The status wall is divided into several columns according to the typical development activities of the Team in an iteration, for example, "to be developed", "under development", "to be tested", "under test", and "completed test. At the beginning of an iteration, we will put the story planned to be completed in this iteration into the "to be developed" column. One advantage of the visual status wall is that all team members can learn the plan and progress of this iteration in real time. When a developer receives a task, he moves the story card he receives from "to be developed" to "under development", and adds a sheet of paper with his own name. After the development is complete, move the story card to the "to be tested" column. When our testers see the story cards to be tested in this column, they take one and move it to "testing" to start the test of this user story. After the test is complete, move the story card to the "test completed" column. If a tester finds a bug, he can use a red card to write down the bug and put it in the column to be developed. On the Status wall, in addition to user stories and bugs, there will also be some tasks such as restructuring and building a test environment that do not directly generate business value. These three tasks use cards of different colors, put it on the Status wall for unified management.

How can such a simple tool help us eliminate waste and solve problems in project management? Let's take a look at it one by one.

2.1 How to reduce the waste caused by Rework

Rework is a serious waste in software development. For example, when the tasks completed by developers are handed over to testers for testing, the key processes cannot be passed and the testing process is blocked; the customer said that "this is not what I want". The analysts handed over the tasks that have not been thoroughly analyzed to the developers, during the final acceptance, we found that the developers added some of their own "play ". This will cause rework. Rework means that you have not done the right thing at a time. It means that the upstream of the process has not delivered high-quality work, and it may also mean that there is a problem with communication between team members.

In the traditional waterfall process, we often expect to make sure that the work in one stage is handed over to the next stage only after being completed with high quality. Later, we learned from the failed experience that this method is too fragile in a changing demand environment. It will not only fail to ensure quality, but also cause greater waste, the delivery cycle cannot meet the requirements. So we introduced the iterative development method [2]. The analysis, development, testing, and acceptance of a requirement has become a more continuous process with a small granularity. In this small delivery cycle, dashboard helps us manage the quality of each stage of a task at a more detailed granularity.

We usually do this. When we move a story card from "to be developed" to "under development", this card must have been analyzed. That is to say, before developers are ready to really start developing this story card, our demand analysts must ensure that all the content and details contained in this card have been analyzed, there are no ambiguous details, and there is no space for developers to make full use of themselves or imagine themselves, and these details must be confirmed with the customer, not just the results of the team's own "design.

This level seems very common. In fact, many projects may have problems here. Many times, when developers start to develop, the demand has not been analyzed yet. Many details need to be clarified and confirmed, and the technical risk on implementation has not been completely ruled out. Some analysts are also good at giving developers a lot of space to exert themselves, and the demand is too concise. When developers start to develop such requirements, they either cannot do it or do it according to their own understanding. After the analysis is done, the analyst finds that it is incorrect. It is different from what I think, so the developer reworks. The worst case is that the customer finally discovered that this is not what I originally wanted.

It can be seen that, when developers move the cards, this user story to be developed has been truly analyzed and is the first step for us to accurately meet user needs. By specifying the premise of this mobile card, coupled with the clarification of user stories (clarified by analysts to developers) or reverse clarification (explained by developers to analysts ), to a large extent, rework can be minimized.

There is also a waste in the testing process. Testers often find that some of the story cards in the "to be tested" status cannot be further tested because the main process is disconnected during the test.

Return to the developer's hand. At this time, developers are already working on another user story. Either he stops the task at hand to solve the test problem, or asks the tester to wait until the problem is fixed before testing. Either of them is a bad choice.

One of the main reasons for this problem is that the developer claims that he has completed "development" and moved the story card from "development" to "to be tested, in fact, I did not test this function. Either it is because of negligence, laziness, or confidence. By introducing a user story preliminary test in this state transition phase, analysts can go to the developer's machine to check whether the features included in the story card package have been implemented before removing the card, it can greatly improve efficiency and reduce waste. If the analyst finds a problem during the preliminary acceptance, the developer can immediately fix the problem at minimal cost, instead of waiting until the tester finds the problem. In addition, the analyst's preliminary acceptance also provides a feedback point to determine whether the implementation is good. This is the earliest time point for us to see whether a requirement is implemented and can actually work.

2.2 how to avoid multi-task Parallelism

Frequent switching between multiple tasks is a common problem. Members of the team, especially developers, will switch between different tasks. As mentioned in the previous story, a certain requirement may still be realized at this moment, and the next moment will be called to fix the defects of a legacy version. Or the person is assigned multiple tasks, and each task is in progress, but none is in the completed state. Task switching is an important cause of reduced efficiency [3], context switching between different tasks will lead to frequent "Stack pressure" and "out-of-stack" tasks in their minds. These operations will take time. If it takes one person a day to complete a task, the person can complete two tasks within two days, but if he starts to work in parallel on the first day, it takes more than two days to complete these two tasks.

As you may have noticed, in the previous dashboard, all the task cards in the "under development" have a small note marked with the name of the person working on the card. If two people work together on a card, the card should have two names. This small practice can help us find out at any time in the team whether each person only works on one task.

If this simple rule can be strictly followed, when we see a person's name appear on multiple cards, we know that this person may be busy switching between multiple tasks at the moment, and each task will not be completed within the estimated time point. If we see that someone's name does not appear on any card, then he is probably in the resting state. The name of each person in the team should correspond to a small note. If you are working on a task at the moment, you can paste your name on the card, if you are not working on this task at the moment, move your name.

When we get the cards in the "to be developed" status bar, ensure that each person receives only one card each time. do not receive more cards. After completing this card, we will return to the next one. When a card is claimed, We will track the card, talk about its completion at the site, and talk about problems encountered during implementation. When its progress and estimated potential deviations are large, we can detect it in time rather than at the last moment and provide the necessary help to ensure that it can be completed smoothly. This approach allows us to focus on small-granularity needs (such as user stories) and focus more on the flow speed of these user stories. When every small user story can flow smoothly, the delivery of the entire project is also guaranteed.

Of course, this practice does not automatically ensure that the team no longer suffers from multi-task concurrency, delays, or other tasks unrelated to the task. Some people may suddenly stop doing some other things in the process of making a user story,

However, they did not update their status on the Status wall in time. The important thing is that the team should have a shared vision to achieve delivery goals, be able to expose problems transparently, and be good at using status walls to discover and improve their own problems. For immature teams, this may require a change cycle.

If a team shares its responsibilities well and the code is owned by everyone, everyone is encouraged to be familiar with and work in different parts of the Code, therefore, in such a team, it is not possible to explicitly assign a large task to a person in advance. On the contrary, the work of all people is not specific in advance, and it is easier for everyone to get only one card at a time, so as to avoid working on multiple tasks at the same time. In fact, the use of the Status wall can also help the team to share their responsibilities. They only need to intentionally allocate some content they have never done before when receiving the task, at the same time, after arranging an experienced person to work with him, the people in the team will gradually realize that they just focused on a different way of working in a module.

2.3 How to Reduce the inventory of semi-finished products and shorten the delivery cycle

The lead time [4] of a requirement is the time it takes from being identified to being finally delivered to the user. The shorter the delivery cycle, the shorter the time it takes for the customer to come up with an idea, to actually use it in the software. From the customer's point of view, a shorter delivery cycle means that your software can respond to market changes more quickly and thus be more competitive, it also means that you can verify your ideas faster.

Too much granularity of task management leads to longer delivery cycles. In the most extreme case, all tasks belonging to a module are assigned to the person in charge of the module at the beginning, and all modifications related to this module are implemented by him. In a module-based division responsibility, each person is only responsible for his or her own specific module team. Generally, the person in charge of this module will implement all modifications to this module. Otherwise, a task that may take two weeks to one month is assigned to someone. Or, even better, a single task itself is not large, but it will allocate the associated tasks to someone in batches. If your team uses large Word documents such as specification documents to organize requirements, be careful. This problem may already exist in the team. The entire team does not have the concept of Small-granularity and frequent delivery, and is used to the delivery mode in large batches for a long time. Because the batch size is large, it is often inaccurate, and the time span is long, there will be more interference factors in the middle, which all lead to the failure of task delivery at the starting commitment time point. The long development cycle also leads to the lag of test activities. The extreme lag changes to testing only after all development work is completed. This is the waterfall model we are familiar. The final impact is that the demand delivery cycle will be long.

A common way of organizing a traditional team is to divide the team members according to the function module and clarify the separation of duties, which will also increase the delivery cycle in disguise. Such teams usually tend to organize half-product tasks based on functional modules, rather than organizing tasks based on finished products that can deliver value. Teams that are used to organizing and developing based on functional modules usually perform "joint debugging" in stages. People in different modules integrate their own code for debugging, due to the lack of frequent integration, the time of such joint debugging activities is often uncontrollable. The team usually has only a large number of semi-finished products in most of the time, and there is no way to carry out subsequent testing and acceptance activities. Instead, the team can only test after assembling a complete function at a certain moment, therefore, the delivery cycle is also relatively long.

Therefore, if our requirements are all divided by functional modules of the software, rather than by user-oriented values, then we aim to deliver user values, at the beginning, I went wrong. User stories can be used to organize requirements based on the values that users can understand. This is an important basis for us to shorten the delivery cycle.

Our status wall can reveal the delivery cycle of demand. Let's take a look at these scenarios.

If our requirements are divided by functional modules of the software, coding of a single module is usually not tested. For example, some teams like to divide the upper-layer page and lower-layer database logic parts of Web applications into different module groups, and one user's requirements will be cut down and handed over to the upper-layer team for completion, some of them are handed over to lower-level teams. This requirement cannot be tested when a single team completes the task, so these tasks will be stacked in the "to be tested" column.

If the demand is so high that it takes a long time (more than one week) for developers to complete the development, the demand will stay in the "Development" column for a long time. As you can guess, when a person carries out multiple tasks at the same time, these tasks will stay longer in the "Development" column than when they are individually developed.

The tasks in any column are actually semi-finished products. Only after the test is completed, the tasks delivered to the user's hands are finished. Each column on the Status wall is better than a warehouse storing various parts. The more cards there are in each column, the longer the stay, the more inventory the current semi-finished products are, it's time to get the team's attention. The status wall visualizes the number of semi-finished products in each stage, allowing the number of virtual physical media such as cards to be displayed.

Through the status wall, we can calculate the delivery cycle of each requirement. On the Status wall, a user story is moved from the "to be developed" column to the "complete" column, this time segment is part of the entire delivery cycle of the requirement and is also very important. By optimizing the process from "waiting for development" to "finished", we can shorten the delivery cycle of the demand. By comparing the demand delivery cycle and the customer's requirements for the delivery cycle, we can quantify the gap and then guide our improvement.

After understanding how the status wall presents a demand delivery cycle, we can easily understand how the waterfall approach leads to a longer delivery cycle. In the waterfall model, testing is performed only after all development is complete, which is equivalent to testing one by one only after all task cards are accumulated in the "waiting for test" status. All developed semi-finished products will be stored in the "to be tested" warehouse until the end of all development activities.

When inventory accumulation occurs, we need to improve it. If there are too many task cards in the "to be tested" column, it means our test activities are not keeping up. There may be problems in our testing environment, or our testing staff is not enough. If too many cards are in the "test completed" status, it indicates that some problems have occurred in our release and final delivery processes. If there are too many tasks in the "to be developed" column, it means that our plan may exceed the development capability of the current team, or reflect the shortage of developers. There is also a situation where the "to be developed" column is left blank for a long time, which may indicate another problem, that is, the analysis speed of our analysts cannot match the development capability of the team. A good team is bound to coordinate and cooperate with various roles to work in parallel, and the task connections between them can also be smooth.

2.4 measurement, planning and other aspects of iterative Production Capacity

The workload that a team can accomplish in each iteration is usually the speed of iteration, which is an indicator to measure the team's production capacity in each iteration. This indicator helps the team develop iteration plans. The unit of iterative velocity may vary depending on the team's estimation of the task workload (for example, the number of story points ). Generally, we only need to complete the task workload on several status walls at the end of the iteration.

After several iterations, the iteration speed of the team tends to be stable. When we plan the next iteration, we will refer to the data of previous iterations. If the previous iteration has completed 15 points, then we usually also

We plan the workload around 15 points and place these cards in the "to be developed" column. That is to say, at the end of each iteration, We will update the status wall, put the cards of the coming iterations on the wall, and adjust some cards in the semi-finished state as appropriate.

As mentioned above, the status wall may contain three types of cards. In addition to requirements, there may also be bugs and technical tasks. Each time a tester detects a bug in an iteration, it writes the bug into a card and places it in the "to be developed" column. When there are not many bugs, the team can digest these bugs without affecting the original plan and ensure the software quality is continuously guaranteed. If there are too many bugs, you need to make some plans to scatter the bugs into several iterations. However, at this time, the team may need to reflect on the cause of so many bugs in a timely manner.

Another type of technical task also needs to be considered in the iteration plan together with the bug and demand card. Generally, technical tasks include tasks such as building a continuous integration environment, preparing a test environment, and restructuring. Although they do not directly bring value to users, they are an important factor to ensure software quality and team efficiency. For example, refactoring tasks may have to be considered by teams working on legacy systems. To ensure the smooth implementation of new requirements, you may need to reconstruct some of the previous legacy code in a scheduled manner.

Bugs and technical tasks consume the time resources of team members, but do not directly generate user value. If we measure the overall production capacity of each iteration of the team, we need to consider these three types of tasks when calculating the iteration speed. However, if we only examine the size of the user value delivered by the team in each iteration, we should not include technical tasks and bugs. When a team spends too much time on technical tasks or fixing bugs in iterations, the team needs to review the reasons for the team's poor infrastructure, or too many bugs are caused by team carelessness during development, or some other reasons.

3. Conclusion

In this article, we start from some problems that often occur in project management, analyze some of the reasons, and then introduce how to use the status wall (panel) to visualize task management. In agile projects, status walls are widely used as an effective iterative task management tool. The team uses a simple tool such as status wall to track and manage daily work in iterative development in a transparent and real-time manner, helping the team detect problems in time, eliminate waste, and quickly deliver user value. I hope these words will help teams eager to be agile and improve task management and daily operations.