봄싹 프로젝트 개발이 지나치게 자유롭다 보니 프로젝트 스코프도 애매해지기 시작했고, 현재 누가 어디를 얼만큼 개발했는지 파악하기가 힘들어졌습니다. 나름대로, 이슈트래커, CI 환경, VCS까지 갖출 건 다 갖추고 진행하고 있지만 그래도 뭔가 좀 부족한 감이 없지 않습니다. 그래서 XP 책에서 읽은 내용을 토대로 봄싹 나름대로의 개발 프로세스를 정리해볼까 합니다.

물론, XP installed 책에 나와있는 그대로 할 필요도 없고, 그 책도 일종의 권고사항이지 반드시 따라야 하는 건 아니것 같기 때문에 제 맘대로 봄싹에 필요하면서도 재미있게 개발을 진행할 수 있는 방법을 궁리해봤습니다. xp 책은 그런면에서 좋은 아이디어를 떠올리는데 아주 좋더군요!


먼저, 현재 이슈트래커나, 구글 그룹에 올리고 있는 할 일을 스토리로 정리하는 방법을 생각해봤습니다. 누군가가 고객의 입장에서 스토리를 하나 만듭니다.

"모임에서 있었던 발표 정보를 별도로 관리하면 좋겠다."

이런 카드를 만드는 순간, 그 사람은 고객이 됩니다. 그리고 해당 스토리를 수정/삭제/세부 스토리 등록 등을 하는 권한이 생기죠. 그리고 이 카드가 생기는 순간 모든 개발자에게 메시지가 갑니다. 평가해 달라고..

그럼 일부의 개발자들은 해당 스토리가 너무 애매하다고 더 구체적으로 설명해 달라고 "고치자"를 클릭하며 어떻게 고쳐달라며 '의견'을 제시합니다.

또 다른 일부의 개발자들은 해당 스토리가 너무 방대하다면 좀 더 세부적으로 쪼개 달라며 "나누자"를 클릭하고 어떻게 나누면 좋겠는지 '의견'을 제시합니다.

또 다른 일부의 개발자들은 현재 스토리를 개발할 수 있다는 판단하게 '얼마나 걸릴지', '난이도가 어느정도인지', '누구와 함께하고 싶은지' "측정"을 합니다.

모든 개발자들의 측정이 이루어지기 전까지 사용자는 개발자들의 의견을 반영하여 계속해서 스토리를 수정하거나, 스토리의 하위 스토리를 등록하게 되고, 개발자는 스토리가 변경되거나, 새로운 스터디가 추가될 때마다 계속해서 측정 또는 투표를 할 수 있습니다.

이런식으로 스토리를 정제해 나가는 겁니다. 재밌지 않을까요? JIRA를 어떻게 잘 설정해서 쓰면 이렇게 할 수 있을것도 같긴 한데.. 좀.. 복잡해 보이는 UI가 위 시나리오에 적당해 보이지는 않습니다. 적당한 툴이 있으면 좋겠는데 없으면 봄싹 이슈트래커도 나중에 만들어야겠네요.

다음은 이렇게 정리된 스토리들을 가지고 배포 계획을 세우는 방법에 대해 생각해보겠습니다.