Quick Validation. Build

12009

Overview

The build phase is the process of converting natural language descriptions into executable software, referred to as "quality-compliant software packages." This phase requires relevant personnel to reach a consensus on business issues and experimental plans, as well as to accurately translate the team's intentions into a final digital program composed solely of 0s and 1s.

This phase involves the most participants, especially when developing a new product or making significant changes to an existing product. Participants include business personnel, product managers, development engineers, testing engineers, and operations engineers. Each role has different background knowledge and skill advantages, and how to quickly transform the solutions in people's minds into runnable high-quality software packages has always been a challenge in the field of software engineering. This is the phase with the most uncertainties during the validation stage.

Timebox management, task decomposition, and continuous validation are effective methods to address this uncertainty.

Management Methods

Timebox Management

This is a common management method used in many project management approaches. The timebox method typically involves deliverables, delivery quality, and deadlines. By establishing a timebox management mechanism, the current project status (progress and quality) can be understood, risks can be identified in a timely manner, and countermeasures can be formulated. It allows the team to continuously focus on work output and receive timely feedback on progress and quality.

Task Decomposition

The two common types of task decomposition are requirement splitting and development task splitting.

Requirement Splitting

The "requirements" referred to here are the minimum viable solutions that have been explored and selected by the team to enter the implementation phase, rather than the original business domain requirements. "Requirement splitting" is the process of breaking down the experimental plan into finer-grained sub-requirements through team discussions, and it is also a process for team members to reach further consensus. The output of this work is finer-grained sub-requirements. Through requirement splitting, team members communicate and ask questions, making the solution clearer and reducing ambiguity. At this point, "whether the team has reached a consensus" can be used as a criterion for whether the requirements are clear.

Development Task Splitting

To achieve a certain requirement, it is divided into multiple development tasks, which can be completed by one person or multiple people. The difference from requirement splitting is that once development tasks are completed, they typically cannot be accepted by other roles. This process is also a further refinement of the requirements, allowing for the identification of finer-grained risk items.

Continuous Validation

Whenever a development task or requirement (including sub-requirements) is completed, the delivery quality is immediately validated, rather than waiting for multiple requirements to be completed before conducting a large-scale quality validation. This is a rapid feedback mechanism, meaning that feedback is provided as soon as a task is completed. For example, these quality validation tasks may include code standard checks, code security scans, and verifying whether the original functionality has been compromised or whether design requirements are met. Although the work results have not yet been delivered to the user, it is possible to validate whether they meet internal quality standards.

If all continuous validation work relies on manual execution, then continuous validation will incur high costs. "Continuous integration" and "automated testing" are effective means to reduce the costs of continuous validation. Continuous integration refers to the practice where developers integrate their completed development tasks with the code of other team members (or the functionalities of other modules in the system) as soon as possible and validate the quality of the completed task. The quality requirements not only pertain to the current development task but also ensure that no damage has been done to existing functionalities. Only in this way can developers receive early feedback on code quality and avoid leaving defects for downstream work.

In continuous integration practices, the most important quality validation method is automated testing. The coverage, execution time, and reliability of test results of automated testing directly affect the reliability and credibility of the quality feedback itself and are crucial aspects that cannot be overlooked.

## Overview

The build phase is the process of converting natural language descriptions into executable software, referred to as "quality-compliant software packages." This phase requires relevant personnel to reach a consensus on business issues and experimental plans, as well as to accurately translate the team's intentions into a final digital program composed solely of 0s and 1s.

This phase involves the most participants, especially when developing a new product or making significant changes to an existing product. Participants include business personnel, product managers, development engineers, testing engineers, and operations engineers. Each role has different background knowledge and skill advantages, and how to quickly transform the solutions in people's minds into runnable high-quality software packages has always been a challenge in the field of software engineering. This is the phase with the most uncertainties during the validation stage.

Timebox management, task decomposition, and continuous validation are effective methods to address this uncertainty.

## Management Methods

### Timebox Management

This is a common management method used in many project management approaches. The timebox method typically involves deliverables, delivery quality, and deadlines. By establishing a timebox management mechanism, the current project status (progress and quality) can be understood, risks can be identified in a timely manner, and countermeasures can be formulated. It allows the team to continuously focus on work output and receive timely feedback on progress and quality.

### Task Decomposition

The two common types of task decomposition are requirement splitting and development task splitting.

**Requirement Splitting**

The "requirements" referred to here are the minimum viable solutions that have been explored and selected by the team to enter the implementation phase, rather than the original business domain requirements. "Requirement splitting" is the process of breaking down the experimental plan into finer-grained sub-requirements through team discussions, and it is also a process for team members to reach further consensus. The output of this work is finer-grained sub-requirements. Through requirement splitting, team members communicate and ask questions, making the solution clearer and reducing ambiguity. At this point, "whether the team has reached a consensus" can be used as a criterion for whether the requirements are clear.

**Development Task Splitting**

To achieve a certain requirement, it is divided into multiple development tasks, which can be completed by one person or multiple people. The difference from requirement splitting is that once development tasks are completed, they typically cannot be accepted by other roles. This process is also a further refinement of the requirements, allowing for the identification of finer-grained risk items.

### Continuous Validation

Whenever a development task or requirement (including sub-requirements) is completed, the delivery quality is immediately validated, rather than waiting for multiple requirements to be completed before conducting a large-scale quality validation. This is a rapid feedback mechanism, meaning that feedback is provided as soon as a task is completed. For example, these quality validation tasks may include code standard checks, code security scans, and verifying whether the original functionality has been compromised or whether design requirements are met. Although the work results have not yet been delivered to the user, it is possible to validate whether they meet internal quality standards.

If all continuous validation work relies on manual execution, then continuous validation will incur high costs. "Continuous integration" and "automated testing" are effective means to reduce the costs of continuous validation. Continuous integration refers to the practice where developers integrate their completed development tasks with the code of other team members (or the functionalities of other modules in the system) as soon as possible and validate the quality of the completed task. The quality requirements not only pertain to the current development task but also ensure that no damage has been done to existing functionalities. Only in this way can developers receive early feedback on code quality and avoid leaving defects for downstream work.

In continuous integration practices, the most important quality validation method is automated testing. The coverage, execution time, and reliability of test results of automated testing directly affect the reliability and credibility of the quality feedback itself and are crucial aspects that cannot be overlooked.