The team is generally a description of a collective. The narrow sense is the group of developers, and we only discuss the concept of broad sense here. The main members inside the team are people, but they also include the tools, equipment, etc. used. Any book is not clarified, but you must talk about this concept before I have described the team building, and some of the experiences caused by this concept.
First, the concept of the team
The team is the sum of the collectives of the unified purpose. It consists of people, tools, devices, and some auxiliary resources, such as certain information, and the like. Therefore, the team is a group with independent work ability and has a separate thinking environment. If someone tells me, he has made a team of Office with friends, without a fixed working environment, communicating information on the Internet. I certainly won't believe it, because they don't have an environment, it is incomplete, there is no assistance to development capabilities. They can only be part of a complete team. Here, don't limit the team to the software industry, a computer several pirated development environments. Therefore, in order to make the team work, the key part is the construction of the environment, and people are just creative workers in the role of people. Therefore, the part of the team can be described as: the process of building an environment for the creative labor; the part of the environment can be described as: the process of building an environment for repetitive labor. Therefore, the former needs flexible, freedom and rigor, the latter needs to be stable, fast and accurate. Simple instance: such as software development people are relatively free, they can talk freely, they can freely adjust the rest time, etc., the computer used should be fast and stable, although the work is good, but who hates faster What about speed? Information is also part of the team, such as pre-training for a project, should have accurate concepts and rapid entry. These are part of the team. And it is not possible. As for the choice of team staff, it is subjective problem, and it is no longer discussed here.
Second, the software engineering in the team
I deliberately avoided a problem, it is the project management within the team. To explain this problem, you must first understand the software engineering. Software engineering includes two aspects: first, software development technology. Second, software project management. Software development technology includes all current development details, this I have no ability to explain, here I only talk about the software development project management section, but I must understand that project management is only part of the software engineering, not all. Software Engineering Tursing section can refer to me "software design depth excavation" on www.9cbs.com, the time is a bit long, but I need a lot of things I need to fix it. Use www.google.com to search directly.
Let me talk about the team's software engineering.
The team's scale and software engineering matching is proportional, such as teams below 10 people, many problems in software engineering can be interpreted as the exchange of people. The 10-25 people need to have few intermediate information exchange management, such as using emails to send task books, etc., 25-50 people need to use more intermediate quality assurance, such as using ClearCase to configure management VSS obviously does not adapt to large-scale software development. Growing from a small team to the big team is not a change in the application of software engineering, but a change in the application of software engineering. There is no conflict between the team's size and the use of software projects. Different teams must ensure that the final software quality, this is clear, we will be flexible, direct communication, such as orally correcting some superficial mistakes in the small team, see each other The code directly pointed out the problems in development in development, so because we pursue efficiency, quality is very perfect in increasing improvement. In order to avoid the explosion of information exchange, the big team must use some intermediate management steps to ensure load balancing of various team information flow. Project management is also naturally produced in such a need. Therefore, the team's software project is a perfect software engineering manifestation. Just in many cases, I missed the chance to tell the summary. When the process ends, it is difficult to improve again. After all, the memories are fragments. I often hear some people say that they participate in small projects. There is no experience in software engineering. In fact, you have the different performance of software engineering. People who have not participated in small projects are of course not complete. of. Third, the team construction under pressure
We cannot always develop large-scale projects, so we are suitable for small teams in development models. The management model of the team is actually mature, and almost all software engineering works are ideal for large software projects. Therefore, we discuss the team building of the team to adapt to most of the situation.
Only the people in the team are changed under pressure. So, what is the team under pressure?
The most serious problem is that they will feel desperate. Since all the reasons are possible to cause the mood changes in team members, and most of the cases are irreversible. When the time is too short and the project is too large, the team will inevitably take the discussion of the project, and the discussion brings emotional fluctuation, then impetuous, flustered, work efficiency is also followed, actually producing this The reason is because they participated in the discussion of project management. In many cases, all team members should avoid participating in the project planning part, and more discussions should be limited to the project itself, such as design. I have to focus on emphasis on the role of the project manager because he is responsible for the solution to the incredible pair of paradox, and a solution for the problem that is impossible to solve the problem. But the team staff is very smart, they know the questions faced by the team, of course, have their own ideas, this should be by the project manager to answer the issues of all team members. The key points that need to be explained should be how to solve the technical problems in the project, how to use the quality control and software engineering methods, project funding issues, overtime problems, complete the project's significance, if there is no previous consequences of the project on time.
The project management process under pressure is the man's management process. Software engineering This time, this is especially fragile. I have experienced a programmer to refuse overtime because the chair is not suitable, of course he is very angry. Be careful when performing project management, can even perform different software management methods according to each different person. Let the team feel that there is no positive emotions. The responsibility of the project manager during this period is a key issue. Different people's management model will make the workload growth, the management complexity of collaborative methods, optimize team production efficiency, and increase a large number of management burdens. There should be a lot of profit marks, so adding project management resources should not be a problem. For example, go out to eat together, drink tea, play, etc. will make the team forget the pressure and relaxed mentality is the key guarantee of winning. This activity is necessary, from mental health, this is a balanced relationship that must be maintained. You can also increase managers to track the development details of each developer in the team to promptly feedback. Developers don't have to delay too much time by the intermediate process generated in some project management. A few years ago, I have had such an experience. I have given my team backbone (2 people) with special technical secretary, they Responsible for all documents, unit testing, and code testing of these two people. In the work of the backbone, even the development side, the secretary recorded the corresponding details in time, thus finishing the text and then review the backbone. An item originally developed for half a year, all completed in three months, and the corresponding development cost has only increased by 10%. The most important thing is to ensure product quality. After that, they will tell me, "I really stimulate this, I hope I don't have to experience it again next time ..." So I want to remind everyone, stress management is a short deformity management, it is impossible to suit most developments. . If the team makes such a management process three consecutive times, I think they will be crazy. I still didn't mention overtime problems now. In fact, under pressure, overtime is inevitable, but I don't say that advocate overtime, because the team should be the company's leadership under high pressure, and it is imposed on the team's performance. Everyone has a certain ability to work, the most important thing is that we can't add the ideals of the team to the team members, because they are free. We are still avoiding this contradiction!
Here are some principles of team building under pressure:
1. Give the team's maximum degree of freedom: This refers to the freedom of management. Don't be limited by the company's internal system, because team management under pressure is deformed.
2. Give the team to equip the most stable equipment: I don't explain this, the most stable in this situation is more important than the fastest.
3, giving the team more disposable funds: strain changes in many resources and personnel demand, such as need to purchase books, equipped with outcomes, etc., these require fast to reduce team extra time. Wasting. Ordinary projects allow funds to declare the process.
4. The project manager must have some experience: the team in this situation allows novice to manage the disaster. And the project manager experience is very rich. This provision can also not follow in the ordinary project.
5. Team members jointly design: The project should be designed with all members to determine the feasible design as soon as possible. All members should have a deep understanding of the design, which is convenient for future communication. This terms are implemented in a general project.
6, targeted optimization development plan for different member design: This method is only for this project, and can be developed in terms of personal hobbies, capabilities, resource allocation, etc. This approach is not suitable for the company's development. After the person changes, the project image is relatively large, so the ordinary project must not be managed according to this.
7. Solve team members' life issues: In the problem of team resolution, we must solve before the project begins. The reason is very clear. In the general project, it contains redundant time, and project progress can withstand members to handle life and other issues. The most concerned is the efficiency, so this terms are not suitable for ordinary project development. 8, use agile development mode. This is the development model of the lightweight program, and the project manager should have these knowledge.
9. Project training should be carried out early: the first thing after the contract signature is the skill training in the project, such as the industry, cutting-edge technology, etc. This direct related to project progress, user needs and stability indicators.
10, let the management away from the team: If there is an experienced team has such an experience, many opinions of management are not suitable for technology development under pressure, let them leave the team is the guarantee of the team's normal operation. In many cases they are willing to be your potential customers, they will say this, then come to your team, then they have many opinions, then they will tell the team with the leadership, instead of the customer's identity . Believe me, let them leave your team, they will generally not do such a role to interchange, because they don't know what customers do, not all, is most.
The small team of pure software company is developed above. If you want to discuss all kinds of conditions, it is a bit unrealistic. Here I only discusses the problems of most companies. But everyone must understand that if you blindly use this way to develop an impossible project, the result is still failed, because your starting point is wrong, this method is just correct, just like we will submit software tomorrow, today Like the night, it is time compression, not true efficiency, usually this kind of development will give the team a certain holiday, because they make benefits for the company, which is what they deserve.
