이 글은 캡틴 포비의 <이슈 관리, 일정 추정> 강의 내용을 정리하고, 적용해본 경험을 담은 글입니다.
💬 여기서부터는 포비(박재성 개발자님)의 목소리로 읽어주세요 :)
우아한테크코스에서는 본과정 시작 전 입문 테스트 단계인 프리코스 때부터도 To Do List(a.k.a 구현기능목록)를 만드는 연습을 하게 된다. To Do List를 만드는 작업은 바로 이슈를 만드는 작업이라고도 할 수 있다.
이렇게 기능 목록을 작은 단위로 쪼개고 그들의 우선순위를 정하는 것은 상당히 중요한 '설계' 과정이다. 이슈를 어떻게 관리하는지는 굉장히 핵심적인 부분이고, 이슈관리를 잘하는 것은 후속작업을 위해서도 중요하다. 그러나 개발자들은 이슈를 제대로 관리하지 않고 바로 개발에 들어가는 경향이 있다.
프로젝트 시작에 앞서 어떻게 이슈를 관리하고 일하는 것이 효과적일지 고민해보자.
👨🏻🏫 이슈 생성, 우선순위 부여
프로젝트에서 작업할 이슈를 어떻게 관리하는 것이 좋을까?
이슈관리를 할 때 가장 중요한 것은 이 이슈들을 충분히 작은 단위로 만들어 독립된 단위로 만드는 것이다. 그렇게 해야 누군가에게 이슈를 배정해서 그걸로 끝낼 수 있다. 예를 들어, '스터디를 하겠다'는 너무 단위가 크다. 더 디테일하게 하나하나 충분히 작은 단위로 쪼개야 한다.
우선순위도 중요하다. 이슈에 대한 우선순위 관리가 잘 되어있어야지만 개인별로 작업 배분이 가능하다. 너무 빠르게 개발로 들어가려고 하지 마시고, 이슈들을 설계하는데 많은 시간을 투자했으면 좋겠다.
👨🏻🏫 업무 분담
그렇다면 업무 배분은 어떻게 관리하는 것이 좋을까?
똑같은 일을 하더라도 내가 주도적으로 하면 즐겁게 하지만 남이 시키면 하기 싫어진다.
push 방식
보통은 팀장이 주도하면서 구성원들의 업무 현황을 본 다음에 일괄적으로 업무를 배분한다. 사실 업무를 배분하는 입장에서도 되게 재미없고 스트레스를 받는다. 왜냐하면 어쩔 수 없이 되게 재미없는 업무가 있는데 이 지루하고 반복적인 업무를 누군가에게는 줘야 하는 부담이 있기 때문이다.
pull 방식
한편, 수평적인 관계에서도 업무 배분이 어려울 수 있다. 그럴 때는 담당자가 명확한 이슈를 처음에 배분해놓고, 명확하지 않으면 업무를 배정하지 않고 우선순위만 정해놓는 방법이 있다. 구성원 중 한 명이 맡고 있던 업무가 끝났으면, 남은 이슈 중 우선순위가 가장 높은 업무를 자기에게 무조건 당겨온다.
새로운 기술로 치고나가는 팀원들이 재미있는 업무를 다 해결하게 되는 경향이 있다. 실은 배려심이 강하고 허드렛일이고 다른 사람이 챙기지 않기 때문에 챙기는 사람이야말로 팀워크를 형성하는데 중요한 역할을 한다. 본인이 팀에서 어떻게 일하는지 보고, 내가 팀에서 너무 재밌는 일만 하려는 성향이 있는 게 아닌가 그러면 경계심을 가지고 본인이 일하는 방식을 돌아보자. 허드렛일도 나서서 하는 모습을 보이면 좋겠다. 그런 허드렛일을 나눠야지만 같이 성장하고 팀워크도 생긴다.
| Push 방식 | Pull 방식 |
| 리더가 프로젝트 전체 조율 및 업무 배정 | 작업자가 명확한 경우를 제외하고는 우선순위에 따라 스스로가 본인의 업무를 할당 |
| 대부분의 수직 구조 회사의 업무 배정 방식 | 수평구조에 적합한 방식 |
👨🏻🏫 일정 추정
각 이슈별 일정 추정은 어떻게 하는 것이 좋을까?
경험 많은 시니어에게 일방적으로 맡기는 게 좋을까? 아니면 경험이 없는 사람이 하는게 좋을까?
일정 추정이 힘든 이유는 해당 도메인에 대한 지식이 낮기 때문이다. 힘든 작업. 도메인 지식이 이미 있는 소프트웨어인 경우에는 그나마 일정 추정을 잘하지만, 도메인 지식이 없는 경우 시니어 개발자는 상당히 공격적으로 일정을 추정하는 경향이 있다. 그래서 오히려 약간 보수적으로 잡는 주니어가 추정을 잘하는 경우도 있다.
일정 추정 에피소드 1 - 팀장과 팀원
팀원: (마음 속으로 5일 정도 걸릴 것으로 예상함)
팀장: 이 기능 하렴 되지 않아? 내가 예전에는 말이야...
팀원: 하루는 너무 짧고... 최소 3일은 필요합니다.
팀장: 3일도 너무 긴데... 2일로 잡으면 안 될까?
팀원: (ㅠ.ㅠ) 예. (오늘부터 야근해야겠군.)
위와 같은 대화를 통해서는 정해진 일정은 사실은 확신할 수 없는 일정이다. 팀원 입장에서는 팀장이 더 일정을 더 잘 추정할 것 같다는 생각도 들고, 너무 보수적으로 잡으면 실력이 없어 보일까 봐 걱정도 되고, 또 팀장에게 의견을 크게 낼 수 없기도 결국 이런 리스크를 만들게 된다. (구구: 3일 만에 만들면 3일이면 만드는구나라고 생각하게 되는 문제도 있습니다.)
일정 추정 에피소드 2 - 개발자와 기획자
개발자: 5일 정도 예상해요.
기획자: 그렇게 많이요? 버튼 하나 추가하는데... (의심의 눈초리...)
개발자: DB가 어떻고, 테스트가 어떻고, 리팩토링이 어쩌네... (이런 것도 모르냐? 기술 공부 좀 해라)
기획자: (멍한 표정. 의심이 가지만) 그렇게 하시죠...
위와 같은 대화를 통해서는 서로에 대한 신뢰만 상실하게 될 뿐이다.
일정 추정을 잘~ 하기 위해서 '플래닝 포커'를 통해 스토리 포인트를 산정하는 방법을 시도해볼 수 있다. (플래닝 포커 앱도 있음) 플래닝 포커는 대략적인 기획을 완료해 기능목록과 우선순위가 결정된 후에 진행한다. 스프린트를 시작하는 시점에 진행한다. 예를 들어 마일스톤이 2주 단위이면, 2주 중 가장 첫째 날에 플래닝 포커를 진행하면 된다. 해당 마일스톤에서 진행 가능한 기능 목록을 결정하고 스토리 포인트 산정을 진행한다.
상대적인 스토리포인트스토리 포인트 1점을 기준으로 다른 이슈의 스토리 포인트를 정한다. 참고로 스토리 포인트는 5 이하로 정해지는 것이 좋다. 5보다 크다면 이슈가 너무 크게 정해진 것이고 더 잘게 쪼갤 필요가 있다.
💬 여기서부터는 제 목소리로 읽어주세요 :)
🚀 적용해보기
'여기서만나' 팀 프로젝트가 본격적으로 시작되면서, 강의 중 요약해주신 다음의 순서를 따라 본격적으로 이슈 관리에 도전해보았다.
1. 작업 목록 이슈를 정리한다.
2. 작업 목록의 우선순위를 결정한다.
3. 각 작업의 스토리 포인트를 산정한다.
4. 모든 작업을 이슈관리시스템에 등록한다. (e.g 깃허브)
1. 이슈 정리
우선은 우선순위나 일정에 대한 고려 없이 일단 쭈욱- 적어보는 것으로 시작했다. 아주 조금이라도 구체화된 아이디어를 모두 나열하니 상당히 양이 많았다.
2. 우선순위 부여
그러고 나서 각 기능의 우선순위를 다음 3가지로 구분했다.
1번. 우리 서비스에 필수적인 기능
2번. 선택적으로 구현해도 되는데, 있으면 좀 많이 좋은 기능
3번. 선택적으로 구현해도 되는데, 역시 안 해도 될 것 같은 기능
한편, 6주라는 고정된 시간 안에 완성을 해야 했기 때문에 우선순위를 결정하기 위해서는 프로덕트 그 자체에 대한 고민뿐만 아니라 우리들에게 주어진 시간 리소스도 고려해야 했다.
그래서 구체적인 일정 산정에 들어가기 전이긴 하지만, 우선순위 구분과 함께 각 '스프린트 별'로 이슈 카드를 배치해서 총 6주라는 타임라인 안에서 각 이슈가 소화될 수 있을지 개략적으로 감을 잡을 수 있도록 했다. 첫 스프린트에는 오로지 MVP 완성만을 목표로 하다 보니, 1번의 설명 그대로 서비스에 필수적인 기능만 담게 되었다.
3. 스토리포인트 산정
우리 팀은 스토리 포인트 1점은 1시간으로 정하고, 30분 단위까지만 쪼개기로 했다. 이렇게 하니까 시간 단위로 딱 떨어져 직관적으로 이해할 수 있었다. 또 0.5 단위로 나누어 떨어져 표기할 때도 별 고민 없이 깔끔하게 표기할 수 있었다. 예를 들어 [1.5]라고 적혀있으면 1시간 30분 걸리는 이슈로 추정한 것이다.
스토리 포인트 산정은 페어끼리 자체적으로 수행했다. 나와 나의 페어(심바)는 구현 기능목록을 순차적으로 훑으면서 상대적인 포인트를 산정했다. 로그인 기능은 '2점', 그보다 간단한 내비게이션 바 라우팅 기능은 '1점'과 같은 식이었다. (돌아보니 매우 주먹구구...)
4. 이슈 등록
우리 팀은 소스코드 저장소인 깃허브에서 지원하는 이슈관리 시스템을 이용하기로 했다. 무료이고, 접근성이 좋기 때문이다.
팀 repository에 우리 팀에게 필요한 라벨을 생성하고, 마일스톤도 등록했다. 그리고 이슈를 등록했다. 이슈의 제목 맨 앞부분에 대괄호에 산정한 스토리 포인트를 적는 것을 우리 팀의 이슈 제목 컨벤션으로 맞추었다.
프로젝트의 진행 현황을 한눈에 파악할 수 있는 칸반 보드도 생성했다. Projects 메뉴에서 등록할 수 있다. PR이 올라오거나, 리뷰가 진행되거나 merge 되었을 때 등등 자동으로 카드가 이동되어 편리했다.
+ 사후 평가
스프린트 1에서 소요될 것으로 예상한 스토리 포인트는 총 23.5 점이었다. 스토리 포인트 산정을 마치고 페어에게 순진무구하게 얘기한 기억이 난다.
???: "우리 딱 4일이면 끝나겠는데요? 너무 여유로워서 필수 기능 말고 선택 기능도 욕심낼 수 있을 것 같아요."
실제로는 47.5 포인트가 소요되었다. 스토리 포인트를 추정하는 과정에서 미처 고려하지 못했던 것들이 많았다.
우선, UI를 디자인하는 시간을 빼먹었다. 한 페이지의 UI를 구성하기 위해 figma 페이지에서 작업하는 시간이 1시간 이상되는데 이 시간을 전혀 고려하지 못했다.
또, 새로운 기술을 학습하는 시간을 고려하지 못했다. dev툴로 비동기 데이터를 간편하게 보고 로딩 UI나, 캐싱 구현을 편하게 하기 위해 react-query 를 도입했는데, 처음 사용하는 api를 익히고 삽질하는데 드는 시간이 만만치 않았다. 지도 정보를 표시하기 위해 사용한 카카오 api 의 예제를 확인하고 적용해보는데도 시간이 많이 들었다.
마지막으로, 버그를 해결하는 시간을 따로 마련하지 않은 것도 실수였다. 스프린트 1 때는 구현만 하면 끝날 것이라고 철석같이 믿고 새로 생긴 이슈를 대응하는 버퍼 시간에 대한 고려가 전혀 없었다. 이렇게 누락된 요소가 많다보니 예상한 시간보다 2배가 더 걸릴 만했다.
스프린트 3까지 마친 지금은 버그가 없을 수는 없다는 사실을 받아들이고, 일정 산출 시 버퍼 구간을 마련하는 노하우가 생겼다. 아직도 일정 추정은 너무 어렵지만, 마지막 스프린트 때는 드물게 딱 맞게 일정을 산정한 적도 있었다.
분명 이슈 관리와 일정 추정은, 단기간 내에 습득할 수 있는 역량이 아니다. 그래서 캡틴 포비께서 우리 새싹들이 조금이나마 빨리 직접 부딪혀보고 이런 고민을 시작해보라는 의미에서 강의를 진행해주신 게 아닐까 하는 생각이 든다.
어떻게 이슈를 관리하고 일하는 것이 효과적일지 계속 고민을 이어가면서 언젠가는 일정 추정의 마스터가 되어보자. 💪
'General' 카테고리의 다른 글
| [오브젝트] 2장 객체지향 프로그래밍 (0) | 2022.07.30 |
|---|---|
| [테코톡 요약] 우아한테크코스 3기 레벨3 테코톡 모아보기 (0) | 2021.07.15 |
| [테코톡 요약] 우아한테크코스 3기 레벨2 테코톡 모아보기 (0) | 2021.04.29 |
| SQL 기초 & 자주쓰는 쿼리문 정리 (10) | 2021.03.29 |
| [테코톡 요약] 우아한테크코스 3기 레벨1 테코톡 모아보기 (3) | 2021.02.18 |
