IDD는 짧은 학습 흐름 뒤에 엄격한 승격 경로를 둡니다.
작업이 답해야 할 질문을 씁니다. 넘지 말아야 할 안전 경계도 함께 씁니다.
좋은 질문: “어떤 데이터 모양이 이 세 가지 사용자 행동을 가장 쉽게 설명하는가?”
약한 질문: “기능을 만들어라.”
첫 질문에는 증거로 답할 수 있습니다. 둘째 질문은 많은 결정을 구현 안에 숨깁니다.
질문에 답할 수 있는 가장 작은 구현을 만듭니다. 운영 트래픽, 실제 비밀과 영구 데이터에서 떼어 놓습니다. 임시 구현이라고 표시합니다.
탐침 하나는 핵심 불확실성 하나만 시험해야 합니다. 서로 관련 없는 질문 여러 개에 답한다면 나눕니다.
다른 사람이 확인할 수 있는 형태로 결과를 기록합니다. 증거에는 다음이 포함될 수 있습니다.
- 입력과 출력 예제
- 측정값
- 실패 사례
- 화면 또는 실행 흔적
- 구현 중 발견한 가정
- 경쟁 탐침 사이의 차이
동작하는 코드만으로는 부족합니다. 증거는 처음 질문과 연결되어야 합니다.
어떤 동작을 제품의 일부로 만들지 사람이 결정합니다. 받아들이거나, 거절하거나, 여러 결과를 합치거나, 다른 탐침을 요청할 수 있습니다.
이 단계는 발견과 권한을 분리합니다. 에이전트는 권고할 수 있습니다. 제품의 의미는 사람이 결정합니다.
결정을 오래 유지할 수 있는 검사로 표현합니다.
- 정해진 동작을 위한 테스트
- 인터페이스를 위한 계약 또는 스키마
- 점수화된 예제가 필요한 동작을 위한 평가
- 안전 또는 사업 규칙을 위한 불변조건
그다음 공식 구현을 작성하거나 고쳐 이 검사를 통과시킵니다. 탐색 코드를 조용히 승격하지 않습니다.
구현 시도와 독립된 검사를 사용합니다. 다른 검토자, 새 문맥을 가진 별도 에이전트, 결정적인 검사기 또는 이들의 조합이 될 수 있습니다.
검증자는 작성자의 의도가 아니라 승인한 계약을 확인합니다.
변경을 배포 가능하다고 부르기 전에 위험에 맞는 게이트를 적용합니다. 보안, 성능, 개인정보, 롤백, 관찰, 마이그레이션, 운영과 문서가 포함됩니다.
| 상태 | 의미 | 아직 필요한 것 |
|---|---|---|
| Probe | 질문 하나를 위한 임시 구현 | 증거와 제품 결정 |
| Candidate | 비교하거나 다듬을 가치가 있음 | 승인된 동작과 지속 가능한 검사 |
| Contracted | 사람의 결정이 테스트, 계약 또는 평가에 표현됨 | 필요한 배포 게이트와 독립 검증 |
| Shippable | 계약된 변경이 필요한 게이트를 통과함 | 실제 릴리스는 별도의 운영 행동 |
상태 변경은 명시적이고 추적 가능해야 합니다. 코드베이스에 오래 있었다는 이유로 탐침이 배포 가능해지지는 않습니다.