Author: sodimethyl Source: http://blog.csdn.net/sodmenote: This article can be copied or reproduced without the consent of the author, but any reference to this article should be retained Article The author, source, and declaration information of the first three rows. thank you. note: one of the manifestations of it impetuousness in China is that, as long as there is a new concept in foreign countries, the domestic circle will immediately stir up and say: what kind of development method is invented, how advanced it is, and how effective it is, or should we try it? This is a team sentiment on "How to introduce development methods". Its core idea is: Each team has many differences in terms of technical level, team atmosphere, and psychological mentality, we cannot choose not to use it in our own team because of others' comments on a development method. Even if we want to use these new concepts, we should make improvements and re-engineering based on the actual situation of the team, seize the essential spirit of the new concept, and simplify and learn from specific methods in order to better promote the current development. Introducing the text-agile development is no longer a new concept, but my understanding of the essential meaning of agile has gradually become profound in the last one or two years. In my opinion, there are at least two meanings of Agility: first, agility in R & D speed, and rapid development through optimization of collaboration and design methods; second, rapid response to market needs determines the direction of the product. That is to say, in my opinion, "AGILE" is relative to the entire product line. It is not only required in the R & D stage, but the complete product line includes: planning and design, product R & D, product operation, customer service feedback, and marketing. agile methods can be expanded from R & D to other fields, in general, the response speed of the entire product to market and user needs is improved, and the overall implementation speed of the entire team on the product strategy is improved. It is narrow to regard "agility" as the agility of R & D, but the agility of R & D is the foundation of agility in other stages. Single agile development is just a concept. It is derived from many specific development methods that allow R & D to be faster, such as Pair programming, such as scrum. No matter what development method is used, the ultimate goal is only one: fast and good products, agile theory is no exception. "Fast" and "good" have become our constant goals. In fact, when you become more familiar with agile applications, you will find that agile is not just a development theory, but also a religion. Because, in this very specific way, it is spreading faith and setting up common values, which are sharing, pragmatism, and striving for perfection. This kind of experience has become more profound since we adopted scrum. Our scrum, in a strict sense, is not the very standard scrum in textbooks. We just intercept the best of scrum and adopt the most useful part of it. As early as in the previous article, I mentioned that our R & D is as follows: 1. the previous practice was to set a stage R & D goal. The entire team had a unified goal, and now it has become a goal for each group; 2. during the phase of R & D, we split the R & D tasks. We do not have specific system analysts. Everyone designs their own complete systems from start to end, including system analysis, coding, and white box testing. 3. every day at a morning meeting, every R & D Engineer will attend. At this morning meeting, each person will give three simple words: What was completed yesterday, and what was prepared today, who should cooperate with each other; lessons learned and experiences from yesterday's work; 4. during the R & D process, developers can fully share development information through various means, such as face-to-face communication, Im broadcast, and telephone communication. each R & D personnel has full self-management rights. The superiors only pay attention to the results you have made, rather than the processes you have made. As can be seen from the above points, this development method requires everyone to have good self-management capabilities, and be able to manage their own R & D progress, R & D quality and R & D efficiency. However, not everyone is perfect for self-management. What should I do if this happens? Our practice is as follows: 1. he tries his best to improve his self-management level. For example, he is guided by experienced colleagues to participate in the morning meeting of each group and the development and discussion of key systems, and to guide their development process; use various methods to share good self-management methods with others; 2. if his self-management level is really poor, but he is working very hard, then only some systems with little requirements on self-management should be arranged for him to reduce the R & D Risk of the entire product; 3. if he is not only poor in self-management, but also does not learn, do not forge ahead, do not share, we only have to give up on him, will not waste time on him. Probably, the agile and scrum development methods we use will be considered by many Orthodox people not really agile and scrum. But what I want to talk about is that the most important thing for us to learn methods and theories is to grasp its core points. We need to know how to do this to benefit our team and projects, there is no need to follow the agile paradigm to prepare all the relevant procedures and personnel, and then use the book-based approach for agility, each team can be streamlined or improved according to their own circumstances. I always think that the simpler the things, the easier it will be to persist. Because the simpler it is, the more people can understand, remember, and use it. This is also true when it comes to development methods. If a development process is too complex and cumbersome, it will inevitably be unable to be widely promoted. So when I hear about a new development method, I will first think about whether it can be used by our team, and then I will think about how to use it more simply for our team, if the method is too complex, I will not select it. In terms of various agile methods, we will never introduce them in a systematic manner. We do not need to use them, but can use them. They should be based on our own needs and feelings. For example, Pair programming is very flexible. Our usual development is dominated by scrum and supplemented by other open methods. If we encounter a logic that is similar in the logic of the server and the client, the participants will temporarily adopt a Pair Programming Method to complete this logic. Once this logic is completed, it will be restored to the status of their respective development. I have heard that many organizations adopt Pair programming to allow two people to take turns programming, and even adopt the method of assigning only one computer to two people. During the development of the entire project, both use one computer. I don't know how other people will feel in this situation. In my own experience, I am very disgusted with such a long-term Pair programming model, it makes my work environment unprivate and free. During the entire R & D cycle, coding is only one of the steps. There are many other things to be done, and I don't want or need to let another person look at them. This method makes me feel too disciplined. What we are pursuing is,First, let the people who do things better themselves. If a development method will make developers uncomfortable, no matter how advanced it is, we will not immediately force it to adopt. We would rather spend time and money to let developers know whether it should be used, can be used, and can be used consciously. All the so-called management and its final implementation are in the word "person". One way is not good. I can change one, however, if you destroy people and people, the cost will be much higher. The selection of development methods should be based on the actual situation of team members. The actual situation includes both the technical level and the psychological mentality. When the technical level and psychological mentality are not at that step, if we forcibly promote a development method, the effect can only be counterproductive. At this time, we should consider how to improve and improve everyone's technical level and psychological mentality better and faster.
