애자일 스크럼 프로젝트 관리

스크럼을 실무에 도입한 경험

지금 스크럼을 도입해서 사용하지 않은팀이라도 애자일 이라는 용어는 계속해서 들어보셨을거라 생각합니다. 그리고 아마도 가볍게 몇가지 시도를 해보다가 큰 효과를 보지 못해 애자일 회의론자로 돌아서신분들도 있을거라 생각합니다.

우선 애자일은 단지 방법론임을 이해해야합니다. 애자일을 도입함으로써 우리 프로젝트가 멋지고 세련되지는 마법툴이 아닙니다. (물론, 애자일 스크럼프로젝트를 멋지게 관리할수있는 Jira가 존재합니다) 애자일을 도입하려는 팀의 구성원 모두가 단순히 프로세스를 따라하는것이 아니라 우리가 수행하는 애자일을 위한 문화들이 정확히 어떤 목적을 위해 수행되는지 인지하고 따르기위해 노력하면서 방법론의 목적을 달성할 수 있을것입니다.

저는 이번포스팅에서 스크럼을 도입해 팀의 태스크를 효과적으로 관리한 경험을 공유하려고 합니다. 가장먼저, 스크럼 프로젝트 관리방법 도입을통해 아래와 같은 결과를 얻을 수 있었습니다.

  • 자연스러운 팀원들간의 태스크 공유
  • 실무자와 팀원들간 작업에 대한 이해내용 지속적인 검증 (작업미션에 대한 지속적 교차 검증)
  • 팀전체, 팀원 개개인의 지속적인 중단기적 목표 설정및 공유
  • 지속적인 개발문화 발전을 위해 팀차원의 다양한 시도를 할 수 있는 자리 마련
  • 관리자의 효과적인 팀원 리소스 모니터링

스크럼 용어정리

스크럼을 시작하기전, 스크럼에서 일반적으로 사용되는 용어에대해 간단하게 정리하고 가보겠습니다.

  • 스크럼
    • 애자일한 개발을 위한 점진적 개발방법론
  • 데일리 스크럼
    • 매일 진행하는 짧은 회의 (완료한 내용, 진행예정인 내용, 진행중 어려움을 겪고있는 내용)
    • 🌟 목적 : 단순한 정보전달이 목적이 아닌, 미팅을 통해 팀원들과 백로그를 조율하는것
  • 스프린트
    • 과제가 진행되는 주기로서 팀별로 1~8주 정도로 상이 할 수 있음(개인경험상 2주가 적당)
    • 🌟 목적 : 현재 상황에 기반하여 반복되는 주기내에 완수하고자 하는 중단기적 목표를 세우는 것
  • 백로그
    • 과제를 위해 수행되어야 하는 태스크로서 지속적으로 업데이트 될 수 있으며 우선순위가 존재 할 수 있음
      • 스프린트 백로그 : 이번 스프린트 주기에서 수행되어야할 백로그 (스크럼보드에 정리된 태스크들)
      • 글로벌 백로그 : 이번 스프린트 주기에서 수행되지 않아도 되지만, 언젠가 수행되어야할 백로그
    • 🌟 목적 : 과제 달성을 위해 수행해야할 작은 미션들이라 생각하고, 백로그간의 우선순위를 잘 설정하여 수행될 수 있도록 해야한다
  • 스토리포인트
    • 태스크 수행을 위해 필요한 척도를 구체화한 포인트로 나타낸것으로써 작업난이도, 작업량등을 고려하여 구현에 필요한 규모를 추정한다
    • 🌟 목적 : 태스크에 대해 팀원들간에 추정한 구현 규모가 다를수 있다. 스토리포인트 조정작업을 통해 태스크에 대해 서로가 이해한 내용을 잘 공유하고 일정산정에 도움이 되도록 해야한다
  • 번다운 차트
    • 작업 진척도를 확인할수 있는 차트로써 조직별, 구성원별 진행상황을 한눈에 파악 할 수 있음
    • https://search.naver.com/search.naver?where=image&sm=tab_jum&query=%EB%B2%88%EB%8B%A4%EC%9A%B4%EC%B0%A8%ED%8A%B8
    • 🌟 목적 : 스프린트내에서 일정이 딜레이 될 조짐이 보인다면 빠르게 파악하여 조정 해야한다
  • 프로젝트 오너
    • 백로그를 관리하며 우선순위를 조정,관리하는 책임자
  • 스크럼 코치(마스터)
    • 스크럼 방법론이 잘 적용될 수 있도록 필요한 지원을 하는 조력자

스크럼 사이클

이제 실제로 팀에서 어떤 방식으로 스크럼을 적용했는지 정리해보겠습니다.

가장 먼저 해야할 것은 위 용어설명에서 나온 스프린트 주기를 설정하는 일 입니다. 일반적으로 1~4주 사이의 간격을 선택하며 팀마다의 배포주기, 미팅주기 등을 고려하여 설정하면됩니다. 주기가 너무 길어지면 스프린트기간내에 작업목표가 수정되는일이 발생할수있고 주기가 너무 짧아지면 잦은 목표설정으로 피로감이 올 수 있으니 적절하게 설정하는것이 좋습니다. 여러 주기를 수행해보면서 개인적으로는 2주정도의 주기가 가장 적절했던것 같습니다.

그다음부터는 이제 스프린트 주기별로 해야할 일 들입니다.

  1. 스프린트 계획 미팅
    • 스프린트의 목표를 세우고 팀원별로 이번회차의 스프린트에서 수행할 백로그들을 정리하는 작업입니다.
    • 각 팀원들은 미팅전에 이번 스프린트 기간동안 진행할 백로그들을 생성합니다.
    • 백로그 생성시에는 작업의 우선순위를 고려해야하며 반드시 스토리포인트를 잘 설정해두어야합니다.
    • 이 작업을 하면서 각각의 팀원들이 세우고있는 중단기적인 목표를 모두에게 공유 할 수 있습니다.
    • 스토리포인트 1pt = 1MD의 룰을 세우고 작업에대한 대략적인 일정과 생각하고 있는 규모를 전달받을 수 있습니다.
  2. 스프린트 수행
    • 스프린트 계획 미팅에서 설정한 백로그를 해결해 나갑니다.
    • 매일 데일리스크럼미팅을 하며 내용을 공유합니다. 단, 공유내용이 길어진다면 데일리스크럼미팅이 끝난후 담당자끼리만 별도의 미팅을 진행합니다.
    • 실무자는 스크럼보드를 통해 진행중인 백로그의 태스크 flow(Todo - InProcess - Done)를 즉각적으로 반영합니다.
    • 관리자는 번다운차트를 활용해 팀 전반적으로 백로그가 잘 수행되가고 있는지 파악 할 수 있습니다.
  3. 스프린트 회고
    • 팀원 구성원들이 각자 계획했던 작업들이 성공적으로 마무리 되었는지 공유합니다.
    • 작업을 진행하면서 팀원들에게 전달하고 싶었던 이슈들을 공유합니다. (기술적 난관, 노하우, 아이디어 등)
  4. KPT 회고
    • KPT (Keep, Problem, Try)를 통해 팀문화를 점검하고 발전시키는 시간을 가집니다.
    • Keep 우리가 계속 지켜나가고 발전시켰으면 좋겠다 하는 내용을 구체적으로 좋았던점을 공유합니다. Keep의 내용이 쌓여갈수록 팀이 가진 좋은 정체성들의 모음집이 될 것 입니다.
    • Problem 일 혹은 팀 문화에 있어서 개선되었으면 하는 안건들을 공유합니다. 작은불편함이라도 하나씩 개선해 나가면서 좋은 팀의 문화가 만들어질것입니다.
    • Try 팀의 발전을 위해 시도해보고 싶은 것들, 혹은 Problem의 개선을 위한 방안들을 공유하고 시도여부를 결정합니다. 바로 적용하기 어려운 안건의 경우 다음 스프린트때까지 결정을 유예하여 팀원들의 의견을 반영하여 결정합니다.

위의 사이클을 계속해서 반복하면서 프로젝트를 애자일하게 관리하는것입니다. 위 사이클대로라면 매 주기마다의 회의에서는 3,4번의 이전 스프린트에 대한 회고와 1번의 다음 스프린트에대한 계획을 잡기위한 회의가 같이 이루어질 것 입니다.

자기계획형 스프린트

일반적으로는 프로젝트 오너(PO)가 백로그를 생성하고 할당하는 전통적인 스크럼 방식과는 다르게 실무자가 직접 스프린트 주기마다 진행할 목표를 세우는 ‘자기계획형 스크럼’ 방식으로 진행했습니다. 물론 이것이 되려면 스프린트 미팅 전에 별도의 사전 미팅을 통해 프로젝트요구사항 파악 및 작업 분배 작업이 선행되어야만 합니다.

제 경험으로는 PO가 백로그를 직접 관리하는 전통적은 방식은 아래와같은 단점들이 존재했습니다.

  • PO가 백로그를 관리하는데 사용되는 리소스가 굉장히 많이듭니다.
  • PO가 직접 실무를 담당하지않는 경우가 많기때문에 백로그가 디테일하게 세분화되기가 힘듭니다.
  • PO가 생각한 작업의 규모와 실무자가 생각한 규모가 다를 확률이 많습니다.

위와 같은 이유로 스프린트 백로그 관리는 실무자들이 직접 계획하도록 설정하도록 했습니다. 다만 아래의 규칙을 세워두고 각자가 백로그를 계획할때 참고 할 수 있게했습니다.

  • 스프린트마다 workingDay 80% 정도로 StoryPoint를 산정한다. (작업중 변수는 반드시 일어난다)
  • 작업 규모를 산정할때에는 단순 개발시간 뿐만 아니라 조사 및 커뮤니케이션에 사용되는 시간도 고려해야한다.
  • 하나의 백로그는 가능한 Story 3pt를 넘지않는 선으로 세분화한다.

자기계획형 스프린트로 얻을수 있었던 점은 좋은결과를 얻을수 있었던 점은 이와 같습니다.

  • 세분화된 작업계획을 설정 할 수 있다.
  • 대부분 직접 계획한 작업기간에 맞출수 있다.
  • 개개인의 작업규모 산정에 대한 스킬이 증가되었다.

JIRA 에서 스크럼 프로젝트 관리하기

https://taes-k.github.io/2019/12/07/sw-jira-scrum/

Gihub에서 스크럼 프로젝트 관리하기

https://taes-k.github.io/2022/01/04/github-scrum/

마무리

스크럼에 대해 너무나도 긍정적인 경험을 갖고있는 제가 수행했던 방법을 공유드렸습니다.

위 방법이 스크럼수행을 위한 최선의 방법은 아닐 수 있다고 생각합니다. 또한 여러분이 팀에 스크럼을 처음 도입한다면 매우 어설프고 이게 맞나? 하는 생각이 드시는것은 당연합니다.

다만 분명한건, 팀원들이 함께 스크럼에대해 긍정적으로 생각하고 팀문화의 발전을 꾀하고 있다면 프로젝트만이 애자일하게 관리되는것이 아닌 스크럼 방법론 자체도 애자일하게 팀의 색깔에 따라 점점 개선되어질것이라고 확신합니다.

agile scrum