이번 포스팅은 회사 업무를 하면서 팀원들에게 좋은 피드백을 받은 경험에 관한 포스팅입니다.
저는 업무를 진행 할때 다음과 같은 방식으로 진행합니다.
언어 정의
흔히들 말하는 DDD에서 가장 중요하다는 Ubiquitous Language(보편 언어)를 정한다고 보면됩니다.
기획 첫 시작 등, 문서에 항상 제가 헷갈리는 용어나 기획팀이나 개발팀등 지칭하는 단어가 혼용되거나 하면 한번씩 정하고 지나가는 작업을 합니다.
해당 작업을 함으로써 잘못된 커뮤니케이션을 상당히 방지 할 수 있습니다.
요구사항 정의
회사 내부에선 사양문서 정의 라는 말로도 많이 쓰이는데요.
기획 문서를 보고 제가 이해한게 맞는지 테스트 케이스를 작성하고 답변을 작성합니다.
만약 답이 예상안가는 테스트 케이스의 경우 질문만 작성하고 기획자 분에게 답변을 요청합니다.
다음과 같은 방식으로 합니다.
중복으로 등장하는 케이스들이 좀 많죠? 아직 요구사항을 명확히 이해못할때 작성하여서 그렇습니다.
하지만 해당 작업을 통해서 기획자분과 요구사항을 명확히 하고 제가 만들어야할 비즈니스 로직이 뭔지 명확해지는 단계를 거칩니다.
테스트 코드 작성
이제 테스트 코드를 작성합니다.
위에 기획자 분하고 소통한 테스트 케이스중 중복을 제거하고 서버쪽에서 필요한 테스트 검증 케이스 등을 추가하고 테스트 케이스만 먼저 작성 후 코드리뷰를 받습니다.
이 과정을 통해 아키텍쳐를 점검하고 팀원들과 논의를 거치고 피드백을 받습니다.
드디어!! 코드 구현
이제 드디어 코드 구현의 순간입니다.
위에서 생각을 다하고 방향을 다 정해놧기 때문에 코드 구현은 금방하게 됩니다.
구현을 하고 코드리뷰 후 main에 병합한다면 업무 완료입니다.
위와 같은 방식으로 일하면서 느낀 장점은 크게 3가지입니다.
1. 언어(용어)혼동에 대한 리스크가 사라집니다.
2. 요구사항에 대한 정의가 명확해집니다. 개발자도, 기획자도, 디자이너도 무엇을 어떻게 해야할지 효율적으로 계획 할 수 있습니다.
3. 피드백이 빨라집니다. 위 방식으로 일하니 각 단계마다 전체팀 -> 기획자 -> 개발팀 순으로 피드백의 범위가 좁아지고 각 단계별로 피드백이 끝난 완료된 상태에서 진행 할 수 있어 업무의 효율이 증가합니다.
