스타트업에서 애자일 도입하기

애자일을 도입하게된 배경

우선 외주를 기반으로 시작했기때문에 프로젝트 기간이 매우 짧고 촉박하여 주먹구구식과 폭포수가 난무하는 환경이었다. 
회사가 생긴지 1년도 안된 스타트업이었기 때문에 작업방식은 물론이고 팀간의 소통 또한 제대로 체계가 잡혀있지 않았다. 어쩌면 팀내에서도 공유가 안된 작업들이 굉장히 많았다.
1. 아트팀 작업물을 받아 작업해야하는데 담당자가 누군지, 어디까지 진행되었는지도 잘 모르는 상황
2. 이미 구현된 부분도 기획의 변동으로 재작업이 잦은 상황(변동이 잦으나 공유가 잘 안됨)

 

이러한 상황을 겪은뒤 팀내~팀간의 소통과 작업 현황이 실시간으로 공유되어야한다는 필요성이 느껴졌고, 잦은 기획의 변동이 있기 때문에 기능 구현을 작은 사이클로 가져가야한다는 생각을 하게 되었다.

 

따라서 개발팀 팀원들이 애자일에 대해 공부하고 전사도입을 목표로 타팀과의 소규모 협업에 첫 도입하게된다.

이때 개인적으로 애자일을 공부하기위해 '카이젠 저니'라는 책과 애자일작업방식의 성공사례인 토스팀의 포스트등을 많이 참고하였다.

 

애자일 방식 Scrum & 칸반보드

우리는 여러가지 애자일 프로세스중 '스크럼'방식과 '칸반보드'를 적절히 사용하여 도입하기로 결정하였다.
작고 빠른 개발주기를 가져가기 위해서 스크럼 방식이 적절하다고 생각했으며, 타팀과의 진행사항 공유가 문제였기 때문에 이를 해결하기 위해 작업사항을 한눈에 볼 수 있는 칸반보드를 도입하기로 하였다.

또한 전사도입을 목표로 했기때문에 학습비용이 발생하는 Jira 대신 이미 사용중이던 notion을 이용해 일정과 작업을 관리하였다.

 

scrum
sprint라는 반복적인 개발 주기를 지정하여 작업한다.
각 sprint마다 작업을 할당하고 해당 작업이 어느정도로 수행되었는지 어떤 성과가 있었는지를 주기적으로 점검한다.

칸반보드
칸반 보드는 작업을 시각화하고, 진행 중인 작업을 제한하며 효율성(또는 흐름)을 최대화하는 애자일 프로젝트 관리 도구이다.

 

우리가 도입한 애자일 작업 플로우

scrum 준비

1. Kickoff 회의

기획 혹은 아이디어 출시 확정시 kickoff 회의를 소집하여 스크럼을 생성하고 각 스크럼별 작업자를 할당한다
스크럼은 기능  혹은 컨텐츠 하나를 기준으로 하였다 ex) 커스터마이징, 포인트 시스템 등등
kickoff 회의에서 스크럼 팀장 주도하에 스크럼 주기와 세부 작업방식들을 의논, 결정하고 백로그를 생성한다.

이때 스크럼 구성요소는 다음과 같다

•  pm이 스크럼을 생성하고 팀장과 팀원들을 할당한다. 이후 스크럼이 진행되는 동안 pm은 스크럼팀장과 부서팀장간의 조율을 담당한다.
• 스크럼팀장은 스크럼의 전체적인 관리를 담당한다. 스크럼내의 산출물의 퀄리티 및 기간 조정, 스크럼 방식, 팀원 관리를 맡는다. 
• 스크럼팀장은 꼭 부서의 팀장일 필요는 없으며 산출물 및 작업 조절에 대한 권한을 부서팀장과 동일하게 가져간다

 

스크럼 진행

1. 주간 스프린트 회의
매주 월요일 새로운 스프린트를 시작하며 백로그에서 작업을 할당한다. 스프린트와 작업자가 할당된 백로그 이슈는 열림칸으로 이동한다
주간 스프린트 화이팅!으로 월요일을 파이팅넘치게 오픈한다ㅎㅎ

2.  칸반보드 관리

• 실시간으로 진행중인 작업들은 '진행중' 칸반보드로 이동한다. 작업 틈틈히 작업 현황을 잘 작성해 놓는다
• 진행중 타팀과의 협업 혹은 어떠한 상황으로 인해 진행을 보류해야하는 경우 '보류' 칸반보드로 이동시키고 댓글에 이유를 적어놓는다
  • 타팀의 선작업이 필요해 중단된 경우는 해당 작업자를 태그하고 이유를 적어놓아 트래킹 가능하도록한다
• 작업이 끝난것들은 '완료' 칸반보드로 이동시킨다

 

실제로 스크럼을 관리하기 위해 만들었던 템플릿이다

3. 일일 스크럼 미팅
매일 현재 본인의 작업상황과 이후 예정 작업을 짧게 공유

 

4. 스프린트 회고 회의
한개의 스프린트가 끝나는 주 마지막날에 KPT방식을 이용해 스프린트 회고회의를 한다
회의 내용은 한 주기동안 이루어진 스프린트에 대해 잘한것과 아쉬운것들을 작성하고 아쉬운것에대한 해결방안이나 좋았던것을 더욱 업그레이드 시킬 내용들을 논의 한다.
또, 스프린트중 완료된 작업들이 인수조건을 정말 완료했는지 모든 작업자가 평가하여 동의하에 '종료' 칸반보드로 옮긴다

KPT 회고란?

디자인소리 - 프로덕트 매니저의 애자일 회고 방법론 - KPT 실전편

스크럼 마무리

1. 스크럼 회고 회의
스프린트 회고회의와 마찬가지로 KPT방식을 이용해 회고회의를 진행한다
회의 내용은 스크럼 전반적인 문제점이나 장점등을 도출하여 다음 스크럼에서 참고 할 수 있도록 정리 후 공유하는것이다

 

애자일 실제 도입후 장단점

장점
1. 타팀과의 소통이 굉장히 원활하게 변화하였다
2. 연락없이도 작업자의 현재 진행 사항을 파악할수있기 때문에 커뮤니케이션 비용이 줄었다
3. 본인이 해야할 작업에 대해 우선순위와 전후관계가 명확해졌다
4. 개발주기가 짧아 변화에 유연하게 대처 가능했다

단점
1. 개발분야에서 유명한 방법론이다보니 비개발분야의 팀원들에게 이해시키기 쉽지않았다
2. 1번과 같은 이유로 애자일 도입을 위해 애자일 관련 설명자료를 만들고 교육하는것에 대해 초기비용이 굉장히 컸다
3. 작은 기능을 기준으로 스크럼이 만들어지다보니 굉장히 많은 스크럼이 존재하게 되었고 이에 따라 회의 횟수가 과도하게 증가하였다

 

느낀점

실제로 스크럼팀장을 맡아 우리 회사 첫 애자일 스크럼팀을 운영해본 결과 장점도 단점도 확실하다는 생각이 들었다. 단점은 주로 애자일 시스템자체를 이해하지 못하는 팀원들을 이해시켜야한다는 것인데 이를 위해 애자일 교육자료를 만들어서 교육하는 시간을 따로 가질정도였다 (도입자체를 터프랜딩해서 생기는 문제였을 수 있다) 

 

다만 초기 비용을 투자하고 이겨낸다면 스타트업에 적합한 작업방식임은 분명하다고 느꼈다. 기능 구현 자체를 작게 자주 가져가기때문에 변화하는 기획에 대응할때 보수 비용이 줄었고, 유연하게 돌발상황에 대처할 수 있었다. 타 작업자의 작업상황을 투명하고, 실시간으로 트래킹되었기 때문에 나의 작업 계획도 원활히 흘러갈 수 있었다.

 

결과적으로 마감 예정일보다 4일이나 빨리 프로젝트를 완성할 수 있었다. 작업을 하면서 타팀과의 협업이 주로 이루어졌음에도 원팀이라는 생각이 강하게 들었고, 내가 책임지는 나의 프로젝트라는 생각이 들어 회사 입사이래 가장 즐겁게 작업할 수 있던것 같다. 재밌어서 일을 찾아서 하다보니 빨리 끝난것 같기도..?