3 P and 1A in software development

This is a summary of past development, management experience and pspl and SEA development experience.
This summary focuses on development management, including four aspects: Project; process; product; architecture;
Therefore, the summary is named 3 P and 1A in software development.
The outline is as follows:
1. 3 P relationships in Development and Management
Starting from the project, summarize the process, sublimate the product, and not abstract the architecture.

2. Relationship between 3 P and 1A in the development management used in this development
Plan the architecture, develop the product, summarize the process, and promote it to the project.

Iii. Process summary

Iv. Architecture Summary

1. 3 P relationships in Development and Management
In the past, many companies in China received tickets and established them again. This is also the case for the companies I have experienced.
Therefore, the company's work can be divided into two parts: open a ticket and create a project. Work starts from opening a ticket and ends with acceptance.
There is only one concept: Project.
Slowly, when the company is large and there are more projects, it finds that some projects are doing well and some projects are doing messy.
How can this problem be solved? At this time, management will be put on the agenda. We need to strengthen management by using ISO9000 and CMM.
ISO9000 is about process standardization, while CMM is about Process Capability Maturity. Then we set up organizations such as QA and SEPG to organize and summarize the process.
As the market becomes more and more competitive and the customers become more and more mature, in the new market field, the good days of getting a ticket by link + PowerPoint have also gradually passed.
The customer selects and selects different current products. Therefore, the R & D department needs to develop a new product, issue a ticket to the sales department, and implement the product for the engineering department.
Product becomes a link connecting the market, R & D, sales, and engineering.
In the old market field, as the number of projects increases, there is a very chaotic version relationship, which brings many problems.
The most typical problem is that version A becomes a benchmark version because it is typical and widely used in subsequent projects. It is implemented in Project B to solve some bugs and become Version B,
The C Project also contains these bugs, and Version C is inherited to present a complicated bug propagation phenomenon, and everyone is struggling with it.
Defining and maintaining the benchmark version is an important task.
In this way, the product gradually emerged as an object that everyone began to pay attention to, but how to solve it is still under exploration.
Product lines and product groups are a test direction.
When it comes to architecture, there is no concept, just some sprout, such as summing up the technical platform.
From project to process, to product, this is a very natural process. It is a process of finding and solving problems by feeling the stones,
It is a better choice for companies that are under great pressure to survive, and a deep understanding of software development. However, such a process also needs to be transformed
Pay a considerable amount of money and carry a considerable amount of historical debt.
(To be continued)