YAGNI

YAGNI는 일을 여섯 역할로 나눈다. 각 역할에는 정해진 상한이 있다. Bailey는 다음에 올 것을 제안한다. Reeve는 계획을 비평한다. Wright는 pull request까지 빌드한다. Proctor는 모든 PR을 리뷰한다. Fletcher는 브라우저 QA를 실행한다. Harper는 무슨 일이 있었는지 보고한다. 경계는 직무만큼 중요하다. Wright는 절대 병합하지 않고, Proctor는 절대 병합을 막지 않으며, Harper는 전혀 행동하지 않는다.

각 작업 항목은 제안, 계획, 각 실행, pull request, 리뷰, 테스트 증거, 사람이 답한 게이트, 총비용을 담은 하나의 페이지다. 결정은 흩어진 스레드가 아니라 그 페이지에서 정리된다. 그 페이지에 남긴 댓글은 계획의 한 줄이 되거나 Playbook의 새 규칙이 된다. 에이전트가 예상 밖의 일을 했을 때, 그 이유를 여기서 알게 된다.

모든 팀은 훈련 단계에서 시작하고, 모든 단계가 사람을 기다린다. 기록이 해결된 결정으로 채워지면, 엔게이지먼트를 한 칸 올리고 그러면 스스로 처리할 권리를 얻은 일은 더 묻지 않는다. 병합은 어느 칸에서도 사람에게 남는다. 그래서 가장 높은 자율 단계도 감독되는 자율이다.

설정 통화를 지나면 워커와 개발자가 같은 미터를 공유한다. 라우터는 각 단계를 실행 전에 산정하고 품질을 유지하는 가장 저렴한 레인에 둔다. 그래서 일상적인 읽기는 최고 요율을 내지 않는다. 좌석 없음. 플랫폼 수수료 없음. 워커당 청구 없음. 각 실행은 돌아가는 동안 비용을 출력한다.

팀은 단일 저장소가 아니라 당신의 엔지니어링 팀 하나를 그대로 비춘다. 자체 저장소, Playbook, 예산, 그리고 책임을 지는 한 사람을 가진다. 워커는 Jira나 Linear에서 백로그를 읽고 Slack에 보고한다. 그래서 이미 쓰는 도구는 그대로 남는다. 제안 단계에서 Slack의 프로덕트 매니저를 태그하면, 그 답이 작업이 시작되기 전에 계획에 들어간다.

커넥터 자격 증명은 고객 단위로 범위가 정해지고 암호화되며, 기본 접근은 예상보다 좁다. 한 엔게이지먼트에서 어떤 워커는 웹 앱에서 승인하되 인프라 저장소에서는 조언만 하도록 둘 수 있다. 이렇게 하면 넓은 권한이 민감한 저장소로 새어 들어가지 않는다.