walkthrough

이해관계자 워크스루(walk-through)

아무도 문서화하지 않은 요구사항은 작성자가 아닌 누군가가 실제로 작업을 수행하려 할 때 표면화됩니다. 서비스를 설치하는 운영자, 데이터를 검색하는 과학자, 리포지토리를 설정하는 동료, 새벽 3시에 로그를 읽는 유지보수자가 그 예입니다. 워크스루는 변경 사항이 명세되기 전에, 이름을 가진 페르소나와 구체적인 프로세스를 바탕으로 종이 위에서 이를 수행합니다. 그 결과물은 설계가 아니라 소유자에게 전달할 질문, 격차(gap), 그리고 명세와 테스트에서 사용할 수 있는 수용 예시입니다.

MIT 라이선스의 jeffallan의 Feature Forge 스킬에서 차용한 두 가지 습관이 있습니다. 제품 모자(사용자 가치, 목표, 성공)와 개발자 모자(실현 가능성, 보안, 엣지 케이스)라는 두 가지 모자를 번갈아 쓰는 인터뷰 기법과, melodic-software의 requirements-elicitation 스킬에서 차용한 시뮬레이션된 이해관계자가 '말한' 내용은 실제 이해관계자가 말한 내용보다 신뢰도가 낮다고 표시하는 방법입니다.

입력

워크스루를 시작하기 전에 사용자와 다음 사항을 확정하고 출력 상단에 작성합니다.

1. 페르소나. 그들은 누구인가, 이 프로세스를 통해 무엇을 원하는가, 무엇을 알고 모르는가, 자신의 머신에 무엇이 있는가, 절대 읽지 않을 것은 무엇인가. 원형(archetype)보다는 기관 내 실제 사람의 역할을 선호하며, 물어볼 수 있을 때는 추측보다 실제 사람의 답변을 선호합니다.
2. 프로세스. 그들이 수행하려는 작업, 첫 단계부터 완료되었다고 간주하는 순간까지의 과정입니다. 예시: 서버에 크롤러 설치, 인덱스에서 지난주 측정 데이터 찾기, 외부 컬렉션으로 새 파일 형식 추가, 에이전트를 사용한 개발용 새 리포지토리 시작, 야간 실행 후 크롤 로그 읽기.
3. 기존 자료. 페르소나가 만나게 될 문서, 코드, 명령어, 페이지. 계획이 아닌 현실을 테스트할 수 있도록 이 자료들을 읽습니다. 페르소나가 읽는 순서대로, 그리고 그들이 건너뛸 내용은 건너뛰며 읽습니다.

워크스루

페르소나의 입장이 되어 프로세스를 한 단계씩 진행합니다. 각 단계마다 다음을 기록합니다.

• 수행하는 작업: 구체적으로: 입력한 명령어, 연 페이지, 읽은 파일, 질문한 사람.
• 그 순간에 알아야 할 사항: 그리고 기존 자료가 그것을 알려주는지 여부.
• 실제로 여기서 잘못되는 것: 조용한 실패, 오해를 불러일으키는 메시지, 기본값이 없는 선택, 필요한 권한이 없는 단계, 피드백 없이 기다려야 하는 상황.
• 소유자에게 묻고 싶은 질문: 그들의 언어로 표현합니다.

그런 다음 전체 워크스루에 대해 두 번 모자를 바꿔 씁니다. 제품 모자로는 페르소나가 원한 것이 무엇인지, 프로세스가 그것을 제공하는지, 그들에게 '완료'란 무엇인지, 무엇에 대해 불평할지 질문합니다. 개발자 모자로는 실행 불가능한 것, 불안전한 것, 대규모에서 느린 것, 단계 순서상 취약한 것이 무엇인지 질문합니다.

워크스루가 문서에서 다루지 않는 지점에 도달하면 답을 만들어내지 말고 질문으로 기록합니다. 계속 진행하기 위해 어떤 가정을 해야 했다면 그 사실을 밝히고 나머지 워크스루는 그 가정에 기반하고 있음을 표시합니다.

단계가 일반적인 무언가를 드러낼 때는 한 단계 더 올라가서(5 Whys) 생각합니다. 혼란스러운 메시지는 하나의 단계일 뿐이며, '도구가 작업을 수행하기 전에 무엇을 할 것인지 절대 말하지 않는다'는 것은 요구사항입니다.

출력

워크스루를 프로젝트의 디자인 노트(예: design/walkthroughs/<persona>-<process>.md)에 작성하고, 해당 디렉토리가 없다면 docs/walkthroughs/에 작성한 후 답변에 짧은 요약을 제공합니다. 템플릿:

# 워크스루: <페르소나>가 <프로세스>를 수행

페르소나: <누구, 목표, 지식, 환경>. 신뢰도: <시뮬레이션 | ...와의 인터뷰 기반>.
기존 자료: <읽은 문서, 코드, 명령어>.

## 단계
1. **<단계>.** 수행: <...>. 알아야 할 사항: <...>. 잘못되는 것: <...>. 질문: "<...>".

## 제품 모자
<그들이 원한 것, 그들에게 '완료'란 무엇인지, 그들이 불평할 점>

## 개발자 모자
<실행 불가능, 불안전, 느림, 취약함>

## 소유자에게 전달할 질문
- <페르소나의 언어로 된 질문, 해당 단계 출처>

## 격차(Gaps)
- <존재하지 않는 요구사항, 동작 또는 문서; 해당 단계가 필요로 하는 것>

## 수용 예시
- <구체적인 상황일 때, <관찰 가능한 결과>. (명세 시나리오나 테스트에 바로 사용 가능)>

규칙

• 어떤 부분이 시뮬레이션되었는지 명시합니다. 에이전트가 수행한 워크스루는 세심한 동료가 발견할 수 있는 격차를 찾아냅니다. 실제 페르소나가 가치를 두는 것이 무엇인지는 알 수 없습니다. 실제 이해관계자가 있는 경우 그들에게 질문을 전달하고 신뢰도 줄을 업데이트합니다.
• 페르소나의 입장을 유지합니다. 시스템이 어떻게 동작하는지 알고 있어도 페르소나는 모릅니다. 당신이 아는 것이 아니라 그들이 보는 것을 기록합니다.
• 일반적보다 구체적으로. '운영자가 modama-crawler crawl을 실행하고 2시간 동안 아무것도 보지 못함'은 발견 사항입니다. '피드백이 개선될 수 있음'은 발견 사항이 아닙니다.
• 질문, 격차 및 예시가 전달물입니다. 여기서 해결책을 설계하지 마십시오. 소유자가 무엇이 요구사항이 될지 결정합니다.
• 새로운 시각을 고려하십시오. 기존 도구의 경우, 페르소나, 프로세스 및 사용자 대상 문서만 제공받고 도구를 실행하라는 지시를 받은 하위 에이전트는 작성자가 더 이상 모를 수 없는 것을 발견합니다. 이는 이 플러그인의 hallway-test 스킬입니다. 워크스루가 '직접 해보자'로 바뀔 때 사용하십시오.