Talking about Agile and CMMI
- 2020-12-30 16:07:04
- philip Original
First of all, there may be people who question what Agile is and what CMMI is. But this is not the point I want to talk about.
At the beginning, I will give you a personal summary. You can try to find the projects of your company. Where is the fundamental problem? Is it mainly focused on management and personnel communication? The lack of technology actually only accounts for a small part. Therefore, our predecessors have summed up these two things through constant exploration.
1. What is agile? Agile is actually born to solve communication problems.
2. What does CMMI do? CMMI was born to solve management problems.
When it comes to communication, it must be clear here. For a project, communication is nothing more than these three aspects:
1) Communication within the project team;
2) Communication between the project team and the company's internal personnel;
3) Communication between the project team and the customer.
Well, first figure out the purpose of the two, and then we will carefully analyze.
Why is agile to solve communication problems?
First of all, many people know that Agile promotes people-oriented, right? Why put people first? Because the project is done by people, and the plan is proposed by people. People-oriented is reflected in all aspects of agile best practices: team member quality, team stability, team size limitations, sitting with customers, pair programming, rapid iteration and rapid delivery, daily regular meetings, (team) sitting Together, spontaneous organization, overlapping functions, etc.
1. The quality of team members is a prerequisite to ensure good communication.
2. Team stability is an element that guarantees no or few omissions in communication. If the team members have been relatively stable, then communication with each other will become more and more smooth, and there will be no or few handovers of work. Why do you say that? Everyone will know the importance of stability by looking at the effect of the handover of work around us. (But for short-term companies and short-term projects, this one can be weakened)
3. Team size limit, various agile methods will have a limit on the size of members, generally ranging from 4 to 9 people. Why is this restricted? The reason is simple. There are fewer people, and there is little mutual improvement. Once the staff changes, the relative change ratio is high, and the cost of work handover is high; if there are more people, the communication objects will be increased, thereby increasing the communication burden and increasing Difficulty in communication.
4. Being with customers, many people overlook this point. This is actually a crucial point for the success of Agile. How do you say? Where did the requirements in agile come from? Is it a backlog one by one (in some places, one by one feature description)? But such information is usually not enough (why do you say that? Just imagine, if such information is sufficient for development and testing, then putting together such information is already our complete requirements document), what if the information is not enough? do? It is especially necessary to bring customers to sit with us. If you have any questions in the information, you can get answers from customers at any time. Does this speed up our development greatly? Of course, this is only one of the key points of "Being with the customer". Another key point is that, "Being with the customer", the customer can propose his changes with great convenience, and the project team can also quickly understand the changes. Then quickly communicate with the customer the impact of the change and reach an agreement, and then quickly respond to the change. This is how the agile embrace of change comes. Just imagine, if you only make changes to the customer, we do not understand the change at all, and feed back the impact of the change to the customer. Are you going to die or do you have inexhaustible resources?
5. Pair programming, what is the solution? Let's take a look at the traditional development, is there a code review link (if you don't think it is necessary, you don't need to continue to read it)? Many project managers who are eager for quick success will completely ignore the part of code review, believing that code review is too time-consuming and has little effect. It is true that the code review of many projects will indeed take a lot of time as a result, but the results are not very effective. Why? Many people don't think about it carefully. How is your code review reviewed? Is a team of people sitting together line by line? Or go there one-on-one? (I'm not talking about methodology here, because there is no absolutely good way) No matter what method, have you ever found the reason why you didn't do a good job? Well, at this time, Agile pointed out a clear way for everyone-pair programming. Let developers learn in programming, and at the same time, let our code be corrected in programming, and early correction of problems in the code can bring benefits to the follow-up work, I believe I don't need to say that everyone understands.
6. Fast iteration and fast delivery. How does this relate to communication? I believe everyone understands that if the project is completed and the product is delivered to the customer, the customer cannot accept the inspection at this time, and we will rework again. The cost can be huge and the impact can be fatal. And if the customer is delivered in a short period of time, the customer can find the problem early, and we can also make corrections early to avoid subsequent chain reactions. During this period, customers can (compared to traditional working methods) feedback problems with us in advance, which is an optimization of communication procedures. At the same time, combined with point 4, such fast delivery costs are much lower than traditional delivery costs.
7. Daily meeting, this is too easy to understand. It is not only a way of reporting, but also a way of regular communication within the team. Some people may question here, because the daily routine usually requires no more than 15 minutes, and the report content is nothing more than three. How to communicate? What I want to say is that everyone should not think of communication so narrowly. The real purpose of the daily meeting is not to report work, but to introduce your work to the team. Only when you figure out how to introduce your work to others can you hold a good daily meeting. And since the daily meeting is to introduce others to their work, what do other people need to do in the meeting? Obviously, everyone should listen carefully to other people’s work and keep thinking. Why do you want to do this? The purpose is that when there is an inevitable lack of personnel in a certain period of time, other members can quickly make up. If you say it in this way, I believe everyone will understand why the daily regular meeting also focuses on personnel communication.
8. (Team) Sit together and ask everyone a question before talking about this topic. How do you sort the effects of the following communication methods from poor to good?
a) Text communication
b) Voice communication
c) Video communication
d) Face to face communication
After you sort it out, come to see our "(team) sitting together", I shouldn't need to say anything later.
9. Spontaneous organization, this should be related to communication, which may be a bit abstract, but think about it, you usually have a better relationship with talkative people, or better relationship with dull people (remember, it is usually Don't tell me special cases)? A person must have a sense of initiative (spontaneous) in order to better show oneself to others, and to let others walk into (not approach) oneself. In this way, communication with each other will be smoother. In addition, spontaneous organizations have an implicit requirement that the project should not be interfered by outsiders, and outsiders must not interfere with the operation of the project. This is to reduce the stakes between the project and the external (non-client), in order to weaken the influence of communication between the two.
10. Cross-functionality. Speaking of this, I would like to say that this is a very critical point in agile and easily overlooked by everyone. The functions are overlapping. To put it bluntly, development and testing are the same person, that is, the same person does both development and testing. What are the benefits of this? Reduce the links of personnel communication! If in an agile project, development and testing are separated, it is necessary to develop and understand once and test to understand once. If the two are combined into one, you only need to understand once (Note: The understanding here includes The process of confirming requirements). Maybe someone will do it again. Wouldn't this be a way to verify yourself? It can be said yes, or it can be said no. Yes, it is because he must perform unit testing on his own modules; no, it is because of our traditional system testing. The execution of the use cases can be selected by everyone "self-organized", that is, you can decide which module you should do. System test. If everyone chooses to do their own system testing, I can only say that the results are more worrying.
Among the 10 items analyzed above, the first 1, 2, 3, 5, 7, 8, 9, and 10 are mainly to solve the communication problems within the team; the 9th is to solve the communication problems between the team and other personnel in the company; 4 and 6 are to solve the communication problem between the project team and the external (customer). And agile, through this series of measures, to ensure the effectiveness of communication between personnel, in order to reduce the risk of project failure, improve project efficiency (communication cost is reduced, efficiency naturally increases) and success rate.
Speaking of agility, let's talk about CMMI. Anyone who knows the history of CMMI knows that CMMI itself was born out of management. Without the chaos and disorder of management, there would be no birth and growth of CMMI. Let’s take a look at the 22 PAs of CMMI: RD, TS, PI, VER, VAL, IPM, PP, SAM, RSKM, PMC, REQM, QPM, CM, PPQA, MA, DAR, CAR, OPF, OPD, OT , OPP, OPM (called v1.3). Among them, 5 are PAs for organizational system construction, 5 are PAs for engineering (project implementation), 7 are management PAs (v1.3 puts REQM in the management category), and 5 are auxiliary PAs. However, in addition to the 7 management PAs, the 5 auxiliary PAs can be said to serve for better management of the project, and the 5 project PAs simply point out the necessary activities in the project implementation process, and 5 organizations Grade PA actually makes requirements for the management of the organization. This shows the weight of management in CMMI. (Note: If you want to learn more about each PA, please go to the official web cafe by yourself. If you have any questions, you can discuss it here--)
Having said so much, everyone is tired. Please forgive me!
But in the final analysis, whether it is Agile or CMMI, its purpose is to reduce the risk of project failure and improve project efficiency and success rate. One way is to solve the communication problem, and the other is to solve the project management problem.
From another perspective, neither of them is a silver bullet, and does not guarantee the success of the project, but only increases the probability of its success.
- ZDOO Cloud
- Request Demo
- Tech Forum
- Private Policy
- Term of Use
- Google Groups
- Leave a Message
- Email: email@example.com