Methodology in JSP project design

Author: Luck
Email: webmaster@chinaspx.com
When designing JSP projects, the current methodology provides more limits rather than help. According to Mr. Kochmer, the key to successfully running a JSP project is project management rather than design.
.
Contrary to the general idea, the best design methodology is not the formal one when running a project. Most design methodologies are bloated and impractical. If a design method requires a 200-page manual, it can only be described as complicated in actual application. In my opinion, the essence of the design method should be simple and integral. In fact, for a successful design method, the most important thing can be said to be something unrelated to the design, but to the project management strategy. If improperly managed, you may fail even if you have the best design. One of the most important aspects of the design method is that a simple framework must be provided, which should be able to put together a wide range of confrontation and contradictions in any successful design.
In the following guide, we will explain this question and describe the most basic composition principles in project management.
Project management principles
There are several major factors that can cause project failure. The 10 most important factors are listed below, which also contains a simple explanation of each factor.
The project is too rigid to be modified as needed.
There is no principle in the project, and the user's wishes often change, so the project cannot be completed within a reasonable period of time.
Lack of communication or poor communication between programmers and customers.
There are unrealistic expectations.
The schedule is impractical.
The project is too large to be successfully managed.
No tests or too many tests.
Use the wrong tool.
The technologies used by the project are too advanced and advanced for projects and users.
Project members are not respected.
Most of the principles below are proposed to solve these problems. Of course, each project has its own balance. Therefore, each project manager and the main programmer must adjust according to their internal characteristics.
During the project design process, users must be allowed to propose design change requirements. But at the same time, a project must have a certain degree of "rigidity", so as to minimize design changes. Balancing this contradiction requires a very good design art, and the balance between each project is different.
During the project process, the team should communicate directly with the customer, and at least ensure the minimum project review and problem clarification/analysis process.
A project cannot be longer than one year. The best time is 6 to 9 months. It is best to cut any larger or longer project into smaller sub-projects.
The project manager and the program design director must be two different people. The combination of the two roles makes a person's burden too high, and both roles cannot do well.
The number of people in a project cannot exceed 7, with 5 as the best.
It is better for a project team to mix senior and young developers.
I found that if a development team is a senior developer, it is easy for the group to get stuck in lazy and disruptive situations. A team of completely young developers obviously lacks experience. Young members in the team can eliminate the inertia of old senior personnel. Young new users may often ask why? Such problems often lead to good improvements. At the same time, senior developers can train new users so that they can often check the design, which can also bring about improvements.