Agility in my heart (6)-How to plan every day in scrum

Author: sodimethyl
Source: http://blog.csdn.net/sodme
Disclaimer: This article may be reproduced or reproduced without the consent of the author. However, please keep the author, source and declaration information of the first three lines of the article for any reference to this article. Thank you.

Introduction:
In the previous article, I talked about the concept of project layer-by-layer decomposition in scrum mode. In fact, our goal is not to break down the project itself. Our goal is to strengthen project control, it is intended for a relatively large project to be able to carry out R & D at a relatively controllable progress. After layer-by-layer decomposition and implementation in actual R & D, it depends on how the work of each day is arranged. In fact, there are many other development methods with better project decomposition methods than scrum, but why are those methods easy to get stuck in an uncontrollable progress? I think one of the most important reasons is that the specific control of each day is not well done. OK, let's take a look at how to make every day well under the scrum development method.

Body:

From the previous article, we can see that Scrum Splits a complete project R & D layer by layer into every 2 ~ Three months, two weeks, or even one day of control granularity, and in the development practice of each day, what content will be prepared for today. Therefore, the question ultimately comes down to: How should each team member reasonably plan their work every day and how to efficiently complete the work every day, how can we achieve growth and progress in every day's work so that every day can gain a sense of accomplishment and promote product development?

For planning, each of us may be working every day. However, for many people, "reasonable and accurate planning" is not an easy task: no matter how well we plan, there will always be a variety of unexpected events, which will affect our original plan and will not be completed within the scheduled time. Therefore, in a sense, we can say that there is no absolutely accurate planning control. We can only predict as many unexpected situations as possible based on our own practices, reserve time in advance to prepare for handling accidents, and keep the time consumed in accidents within a controllable range.

To sum up, for programmers, the daily work we face can be divided into the work we do independently and work with others. My general experience is that we can improve our ability to handle and effectively control the execution of tasks in this order: from simple to complex, from single-line to multi-line, from individual to group, from the eyes to the long run. Set priorities to three priorities: urgent, important, and General. Then, handle these priorities based on priorities.

Limited by the technical level of everyone, every developer must experience a process from unfamiliar to skilled in the development tasks they face as they grow up. In terms of technology, it must also go through the process of exploring and using existing frameworks. When a newbie is developing in a new field, there will always be new problems and experienced people in this new field, we will find similar solutions for new problems from our own experience library. People without experience can only gradually accumulate their own experience from the beginning, this is a natural process for personal growth. What we need to do is to actively think about and practice how to get new people to gain such experience more quickly and minimize the losses that new people bring to the project due to lack of experience.

Returning to the new person's daily plan, the main difficulty may be that, due to lack of personal experience, it is impossible to predict the specific time required for the development of a function. This is not an easy solution. My suggestion is: before deciding what to prepare for today, first, analyze the data structures, processes, interfaces, and related resources involved in this function as much as possible, such as art resources and resource configuration of planning documents. With a complete analysis of the relevant content of this function, we will first evaluate the approximate time consumption, controllability, and uncontrollable points of each aspect.

At the beginning, your time estimation may be very inaccurate, but it doesn't matter. As long as you stick to this meticulous analysis, as your personal experience continues to accumulate, your estimation of time will become more accurate, and your analysis and execution of one thing will become more and more in place. For qualified teams, it would be great if an old colleague can coach and help new people at this stage and help them determine their daily work goals. Of course, the role of this "old colleague" is not necessarily a member of the team, the project manager or other colleagues who have a deep understanding of the project can also help new people to complete the task. No matter who plays this role, the goal is to help new people better determine what they want to do today.

In general, the method of planning your daily work is still: careful analysis and layer-by-layer decomposition. However, to ensure that your goals are met, you need to consider the uncontrollable points in your daily work goals. What problems may arise from these uncontrollable points, how can we eliminate or further confirm these uncontrollable points? Is there any way to make these uncontrollable points controllable?

"Make Things", "make things better", and "make things fast and well" are the three realms of doing things.

This is a never-ending and constantly improving process. As long as you stick to the fundamental problem of "how to make things better, you will find a variety of ways and means to make things better. In the scrum development mode, improving the developer quality is the most basic and effective, and is also the most pragmatic and fundamental requirement.

Of course, this method requires a high degree of self-discipline for developers. Even if we are very focused on "completion", different developers will have different ideas and practices. Developers who are a little lazy or irresponsible may intentionally set fewer targets even if they can do more on a daily basis, to achieve the status that can be completed on a daily basis. I would like to say that this situation is normal, but whatever the developer's "Laziness", the development goal of a single Sprint (every two weeks) is the minimum, no matter how you balance your development time and the content of this sprint, you should finish it as soon as possible.

On the other hand, we should encourage and reward those colleagues who always finish a little more on a daily basis, and strive to form a catch-up atmosphere in the team. For those who finish ahead or exceed the limit, different forms of rewards can be given. The rewards can be material or spiritual (completion status notification email ), or it can be time (completed in advance, and the rest of the time can be used to take a rest, take a holiday, or arrange your own project-related plans, such as reading books, looking for materials, learn about the latest information in this industry ).

That is to say, from the perspective of individual team members, we can analyze the target requirements in detail and break down our work objectives layer by layer to develop a development time plan that is more in line with our actual situation. For the team, we can spur everyone to form a R & D atmosphere that is your catch up with each other by following disciplinary measures and rewarding advanced methods. In terms of project control, I personally disagree with the lazy style of work. It is difficult to make things, make plans, and make full-day projects.

The passionate development status comes from the development goals you set for yourself and the efforts you have made for this goal. In these efforts, accurate planning is the first thing you need to do. In the beginning, you do not need to set the goal too high or too far. You should try to be as close as possible and implement it as easy as possible, you will continue to pursue new and higher goals in the sense of accomplishment of "constantly completing development tasks on Schedule.

At the same time, the scrum development method itself also provides developers with the best self-discipline means: morning meeting. At this meeting, you need to make public information about what you did yesterday, what you did, and what you did. When you are not there, you may not be able to experience the stress that this public speech method puts on the speaker himself: If you are always playing around every day, other team members can easily see from what you said whether you are actually working hard and are actually working hard. We say that people have to face the tree, and I believe that, especially for technical people, there is always shame and self-esteem, in this way, a long time of public exposure to his mixed life will always put some pressure on him and spur him to do his work with heart.

Different people may have different ways of planning based on their habits. I am doing this:
1. Before getting off work every day, think about what you are going to do tomorrow, consider the steps, links, people and resources involved in doing this, and identify the links and sequences;
2. Use Google Calendar to record all preparations for tomorrow;
3. When you go to work the next day, follow the content recorded on Google Calendar to attend the morning meeting and drive your work today.

In addition to Google Calendar, the software used to record daily work content also has a much used rainlendar, which is different from Google Calendar, the advantage is that today's work goals can be directly displayed on the desktop, which can be seen from time to time. The disadvantage is that, unlike Google Calendar, I can know which day I have completed in any location, even Google Calendar allows you to share your planning content with others and set access permissions. This is especially suitable for team development and allows team members to understand each other's daily work content. You can choose a software to record your daily work content based on your preferences. Of course, if you only use paper or pen to record your work, however, you will not be able to easily review history, reflect on lessons, and sum up your experience.

In the next article, I will continue to share with you my agile and scrum experiences. The theme will be scrum information sharing.