클로드와 협업과정 도식화 – 에이전트들을 만들어 끊임없이 토론시키고 정리하라
AI 협업을 어떻게 해야 좋을까?
고민하다 다양하게 접근하였는데요.
요즘은 컨셉잡으면 바로 코딩들어가지요. 현장에서는 화면 타이틀만 주어지면
나머지는 도급계약직이나 프리개발자들이 알아서 코딩하고 완료해야하는 경우도
많이 있습니다.
똑같이 퀀트시스템을 개념설계까지 이끌고, 1900건의 요구사항을 가지고
스프린트를 나누어 실행했더니 모바일 9개화면을 최종 결과물로 내고 이행되었다는
말을 하였습니다.
데스크톱버전은 아예 생략해버렸고 무엇이 문제인지 알고 싶었습니다.
요구사항 추적표와 프로덕트 백로그를 제출하게 했고 요구사항 설계누락이 상당 수 있다는 것을 알게 되었습니다. (여기서 설계서는 화면 정의서죠. 요즘 화면설계서라고 불리우는 왜 그렇게 정의되었는지 과정이 없는것은 그냥 화면 정의서라고 부릅니다.)
상세설계가 이루어지지 않은 상태에서 작업을 하니, 좋은 말과 텍스트 표시로 전부 반영되었다는
거짓된 보고가 이루어졌습니다.
다시, 수행한 스프린트를 전량 폐기하고, 개념설계 이후의 상세설계를 QA를 행해가며 다시 진행하고
다시 구현을 위한 스프린트를 세울 수 있을정도의 설계을 끌어낼 수 있게 되었습니다.
이렇게 단계 별로 진행되고, 쓰면 안되는 부정합상태로갔다가 다시 오류를 바로 잡고 돌아오는 과정을
설계의 상태가 전이되는 과정으로 볼 수 있을 것 같아서 이런 과정을 상태전이도로 정리해 보았습니다.
어떻게 프로젝트를 그리는가는 이끄는 사람 취향이겠고, 앞으로도 변화하겠지만 저는 에이전트들을 통해
도출하고 합의해내는 과정이, 결국 코딩을 하는 (손)으로 역할보다 먼저 객관화된 요구사항과 설계들을
이끌어내는 (머리)로써 AI를 활용비를 높이는 것을 추천해 봅니다.
요구사항 추적표
1,900건의 원천 의견에서 추려낸 요구사항 1,179건을, 설계요소·메뉴·스크린 반영 여부와 원천 의견까지 한 줄로 잇는 요구사항 추적표입니다. 헤더를 클릭해 정렬하고, 필터로 원하는 유형·릴리스를 좁혀 볼 수 있습니다. (빈칸은 아직 반영되지 않은 곳을 감추지 않고 그대로 드러냅니다.)
유형: BIZ(비즈니스)·OBJ(목표)·RULE(규칙)·UC(유스케이스)·FR(기능)·DR(데이터)·EIR(연동)·QA(품질)·CON(제약)·ENV(환경)·AS(가정)·UX(사용자경험) · 출처: quant_pm DB 요구사항 추적표