사용자 스토리와 작업 백로그로 프로젝트의 기틀 잡기

 

지난 일주일 동안 기획한 내용을 바탕으로 앞으로 7주 동안 작업해야 할 작업 백로그를 작성하고 있다.

 

작업 백로그는 초기 기획에서 작성한 사용자 스토리를 기반으로 작성하는 모든 작업을 적정 단위에 맞게 구분한 것이다. 매주 백로그에서 일주일 동안 진행할 작업 양을 TODO로 가져와 작업을 진행하는 스프린트 방식으로 일과가 진행될 예정이다.

 

월요일에 기획을 바탕으로 첫 작업 백로그를 작성하기 시작했을 때, 사용자 스토리 하나를 메인 화면, 운동 모집글 작성하기, 클럽 리스트 보기처럼 한 화면 전체에서 나타나는 작업을 기준으로 작성했었다. 그리고 작업 목록을 프론트엔드 화면에서 나타나는 프로세스 위주로 작성했었다.

 

 

 

작성한 사용자 스토리와 그 하위 작업 목록에 대해 노아님께 피드백을 받았다.

 

우선 사용자 스토리는 한 화면에서 나타나는 발생할 수 있는 모든 이벤트에 대해 작성되어야 한다는 피드백이 있었다. 사용자 스토리는 사용자가 해당 기능을 사용했을 때 얻을 수 있는 가치 관점에서 작성하는 것인데, 한 화면에서 사용할 수 있는 기능들은 각각 서로 다른 가치를 제공하기 때문에 그에 대한 사용자 스토리 역시 각각에 대해 모두 작성되어야 했다.

 

그리고 작업 목록은 개발을 진행할 때 Catalog에서 직접 Todo와 Doing으로 옮긴 뒤 직접 task의 내용을 보면서 작업하기 때문에 구현 방식이 구체적으로 드러날 수 있어야 한다는 조언이 있었다.

 

내 작업 카탈로그는 화면 UI가 어떻게 출력되는지에 일단 초점을 맞추고 있었기 때문에 Catalog에서 알 수 있는 내용들은 대부분 UI에서 어떤 로직이 이루어지는지 위주로 작성되어 있었다. 따라서 Catalog에 백엔드에서 어떤 프로세스를 거쳐 데이터를 가져오고, 상태가 변경되면 어떻게 데이터를 생성하거나 수정하는 요청을 보낼 것인지 같은 내용들이 보완되어야 할 것이다.

 

마지막으로 특정 영역의 기술과 관련된 기능을 구현하는 부분에 대한 조언이 있었다. 작업 카탈로그에는 Spike Solution이라고 하는 방식의, 특정 기술을 학습해 애플리케이션과는 별도로 실험을 진행하면서 프로젝트에 적용 가능한지를 확인하는 과정이 들어갈 수 있다고 한다.

 

서드 파티 로그인, 지도 컴포넌트 그리기, 실시간 채팅 관련 기술 이해 등 앞으로 프로젝트 기간 동안 학습해야 할 내용들이 많다. Spike Solution을 카탈로그에 추가하는 데 부담갖지 않는 대신, 구현을 진행할 때에는 개발 시간을 희생해 학습에 사용하는 만큼 공신력 있는 문서와 기술 활용 사례들을 찾아보면서 구현에 필요한 내용들을 빈틈없이 습득해야 할 것이다.

 

 

기획과 관련된 작업을 계속 진행하다 보니 해야 하는 범위가 너무 넓은 것 같기도 하고 개발이 그리워지기도 하지만, 처음부터 모든 영역을 스스로 기획해보는 쉽게 얻을 수 없는 경험을 하는 것이라고 생각하도록 하자. 마음 흐트러지지 말고 목표한 작업을 수행하고, 작업을 통해 어떤 가치를 얻었는지 생각하는 데 집중하도록 하자.