목표 결과를 이니셔티브로 전환하기

단계보다 결과를 먼저 설명하세요

가상의 장비 서비스에 직원 셀프서비스가 필요합니다. 유용한 요청은 결과를 명시합니다. ‘인증된 직원은 요청을 만들고 자기 요청만 볼 수 있다.’

중요한 이유를 설명하세요. 현재는 관리자가 직원을 대신해 요청을 입력합니다. 요청 생성, 상태 표시, 접근 검사, 그 동작의 증거로 범위를 정하세요. 자동 구매와 관리자 승인 규칙 변경은 제외하세요.

저장소를 살펴보기 전에 파일 수정 방법을 지정하지 마세요. 이니셔티브는 의도를 담고 상세 계획은 그 의도를 구현 단계로 바꿉니다.

요청에서 나온 결과를 검토하세요

Taiga는 요청과 제품 맥락을 사용해 이니셔티브 하나 또는 순서가 있는 이니셔티브 집합을 만듭니다. 새 작업은 Backlog에 들어옵니다. 큰 요청에는 독립적으로 검토할 수 있는 여러 변경이 필요할 수 있습니다.

생성된 최종 상태와 Why, Scope를 읽으세요. 필요한 동작이 유지되었고 제외 항목이 지켜졌는지 확인하세요. 기존 이니셔티브가 요청을 이미 다룬다면 Taiga는 중복을 만드는 대신 기존 항목을 알려 줄 수 있습니다.

게시된 정책에 막힌 요청에는 해당 정책이 정한 결정 경로가 필요합니다. 설명을 읽고 그 경로로 충돌을 해결하세요. 금지된 행동을 숨기기 위해 요청을 다시 쓰지 마세요.

보드를 실행 순서로 다루세요

Taiga는 계획을 포함해 제품당 한 번에 하나의 이니셔티브를 처리합니다. 현재 풀 리퀘스트가 머지된 뒤 다음 대기 이니셔티브를 시작합니다. Backlog나 Todo의 항목을 Queue로 자동 이동하지 않습니다.

Queue에 넣는 결정은 중요합니다. 미완료 의존성을 기다리는 동작을 재정의합니다. 직원 셀프서비스를 대기열에 넣기 전에 ID 기반이 있는지, 또는 선택한 범위가 그 기반을 올바르게 마련하는지 확인하세요.

상세 계획을 살펴보세요

계획기는 저장소, 제품 문서, 정책, 지침, 배포 맥락을 읽습니다. 실제 사용자 결과와 환경에 맞춰 계획을 확인하세요.

장비 서비스에서는 세 가지 접근 사례를 검증하세요. 직원이 자기 요청을 봅니다. 다른 직원은 그 요청을 볼 수 없습니다. 관리자는 의도한 검토 접근을 유지합니다. 구현이 데이터 마이그레이션이나 운영에 영향을 주면 이를 포함하세요.

Build on its own by default가 꺼져 있으면 완성된 계획은 결정을 기다립니다. Approve는 승인자의 권한 범위 안에서 승인자 ID로 빌드를 시작합니다. Reject는 피드백을 사용해 다시 계획합니다. 이니셔티브마다 자체 설정을 가질 수 있습니다.

다음 결정에 맞는 기록을 사용하세요

계획은 버전으로 관리합니다. 실행 기록에는 어떤 계획을 실행했는지가 남습니다. 의도한 접근이 바뀌면 이니셔티브와 적절한 재계획 동작을 검토하세요. 이전 시도는 실행 기록에서 살펴보세요.

빌드, 머지된 풀 리퀘스트, 프로덕션 릴리스는 서로 다른 상태입니다. 작업이 진행되어도 인수 증거와 배포 책임을 드러내세요. 자율성 설정에서 계속 학습하세요.