프론트엔드 파트의 스크럼 개선기
JIRA의 애자일 도구를 활용해 플래닝 및 회고하기
R&D 센터는 JIRA를 활용해 업무를 수행한다. JIRA를 도입하면 별도의 업무일지를 작성하지 않아도 될 정도로 어떤 팀원이 무슨 일을 하고 있고, 얼마나 걸렸는지 등을 알 수 있으며, 개인과 팀의 퍼포먼스가 어느 정도 되는 지도 측정할 수 있다.
사실 작년 한 해 동안은 빠르게 프로젝트를 진행하다 보니 스크럼이니 칸반이니 하는 애자일 방법론을 도입하기가 어려웠다. 대략적인 큰 틀과 릴리즈 일정을 잡고 이에 맞춰 업무를 진행하기 바빴다. 그러다 보니 일하는 사람만 일하게 되는 문제점이 있었고, 특정 사람이 과도하게 업무를 하다 보니 업무 피로도가 높아지고 품질이 저하되는 등의 문제가 발생하게 되었다.
센터에서는 이러한 문제를 해결하고, 애자일하게 일하기 위해 '이야기 점수' 산정이라는 방법을 도입하였다.
이야기 점수를 산정하는 이유는 다음과 같다.
첫째, 개인 / 팀 퍼포먼스를 측정하기 위해
둘째, 측정한 개인/팀의 퍼포먼스를 바탕으로 스프린트 플래닝을 하기 위해
해당 방법을 도입한 후, 프론트엔드 파트에서는 다음과 같이 플래닝 및 회고를 진행했다.
1. 플래닝
각 서비스 담당자(개발자)가 본인이 약 2주간 진행되는 스프린트에 진행할 이슈를 목록화하여 가져온다.
다 함께 이야기 점수를 산정한다.
약 2주간 개발을 진행한다.
2. 회고
플래닝에 없던 이슈 중 이야기 점수가 없는 이슈들의 이야기 점수를 산정한다.
이러한 방식으로 계속 일을 하다 보니 다음과 같은 생각이 들었다.
이게 진정한 애자일, 스크럼 방법일까?
원래라면 회고 때 이번 이터에서 점수가 잘못 산정된 이슈들을 재산정한다던지, 우리 파트가 잘한 것 또는 잘하지 못한 것 그리고 개선할 점 등등에 대해서 논의가 되어야 한다. 그러나 눈에 보이는 거라곤 프론트엔드 담당자 별 이슈 목록이 전부이다 보니 플래닝을 할 때도 회고를 할 때도 얘기할 게 별로 없었다.
문득 이렇게 의미 없이 플래닝과 회고 회의 시간을 보내기엔 너무 아깝다는 생각이 들었다. 그래서 우리가 하는 이 활동에 대해 인사이트를 얻을 수 있는 방법이 없을까 생각하며 JIRA에서 제공하는 애자일 도구들을 알아보기 시작했다.
JIRA에서는 스크럼과 칸반 방법론을 위한 도구들을 제공하고 있었다. 우리는 스크럼 방법론을 사용하고 있었으므로 JIRA에서 제공하는 애자일 보드와 백로그를 활용해 플래닝을 하고, 보고서를 활용해 회고를 하면 좋겠다는 생각이 들었다.
JIRA 애자일 도구를 활용한 플래닝
1. 플래닝 전 날
1) 스프린트 백로그 등록
프론트엔드 파트 팀원들은 해당 스프린트에서 수행할 백로그를 등록한다. 애자일 보드를 만들 때 필터를 연결할 수 있는데, 이 필터에 해당하는 조건(수정 버전 또는 타겟 버전 등등)에 맞게 이슈를 변경해준다.
2. 플래닝 당일
1) 스프린트 플래닝
애자일 보드의 백로그를 눌러 스프린트를 만든다. 스프린트를 만들고 해당 스프린트에서 작업할 이슈들을 함께 논의해 스프린트 영역으로 이동시킨다.
2) 이야기 점수 산정
스프린트 목록에 있는 이슈들을 보며 이야기 점수를 산정한다. 이때, 이슈 담당자는 해당 이슈에 대해 팀원들에게 설명하고 팀원들을 이를 듣고 각자 생각한 이야기 점수와 그 이유를 함께 얘기한다.
3) 재확인 및 조정
담당자별 작업량을 보고 이슈가 적절하게 분배가 되었는지 확인한다. JIRA 애자일 보드에서는 담당자별 작업량을 확인할 수 있도록 아래처럼 제공하고 있다.
예시 화면 - 담당자별 작업량3. 스프린트 진행
위에서 플래닝 한대로 2주 동안 스프린트를 진행한다. 스프린트 내 작업하는 이슈들은 Github PR을 통해 코드 리뷰된 후 GateKeeper에 의해 Merge 되며, Merge 후에 이슈가 해결된다.
JIRA 애자일 도구를 활용한 회고
4. 스프린트 종료 후
1) 대시보드
스프린트가 종료되면 지난 스프린트에 대해 회고하는 미팅을 가진다. 쌓여있는 데이터만 가지고는 회고를 할 수 없으며, 그렇다고 할 때마다 지라 필터를 걸어서 보는 것은 아무런 의미가 없다. 불편할뿐더러 우리가 정말 잘하고 있는지, 우리가 어떤 부분을 보완해야 하는지 등등을 인사이트를 얻기 어렵다.
그러므로 쌓여있는 데이터 속에서 우리의 애자일 프로세스가 제대로 흘러가는지 확인하고, 의사결정을 내리기 위해 대시보드를 만들었다. JIRA에서 제공하는 대시보드를 활용하면 스프린트가 얼마나 남았는지, 현재 진척상황은 어떻게 되는지 각 담당자 별로 얼마나 이슈가 남았는지 등등을 확인할 수 있다. 해당 대시보드는 아래 링크를 참고하여 만들었다.
Atlassian 스크럼 프로젝트 관리 - 2부 체계적인 애자일 스크럼 프로젝트 관리
프론트엔드 파트 스프린트 대시보드2) 스크럼 보고서
대시보드를 통해 해당 스프린트가 얼마나 남았고, 현재 진척상황은 어떠하며, 번다운 차트를 통해 남아있는 작업과 목표 달성 가능성을 예상할 수 있었다면 스크럼 보고서를 통해 더욱더 데이터 중심적인 회고가 가능하다. 이에 따라 다음 스프린트에서 개선할 영역들에 대해 더욱 세밀하게 작성할 수 있다.
다음은 JIRA에서 제공하는 스크럼 보고서이다.
현재 우리는 번다운 차트를 대시보드 위젯으로 사용하며, 회고 때는 스프린트 보고서를 사용하였다. 스프린트가 종료된 후 스프린트 보고서를 확인할 수 있는데, 보고서 내에 페이지 만들기 버튼을 제공해 회고록을 바로 작성할 수 있다.
3) 회고하기
프론트엔드 파트 회고록은 위키에서 제공하는 회고록 양식을 베이스로 만들었다. JIRA에서 제공하는 스프린트 보고서와 소멸 차트를 보고 해당 스프린트의 플래닝과 진행 사항들에 대해 다 같이 검토한다. 이때, 검토하는 사항들은 아래 링크를 참고했으며, 다음과 같다.
스프린트가 플래닝 한대로 잘 진행되었나요?
혹시 스프린트 중간에 새로운 이슈들이 생기거나 중단된 것들이 있나요?
혹시 스프린트 내에 완료되지 않은 이슈들이 있나요?
만약 플래닝 한대로 잘 진행되지 않았다면 함께 그 이유를 찾고, 해결해봅시다
스프린트 고려 사항
스프린트 보고서를 통해 플래닝 한대로 스프린트가 잘 진행되었는지 파악하고, 소멸 차트를 보며 해당 스프린트에 어떤 이벤트가 플래닝에 어떻게 영향을 주었는지 파악한다. 소멸 차트는 스프린트 진행 및 회고 때 굉장히 중요한 부분이며, 만약 이 부분이 파트 외부 요인으로 인해 영향을 주었다면 방해 요소를 제거할 수 있도록 요청한다.
* 스프린트 보고서
각 스프린트 별로 완료된 작업과 백로그에 미루어둔 일에 관해 이해할 수 있습니다. 이는 팀의 제출량이 과도한지, 범위 크립(scope creep)이 지나친 지 여부를 결정하는 데 유용합니다.
*소멸 차트
전체 남은 시간과 스프린트 목적을 성취하는 것과 같은 프로젝트를 관리합니다. 이를 통해 팀의 진척도와 올바른 업무 방향을 관리할 수 있습니다.
그리고 마지막으로 스프린트 기간 동안 칭찬할 부분과 개선할 부분을 정리해 다음 스프린트 개선사항으로 반영한다. 이번 회고 때는 각자 자리에서 옆에 있는 팀원을 칭찬하도록 유도하였는데, 업무 및 업무 외적으로 소소하지만 고마웠던 일들을 서로 즐겁게 얘기해주어서 분위기가 좋았다. 그리고 개선해야 할 부분은 각자가 아쉬웠던 부분을 얘기할 수 있도록 하고, 다음 스프린트에 개선할 수 있도록 간단한 조치사항을 기록하였다.
사실 아쉬웠던 부분, 개선하고 싶은 부분은 각자 또는 파트가 반성해야 할 부분이라 팀원들과 함께 얘기하기 껄끄러웠을 수도 있는데, :disappointed: 이모티콘을 하나씩 붙여놓으니 딱딱하지 않아 보고 말하는 팀원들 입장에서도 덜 부담스러워했다. 오히려 서로 솔직하게 얘기하려고 하는 분위기가 형성되었다. (다행)
애자일 도구 도입 그 이후
이번 스프린트에 JIRA 애자일 도구 도입 및 스크럼 개선을 하며 저번 주 금요일에 회고를 진행한 결과, 팀원들 모두 개선된 프로세스에 만족하는 듯했다. 대시보드를 통해 현재 스프린트의 진척사항 및 팀원들의 상태 등을 파악할 수 있고, 쉽게 인사이트를 얻을 수 있어 의미 있는 해결책을 같이 논의해볼 수 있었다는 의견에 모두 공감을 하였다. 또한, 스프린트 보고서 및 소멸 차트를 보고 함께 원인을 추정하고 해결법을 도모해나가는 과정이 재미있고 굉장히 의미 있는 시간이었다고 얘기해주었다.
프론트엔드 파트 팀원들이 얘기한 스크럼 장점과 단점이번 스크럼 방식 개선은 단점보다 장점이 많았으며, 팀원이 적기 때문에 이러한 부분들을 장점이라고 다들 느낀듯하다. 앞으로도 이 장점을 유지할 수 있도록 팀원들과 함께 노력해야겠다는 생각이 들었다.
개인적으로 애자일 도구를 도입하면서 애자일 및 애자일 도입기 등등 다양한 블로그를 찾아보았는데, 애자일과 애자일을 도입하는 이유 등에 대해 꼭 팀원들에게 전달해야겠다고 생각했었다. 그래서 애자일 도구 사용법, 회고 등등 어떤 것들을 진행하기 전에 애자일은 개발자를 관리하기 위한 도구가 아니며 우리가 이러한 플래닝, 회고 등을 하는 이유는 개발 문화나 제품을 개선하기 위한 신속한 피드백을 얻고 수행해나가는 데 목적이 있다고 계속 거듭 강조를 했다.
팀 내에 애자일 문화를 도입한다 하면 모두가 애자일에 대한 인식이 Align 된 상태여야 하며, 누군가는 애자일 문화를 전파하기 위한 노력을 해야 한다고 생각한다. R&D 센터의 프론트엔드 파트도 아주 완벽한 애자일 조직이라고는 할 수 없지만 유연하고 최상의 퍼포먼스를 내기 위한 조직으로 발전하기 위해 더욱더 서로 공유하고, 방해 요소를 제거해나가는 등 앞으로도 많은 노력을 기울일 예정이다.
P.S 올해 가장 기억에 남는 최고의 칭찬
혹시나 이 글을 읽고 우리의 문화 활동이 너무 즐거워 보이고, 가슴이 뛰고, 내가 찾던 회사라면?
백엔드 / 프런트엔드 / QA (채용 중)
Edit by April
Photo by Brooke Cagle on Unsplash
