[부스트캠프 웹・모바일 8기] 극찬 받은 개발 프로젝트 문서화

시작하기에 앞서 star 구걸을 위한 홍보부터...

https://github.com/boostcampwm2023/and04-catchy-tape

GitHub - boostcampwm2023/and04-catchy-tape: 야, 너도 가수 할 수 있어! 📼

 

프로젝트 노션 소개

사실 제목은 어그로이고, 극찬까지는 모르겠지만 칭찬을 받은 건 맞다. 프로젝트에 문서에 대해 운영진, 동료 캠퍼, 자문위원(내 기준 유명하신 분), 멘토님께 칭찬을 받았다. 특히 운영진께서 슬랙 채널에 우리 프로젝트 노션을 공유해 주시기도 했다. 우리 프로젝트 문서 페이지는 이렇게 생겼다. 캡처된 것 외에도 더 많은 내용이 있으니 궁금하다면 링크를 참고하길 바란다.

주요 문서는 루트 페이지 외에도 안드로이드, 서버 페이지 등이 있다. 안드로이드와 서버 페이지도 공유한 사진 외에 더 많은 문서가 정리되어 있다. 이 페이지에는 주로 기술적 고민을 작성했다.

아래로 더 많은 문서가 있음

아래로 더 많은 문서가 있음

문서들은 주기적으로 정리하면서 각각의 문서가 찾기 쉬운 위치에 놓였는지 확인했다. 그 과정에서 하나의 문서에 너무 많은 내용이 들어간다면 별도의 페이지로 추출하거나, 너무 적은 내용이 들어간다면 합치는 작업을 했다. (이건 마치 리팩토링 같잖아?) 팀 내에 꾸미기 달인이 있어서 위치만 대충 정리한 채 자고 일어나면 노션이 반짝반짝하게 바뀌어 있었다.

 

서비스 퀄리티 높이기

위에서 정리한 문서는 명확한 커뮤니케이션과, 이미 논의했던 내용을 빠르게 찾기 위한 작업이었다면, 아래는 서비스 퀄리티를 높이기 위해 작성한 테스트 시트다. 기획상에서 작성한 기능이 정상 동작하는지 확인하기 위한 시트와 발생했던 버그 목록을 분리하여 관리하고 있다.

이 테스트 목록은 주로 각 배포가 이루어지기 전 확인하기 위한 용도이다. 누적되는 목록으로 인해 비용이 점점 많이 들기 때문에 일부 항목은 테스트 코드로 대체할 수 있는지 확인하고 있다.

 

프로젝트 일정 관리

프로젝트 관리는 Jira도 고민했으나, GitHub Project 기능을 최대한 이용하기로 했다. 라벨과 마일스톤을 통해 분류했고, 예상 개발 시간과 실제 개발 시간을 관리하여 예상 시간 정확도를 개선하고 있다. 개발을 시작한 2주차 스프린트에서 55%의 정확도로 예상했고, 5주차 스프린트에서는 86%까지 개선했다. 일정 관리는 빨리 개발하는 것이 아닌, 주어진 시간 내에 개발 가능한 범위를 식별하고 완성도를 높이기 위한 목적을 우선시했다.

노션에 백로그를 작성하고 여기로 옮기는 것은 중복 작업이라 생각되어 작성하기 않았고, 일정 관리는 GitHub에서만 관리하도록 통일했다.

 

문서화 개선하기

프로세스를 개선하기 위해 문서화 뿐만 아니라 다양한 곳에서 공통적으로 적용할 수 있는 것이 있다. "목적을 생각하는 것"이다. 이번 문서화의 목적을 커뮤니케이션 비용을 줄이고 개발 스펙을 명확하게 하기 위함이었다. 그리고 각 페이지별로 세부적인 목적이 다를 수 있다.

과거 프로젝트의 문서화 과정에서 겪었던 문제가 있다. 회의록의 제목으로 날짜 정도만 작성했었다. 회의에서 논의했던 내용을 찾으려고 했는데, 어떤 회의록에 적혀있는지 찾는 데 오래 걸리거나, 다시 논의하는 상황이 생겼다. 그래서 그 이후로는 회의록에 반드시 회의 주제를 제목으로 입력한다. 즉, 비용을 줄이고자 하는 목적을 달성하지 못 했고, 이를 개선했다.

또는 다음 중 어떤 상황인지 생각해봄으로써 문서화를 개선할 수 있다.

• "커뮤니케이션 비용을 줄여야 해! (시간을 아껴야 해!) " → "문서화를 하자"
• "문서화는 일단 해야 해!" → "도움이 되는지는 모르겠지만 시간이 들여야 하는군!"