Adding to and implementing

Superfluous

When designing and developing the second system, developers are most likely to create a transitional design. For the first system, they are more of a follow-up, and may not be familiar with the system and tasks. They will work carefully to accomplish the tasks assigned by the master. For the second system, they have the experience of the first system, are full of confidence in system development, and have a stronger idea of adding modification and polishing In the first system. Therefore, the second system is most prone to over-design.

It is mainly reflected in the following aspects: developers spend too much time on the Interface aesthetics, but they are more self-aware and ultimately come up with a fancy, non-Concise user interface, therefore, we need to solicit more comments from the artist and the interaction design or users for interface standardization and interaction design. In addition, there is excessive design. Simple problems are solved using complicated ideas or framework models. The weight and framework model of the system should be related to specific business needs, on the basis of scalability and performance, we should adopt as simple as possible methods. The more new technologies are, the more unstable and uncertain.

The requirements for gold plating are another important aspect of the online shopping spree. for developers, it is often easy to determine whether a function is required by the customer, or to guess the user needs certain features based on their own experience in developing historical systems, none of these are possible, but the key point is that any idea of adding or modifying the required feature points should be confirmed by the user. Adding a function is a kind of gold-plated requirement. This not only increases the software development cost, but also disrupts the original development schedule and often reduces user satisfaction.

Some mechanisms need to be introduced in order to avoid superfluous image painting. For example, the formulation of Software Development specifications, including interface design specifications, requirement development specifications, database design specifications, and code specifications, must be strictly enforced. In addition, the review mechanism is introduced. In the demand stage, the review mechanism is introduced to reduce the requirements for gold plating, the reviews introduced in the architecture design phase help to maintain conceptual consistency and determine the matching degree between the architecture and business objectives.

Implementation

I still want to understand implementation as a kind of team discipline. team spirit and team building are important, but they focus on positive team cohesion and work enthusiasm. However, when you are proactive, you may make mistakes, or you may be relaxed and cannot strictly demand yourself. The purpose of discipline is to avoid this situation. Discipline is not a rigid process. discipline is a team rule and determined after joint discussion by the team. Therefore, the project manager should first take the lead in executing team discipline.

Discipline must be documented and rational, if not documented. We often say what we should do next time, but the specific execution details of the things that are stuck in the mouth cannot be found, and the team members will still make the same mistake next time. Team members who fail to comply with the discipline for multiple times must assume corresponding responsibilities. When the set team discipline is not strictly enforced, more people will destroy the discipline, and finally the team rules will become a blank piece of paper.

For software requirement specification, architecture documentation, user manual and help, installation and deployment operations, and so on, they all need to be standardized and documented. If a work item implements the entire software development lifecycle or interacts with users, the work content will be the key considerations of docization. The work content is not only docized, but also standardized. The value must be reflected after the document is made. The key and core content of the value is described in the document. We need to define the key and core content of each of the software requirements, architecture design, and so on.

Meetings are inevitable in software development. The key point of meetings is effectiveness. For weekly meetings, the effective focus is to unify the objectives and negotiate the commitments. Therefore, the task completion and arrangement, problems and risks will be designed. For the review meeting, it is effective to see whether critical problems have been discovered and the leakage of major defects has been prevented. Therefore, the leakage of defects is an important measure. Code lookup is effective in controlling code quality and testing a hundred boxes, and in learning and improving skills by the team.

The best friend of the project manager is the enemy he faces every day-an independent product testing organization/group. The test team should be independent of the project manager to ensure three powers. The tester is the user's spokesperson and Their role includes both verification and validation. For validation, it is important to check whether the final product can meet the user's needs. For verification, it is important to check whether the originally formulated requirements, rules and design decisions have been strictly implemented.