Understanding and practice of the basic process concepts of agile development

I haven't updated my blog for a long time. The objective reason is that I am really busy. The subjective reason is that I am too lazy. However, if you think about it, your knowledge and experience are gradually accumulated, and you will not summarize, review, or record it. In many cases, what you should have accumulated will gradually be forgotten. I wrote it in my blog to share with you, record the path I 've traveled, and reflect on what I 've done. It's not so busy with my work. It is good for you and everyone. I think so, but I can't care about anything when I get busy. Therefore, taking advantage of the May Day holiday, we finally have time to write something for sharing and recording.

The company has been implementing agile development for some time. IBM consultants also provide weekly tutoring sessions. There is not much new knowledge, but they mainly follow up to solve some problems encountered in daily execution and correct some wrong understandings. I will not say much about the concepts and benefits of agile development. I will search online and ask for more information than I do for development. From the perspective of a daily performer, I will sort out the basic process and problems of agile development.

User stories. Agile development is first based on user stories. When developing a user story, you must note that the granularity of the user story and its relative independence. In actual execution, we often see a large deviation in the user story Scale Estimation, or half of the story is found to be dependent on other modules. These problems are believed to be common problems in Agile development. Developers tend to degrade the management function of agile development because of their large deviations. Our principle is: first rigidity, then solidification, and finally flexibility. Only in this way can we ensure the normal implementation of agility. When everything is on the right track, let's talk about improvement. Of course, we have also taken some measures to provide feedback to People evaluating the size of user stories, so as to gradually improve the accuracy.

Unified Team. The reason why agile development is agile is that a unified team (personal understanding ). The unified team includes developers with various roles in development, including SE, ue, UI, and QT. These personnel can communicate well with each other in the same team, which reduces the time cost for official documents and can be corrected immediately after misunderstanding. In actual implementation, it is found that although a team is named in name, different roles have different positions and sometimes it is difficult to ensure true "unification ". This requires the managers of each group to truly stand in the project perspective, give the executors more freedom, and reduce conflicts at ordinary times, and increase tacit understanding in multi-organization group activities.

Iterative development. Iteration refers to dividing the development time into small stages with a fixed length of time. Each iteration completes the corresponding user stories, and new requirements and changes are placed after the next iteration based on the priority. Iterative development is basically the daily process of implementing agile concepts in our actual development work, which is closely related to our development work. At the beginning of each iteration, an iteration plan will be implemented. Based on the priority of the requirement, the agile team members will get their own stories suitable for their own scale. Then, clarify the user story, break down the user story into tasks precise to Person X day or hour X Day, so that managers can easily control the progress. When each iteration is completed, an iteration review meeting will be held. At the iteration review meeting, we will summarize the number of completed stories to demonstrate the results of this iteration and listen to the opinions of the members in the group for continuous improvement and tacit understanding. At the beginning of implementation, many problems will be found at each iteration review meeting. The meeting itself can only expose the problem and cannot solve the problem. Therefore, at each iteration review meeting, we will formulate an iteration improvement plan and report on the progress of the previous iteration plan during the next iteration review. I personally feel that this method has achieved better results.

Maintain the status bar. To make the progress of iterative development clearer to leaders. We will paste the completion stories of each iteration plan, the tasks to be divided into, and the statuses of the stories and tasks on a whiteboard. On a daily basis, the agile team members will hold a stand-up meeting, review the work done in the previous workday, the work planned to be done today, the problems and risks encountered, update the status bar after the meeting, and confirm which work plans to be made, what is being done and what has been done. In the end, a burn-out chart is formed to reflect the remaining workload of the iteration and gradually decrease until the iteration ends. Ideally, the burn-out chart should be "burned-out ". In the actual process, the status bar is often not updated in a timely manner and should have performed well for the leaders. The results make the leaders more depressed... A good practice is to assign a person in each iteration to follow up the status bar updates, so that they can be updated in a timely manner. Another problem is the increasing and endless burning of the burn chart. A small amount of increase and a small amount of remaining work are normal, mainly because the estimated workload deviation or other emergency incidents have affected the progress. This should be analyzed based on specific situations. However, when several rounds of iterations are not enough, managers should pay attention to it and analyze the causes in a timely manner to prevent the situation from deteriorating. Our group has encountered a situation where we did not pay much attention to it at the early stage, resulting in less than half of the burned-out diagram until the end of the iteration.

Now, agile development is mainly to make software development projects more controllable, so that leaders who do not know the specific details can intuitively understand and manage the progress of the project. Of course, this is just a management tool. It does not seem applicable to some technical research and prediction projects...