What metaphor do you use in unpredictable R & D projects?

Metaphor description software project,CodeDaquan 2 introduced this method. This method does not know where it originated, but it is indeed visible everywhere in the lives of our software engineers.

Unpredictable R & D projects

A friend of mine told me that his boss is too anxious. Good software is like planting crops. It takes time and care to wait for it to grow. He is a person who always challenges areas he is not familiar with, and is always trying to do it on his own without relying on other open source software development talents. So he has a special situation. It seems to be a bit of a metaphor for planting crops. In fact, it also contains many characteristics of writing metaphor, throwing away and rewriting.

This method of describing the writing metaphor in the Code Daquan is costly. However, the practice of farming through small steps makes the boss unable to predict the progress. Therefore, it is conceivable that R & D personnel using this method carry a lot of mental pressure, and even if it is made, it will cause complaints in most cases.

At least in my opinion, analyzing the risks and costs of using new technology for development won't win first. Then the system is divided into different parts, taking into account their own capabilities, team resources, and selecting some modules for full R & D, other reuse of existing technologies, even if those parts will be reconstructed in the future. There is a similar example. gitlab has just begun to manage permissions based on gitolite. However, as the software continues to mature, the team's ability is improved, since 5.0, they replaced gitolite with their own gitlab shell. This refactoring made the system no longer use two permission management mechanisms, greatly simplifying the code and eliminating many hidden risks.

If you want to cut the system into different parts, it means that this system is structured from a higher level, and the subsystems and modules with different responsibilities are continuously split in a layered manner. Therefore, architecture design must be experienced. Only in this way can we get a system architecture diagram, mark the difficulty with different colors, and then choose the modules that the entire team can do to innovate, however, we will not be able to take care of the remaining parts based on secondary development of other software.

My friends are also opposed to scrum. He believes that every sprint will produce results, and the problem is that R & D is unpredictable. How can we ensure delivery on time? A general project can do this. R & D is the combination of science and art.

But there is no way. In reality, the cost of enterprise operations will be rewarded, risks need to be controlled, and the progress cannot exceed expectations. It is often a matter of methodology, such:

1. Use the previous method to set up the architecture, just like building a house (this is the fourth metaphor), and only do the research and development within the capacity to reuse other modules.

2. Using the correct user story to guide the functions of the entire product is indeed better than what engineers do.

3. In terms of the technical objectives of software development, it is good to use the metaphor of oyster farming. Do not design too high goals. Many well-known software have their own development history. since childhood, they have gradually matured. It has undergone several major restructures, such as oracle. If you are able to stay calm, pass the test of time, and continue to evolve. Software is like a creature that will evolve.

4. During the development process, it is often prone to unexpected situations. To change the priority of story, I suddenly want to add a new task. All of these issues need to be discussed with the team seriously, so we cannot engage in personal liberalism. This is actually a lot of geniusProgramEmployees are too proud to cooperate.

In this way, the Sprint plan is close to the team's ability, so there will not be too many unreliable items in the sprint review. This does not mean that there will be no problems. There may be some story that will be rejected by the product owner during review, but this is where the next sprint will learn the lesson: the plan is unreasonable, or a technical debt.

After the above efforts, we can reduce uncontrollable factors, but if the team is really not familiar with the field, oyster farming is a good practice. In this case, the metaphor of housing architecture can only be used for coarse-grained architecture, because it is a completely unfamiliar field, and it is not significant to be careful, but will lead to a waste of costs. Just like metaphor 4-building a house, planning structural support clearly and deciding whether to use wood floors or carpets in the future.

In short, I always use both growth and architectural metaphor.