In the management practice of a software R & D project, the decomposition of project tasks has always been a very important task, but different project managers often operate on this problem in a different way, one of the most common differences is horizontal or vertical decomposition? This article attempts to make a simple discussion on this, hoping to give the project managers who are in the confusion of Project Task Decomposition a little reference. The following two concepts are explained: horizontal decomposition refers to the Division of Personnel roles and task breakdown based on the technical architecture layer. A common scenario is that the technical architecture of a project uses three layers: presentation layer, business layer, and persistence layer. Then, the three layers adopt the struts, spring, and hibernate frameworks respectively, therefore, when recruiting personnel, they put forward requirements for the use of the corresponding framework. When a specific task is decomposed, the Project Manager first breaks down the module task plan, and then the designer defines the inter-layer interfaces of each module, then, the specific encoding task is decomposed Program Member. Vertical decomposition refers to task decomposition based on business modules. A common case is that the project manager first draws up the overall project progress plan and then breaks down the project tasks by module. The designer pays attention to the consistency of interfaces between modules and technical systems, the design and implementation of specific modules are independently implemented by the owners of each module. Horizontal decomposition is a common method currently, with many advantages. There should be many related introductions on the Internet, but the disadvantages are obvious: first, for common programmers, configuration files are very cumbersome to compile, and often do not have a compilation period check. Code Smooth. Second, the code for reading a simple module usually needs to be transferred between the Code and the configuration file, which is difficult, especially for programmers who take over the work of their predecessors, it is a disaster. Thirdly, horizontal decomposition is based on good communication between layers within the module. It requires a high level of communication. If this work is not done well, the entire project will be stuck in the quagmire. Of course, pointing out the shortcomings of horizontal decomposition does not mean to make a full rejection of such a scheme, and many of the shortcomings of the scheme can be avoided in the project, the successful implementation of this scheme is based on many assumptions. For example, the project has a certain scale, the relevant personnel have the technical ability to work in the relevant positions, and the inter-layer interface can be well defined, project Members can communicate well. if many of these assumptions are not met, implementation of this scheme will lead to disasters. I once met a case where I was a video portal O & M system project with a total of 10 projects, but the project manager insisted on horizontal decomposition, it is said that large companies like Microsoft and IBM adopt such a solution. I only asked him one sentence: Where do you know that large companies use this solution? Are you a big company? Of course, he did not seriously consider the problem I raised, and he still implemented his project management policy with a bold axe: first, set two QA engineers to take charge of the test, and one artist to take charge of the page, the remaining six people are divided into the front-end three responsible for the presentation layer and the back-end three responsible for the persistence layer. He only works on the project schedule.
After the split, he found that no one had done the task at the business layer. Because the business layer is closely related to the presentation layer, the task naturally fell onto the front-end of three people, however, there was a huge gap between the frontend and backend, so the tasks at the business layer were changed to those at the backend. However, since the interfaces were not well discussed, the integration test encountered many problems. In fact, many start-up or relatively small software companies adopt vertical decomposition solutions. Due to limited resources, a large number of projects, and lack of high-level system analysis and design personnel, some projects are even completed by one person from Requirement Analysis to coding testing. It is impossible to apply the horizontal Decomposition Scheme mechanically. Of course, the vertical decomposition scheme requires a high level of personnel quality. Not only do you need to be familiar with the technology of the presentation layer, but you also need to understand the basic knowledge of the persistence layer and the business process, what is important is that there is a lack of application-oriented, layered and integrated frameworks on the market, which can facilitate program designers to quickly develop well-designed enterprise applications.
