(Image from http://www.scrum-compact.com/)

들어가며..

안녕하세요, 류원경입니다! 오늘은 저희 ab180의 프로젝트 관리에 '스크럼 방법론'을 어떻게 적용하고 있는지에 대해 조금 이야기를 해볼까 합니다.

시작에 앞서 약간의 밑밥(?)을 깔아보자면, 저는 애자일이나 스크럼, 혹은 소프트웨어 공학, 프로젝트 매니징에 대한 전문가가 아니며, 저희 팀은 이제 막 스크럼을 정착시키기 위해 노력 중인 팀이라는 사실을 인지해주셨으면 좋겠습니다. 따라서 제가 기술하는 내용은 정론이 아닐 가능성이 높으며, 이에 이 글을 읽으시는 많은 분들께서 올바른 가르침을 주시면 정말 겸허하고 감사히 받아들일 준비가 되어있음을 미리 알려드립니다. 반면에 '도대체 스크럼이 무엇인가?' 라는 궁금증을 가지신 분들은 인터넷에 있는 좋은 아티클들을 찾아보시거나, '스크럼: 팀의 생산성을 극대화시키는 애자일 방법론'이라는 도서를 구해 읽어보시기를 적극 권장합니다. 자, 그럼 시작해보겠습니다!

왜 ab180은 스크럼을 도입하였는가?

스크럼 프로세스(Image from Wikipeida, GFDL) (Image from Wikipedia, GFDL)

저희는 현재 한 명의 기획 및 비즈니스 담당자, 네 명의 개발자, 한 명의 디자이너로 구성된 소규모 팀입니다. 더불어 제작하고자 하는 제품(airbridge)은 서비스 기획, 비즈니스 개발, 소프트웨어 개발이 동시에 점진적으로 이루어지는 중입니다. 따라서 시시각각 달라지는 개발 스코프와 비즈니스 상황에 팀원들이 기민하게 대응해야하는 바, 요구 사항 분석부터 차근차근 이루어지는 전통적인 폭포수 모델, 혹은 그로부터 발전된 많은 개발 모델보다 스크럼을 사용하는 것이 훨씬 효율적이라고 생각하였기에 이를 도입한 것입니다. 저희는 정말 럭비의 스크럼처럼 모든 팀원들이 뭉쳐 '으쌰으쌰'하며 일을 닥치는대로 해치워 나가고 있기도 하고 말이지요.

실질적으로 어떻게 실천하고 있나?

  1. 업무 분장
    실제 만들어질 제품에 대한 모든 권한을 가지고 있는 '제품 책임자(Product Owner, PO)'는 기획 및 비즈니스 담당자이자 대표인 남성필 군이 담당을 하게 되었습니다. 물론 모든 팀원이 그러하겠지만, 대표직을 맡고있는 남성필 군이 저희 서비스나 팀에 대한 비전, 혹은 방향성을 개중에서도 가장 잘 알고 있고, 또 앞에서 이끌어 나가는 역할을 맡고 있기 때문입니다. 더불어 실제 스크럼 프로세스를 관장하고, 프로세스 중에 있는 팀원들의 애로사항을 처리하며, 팀에 프로세스가 잘 안착할 수 있도록 노력해야하는 '스크럼 마스터(Scrum Master)'는 제가 맡기로 하였습니다. (그래서 이 글을 쓰고 있죠.. 허허..) 스크럼의 실제 주체가 되는 개발팀은 사실상 프로덕트 오너와 스크럼 마스터를 포함한 총 6인입니다.
  2. 스프린트 주기
    저희의 스크럼 스프린트는 '1주'로 책정하였습니다. 아직 스크럼 프로세스가 팀 내부에 정착하는 과정 중이기 때문에, 연습을 위해 일단 가능하다면 가장 짧은 주기로 스프린트를 시행하는 것이 좋다고 생각했기 때문입니다. 차후에는 이를 2주로 늘려나갈 계획입니다. 사실 이 부분에서 스토리 포인트 산정 회의나, 회고 회의에 들어가는 시간 비용이 더 커지는 비효율이 발생할 수 있지도 않을까 걱정이 되긴 하지만, 최대한 '타임박스'를 지키며 회의를 할 수 있도록 할 예정입니다.
  3. 제품 백로그 추가
    제품 백로그는 '프로덕트 오너'가 정의하고 그 우선순위를 정하는 것이 원칙이나, 저희는 소규모 팀이고 모두가 제품 기획 단계에 대해 발언권을 가지고 있기 때문에, 다같이 회의를 통해 백로그 티켓들을 정의하고 그 우선순위를 책정하고 있습니다. 더불어 각 개인이 회의를 통하지 않고서도 '제안(Suggestion)' 수준으로 백로그 티켓을 생성할 수 있도록 하고 있습니다.
  4. 스프린트 준비 & 스토리 포인트 산정(Estimation) 회의
    저희는 하루를 3점으로 하는 피보나치 수열을 스토리 포인트 산정에 사용하고 있습니다. 스토리 포인트 산정 회의에는 모든 팀원들이 참석하여 '플래닝 포커 게임'을 통해 이루어지며, (포커 따위 없이..) '하나~ 둘~ 셋~!' 하면 동시에 손가락으로 점수를 표시하는 방법을 사용하고 있습니다. 아직까지는 스크럼이 성숙하지 않아서 예상 산정치가 정확하지 않은 경우가 다수 존재하지만, 점차 나아지리라 생각합니다.
  5. 데일리 스탠드업(Daily Stand-up) 미팅
    매일 아침 11시 30분에 사무실에서 데일리 스탠드업 미팅을 5분에서 10분 가량 진행합니다. 각 팀원이 돌아가며 '한 일', '할 일', '애로사항'을 이야기하면, 스크럼 마스터가 이를 취합하여 기록함과 동시에 각 개인의 진행 상황이나 애로사항을 정리해서 다시 발표합니다. 이를 통해 각 팀원들은 서로가 어떠한 작업을 진행하고 있는지, 어떠한 애로사항을 가지고 있는지를 거시적으로 파악할 수 있게 됩니다.
  6. 스프린트 리뷰(Sprint Review) 및 스프린트 회고(Sprint Retrospective) 회의
    스프린트가 종료된 이후에는 스프린트 리뷰 및 회고 회의를 진행합니다. 스프린트 리뷰 회의에서는 실제 이번 스프린트에서 개발된 증분 내용이 어떤 것인지, 계획대로 잘 개발 되었는지를 확인합니다. 그 이후 스프린트 회고 회의에서는 각 팀원이 이번 스프린트를 진행하며 좋았던 점, 그리고 고쳐야 할 점을 주어진 시간 안에 포스트잇에 작성하고 돌아가며 발표합니다. 좋았던 점을 발표할 때에는 다같이 박수로 환영하며 분위기를 고취(?)시킵니다. 작성한 포스트잇은 비슷한 분류끼리 묶어 붙여두고 스크럼 마스터가 최종적으로 이번 스프린트에서 좋았던 점, 고쳐야 할 점을 모아 발표하고 기록하면서 고쳐야 할 점에 대한 해결책을 제시하며 회고 회의를 마무리합니다.
  7. 워크플로우
    우리팀의 스크럼 워크플로우 저희가 스크럼에서 사용하는 워크플로우(Workflow)는 다음과 같습니다.
    1. 제안(Suggestion): 말 그대로 제안 단계입니다. 프로덕트 오너 혹은 각 개발 팀원들이 새로 추가해야 한다고 생각되는 Feature의 티켓들은 기본적으로 이 단계에 머물러 있게됩니다. 이 부분은 스프린트 외부에 있는 단계입니다.
    2. 산정 대상(Pick for Estimation): 제안 단계에 있던 티켓 중, 실제 개발을 요한다고 생각되는 경우에 이 '산정 대상' 상태로 이동하게 됩니다. 이 상태에 있는 티켓들은 매주 금요일에 있는 '스토리 포인트 산정' 회의에서 모든 개발팀의 의견을 모아 스토리 포인트를 산정하게 됩니다.
    3. 개발 준비 완료(Ready for Development): 스토리 포인트 산정이 완료되어 개발 준비가 완료된 상태입니다.
    4. 개발 중(In Development): '개발 준비 완료' 상태에 있던 티켓들은, 각 팀원들이 스스로에게 티켓을 할당(Assign)함과 동시에 실제 '개발 중' 상태로 이동하게 됩니다.
    5. 코드 리뷰 필요(Required Code Review): 개발이 완료된 이후, 각 티켓마다 정해진 'Approver'가 Open Pull-Request 상태의 코드를 리뷰합니다. 이 'Approver'는 코드에 문제가 없다는 것을 보장하고 티켓을 다음 단계로 이동시킵니다.
    6. QA 필요(Required QA): 실제 티켓에 기술된 개발 내용이 제대로 만들어졌는지, 사용상에 문제는 없는지에 대한 테스트를 처음 티켓을 제안한 'Reporter'가 진행합니다. 이 부분에는 자동화된 테스트 기법이 사용될 수 있습니다. 실제 Feature도 정상적으로 구현되었고, 테스트상에서도 문제가 없다면 티켓을 다음 상태로 이동 시키고 코드를 메인 개발 브랜치(develop)에 머지합니다.
    7. 완료, 버림(Done, Stash): 이렇게 개발, 코드 리뷰, 테스트가 모두 완료된 티켓은 '완료' 상태에 해당 스프린트가 종료될 때까지 머무르게 됩니다. 개발 도중, 시장 변화나 급작스러운 제품 Feature 변경으로 인해 특정 티켓이 더 이상 의미가 없어진 경우에는 'Stash' 상태로 이전시켜 해당 이슈를 더 이상 진행하지 않도록 합니다.
  8. 사용 툴
    1. JIRA (이슈 관리): 이러한 스크럼의 모든 과정에 대한 관리, 이슈 트래킹은 모두 JIRA를 통해서 진행하고 있습니다. 처음에는 툴 자체가 매우 방대해서 메뉴 하나 찾는데도 허둥지둥이었지만, 지금은 Dashboard도 만들어보고 이런 저런 커스텀도 해보면서 차차 익혀나가고 있는 중 입니다. 클라우드형 서비스를 이용하다보니 속도가 조금 느린게 아쉽습니다ㅠ.ㅠ 번다운 차트도 지속적으로 주시(?)하려고 노력 중 입니다.
    2. Bitbucket (소스 관리): 코드 수준에서도 이슈에 대한 트래킹을 잘 할 수 있도록 '하나의 티켓 = 하나의 브랜치'라는 기본 정책을 유지하기 위해 노력하고 있습니다. JIRA와 Bitbucket을 연동하여 손쉽게 티켓에 대한 브랜치를 생성할 수 있도록 합니다.
    3. Confluence (문서 관리): 개발에 관련된 모든 문서는 Confluenece에 보관합니다. 이 역시 JIRA와 연동되어 있기 때문에 문서 내부에서 특정 이슈 티켓에 대한 언급 등이 아주 손쉽게 이루어집니다. (아틀라시안 만세!) 이렇게 총 세 가지의 툴을 이용해 '이슈', '코드', '문서'가 삼위일체(?)를 이루어 추적될 수 있도록 하고 있습니다.

고민: 정말 효율적인걸까? 우리는 잘 하고 있는걸까?

는 다음 2탄에서 계속하지요..^0^

쉬운 앱마케팅을 위한 무료 그로스해킹 툴, 에어브릿지

에어브릿지는 앱마케팅 캠페인의 실시간 성과 측정부터 유입경로까지 분석가능한 원스톱 앱마케팅 솔루션입니다. 모바일 앱마케팅 분석, 지금 바로 무료로 시작하세요!