Initial Research on "minimal mode" of software development and Teams 1

Cmme 2, 1, or 1.5?

First of all, to tell the truth, there is no minimum pattern for software development. If I can, I don't want to try the so-called minimum pattern. Now there is no way to open a-second-hand car, it does not mean that I would like to drive this kind of car all my life.

The CMMI3 certification requires at least 20 participants. In fact, a hard indicator is provided. To ensure that CMMI3 meets the quality requirements, most of the Process fields cannot be tailored, make sure that you have enough resources to do the right thing.

Maybe I haven't caught up with the good season. The projects and teams I 've experienced really don't have the size of a single 20 people, but the team is small but I want to survive, no matter what, life must continue, and software must be completed.

Maybe the small team must go to CMMI3, but it is still far from high technology. Let's take a look at CMMI2, but CMMI2 is not a fuel-saving Lamp, and it has included QA management and configuration management, demand management and measurement management are not supported by teams with less than five people. I think the number of auxiliary management tasks for at least three to five people will be increased, in addition, with the supporting development team members, the overall scale should be conservatively estimated to be more than 10-15 people. To be honest, this scale is also a bit difficult for general software companies.

What should I do? CMMI is a completely "ignorant" model, and almost all teams can achieve it. I will not explain it here, so CMMI2 seems to be the minimum limit, does a team of less than 10 really have a problem with cmme? Can't the process domain be cut any more? There is no answer to this cmme expert. The only way is to find it on your own-just like hanging wires with or yuan worth driving, the only way is to go to the used car market for Taobao.

Therefore, we have begun to explore the "minimal mode" between CMMI2 and cmme.

First, I must describe my three points:

1. the "minimum mode" is the minimum limit for my personal tolerance. If this is not met, I personally think that you are not doing software, but playing software; some other experts may think that my "minimal mode" is playing with software.

2. the quality of the "minimal model" software must be lower than the CMMI2 standard. There is no luck in software development, and there is never a good thing to reduce the price, of course, I personally think that the quality of the "minimum mode" is acceptable, otherwise I will be mistaken. of course, it may only be my acceptance. You still need to make your own judgment.

3. the "minimal mode" is intended for current and confused teams. Some small teams have a suggestion and a starting point. I still hope that everyone can take off from here rather than stop it, as I said at the beginning, no one is willing to do the so-called "minimum model" for the rest of their lives. People always have an ideal idea. It is understandable that one to two thousand cars are just working at work, and they will be despised for the rest of their lives.

2 main lines. 4 steps

If there is a simple model, I think there must be two main lines and four steps in the software development process.

 

2The main line is management and technology.

4Step 1 is requirement,Design,Development and testing.

 

The two main lines are dual-track and the four steps are carriage. Trackless cars cannot drive, no cars-This doesn't make sense.

It should be noted that the four steps are only the content of the software execution process. The focus is on the software development lifecycle rather than the project, and the project operation needs to be considered more, just like a train, you need to go out and enter the station, and monitor the travel process to ensure security. For the moment, we will not mention the operation of the project. Let's talk about software development to see what we need at least.

Management

What is management? There is no need to explain it. project management, development management, and team management are all familiar terms. I think a team of more than three people needs to be managed. Nothing else, that is, to allow three independent programmers to make software with defined quality at the specified time and technology, this is like a mythical story. in a word, managers are indispensable. At present, the scale of software is getting bigger and bigger. It is very rare for a lone hero or a bloody development team, therefore, most teams must have the "manager" role. but in many cases, everyone is biased towards managers. Everyone thinks that this is a idle job, and the workload is estimated to be lower than that of our civil servants. Isn't it just a notification or someone who buys dinner. therefore, most of the management tasks are part-time. The most common practice is that technical experts can manage them by the way. what I want to talk about is that the management work is actually very heavy and critical. The management of software quality, time, team, ability, and ultimately success, played a crucial role,

Management should not only be available, but also be dedicated. A team without full-time management should have cars without drivers. I really suggest you do not go up.

Technology

Technology, this is too simple, no technology can do software, the team is large and small, but the developers inside who do not have 2 brush. therefore, technology is the least problematic. is that true.

Here, I need to propose another concept-architecture, what architecture is, and software developers have their own opinions. Everyone knows that the architect is a great job, it has also become the dream of many software people. what is the architecture? I understand it in two words: control. the technology that can be controlled is the framework, and the technology that cannot be controlled is only the theory. the architecture represents not only the technology itself, but also the understanding, understanding, experience, and accumulation of technology. Just like a passenger car driver, he must not only have a special driver license, how many years and bus experience are needed. If nothing is just about driving, the risk is enough to destroy a long-distance trip.

Architecture and control have three problems to consider:

Depth and breadth: The architecture must cover all issues of project development. Please note that there is always a mature solution for any issues in development. this may be a high requirement, but we must make it clear that this is the development direction of our architecture. for example, if there is no good solution to a problem in this project, the next project will be ready. After several projects, the depth and breadth of the architecture will be greatly improved. in fact, no matter what level of problem, you must have a mature solution instead of leaving it to developers for their own use. For example, for Web projects, it is not just performance, security, but reporting that these advanced problems require a solution, some basic problems, such as page turning, Session, and upload, must have mature ideas. This is the breadth, depth, and meaning. Many people are keen to find Google Baidu if they encounter problems, in addition, Google Baidu has also found a temporary solution. For the time being, it does not mention the impact of temporary solutions on the project progress. I just want to say that many architects dream of it, the difficulty is that Google Baidu can replace it in one minute, and the mysteries of it can be easily understood.

Second, unification: This is an obvious problem. The architecture must be unified. Everyone in the development team has different technical routes and different understandings of the architecture, however, the architecture of a project must be unified to control and control the project. the breadth of architecture has a great impact on unification. The larger the breadth, the less room for everyone to exert themselves, and the more unified parts, the easier the architecture to control. I would like to say that many new programmers are very disgusted with the established framework to compress their space to play. Here I would like to tell these new people sincerely that a well-defined team is your gospel, A team that allows new people to play freely is a real trap. Remember.

Finally, accumulation and training: the architecture is definitely not only in the current project, but also the product of the current team. No architect can form a "shocking" Architecture in his first project, the architecture needs to be constantly accumulated and improved in a large number of projects. In addition, the architecture is definitely not exclusive to one or a group of people. After a special person or group is removed, the architecture should still have powerful vitality, this is training. The architecture should be easy to teach to all kinds of future generations. The faster the teaching, the more convenient the architecture is.

 

Requirement

The requirement is to clarify what to do and what to do. However, software is a magical thing. If you don't know what to do, you can start to do something that is almost always happening. I don't know what to do. It's not uncommon to do this.

The requirement is not only a business thing, but also a consensus and contract. The demand cannot be exhausted, and the customer wants more than what we can do, the development team requires a stable and reasonable scope.

Although some technical skills are required, most people can understand and communicate with each other. Most of these requirements are in the scope of customer requirements, that is, to find out what kind of software the customer wants. Demand problems often occur in two aspects:Implementation and Stability. To put it bluntly, we still need to determine whether the technical record can be implemented. In addition, we need to reach a consensus between the customer and the development team to determine the scope of the decision, there is a great relationship between implementation and architecture, while stability requires a game. Here we need the coordination of managers. Of course, there are business problems, and this is not within the scope of this article.

 

Design

Design is what we should do, what style of our software, and what routines. Developers often ignore the design and pay close attention to the demand. The reason is simple. Developers cannot decide the demand, but they can decide the design. Because design is a technology, it is precisely the design problem.

The first problem is the rationality of the design. This is a problem that people often ignore, because rationality is not only a technical issue but also a demand issue. In most projects, the customer's requirements are often extended to the design, especially the interface and user experience. Therefore, prototype validation has been put on the agenda more and more, and can be solved at the demand stage, even as a requirement. This is a problem.

Another problem is the unification of design. Because design is a technical category, developers can design almost everyone. For example, when adding, deleting, and modifying pages, graduates will do the same thing, but the style of everyone will inevitably be different, however, a software must have a unified design, and all the details should be unified. This problem must be solved in the design phase. Many times there will be a problem similar to God, and the detailed design problems are difficult to prevent, resulting in a small number of major software problems, small problems everywhere embarrassing situation, in the face of strict customers, such software is difficult to say professional. It is not difficult to understand why the design documents in Japan are so arrogant.

Development

Development is the skill of most software people, but in fact most people are not very familiar with programming, or do other things before learning programming.

Note two issues during development:Self-discipline and self-check.

First, check whether you have a specification, that is, whether the code you write has a routine. The most obvious mark is comment. Most people have their own experiences with this problem, so I will finish it.

The second problem is development self-check. The popular method is Code Review and unit test. Code Review requires third-party intervention, such as double programming, while unit test requires capabilities other than programming, these require both human and time investment, so they are often ignored. Self-check is not only for companies and projects, but also for yourself. You can reflect on how much programming capability has been improved since you started programming, I can understand the meaning of this sentence.

Test

Testing is to verify the correctness of the software, of course, mainly the consistency of requirements, but many tests will be busy with detecting code vulnerabilities. This is actually paying for the entire development team, including the architecture staff.

Maybe, for a real developer, his code is basically perfect without testing. But I still want to say, just give me a test, the Ancient Poetry cloud "does not know the true colors of the mountains, just because they are in the mountains". Magical development cannot completely discover the problems of their own code. What's more, the software needs to be reviewed from another perspective.

I have not studied much about the tests. I just want to tell you that a good tester is the guardian and teacher of developers. It is said that Microsoft uses senior developers for testing. This is the ultimate model.

 

Next, I would like to talk about my "six-person model" and explore the "minimal model" for development team building.