[If you are enlightened] the Japanese-style project module developers should provide a staged Summary (1)

When a module developer assumes the role, the following is a record of the development job flow account, which is to be reviewed and shared. The date is not a strict project process and is for reference only.

 

2012/08/01

■ Japanese-to-Chinese Style samples (I .e. demand statement)

Product: None

■ Read the learning style book (refer to relevant materials for more information)

Product: style Reading Notes, QA

 

JuneJune2012

■ The Japanese side uses a video conference to explain the style to the Chinese side

Product: meeting records, QA

■ Secondary understanding of Chinese Reading Style

Product: style Reading Notes, QA

 

2012/08/07

 ■ Code Volume Evaluation

Product: Code Evaluation Result

■ Break down tasks and establish a module team

Product: Task Decomposition result, established by the team member

■ Develop a Development Plan

Product: Development Plan

 

2012/08/08

■ Start with SD

■ Internal style learning meeting of the group

Product: QA

■ Intra-group division confirmation

Product: module task decomposition results, established by subtask owners, and established by module style owners

 

JuneMarch 10 2012/08/13JuneMarch 172012/08/20

■ SD, progress tracking

Product: progress tracking table, SD product list

■ SD completed

 

2012/08/21JuneJune

■ Start with SDR, select the reviewer

Product: SDR time period reservation, meeting room reservation, reviewer Establishment

▲0.2 hours/review time standard

▲0.2 errors/review errors

■ SDR

Product: SDR result record ticket

 

(Synchronized with the on)

■ SDR result correction (implemented by each module)

Product: Modified SD product, SDR record ticket records

■ SDR amendment validation (cross-responsibility)

Product: the confirmation time and confirmation person of the SDR record ticket record

 

June

■ SDR completed

■ Submit the SD product to the Japanese side for confirmation

Product: SD Product Overview and SD Product

So far, style understanding and SD job have been completed.

Important:

①. During the style understanding and SD operations, we should try our best to find out the omissions and errors of the style and propose QA to the Japanese side. After SD is complete, the style should be fully understood. In PG stage, do not mention any QA.

②. SD Quality Analysis Data Source self-SDR results, which should be recorded in the process including: Total SD workload, total SDR time, SD picking volume, and SD reviewer.

③ There are SDR time standards for fixed projects, such as the above 0.2 hours/piece. There are also SD bug rate standards, such as the above 0.2 pieces/piece. The above floating 30% is better, depending on the project.

④. Plan preparation must be robust and not too tight. It is necessary to reserve some time for other jobs, such as code merging, quality analysis, and project team education.

⑤. The progress tracker should consciously pay attention to matters that may cause delays, such as QA that requires answers from the Japanese side, unknown jobs, and unexpected situations for developers, this requires the module to be more conscious than ordinary developers.

6. When the project is executed in strict accordance with the plan and there are few QA tasks, the module owner needs to be alert. This may be because the subtask owner is not aware of the issue and cannot fully understand the style and mining style errors.

Top priorities:

The later problems and risks are exposed, the more labor and material resources required. Therefore, during the development process, the module owner should always be alert to any possible risks and try to solve them in the project.

 

------

PG job To be continued .....