스크럼, 입고팀이 애자일하게 일하는 법 2부
개발자 입장에서 쓴 스크럼 운영 후기
차다희
게시 날짜: 2022.07.11.
- 1. 글을 시작하며
- 2. 스크럼을 진행하며 좋았던 점 (feat. 순도 100%의 개발자 시점)
- 3. 스크럼팀 운영시 주의할 사항
- 4. 글을 마치며: 스크럼 안티 개발자, 왜 스크럼 열혈팬이 됐을까😍
- 5. 레퍼런스
1. 글을 시작하며
안녕하세요. 입고팀 입사 6개월차인 병아리 개발자입니다.
1부에서는 스크럼 운영 방식을 소개했다면, 2부에서는 개발자 입장에서는 스크럼에 대해 어떻게 느꼈는지 나누려합니다.
2. 스크럼을 진행하며 좋았던 점 (feat. 순도 100%의 개발자 시점)
아래는 6회의 스프린트를 겪으며 개발자로서 느낀점입니다. 애자일과 스크럼은 ‘개발자를 무리한 일정에 맞추도록 혹사시키는 것'이라는 편견을 가지고 있던 제게, 이번 경험은 어떻게 하면 효율적으로 일할 수 있는지 학습할 수 있던 소중한 시간이었습니다. 스크럼에 대해 개발자의 입장에서 어떻게 생각하는지 궁금해하시는 분들이 많을 것 같아, 이번 후기를 작성했습니다.
2.1 커뮤니케이션 비용의 절약
입고팀은 스프린트 보드를 사용하고 있습니다. 각자가 맡은 업무의 진척도를 한 눈에 볼 수 있기 때문에 어디서 문제가 발생했는지, 현재 단계가 끝나면 다음에 처리할 일은 무엇인지 파악할 수 있어 커뮤니케이션 비용이 절약됩니다.
예를 들어 아래 스프린트 보드에서 티켓 IBS-1002가 PR REVIEW로 넘어가면 QA는 “곧 QA 요청이 들어오겠구나” 생각하고 미리 테스트 시나리오를 작성할 수 있습니다.
2.2 개발자, 기획자, QA 모두 공통의 목표를 향해 “화목하게” 일할 수 있다.
IT 회사마다 분위기 차이는 있겠지만, 개발팀/기획팀/QA팀 간에는 보이지 않는 장벽이 존재합니다. 특히 개발자와 기획자의 관계는 많은 경우 원수 사이입니다.
아마 많은 팀에서 아래와 같은 대화가 하루에도 몇 번씩 오갈것입니다.
🧑💻 개발자: 기획서가 부족하네요. A, B 부분 기능 명세가 충분하지 않습니다. 이 기능은 꼭 필요한가요? 너무 많은데요.
🤷♂️ 기획자: 도대체 얼마나 디테일한 기획서를 원하는거죠?! 사용자 편의성을 위해 이 기능 꼭 있어야 합니다.
🙅♀️ QA: 버그 버그 버그… 고쳐주세요
🤦 PO: 하… 그래서 우리 일정 어떻게 하면 맞출 수 있는데요.
하지만 스크럼을 진행하면서, 주어진 스프린트 내에 티켓을 마무리하기 위해(=공통의 목표) 사이좋게 협업할 수 있었습니다.
2.3 회고를 통한 피드백 시스템 정착
첫째. 피드백을 위한 시간을 명시적으로 설정해둠에 따라, 스프린트 동안에는 목표 달성에만 집중할 수 있었습니다. 개발을 하다 보면 팀 업무 프로세스에 대한 이런저런 아쉬움과 불편함을 마주하게 되는데요. 확보된 회고시간을 통해 이에 대해 충분한 논의를 할 수 있었습니다. 회고시간이 없었다면 혼자 끙끙 앓거나, 스프린트 도중에 이슈를 제기해 팀의 개발 흐름을 끊는 일이 생겼을 지도 모릅니다.
둘째. 피드백을 보다 구체적으로 정리할 수 있는 시간이 생겼습니다. 제가 회사 생활하며 가장 곤란했던 것은, 갑작스러운 피드백 요청이었습니다. 이 경우 횡설수설하거나 어색하게 “좋았어요😰”라고 말한뒤 집에서 “이건 말했어야 해!!!!”하고 울부짖었는데요. 2주간 생각을 정리하고 말할 수 있어서 만족합니다. (+ 제가 낸 의견에 👍을 받으면 그날 기분이 매우 좋습니다✌️)
셋째. 팀 개선을 위한 액션 아이템이 도출됩니다. 기존의 프로세스를 비판하기는 쉽지만 개선안을 내는 것은 어렵습니다. 회고 시간에는 아쉬웠던 사항을 개선할 방법이 함께 논의 되므로, 다음에 무엇을 해야할지 방향성이 분명해집니다. 예를 들어 “스토리 리뷰 전 미리 티켓 내용을 각자 읽어오면 좋을 것 같다”는 피드백이 곧 팀의 액션아이템으로 자리잡자, 스토리 리뷰 시간은 30분 단축 되어, 팀 생산성이 향상되었습니다.
2.4 개발팀원 전체의 도메인 이해도 증가
이전에는 내가 맡지 않은 프로젝트에 대해서는 코드를 완벽하게 이해하기 어려웠습니다. 하지만, 스프린트 보드에서 티켓을 차례로 가져가는 방식이기에, 다른 사람이 짠 코드+설계를 잘 이해하려고 더 노력할 수 있었습니다. 처음에는 여러 이슈들을 처리하느라 효율이 떨어지지 않을까 걱정했지만, 배포 후 이슈 대응시 배포 내용에 대해 잘 알고 있기 때문에, 메인 개발자가 아니어도 빠르게 대응할 수 있었습니다.
2.5 개발자가 주도적으로 업무의 일정을 산정할 수 있다.
대다수의 개발자가 회사에서 겪는 일은 갑작스러운 과제 일정에 맞추어 급박하게 개발하는 일일 것입니다. 그 와중에 서비스 운영 이슈&장애 대응도 해야하기 때문에 개발 일정은 더욱 짧아지고, 다크서클은 짙어지게됩니다. 하지만 스토리 리뷰 시간에 포인트를 부여하고, 포인트에 대한 근거를 개발자가 제시하여 PO와 스크럼 마스터를 납득시키기 때문에, 팀원 전체가 업무의 일정에 대해 합리적으로 의사 결정을 할 수 있습니다.
3. 스크럼팀 운영시 주의할 사항
스크럼 운영시 많은 팁과 주의사항들이 있을 것입니다. 그 중 저는 아래 2가지가 가장 크게 기억에 남습니다.
3.1 스프린트 시작 후 티켓 추가는 지양한다.
서비스 운영시 사용자에게 다양한 요청을 받습니다. 평소 습관대로 사용자 요청이 우선이라 생각하여 이번 스프린트 때 바로 넣으려하자 스크럼 마스터가 저지했는데요. 스프린트 2주 동안 접수되는 운영 이슈를 스프린트에 계속 추가하면 스프린트 시작 초반에 세운 목표들을 다 달성하지 못하므로 급한 이슈가 아니라면 다음 스프린트 때 진행하는 것이 옳다는 이유였습니다. 운영 이슈 해결의 급박함은 PO와 스크럼 마스터의 협의하에 결정하는 것이므로 접수된 이슈는 긴급 배포가 필요한 경우를 제외하고는 별도의 스프린트에 진행해야합니다.
3.2 개발자별로 주로 관리할 프로젝트를 정하자
만약 한 팀에서 다양한 도메인을 다루고 있다면 스프린트를 별개로 진행하는 것을 추천합니다. 한명의 개발자가 여러 도메인 (예. 입고 서비스, 인력 관리 서비스)의 프로젝트에 참여하다보면, 효율성이 떨어질 가능성이 큽니다. 도메인별로 테이블 구조, 주의할 사항 등이 다르기 때문인데요. 한 팀에서 관리하는 도메인이 여러개라면 팀원별로 주로 관리하는 프로젝트를 할당, 관련 티켓 위주로 작업하는 것을 권장합니다.
4. 글을 마치며: 스크럼 안티 개발자, 왜 스크럼 열혈팬이 됐을까😍
글 중간에도 언급했듯이, 저는 ‘애자일’과 ‘스크럼’이라는 단어를 마주치면 “악!!🤬” 소리 지르며 도망가는 개발자였습니다. ‘스크럼=무리한 일정’이라는 편견이 뇌리에 박혀있었는데요. 여섯 사이클의 스프린트는 제 편견을 깨부쉈습니다. 글의 서두에 언급했듯이 입고팀의 성격은 천차만별, 업무 방식도 다릅니다. 각자 선호하는 커뮤니케이션 방식, 업무 시간대도 다르고요. 남들의 눈치를 보며, “새로 이직한 이곳에서 어떻게 일할까, 여기서 선호하는 방식은 뭐지?”하고 고민하던 와중에, 스크럼 덕분에 제가 편한 방식대로 일하며 과제 해결에만 집중할 수 있었습니다. 덕분에 저를 비롯한 입고팀은 좋은 제품을, 효율적으로, 즐겁게 만들고 있습니다.
이 글이 스크럼 도입을 고민하는 누군가에게 작게나마 도움이 되었으면 좋겠습니다. 긴 글 읽어주셔서 감사합니다.