기능마다 요구사항·설계·작업을 쓰고 승인받은 뒤 개발하기

## 프로젝트 전체 지침과 기능별 명세를 나눠 두기 개발 지침을 의도적으로 두 계층으로 나누어 유지하십시오. 프로젝트 운영 지침에는 지속적인 제품 맥락, 기술 선택, 저장소 구조, 정책, 규약을 기록합니다. 기능 명세는 범위가 한정된 변경 한 건을 정의하고 그 요구사항, 설계, 작업, 조사, 검증 증거를 담습니다. 기능 작업을 시작하기 전에 관련 프로젝트 운영 지침을 불러오고, 안정적인 제약 조건이 바뀌면 최신 상태로 유지하십시오. 기능별 결정이 프로젝트 전체의 지침을 암묵적으로 다시 쓰도록 절대 허용하지 마십시오. 활성 명세를 식별하고 현재 단계를 공개하여, 재개한 작업이 추측이 아니라 기록된 상태에서 이어지도록 하십시오. ## 먼저 범위를 살피고 명세 하나로 갈지 로드맵으로 나눌지 정하기 아이디어, 영향을 받는 시스템, 종속 관계, 예상 결과를 명확히 하는 짧은 사전 탐색으로 시작하십시오. 범위가 한정된 기능 하나에는 단일 명세를 바로 개설하십시오. 광범위한 계획에는 개요서와 로드맵을 만들고, 작업을 응집력 있는 여러 명세로 나누고, 종속 관계를 기록하고, 그 관계에 따른 단계별로 구현 일정을 수립하십시오. 기존 시스템을 변경할 때는 설계 전에 현재 구현을 조사하고 격차, 호환성 제약 조건, 재사용 가능한 구성요소를 기록하십시오. 신속 경로는 의도적으로 선택한 경우에만 사용해야 하며, 이 경우에도 필수적인 요구사항, 설계, 작업, 검증 산출물을 만들어야 합니다. ## 요구사항, 설계, 작업을 순서대로 쓰고 단계마다 승인받기 명세 단계를 다음 순서로 진행하십시오. 1. 동작, 경계, 제약 조건, 인수 조건을 정의하는 테스트 가능한 요구사항을 작성하십시오. 2. 요구사항을 설계의 근거로 삼기 전에 사람의 검토를 받으십시오. 3. 각 요구사항을 아키텍처, 인터페이스, 데이터 흐름, 위험, 검증에 연결하는 설계를 작성하십시오. 4. 설계를 검토한 다음, 종속 관계와 완료 검사를 포함하는 순서가 정해진 구현 작업을 도출하십시오. 5. 의도적으로 선택한 신속 경로가 전체 절차를 이미 승인한 경우가 아니라면 구현 전에 작업 계획의 승인을 받으십시오. 범위가 실질적으로 바뀌면 오래된 계획을 임시로 수정하지 말고, 영향을 받는 단계로 돌아가 후속 산출물을 다시 검증하십시오. ## 승인된 작업만, 전체 또는 지정 작업 모드를 정해 구현하기 승인된 작업에서만 구현을 시작하고 실행 모드를 명시적으로 선택하십시오. 전체 범위 모드에서는 승인된 계획을 자율적으로 실행하고, 유용한 경우 작업 단위로 업무를 나누고, 결과를 통합하고, 독립 검토를 받은 뒤 최종 검증을 실행하십시오. 선택 작업 모드에서는 현재 맥락에서 지정된 작업만 구현하고 관련 없는 작업은 그대로 두십시오. 완료된 작업을 나중에 다시 검증해야 할 때는 별도의 구현 검토를 사용하십시오. 필수 정보나 필요한 권한이 없거나, 안전 문제가 있거나, 범위를 바꾸는 결정이 내려지지 않은 경우에만 일시 중지하십시오. 어렵다는 사실만으로 승인된 워크플로를 포기해서는 안 됩니다. ## 개발용 스킬을 재사용하고 독립 검토 받기 전문 개발 절차를 명확한 진입 지침 하나와 선택적인 템플릿, 예시, 보조 참고 자료를 갖춘 재사용 가능한 스킬로 유지하십시오. 스킬은 현재 작업 맥락에서 작동해야 하며, 플랫폼, 권한, 작업 범위가 허용하는 경우에만 범위가 한정된 병렬 조사나 검토를 위임할 수 있습니다. 구현에서 발견된 사항에는 반대 관점의 검토를, 장애에는 근본 원인을 먼저 찾는 디버깅을 적용하고, 완료를 주장하기 전에는 최신 증거로 검증하십시오. 관련 스킬이 작업에 적용될 가능성이 작더라도 이를 살펴보고 적용하십시오. 겉보기에 단순하다는 사실은 그 보호 장치가 불필요하다는 증거가 아닙니다. ## 명세 상태를 계속 갱신하고 최신 증거로 완료를 보여 주기 내부 추론에 다른 언어를 사용하더라도 명세 산출물은 해당 명세에 설정된 대상 언어로 작성하십시오. 현재 단계, 승인된 산출물, 종속 관계, 완료한 작업, 남은 작업, 보류 중인 결정 사항을 포함한 상태를 워크플로 전반에서 확인할 수 있게 하십시오. 소스 검사나 작업 완료만을 근거로 성공을 주장하지 마십시오. 적용 가능한 구현 검증을 실행하고, 그 결과로 생성된 산출물을 살펴보고, 완료 설명을 현재 증거와 연결하십시오. 검토나 구현으로 결과가 바뀐 뒤에는 명세와 상태를 업데이트하여 다음 세션이 실제 상태를 이어받게 하십시오.