봄싹이 언제 배포됐었더라... 기억이 가물가물 합니다. 8월 30일이었나. 이제 두 달을 향해가고 있군요. 다음 배포 일정은 임의로 11월 30일로 잡아두었습니다. 세 달은 지나치게 긴 것 같습니다. 이미 봄싹 개발자들끼리는 새로운 UI를 만끽하고 있는데 봄싹 회원들에게 멋진 UI를 빨리 보여드리지 못하는게 아쉽습니다. 배포 일정과 스코프를 잘못 계획했기 때문입니다. UI 개선만을 1차 유지보수 스코프로 정하고 배포했다면 이미 봄싹 회원들은 멋진 UI를 감상하고 계실텐데 말이죠...


먼저 배포 일정을 잡은 다음, 모든 개발자들의 측정이 완료된 스토리 카드 중에서 해당 일정 안에 개발을 할 수 있을 것으로 보이는 스토리 카드들을 고릅니다. 이 일은 전적으로 고객이 합니다. 고객 생각에 어떤 것이 가장 필요하고 비즈니스에 도움이 되는지 생각해서 고르면 되겠죠. 일단 최대한 빨리 중요한 것부터 서비스하고 싶다면 다소 어렵고 일정이 긴 스토리 하나만 고를 수 있겠고, 중요한 건 나중에 공개하고 일단은 기반이 되는 소소한 것들 부터 서비스하고 싶다면, 쉽고, 개발 일정이 짧게 걸릴 것으로 측정된 것들을 고르면 되겠습니다.

그런다음, 하나의 스토리를 구현하는데 필요한 세부 작업들을 개발자들과 논의합니다.

"발표 도메인 객체를 추가해야겠습니다."
"발표와 모임 객체에 연관 관계를 설정해야 겠어요."
"발표에 댓글/첨부자료/발표자 정보가 필요하겠군요."
"새로운 모임을 추가할 때 아예 발표 정보도 추가할 수 있도록 하죠."
"스프링 웹 플로우 학습이 필요할 것 같습니다."
"발표정보 추가할 때 발표자를 선택하는 부분에서는 Ajax를 도입할 수도 있겠네요."
...

이런식으로 하나의 스토리를 구현하는데 필요한 세부적인 작업목록들을 만들어 나갑니다. 이때, 개발자들이 의견을 많이 주어야 하며, 작업 목록 작성은 고객이 담당합니다.

고객이 작업 목록 하나를 작성할 때 마다, 스토리를 등록했을 때 처럼, 평가하는 과정을 거칩니다. 해당 작업은 덩어리가 너무 크다거나, 좀 더 명시적으로 수정해 달라거나 의견을 제시하면서 투표를 할 수 있죠. 혹은 고객이 명시한 작업을 코딩할 수 있겠다는 판단이 들면, 난이도, 걸리는 시간, 같이 작업하고 싶은 사람을 적어서 측정해줍니다.

고객은 가장 낮은 난이도를 제시한 개발자, 가장 낮은 시간을 제시한 개발자, 가장 많은 지명도를 가진 개발자 등의 정보 통계를 보고 해당 작업의 적입자를 찾아서 작업 담당자와 그 파트너를 지정해줍니다. 이렇게해서 하나의 작업에 두 명의 담당자를 지정해 주는겁니다.

그럼 이제 그 두명의 담당자는 서로 의견을 나눠가며 개발을 진행하면 되겠죠!

다음은 개발 과정에 대해 생각해보죠.