타임스프레드 팀의 협업 문화 중 하나인 주기적 출시에 대해 소개합니다.
1. 주기적 출시란?
- 규칙적으로 1주일에 한번씩 앱 업데이트 버전을 출시하며 일 하는 방식입니다.
- 이를 위해 1주일 마다 “백로그 이슈 생성, 추정과 우선순위 결정, 이슈 공유 회의, 출시 범위 회의, 일일 스크럼 회의, 개발 기간, 테스트 기간” 이라는 7가지 과정을 진행합니다. (자세한 사항은 아래 3. 주기적 출시의 과정 참고)
2. 주기적 출시의 목표와 장점
- 주기적 출시의 목표는 “팀 구성원 모두가 즐겁게일하면서도 성공적으로 프로젝트를 완수할 수 있는 환경을 만드는 것”입니다. 아래는 이 목표와 관련한 주기적 출시의 3가지 장점입니다.
- 1. 업무의 목표가 명확해지고 복잡성을 줄일 수 있다. : 1주라는 짧은 기간에 대해 목표 이슈를 정하게 되면 자연스럽게 사업적 목표에 꼭 필요한 요구사항만 추려서 진행하게 됩니다. 또한 상대적으로 적은 양의 이슈에 관심을 집중할 수 있어, 보다 정교하고 구체적인 설계가 가능합니다. 이에 따라 업무의 목표가 명확해지고 복잡성을 줄일 수 있습니다.
- 2. 업무에 몰입하는 환경을 만들 수 있다. : 1주일마다 무엇을 개발할 지 결정하기 때문에 사업 진행에 따라 발생하는 다양한 추가 요구사항을 프로젝트 중간에 난입시키는 것이 아니라 다음 출시로 미룸으로써 개발자를 멀티태스킹으로 부터 보호할 수 있습니다. 또한, 업무의 목표가 명확하고 복잡성이 낮기 때문에 보다 합리적인 일정 추정이 가능하며 이에 따라 개발자의 역량에 맞는 적당한 규모와 난이도의 업무를 배분할 수 있습니다. 1주라는 짧은 출시 기간이 만드는 적당한 긴박감이 너무 나태해지지도 너무 지치지도 않게 해줍니다.
- 3. 긍정적인 업무 분위기를 만들 수 있다. : 1주일마다 개발자의 작업물이 제품 책임자를 비롯한 팀내 요청자와 고객에게 전달되기 때문에 팀내에서 서로를 신뢰하며 협업할 수 있는 문화가 만들어집니다. 개발자는 즉각적인 고객 반응을 확인할 수 있어 뿌듯함을 느끼며 일할 수 있습니다.
3. 주기적 출시의 구성요소
- 위와 같은 목표를 위해 타임스프레드 팀은 1주 주기의 주기적 출시로 개발을 진행합니다. 물론 1주라는 짧은 기간은 너무 빠듯할 수 있고 불완전한 결과물을 낳을 수 도 있습니다. 이러한 문제를 방지하고 프로젝트를 성공적으로 완수하기 위해 타임스프레드 팀은 주기적 출시를 위한 7가지 구성요소를 활용하고 있습니다. 각 구성요소와 저희 팀에서 이를 어떤식으로 진행하고 있는지에 대해 간략히 소개합니다.
- 1. 백로그 이슈 등록 : 타임스프레드 팀 구성원은 파트와 직위에 관계없이 누구나 언제든지 개발하면 좋을 것 같다고 생각되는 아이디어를 Jira에 이슈로 등록할 수 있습니다. 점심을 먹다가 누군가가 이야기한 아이디어가 바로 다음주에 진행되기도 합니다. 이러한 방식을 통해 보다 꼼꼼하고 창의적인 제품을 만들어갈 수 있다고 믿습니다.
- 2. 추정과 우선순위 결정 : 자유롭게 등록된 백로그 이슈들을 제품 책임자가 검토하여 우선순위를 결정합니다. 이슈의 목적, 기대효과, 개발 공수 등을 고려하여 결정하기 때문에 아이디어를 제안한 이슈 생성자는 본인의 이슈가 채택되기 위해 책임감을 가지고 정성껏 작성해야 합니다. 제품 책임자의 결정을 돕기 위해 개발팀장은 각 이슈의 개발 공수를 대략적으로 추정합니다. (XS(1시간 이내), S(1시간~4시간), M(4시간~1일), L(1일~3일), XL(3일~1주), XXL(1주 이상)과 같은 T-shirt 추정법을 사용합니다.)
- 3. 이슈 공유 회의 : 다음주 출시 범위를 정하기에 앞서 30분 정도 팀 전체가 모여 우선순위가 높은 상위 이슈들에 대해 자유롭게 이야기하는 자리를 가집니다. 이를 통해 구성원은 팀 전체의 방향성과 다른 팀원들이 등록한 이슈들을 파악할 수 있습니다. 다양한 파트 구성원들의 아이디어가 모여 더 좋은 이슈가 만들어지기도 합니다.
- 4. 출시 범위 회의 : 이슈 공유 회의 직후 개발팀이 모여 다음주 출시 범위를 결정합니다. 앞선 과정을 통해 각 이슈들에 대해 충분히 이해했고 우선순위도 정해져 있기 때문에, 개발 공수를 고려하여 다음주까지 출시 가능한 범위를 결정할 수 있습니다. 개발팀원 각자의 역량과 관심사를 고려하여 적절한 난이도의 업무를 배분합니다.
- 5. 일일 스크럼 회의 : 출시 범위가 결정된 이후 개발 기간 동안 매일 점심시간 후에 15분 정도 각자의 진행상황을 공유하는 자리를 가집니다. 이 과정을 통해 사전에 예상하지 못했던 문제를 발견하고 어떤 팀원이 업무 과중 상태에 있는지 파악할 수 있습니다. 개발팀장은 각 팀원의 상황에 따라 업무를 재조정하거나 분담함으로써 기간 내에 업무를 완수할 수 있도록 조율합니다.
- 6. 개발 기간 : 개발에만 집중하는 기간입니다. 이 기간 동안은 회의를 최소화하여 구성원이 모두 자신의 업무에 온전히 집중할 수 있도록 합니다. Slack, Jira, Confluece, Git, Zeplin, IFTTT 등의 툴을 사용하여 개발 과정에서 필요한 커뮤니케이션이 최대한 효율적으로 진행될 수 있도록 합니다.
- 7. 테스트 기간 : 타임스프레드 팀은 테스트를 전담하는 팀원이 있으며, 주기적 출시 기간 동안 2.5일을 개발에 할당하고 2일을 테스트에 할당합니다. 테스트는 정말 중요합니다. 충분한 테스트를 통해 결함의 발생을 방지할 수 있습니다. 이는 이전에 출시한 사항들에 대한 재작업을 최소화시켜 지속적으로 계획된 업무에만 몰입할 수 있도록 도와줍니다.
4. 주기적 출시가 어려운 상황과 대처 방안
- 항상 주기적 출시가 가능한 것은 아닙니다. 타임스프레드 팀이 현재까지 경험한 주기적 출시가 어려웠던 상황은 크게 3가지였으며, 이에 대해 저희가 대처한 방안을 소개합니다.
- 1. 프로젝트의 규모가 큰 경우 : 큰 규모의 프로젝트의 경우 현실적으로 1주일만에 완료하기 어렵습니다. 이에 대한 대처 방안은 내부적으로만 주기적 출시를 하는 것입니다. 2개월 짜리 대규모 프로젝트의 경우라도 내부적으로는 이를 쪼개서 1주마다 베타 버전을 공유합니다. 예를 들어, 글을 쓰고 조회하는 기능을 구현한다고 할 때 외부적으로는 모든 기능이 구현되야 공개가 가능하지만 팀 내부적으로는 쓰기 기능만 구현하여 공유하고, 그 다음에 조회하는 기능을 구현하여 공유할 수 있습니다. 이러한 방식을 통해 주기적 출시의 장점을 가져가면서도 대규모 프로젝트를 진행할 수 있습니다.
- 2. 예상치 못한 긴급 이슈가 발생하는 경우 : 충분한 테스트 기간을 통해 상당수의 결함을 막을 수 있지만, 간혹 예상치 못했던 크리티컬 버그 또는 사업적으로 정말 중요한 긴급 이슈가 발생할 수 있습니다. 이 경우에 대해서는 예외적으로 해당 긴급 이슈를 최우선순위로 진행하여 완료되는 대로 hotfix 버전을 출시합니다. 이러한 경우 평소보다 출시 범위를 줄이고 테스트 기간을 늘리는 방식으로 대응합니다. 비록 이번주의 생산량이 줄어들 수 있지만 문제를 확실히 해결하고 넘어가야 또 다른 긴급 이슈의 발생을 방지할 수 있습니다.
- 3. 휴가 시즌 : 주기적 출시에 따라 구성원의 기여와 퍼포먼스가 명확히 공유되고 매주 휴가를 고려하여 출시 범의를 조정할 수 있기 때문에, 타임스프레드 팀은 언제든 자유롭게 연차를 사용할 수 있습니다. 다만 이 시기에는 팀 구성원의 휴가 일정에 따라 출시 일정을 조율할 필요가 있습니다. 정해진 규칙은 고정된 것이 아니라 상황에 따라 실용적으로 유연하게 조정될 수 있습니다.
끝으로, 아직도 협업 과정에서 개선해야 할 문제들이 많지만 타임스프레드 팀은 지속적인 작은 개선이 모여 탁월한 협업 문화를 만들어갈 수 있다고 믿습니다.
아래는 지금까지 협업 문화를 만들어가는 과정에서 영향을 받은 책들입니다.
- 팀/프로젝트 관리 관련 : <더 골 _ 엘리 골드렛>, <한계를 넘어서 _ 엘리 골드렛>, <하이 아웃풋 매니지먼트 _ 앤드루 S. 그로브>, <88연승의 비밀 _ 존 우든, 스티브 제이미슨>, <1만 시간의 재발견_안데르스 에릭슨, 로버트 풀>, <자기경영노트 _ 피터 드러커>, <기하급수의 시대가 온다 _ 살림 이스마일, 마이클 말론, 유리 반 헤이스트>, <파워풀 _ 패티 맥코드>
- 애자일 관련 : <칸반 : 지속적 개선을 추구하는 소프트웨어 개발 _ 데이비드 J. 앤더슨>, <피닉스 프로젝트_ 진 킴, 케빈 버, 조지 스패포드>, <에센셜 스크럼 _ 케네스 S. 루빈>, <스타트업처럼 생각하라 _ 제프 서덜랜드>, <애자일 & 스크럼 프로젝트 관리 _ 이재왕>, <조엘 온 소프트웨어 _ 조엘 스폴스키>, <린 애자일 기법을 활용한 테스트 주도 개발 _ 케네스 퍼그>
