Introduction-the path to my software and team

2 pain points

After so many years of software development, I have brought a lot of teams, and I have no experience. I can only say that I am a little touched.

Software development is not difficult in the end. This is really a problem. When I graduated, I thought it was a great pleasure to do software, but it was very difficult. What is the result, no project is satisfied. Since it is not difficult to do it, but why is it difficult to do it, it is really a worry.

The number of people required by the software team is no longer a problem, but a pain point. At first glance, I thought that one machine is software, but a thousand people in India, I really don't know what they are doing. Why are there so many people? Are they very benzene?

If you have any experiences, you might as well say two pain points in my heart to smile:

1. The software can be developed only, and the team can be developed only.

2. You can modify the software if something goes wrong.

 

Software is development

Maybe everyone will laugh, when in fact most people will be hurt by these two problems, and hurt for many years.

Software only needs to be developed. This seems to be a very simple truth. Just like the ancient hero, killing people is just a matter of passing through the enemy's body with a knife. That's that simple; yes, software development is to compile the code, compile and run the code, and hand it over to the customer, which is indeed so simple.

Looking at this first pain point, I found that this problem is actually a seemingly accidental necessity. The smallest component of the software is the code. With the code, there is the software entity, with the entity, you can think that the software has been completed. This is a very practical idea. In addition, the boss is most concerned about the cost and time of the project, so increasing the number of developers for the development team seems to be the most "effective" method, one person for one week, so it should be enough for two people to develop for at least three days-everyone will think so.

Of course, software development is really amazing. One amazing thing is that, in any case, the software production process can still be completed, after a certain amount of time and effort, the software was born. It seemed inevitable and unstoppable when it was born. So what are we still worried about.

 

No software failure

Some people say that software completion is only the first step of the long journey, and the customer's requirements are far from over. the real modification is still in the future. yes, the second magic of software development is that the software can make up for previous errors through continuous modification, no matter whether the software you submit is 100 or 20 points, it can survive through continuous modification. It can be said that as long as it can be modified, the software will not fail. What else do we worry about.

2 magic rules

Here we introduce two magic rules for software development:

1. Software only needs to be developed and can be basically completed.

2. The software can survive as long as it is modified and rarely fails.

First of all, we must thank these two magic rules, which greatly lowers the barrier of software development, so that many teams and individuals, even if they are ignorant and have no strengths, you can also step into this industry with a variety of gestures to start your career.

Secondly, these two rules have deeply hurt many teams and individuals. After several years of entering the industry, many people have discovered that these two rules are created as a fantasy, a bottomless pit; software can always be completed but never ended; Software won't fail but never succeeded; confusion and current practices, confused about future development.

 

What are I worried about?

What are I worried about? In fact, I am not quite clear about it;

First of all, the software that will inevitably be completed does not give me and my team any wonderful feelings, whether the software is successful or not, and almost no one can answer this question, naturally, there will be no answer.

Second, the end result of endless changes can only be a pain, a sense of excitement over time, a sense of accomplishment, and a hopeless future. almost no one will like this feeling of "never giving up". The collapse of the team and the bad software are almost inevitable.

Finally, the dream and development have almost become a luxury. Looking forward to the enviable advanced development methods in Europe and America and looking forward to the development space after the age of 30, I always feel that it is so far away, hope for a career has reached the verge of breaking.

 

Finding breakthroughs

How to break through is nothing more than seeking for breakthroughs and imitating advanced models. It is too idealistic to seek breakthroughs. If you have the ability to break through early breakthroughs, why wait until now.

It is inevitable to follow the advanced mode of others. We must never follow the blind path: the advanced mode of others is the level of university graduation. How can we learn and learn what we just walked out of kindergarten, it is not as simple as you think.

Here we will talk about two models that everyone is familiar with: cmme and agile development.

Cmme is a very good system. When I want you to know That cmme is a university graduate level, it is indeed a bit of knowledge to use these kindergarten and elementary school children. CMMI2 basically requires 20 teams (one project). How many single development teams can reach 20 in small and medium-sized companies? Let alone whether the quality of the team's internal personnel is up to standard. Some people also talk about cutting. This is true, but the question is who will crop it? Let our children cut out their big brother papers? Reliable? Difficult to use. I also hoped to help us with the domestic cmme training team to crop, and finally found that this was also difficult. cmme can be used, but it is a step by step, which is difficult to crop.

Agile development is even more a joke. What is agile development? Is it a high school level? It is totally wrong. Agile development is a graduate level, and it is a high-level sublimation of the university level, there is no silver bullet in software development, and there is no shortcut. If the primary school has not yet graduated, it will first use a postgraduate approach to solve the problem. The result can only be a complete failure. in my opinion, if both CMMI2 feel that the team is out of reach, do not try agile development easily.

 

My silver bullet"

L learning: learning to understand advanced models and concepts

L Introspection: carefully analyzes the abilities of teams and members

L customization: Find the minimum mode. from scratch, rebuild a reasonable team and set up a reasonable process.

L development: embark on the path of continuous accumulation and Improvement

Here I think I have the following experiences:

If you do not understand the advanced mode, it is a closed-door building and will inevitably fail.

Blind reform is not based on the team situation, and it will inevitably fail.

Software development has its own pattern, and the minimum pattern is definitely not "two knives for revolution". If there is no way to obtain the minimum resource requirements, don't reform it.

If your reform cannot form an effective accumulation model, do not change it. The reform aims to continue to grow in the future rather than solve the current problem. It is better not to change the reform without a development channel.

In the next article, I will explore the minimum pattern of software development and teams.