Article 2: Development Task Decomposition Process

In software development, the process is out of control due to the incomplete decomposition of functions (tasks), and may be delayed due to repeated modification of functions or unexpected technical difficulties, it is more likely to be re-launched. In the development process, a company usually submits a project to a project team, which only requires a few months to complete. The project team is assigned to a developer who only specifies the modules that a person needs to complete, for example, the user management module and the mail sending module. For the company, the project is the smallest decomposition unit, and for developers, the module is the smallest decomposition unit. If a module requires 1000 lines of code and seven working days, it is generally difficult for a person to know the detailed process without the support of any tools, you cannot know the technical or process risks you may encounter.

In software development, nine out of ten people think that development tasks cannot be quantified and can only be qualitative. Therefore, development models such as test-driven development will emerge to be quantified, this has become an insurmountable gap. In fact, what we usually call energy refers to the number of items that can be counted. For example, fruits can be called weights in addition to numbers, such as software development, that is, data cannot be quantified.

The consulting industry used to be an industry I dreamed of entering. Unfortunately, this behavior is like the software industry. It is very popular abroad (with a high threshold) and has become a migrant worker in China, mcKinsey, one of the three major consulting companies, also staged Waterloo in China. Like the software industry, the work of their consultants and developers is not easy to quantify. However, McKinsey's consulting work is refined to every step, the consulting content is refined to every process. This endless and refined working method should also be suitable for software development. The detailed analysis method of this task is called MECE.

MECE is McKinsey's first female advisory consultant Barbara Minto put forward a very important principle in the pyramid principle (the Minto Pyramid Principle, mutually Exclusive collectively exhaustive ". MECE analysis mainly refers to the method of dividing a work item into several finer work tasks. During project decomposition, the integrity and independence of the project must be ensured. The total number of sub-projects after decomposition is = 1. If> 1 exists, it indicates that there are overlapping parts. If <1, it indicates that there are omissions.

In the software development process, we can also break down modules and functions one by one. According to the MECE analysis method, when analyzing problems, we start from the highest level of solution, set the dimension of the solution and list all projects in each dimension. When determining that each project can be solved as an independent project, you can seek a solution for the project. If a project cannot be solved as an independent module, then we must continue to break down. What kind of program can be regarded as an independent project? For example, a user manages this project because it contains functions such as adding, modifying, deleting, and querying, these functions can also be used as an independent small project, so "user management" cannot be used as an independent project. If the analysis granularity ends, the developer in charge of the "user management" project may not know how many functions he needs to implement. Is it necessary to delete the project? Is query required? If you are not sure, the progress will be out of control. Since "user management" cannot be used as an independent project, we can continue to break down the project, for example, "add user", and "Add User" cannot be used as an independent project, because the format restrictions of checksum and username are used when adding them, you can break them down again to find out the two independent projects, "checksum" and "User format limit, taking the checksum as an example, it only involves "querying whether a user exists with the user name as the keyword". In this way, you can determine the object to be queried, the keywords to be queried, and the expected results.

If we break down a whole project into several such completely independent small projects, when developers get the development task, it is a small project, each small project clearly describes what results are needed under what conditions, and the time consumed for these small projects generally does not exceed one working day. developers can freely arrange which small projects can be completed on a daily basis, quality control personnel also know what small projects need to be checked, and everyone knows exactly what they need to do, what they have done, and where problems have occurred. In this way, developers do not need to be entangled in complex logic services, and do not need to bear the risks arising from the complexity of modules. They can safely consider the technologies used to implement these small functions.

 

PS: After writing it, I always think it is not perfect. The ideas and procedures are not clear enough. It's a bit confusing to see the smell of flowers! Change again tomorrow