프로젝트를 시작하는 방법 (ver.2017)

백그라운드

최근 팀이동을 하면서, 일하는 방법이 달라졌다. 

그래서 2017년도에는 어떤 방식으로 일했었는지 기억하기 위해, 글로 남기고자 한다. 

가상의 문제

어떤 방식으로 일하고, 생각했는지에 대해서 설명하기 위해 가상의 문제를 정하려고 한다.

사용자가 광고주 앱에서 LIKE를 누른 상품을 인스타그램에서 광고로 보여주는 다이나믹 광고 상품을 만들어야한다고 생각해보자. 

(지하철포스팅) 인스타그램은 어떻게 내가 찜한 상품을 광고로 보여주는 걸까? - 페이스북/인스타그램에 있는 Dynamic AD를 만들어야한다고 상상해보자 ㅎㅎ 

과제의 시작 (1) - 백로그 미팅잡기

"프로젝트를 시작하자!"라고 결심하면, 백로그를 만들고, 스토리 포인트를 산정하기 위한 미팅을 잡는다.

백로그 미팅의 목적은 아래와 같다.

- 프로젝트의 방향성, 스코프, 업무에 대한 이해도, 난이도 등을 팀 내에 싱크 맞추기 - 전반적인 설계 - 세부 기능 도출 - 세부 기능 구현을 위한 서브 태스크 도출  - 업무 우선순위 결정  - 과제 이터레이션 나누기 - 예상 소요일자 예측

과제의 시작 (2) - 백로그 미팅 전 준비물

미팅을 하기 전에, 아래의 생각들을 정리해와야한다.

- 사용자 스토리 정리하기  - 사용자 스토리를 기반으로 제약사항 / 세부 기능 도출하기  - 내가 생각하는 서브태스크 정리하기  - 고려할만한 요소 리스트업하기  - 과제와 관련된 기존 코드 분석하기

사용자 스토리 정리하기 

문제를 해결하기 위해, 필요한 스토리가 뭔지 정리해본다 

위에서 이야기한 페이스북 다이나믹 광고를 만들어야 한다면, 아래와 같은 스토리들이 나올거다. 

 ( 내가 쉽게 이해하기 위하여... 광고주 앱은 29cm 어플이라고 생각하고, 나는 페이스북 개발자라고 상상해보겠다.. ㅋㅋ )

유저 입장 - 유저가 29cm 어플에서 이어폰 상품을 보고 라이크 버튼을 누른다.  - 유저가 인스타그램을 할 때, 29cm에서 판매하는 이어폰을 광고로 본다.  광고주 입장  - 다이나믹 광고를 등록한다.   - 레포트 페이지에서 다이나믹 광고의 효율을 확인한다.

사용자 스토리를 기반으로 제약사항 / 세부 피쳐 발굴하기 

위에서 정리한 스토리를 가능하게 하려면, 필요한 기능이 뭔지 정리해야 한다. 

아래는 유저 입장의 사용자 스토리를 달성하기 위해 필요한 제약사항 / 세부 기능에 대한 예시이다.

유저 입장 - 사용자가 29cm 어플에서 이어폰 상품을 보고 라이크 버튼을 누른다.    => 사용자라 라이크 버튼을 눌렀다는 사실을 추적할 수 있어야한다.        => 라이크 이벤트 트래킹 기능 - 사용자가 인스타그램을 할 때, 29cm 어플 광고로 29cm에서 판매하는 이어폰을 보여준다.    => 29cm 어플에서 라이크 버튼을 누른적이 있는 유저에게만 29cm의 다이나믹 광고를 보여줘야한다.       => 유저가 29cm 어플에서 라이크를 누른 상품을 알 수 있어야한다.          => 이벤트 트래킹 로그 추출 기능        => 유저가 라이크를 누른 상품이 현재도 판매중인 광고인지 알 수 있어야한다.          => 광고주 상품 유효성 검증 기능

서브 태스크 도출하기 

위에서 정리한걸 기반으로 보자면 아래의 세부 피쳐들이 필요하게 된거다. 

- 라이크 이벤트 트래킹 기능 - 이벤트 트래킹 로그 추출 기능 - 광고주 상품 유효성 검증 기능

그러면 이 각각의 피쳐들을 구한하기 위한 세부 태스크들을 정리해야한다.

예시 ) 라이크 이벤트 트래킹 기능의 서브 태스크 => 광고주 이벤트 트래킹 수집 SDK => 광고주 이벤트 트래킹 수집 API => 광고주 이벤트 트래킹 로그 적재 / 가공 / 집계

과제의 시작 (3) - 백로그 미팅하기

1. 필요하다고 생각했던 기능과 서브태스크들을 서로 공유하고, 합의한다.

2. 서브태스크를 확정짓는다. 

   그러면서 어떻게 시스템을 설계할건지도 함께 논의한다. 

   ex. 이벤트 트래킹 서버를 별도로 둘건지, 별도로 두면서 필요한 서브태스크들은 뭔지 결정한다거나... 

3. 스토리 포인트를 산정한다.

   각 서브태스크에 점수를 매긴다. 이 점수는 과제의 난이도 / 예상 소요 시간등을 반영한 상대적인 점수이다. 

   참고 문서 : (slideshare)스토리포인트로 공수산정하기 운선순위정하기  / (branch) 애자일을 어떻게 실천하나요? - 스크럼편(2/2)

4. 가장 우선순위가 높고, 연관관계가 높은 서브태스크가 뭔지 결정한다. 그리고 과제의 이터레이션을 나눈다.

   ex. 이벤트 로그가 수집되어야, 다이나믹 광고를 적용할 수 있다. 

        그러니 이벤트 로그 기능이 우선순위가 더 높고, 먼저 배포되어야 한다. 

        그러면 이벤트 로그 수집 기능을 1차 이터레이션으로 보고, 광고 송출 기능을 2차 이터레이션으로 여길 수 있다. 

5. 예상 소요 일자를 계산한다.

    팀에서 하루동안 차감할 수 있는 평균 점수를 정한다. 그리고 서브태스크별 포인트 총합에서 평균 점수를 나누면 예상 소요 일자를 추정할 수 있다.

과제의 시작 (4) - 백로그 미팅이 끝난 후..

1. JIRA에 메인 태스크를 만든다. 그리고 서브 태스크들도 등록한다.

지라는 이슈 트래킹을 쉽게 하기 위해서 쓴다. 

브랜치명 / 커밋에 지라번호를 연동시키기기 위해서 사용하기도 한다. 

2. 과제 WIKI를 만든다. 

   과제 WIKI에는 JIRA 티켓 경로, 초기 목적, 요구사항 등을 정리해둔다.

   

요구사항 / 설계 문서등을 정리해두기 위해서 과제 위키를 만든다. 그리고 지라 매크로를 사용하면 위키와 지라가 연동된다. 

3. 구글 스프레드 시트에 서브태스크와 번다운 차트를 그린다. 

   

    참고 자료 : Sprint Burn Down Template (with instructions)

매일 퇴근 전에 차감된 포인트를 번다운 차트에 반영해놓는다. 그리고 출력해서 칸반 보드에 붙여 놓는다.

과제의 시각화 + 프로젝트의 프로그레스 체크 + 프로젝트의 상태 파악 등을 위해서 번다운차트를 그린다. 

4. 칸반 보드에 메인 태스크 / 서브 태스크 포스트잍을 붙인다. 

참고 이미지 

https://www.digite.com/blog/how-granular-should-my-personal-kanban-board-be/