이전 회사를 들어가서 처음으로 당황했던 부분이 있다. 그것은 바로 스프린트 플래닝 미팅이었다.
개발팀에서는 스프린트라고 하는 단위로 기간을 쪼개 (보통 2주 정도다) 그 기간동안 할 일감을 매 스프린트가 시작할때 정하곤 하는데 그걸 정하는 미팅이 바로 스프린트 플래닝이다.
보통 애자일 기반 팀이면 으레 하는것이기 때문에 특별할건 없다. 내가 놀랐던건 미팅의 길이였다.
처음 스프린트 플래닝을 했을때 회의를 족히 4시간은 한 것 같다.
순서는 이러했다. 일단 지난 스프린트에서 하기로 했던 일감 목록들을 쭉 늘어놓는다. 그 중 완료된 일감들은 제외하고 아직 끝나지 않은 일감들을 하나하나씩 확인해보며 그 일을 맡은 팀원과 그 일에 대한 현 상황을 체크한다. 그 일을 진행할 수 없게 가로막는 일이 있는지, 있으면 어떻게 해결해야하는지, 다른 팀원이 도울 일은 없는지, 앞으로 어떤 일들을 추가로 진행해야 하는지 꼼꼼하게 체크한다. 그런 다음엔 그 일감을 끝내려면 시간이 얼마정도가 더 필요할지 예상 시간을 추정해 티켓에 적어넣는다.
모든 팀원들의 모든 태스크를 다함께 체크하다보니 이것만 족히 한시간이 넘는다. 그당시 열명이 훌쩍 넘는 개발자들이 거의 하나의 팀으로 이루어져 있었고, 거기에 QA(테스터)들과 PM들까지 다같이 참여하는 회의다보니 사람들이 한두마디씩만 더해도 시간이 금방 흘러갔다.
이렇게 모든 태스크들을 확인하고 난 후에는 스프린트 레트로를 진행했다. 레트로 시간에는 지난 스프린트를 되돌아보며 잘했던 점은 뭐가 있는지, 개선해야 할 점은 무엇인지 등을 일정 시간동안 팀원들이 게시판에 익명으로 적어낸다. 약 10~15분간 주어진 시간이 끝나면, 게시판에 올라온 의견들을 하나하나 체크한다. 적혀진 의견이 잘 이해가 안가는 부분이 있다면 추가로 의견을 더 덧붙이기도 하고, 개선점을 통해 액션 아이템을 뽑아내기도 한다. 이것도 하다보면 한시간이 또 훌쩍 간다.
잠시 쉬었다가 이제 드디어 새로운 스프린트 플래닝을 한다. PM들이 먼저 이번 스프린트에 꼭 해야만 하는 일들, 우선순위가 높은 일들을 팀원들에게 알리고 관련 티켓들을 우선순위별로 정렬한다. 그런 뒤 본격적으로 일감을 팀원들에게 나누기 시작한다. 일감을 나누면서도 해당 티켓의 목적이 뭔지, 티켓을 완료하려면 어떤 일들을 해야하는지, 질문 및 답변들을 통해 티켓에 관련 내용들을 좀 더 자세히 추가해나간다. 그런 후 이 일을 맡을 사람을 정하고, 이 일의 중요성, 난이도에 따라 해당 티켓에 점수를 매긴다.
그게 끝이 아니다. 이번에는 해당 티켓을 좀 더 자잘한 태스크들로 나누어 그걸 서브 티켓들로 만든다. 각 서브 티켓별로 그 일이 얼마나 걸릴지 예상 시간을 산정하고 티켓에 적어놓는다.
이걸 모든 티켓들, 모든 팀원들을 대상으로 반복한다. 두세시간은 그냥 눈깜짝할 사이에 흘러간다.
이렇게 오래 걸리다보니 스프린트 플래닝을 한번 할때마다 진이 빠졌다. 그날 하루는 플래닝 외에는 다른 일을 할 시간도, 여력도 거의 없었다. 이걸 2주에 한번씩 반복하려니 너무 시간 낭비가 심한 느낌이었다. 스프린트 레트로에 늘 올라오는 개선이 필요한 사항 중 하나는 언제나 '스프린트 플래닝 미팅 시간'이었다.
다행히 새로운 해를 맞이해서 개발팀이 총 세개의 작은 팀으로 쪼개지게 되었다. 각 팀마다 시니어 개발자 1~2명, 미드/주니어/인턴 개발자 3~4명에 담당 PM 1명, QA 1~2명으로 구성되어 훨씬 심플해졌다. 스프린트 플래닝 및 각종 팀 회의도 각 서브 개발팀끼리 진행하기로 했다.
그렇게 팀이 나뉘어지고 첫 스프린트 플래닝 시간이 돌아왔다. 우리팀 시니어는 쿨한 성격이었다. 지난 스프린트 태스크도 간략한 설명만 듣고 적당히 넘어갔고, 새로운 티켓들도 내용은 꼼꼼히 체크했지만, 서브 태스크를 만드는것은 각 팀원들 역량에 맡기기로 했다. 그 결과 처음으로 플래닝 미팅이 단 두시간만에 끝났다. 정말이지 숨통이 트이는 기분이었다. 역시 팀이 작아야 제대로 된 애자일이 가능하구나를 새삼 느꼈다.
아마존에는 2 pizza 팀이라는 원칙이 있다. 한팀은 피자 두판으로 팀원들이 배불리 먹을 수 있을 정도의 인원만 둔다는 원칙이다. 피자 한판에 8조각 정도고, 한사람당 보통 2조각씩 먹는다고 치면, 한팀에 8명 정도가 적당하다는 뜻이다.
이 원칙을 들었을때 정말 가슴 깊이 공감했다. 사람이 많아질수록 비효율적일 때가 많다. 기본적으로 팀이 작아야 훨씬 빠른 대응도 가능하고 의견도 더 활발히 교환되는것 같다.
사실 지금 내가 있는 팀도 꽤 큰 팀이라 2 pizza 규모 이상이긴 하다. 그렇지만 스프린트 플래닝은 대부분 한시간 반 안에 끝난다. 티켓에 대한 부분은 티켓 담당자에게 전격 위임하기 때문이다. 그 티켓의 내용이 뭔지, 어떤 목적인지, 무슨 일이 필요한지 등은 각 티켓 담당자가 알아서 파악해야 한다.
지금 팀의 문화와 저번 회사 개발팀의 문화 둘 다 장단점이 있는것 같다. 저번 팀은 다같이 일감을 분석하고 필요한 일들을 파악했기 때문에 시간은 좀 더 걸리지만 모두가 그 프로젝트에 대해 비슷한 수준의 이해도를 갖출 수 있었고, 공동의 목표를 향해 나아간다는 느낌이 들었다. 어떤 일을 해야하는지 확인해놨기 때문에 스프린트가 시작되면 우왕좌왕 안하고 바로 일을 시작할 수 있었고, 누구에게 도움을 받을지도 분명히 알 수 있어서 막히면 바로 해당 사람에게 도움을 구할 수도 있었다. 그래서 주니어인 나에게는 참 좋았던 부분이 많다.
반면 지금 팀은 각개격파 느낌이다. 티켓에는 참으로 불친절하고 모호한 설명만 한두줄 적혀있고 끝이라, 처음 티켓을 받으면 무슨 일을 어떻게 해야할지 감이 잡히지 않는 경우가 많다. 그래서 티켓을 만든 사람에게 연락하고, 관련 일을 파악하는것만도 시간이 꽤 걸린다. 각 팀원들이 정확히 무슨 일을 하는지도 알기 힘들고, 그러다보니 공동의 목표를 향해 나아간다는 느낌이 약한 것도 사실이다.
뭐가 더 좋다 말하긴 힘들지만 이렇게 다른 팀 문화를 겪어보니 재밌긴하다. 개인적으로는 티켓만 보면 어떤 일을 해야할지 대충 알 수 있도록 티켓 내용은 조금 더 성실하게 쓰되, 그 외에는 담당자가 알아서 하도록 하는게 괜찮은 것 같다. 이런 얘기가 팀에서도 꽤 나오고 있는 모양인지 매니저도 개선 필요 사항으로 언급하기도 했으니 앞으로 좀 더 발전하지 않을까 싶다.
'개발에 대한 단상' 카테고리의 다른 글
아마존에 도전하다 (1) (11) | 2022.02.28 |
---|---|
이직을 결심한 이유 (2) | 2022.02.17 |
데일리 데모 문화 (2) | 2022.02.09 |
너무 하기 싫은 개발 공부, 그래도 해내고 있는 나만의 노하우 (2) | 2022.02.04 |
컨설팅 회사의 소소한 단점 (1) | 2022.01.29 |
댓글