스크럼, 스프린트, 애자일?
애자일(Agile) 소프트웨어 개발을 비롯한 다양한 프로젝트에서 유연하고 반복적인 작업 방식을 지향하는 방법론. 변화하는 요구사항에 빠르게 적응하며, 고객 가치를 최우선으로 두고 결과물을 점진적으로 발전시키는 데 초점을 맞춘다.
스크럼(Scrum) 애자일 철학을 기반으로 한 프레임워크.
스프린트(Sprint) 한 달 이내의 짧은 주기로 이루어진 작업 기간. 이 기간 동안 팀은 스프린트 목표를 설정하고, 목표를 달성하기 위한 작업을 집중적으로 수행한다. 스프린트가 끝난 후에는 결과물을 점검하고, 다음 단계의 계획을 세우기 위해 회고와 리뷰를 진행한다.
내가 이 개념들을 처음 접한 건 소마 프로젝트를 시작하면서였다. 우리 팀의 전담 멘토님 중 한 분께서 (멘토님에 대한 이야기는 밑에서 좀 더 자세히 쓰겠다! 🫢) 예비 기간의 특강을 통해 애자일 개발 방법론을 소개해 주셨고, 멘토님께 멘토링을 받으며 우리 팀은 자연스럽게?! 지라와 컨플루언스, 스크럼, 스프린트를 프로젝트에 적용해 볼 수 있었다.
이렇게 프로젝트 관리를 해 본 건 처음이었는데, 시간이 갈수록 "지난 프로젝트에서도 이렇게 했더라면 더 효율적이지 않았을까?" 생각하게 될 때가 종종 있었다. 과정을 마무리하면서 돌이켜 보면 6개월의 기간 동안, 지금까지의 프로젝트 중 가장 큰 볼륨으로 진행했던 소마 프로젝트를 기간 끝까지 꾸준히 할 수 있었던 데는 프로젝트 관리를 성실히한 덕이 컸다는 생각이 든다. 👏
그래서 이 글을 적어 보게 되었다! 아직 나도 좀 헷갈리는 이론과 개념에 대한 이야기보다는, 이런 도구와 개념을 바탕으로 어떻게 프로젝트를 진행했는지, 그렇게 했을 때 어떤 효과를 느꼈는지를 중심으로 기록해 보려고 한다.
소마에서의 프로젝트 관리 (feat. Jira)
Jira & Confluence
지라 / 컨플루언스 모르는 사람에게 설명하기: 노션 비슷한 것, 근데 이제 스프린트 개발에 최적화된...
우선 지라는 프로젝트 및 이슈 관리 도구로 스크럼, 칸반 같은 형태의 작업 관리를 지원한다. 전체적인 타임라인 설계, 스프린트 진행, 작업 내역 및 예정 작업 관리, 진행 상황 시각화 같은 기능을 갖고 있다. 깃허브와도 연동되어서 실제 개발과 밀접하게 관리할 수 있다.
컨플루언스는 협업용 문서 관리 도구다. (이쪽은 진짜 노션이랑 비슷하다) 지라와 같은 Atlassian에서 서비스하기 때문에 연동이 가능하다.
우리 팀에서는 이번에 지라와 컨플루언스에서 프로젝트를 관리했는데, 2주 단위로 스프린트를 진행하면서 칸반 보드와 백로그를 중심으로 사용했다.
스프린트 플래닝
2주 스프린트는 플래닝으로 시작됐다. 😌
- 이번 스프린트의 목표
- 스프린트 기간 동안의 이슈 사항, 개인 일정
- 일정을 바탕으로 한 예상 작업 시간 산출
- 스프린트 내에 해결해야 할 작업 티켓별로 시간 추정치 작성
- 팀원 각자에게 할당할 작업 티켓 결정
플래닝 시간에는 주로 이런 얘기를 나누고 문서에 기록했다. 가장 좋았던 건 이렇게 내게 할당된 작업을 바탕으로 스프린트 기간 동안의 작업을 계획할 수 있다는 점, 그리고 장기 프로젝트 동안 해이해지지 않고 전체적인 타임라인에서의 프로젝트 진행 현황을 트래킹할 수 있다는 점! 또 '작업이 가능한 시간'을 미리 계산하고 '각 작업에 걸릴 시간'을 예상한 다음 작업을 할당하면 2주의 기간 안에 어느 정도 도달 가능한 작업량을 설정하게 되는 만큼, 꾸준히 효능감을 느낄 수 있게 해 주는 장치이기도 하다.
물론 이런저런 시행착오를 겪기도 한다. 개발 중 예상 못한 에러를 잡느라 예상 시간을 훌쩍 넘기거나, 일정과 무관하게 해야 할 일이 넘쳐서 일단 스프린트 안에 작업 티켓을 가득 채우고 본다거나... 😂 특히 초반에는 시간 추정치와 실제 작업 시간에 차이가 발생하는 경우가 많았다. 우리 팀은 각자가 자신의 작업 내역을 회고하면서 점차 해소된 문제이긴 했지만, 더 신중하게 시간 추정치를 계산하려면 멘토님께서 가르쳐 주신 플래닝 포커를 활용해 볼 수도 있을 것 같다. 프로젝트 후반부에는 플래닝에서 정한 작업 범위의 달성률이 조금씩 올라가기도 했는데, 이때도 성취감을 느낄 수 있었다 👍
데일리 스크럼
매일 아침에는 데일리 스크럼을 진행한다. 스프린트 플래닝에 따라 '오늘 하루 동안' 할 일을 정하고, 공유할 이슈가 있다면 간단히 얘기 나눈다. 그날의 기분이나 컨디션, TMI를 얘기하기도 한다는데 우리는 거기까진 안 했다... ㅎㅎ ; 데일리 스크럼은 할 일을 시작하기 전 짧게 진행한다. 빠른 진행을 위해 서서 이야기하는 스탠드업 미팅도 있다고 한다! 우리 팀의 경우 10분~15분 정도로 시간을 잡았는데, 익숙해지기 전까지는 조금 오래 걸렸다가 익숙해진 뒤로는 그날의 이슈가 얼마나 많은가... 에 따라 달라졌던 것 같다... 😅
티켓으로 개발 관리하기
매일 스크럼을 반복하면서, 스프린트 도중의 진행 상황은 지라의 칸반 보드를 통해 관리한다.
- 티켓
우리 팀에서는 티켓이 개발 단위였고, 티켓마다 하나의 브랜치와 하나의 풀 리퀘스트가 나왔다. 적절한 크기로 티켓을 나누는 것도 처음엔 조금 어려웠는데, 후반부로 가면서는 하나의 피쳐 당 하나의 백엔드 티켓, 하나의 프론트엔드 티켓이 기본으로 나왔던 것 같다. 피쳐에서 티켓을 만들고, 티켓 본문에 상세한 개발 요건이나 개발 후 작성한 PR 내용을 남겼다. 관련해서 기록할 이슈가 발생했다면 댓글을 쓰거나, 컨플루언스 문서를 만든 뒤 티켓에 기록했다.
속성도 설정할 수 있는데, 기본적으로는 담당자와 작업 시간을 설정해서 썼고 필요에 따라 우선순위를 사용하기도 했다. 덤으로 깃허브와 연결하면 티켓으로부터 바로 브랜치를 생성하고, 해당 브랜치의 풀 리퀘스트나 빌드 내역까지 지라에서 확인할 수 있다! 😎
- 워크플로우
칸반 보드에 기본으로 할 일, 진행 중, 완료가 있었던 것 같다. 우리는 조금씩 조정을 거치며 할 일 - 진행 중 - 리뷰 요청 (PR 진행 중) - 완료의 흐름에 정착했고, 추가로 우선순위가 떨어졌거나 당장 작업하지 못하는 티켓은 보류로 넘겼다. 스프린트를 진행하며 작업을 할 때마다 티켓에 시간을 기록하고, 워크플로우에 따라 티켓 상태를 바꾸면 칸반 보드를 통해 이번 스프린트의 현황을 한눈에 파악할 수 있어 좋았다.
- 백로그
백로그에는 "나중에 할 일"을 티켓화해서 모아둔다. 기능 명세에 따라 피쳐별로 티켓을 만들어 놓기도 했고, 프로젝트 진행 도중 "당장 급한 건 아니지만 나중에 해야겠다"고 떠오른 일들을 백로그에 넣어 두면 플래닝 때 백로그를 보면서 티켓을 할당할 수 있다. 이런 작업들은 대체로 시간 지나면 까먹기 십상이라 백로그에 모아 두면 잊지 않고 가져갈 수 있어서 좋았다. (물론 잊지 않는 것과 그 일을 정말 하는 건 다른 문제지만... 🙄)
스프린트 회고
스프린트가 끝날 때는 리뷰 / 회고를 진행한다. 우리는 멘토님과 함께 진행해서 해당 스프린트의 성과나 결과물 등을 공유하고, 완료되지 않은 할 일들에 대해 이유를 파악하고, 지난 스프린트의 목표 달성 여부를 체크한 뒤 KPT 회고를 진행했다.
스프린트 회고는 특히 계속해서 팀원들과 터놓고 이야기할 시간을 만들어 줬다는 점에서 좋았다. KPT 회고를 하면서 이번 스프린트의 좋았던 점, 팀원들에게 감사했던 점, 힘들었던 점이나 고치고 싶은 점 등을 이야기 하는데 우선 나 스스로도 계속해서 성찰할 수 있는 계기가 됐고, 팀원들에게 솔직하게 고마운 마음을 전하거나 스스로 부족했던 부분을 반성하는 시간을 가질 수 있었다. 🤍
with 이광헌 멘토님
우리 팀이 이렇게 프로젝트 관리를 할 수 있었던 데는 소마의 이광헌 멘토님이 아주 아주 큰 기여를 해 주셨다. 🥹 초반 애자일에 대한 이해나 지라 세팅부터 도와주시기도 했고, 우리의 스프린트 주기에 맞춰 2주마다 한 번씩 규칙적으로 멘토링을 진행하면서 회고를 같이해 주셨다. 멘토님과 같이 회고를 하면 우리의 이야기나 고민에 많이 조언을 해 주시는 것도, 그때그때 우리가 성장할 수 있는 도전 과제를 제시해 주시는 것도 모두 좋았지만 거기 앞서서 꾸준히 이 과정을 반복할 수 있다는 큰 원동력을 얻게 된다.
사실 이런 프로젝트 관리는 누구도 강제로 시키지 않기 때문에, 팀에서 관심을 갖고 시작하더라도 누군가 한 명이라도 의지를 갖고 이끌어가지 않는 이상 흐지부지될 위험이 있다. 😢 실제로 지라 자체도 우리에게는 낯선 도구였어서, 소마에서 함께 활동한 다른 팀들은 지라나 스프린트 기반 개발을 끝까지 가져가지 않는 경우도 많이 있었던 것 같다. (물론 애자일이 무조건 정답인 것도 아니니 팀에게 맞는 방법을 찾으면 되는 것!) 하지만 우리 팀에게는 멘토님이 계셨으므로...! 프로젝트 관리도, 프로젝트 자체도 소마 최종 발표까지 텐션을 유지할 수 있었다. 이렇게 하나의 프로젝트를 완료해 본 건 정말 값진 경험으로 남을 것 같다.
혹시나 만약에 소마 16기(나 그 이후)에 지원한 분께서 이 글을 보고 애자일에 관심을 갖게 되신다면 이광헌 멘토님을 모시는 걸 적극 추천한다! 👍👍 단순히 애자일에 한정되지 않고, 프로젝트를 발전시키는 것은 물론 "일 잘하는 방법"에 대해서도 많은 것을 가르쳐 주시는 멘토님이라고 생각한다 😌 (인기가 많으시니까 빠르게 어필하시길...!)
다음 프로젝트를 시작한다면
내 다음 프로젝트가 언제, 어디서, 무엇이 될지는 모르겠지만 🤔 이번 프로젝트를 진행하면서 인원과 프로젝트의 목적에 무관하게 이런 관리 방법을 적용하는 게 도움이 될 것 같다는 생각을 여러 번 했다. 혼자 토이 프로젝트를 하더라도 위 시스템 중 간소화한 방식으로나마 채택해서 적용해 보고 싶은 마음이다.
예를 들어 지라나 컨플루언스를 새로 익히기 부담스럽다면, (사용은 나름 직관적인 듯했지만 소소한 기능이 많아서 잘 활용하기까지는 시간이 좀 걸릴 수 있을 것 같다) 아마 많은 사람들이 이미 익숙하게 쓰고 있을 노션을 활용할 수도 있을 것이다. 쓰면서 내가 느낀 장단점이라면
- 노션 vs 지라: 노션이 보편적이고 친숙하지만, 협업 플랫폼으로 사용할 경우 인원수에 따라 무료 플랜 이용이 불가능하다는 단점. 지라의 경우 처음이라면 조금 낯설 수 있으나 무료로 팀에서 함께 사용할 수 있고, 아무래도 스프린트 기반의 작업 관리에 최적화된 기능들이 많다.
- 노션 vs 컨플루언스: 여기에선 사실 지라를 사용하기로 결정한 게 아닌 이상 노션의 손을 들 것 같다... 문서 작성 면에서는 약간 노션 + 구글 독스 같은 느낌이고, 지라와 연동이 수월하지만 컨플루언스의 표나 데이터베이스 기능을 사용하다 보면 노션의 데이터베이스가 아쉬워지는 순간이 종종 있었고 🥲 우리 팀도 프로젝트 후반부에는 노션을 일부 병행해서 사용했다.
이 정도! 내 기준으로는 개인 프로젝트라면 아직 지라에서 새 워크스페이스를 세팅하기보다 노션에서 시작하는 게 가벼울 것 같고, 팀 프로젝트라면 팀 내의 지라 사용 경험에 따라 도입을 고민해 볼 것 같다.
데일리 스크럼은 일단 풀타임으로 프로젝트를 진행해야 적용할 것 같은데 😅 팀 프로젝트라면 팀이 만나는 주기에 맞춰 현재까지의 작업 현황이나 이슈 상황을 공유하는 방식으로 가져가는 것도 좋겠다. 또 프로젝트 기간이 아주 짧은 게 아닌 이상, 스프린트 기반으로 플래닝과 회고를 진행하는 건 꾸준히 텐션을 유지하고 팀 내 소통을 도모하는 데 도움이 많이 될 것 같다!
마지막으로 이 모든 일들에 앞서서, 팀 프로젝트를 잘 진행하기 위해서는 당연하게도 팀원들과의 소통이 0순위 아닐까 생각한다. 위의 내용은 한창 프로젝트가 달려나가는 도중의 이야기이다. 관리 방식이 잘 잡혀 있다면 안정적으로 뛰는 데 도움이 되지만, 서로 목표를 공유하고 이해하는 팀원들의 존재도 그 못지 않게 강력할 것이다! 이번 프로젝트의 경우에는 시작하기 전 각자가 이 프로젝트에서 이루고 싶은 목표에 대해 이야기하고 함께 그라운드 룰을 만드는 과정을 거쳤는데, 여기에서 우리 팀만의 시스템이 시작된다고 느꼈다. 좋은 팀원들을 잘 만난 덕도 컸지만, 이렇게 시작한 팀이기에 열심히 달리는 과정이 즐거웠던 것 같다. 👟
애자일 입문자의 소소한 기록이었지만... 이 글을 읽는 분들의 플젝과 협업에 작게나마 도움이 되었으면 한다 🍀🪽
