스크럼을 만나다.

가장 대중적으로 알려진 애자일프레임워크 스크럼에 대하여.

https://brunch.co.kr/@574ec2ed558845c/1 읽고 오시면 좋습니다.

현재 개발팀의 워크플로우는 해당 분기의 로드맵 목표를 달성하기 위해 매주 미팅을 진행하고 태스크를 분배했다.(우리는 마일스톤 미팅이라 칭했다.)

마일스톤 미팅에선 로드맵 달성을 위해 개발해야 되는 기능들의 PRD 문서들을 리뷰하며 진행되었고 이를 바탕으로 각 팀원들이 해당 주차에 진행할 업무(태스크)를 배치했다. 이 과정에서 현재 방식의 여러 문제점들이 발견되기 시작했다.

먼저 고정된 마일스톤에 대해 의식하여 문서화된 PRD에 크게 의존하고 있었다. 매 마일스톤 회의마다 보완 및 추가 기획이 필요한지 피드백을 진행해야 했으며, 모두가 목표를 인지할 수 있었고 개발해야 될 내용들이 명확해졌지만 방대한 분량을 다루는 만큼 시간 소모도 컸고 당장 피드백을 해결하지 못하는 경우도 발생했다. (결과적으로 워터폴 방식을 잘못 적용하고 있었다고 생각한다). 그렇기 때문에 고객과 시장의 대응에 빠르게 움직일 수 없었다. 또한 PRD 리뷰와 태스크 배분까지 같이 진행되다 보니 부족한 시간과 비개발 인원의 간섭이 발생해 태스크 분배에 어려움이 있었다. 이를 해결하기 위해 늘 말로만 외치던 애자일을 실현하기로 마음먹었다.

애자일 방법론에는 여러 가지 워크플로우가 존재한다. 그중 가장 대중적인 스크럼을 발견해 회사에 적용하기로 마음먹었다.

스크럼을 선택한 이유는 2가지이다.

첫 번째, 대중적인 만큼 필요시 얻을 수 있는 정보의 양이 많았고,

두 번째, 현재 회사 루틴을 크게 변경하지 않고도 적용할 수 있다고 판단되었기 때문이다.

그럼 이 문제들을 어떻게 스크럼을 통해 해결할 수 있었을까?

스크럼이란?

스크럼을 간단하게 설명하자면 매 일정 주기로 제품을 완성해 나가는 점진적이며 반복적인 프레임워크를 뜻한다. 스프린트는 스크럼의 주기를 뜻하며, 스프린트는 1~4주를 권장하고 있다.

스크럼은 다음과 같은 일련의 워크플로우를 가져가는데,

1. 프로덕트 오너는 프로덕트 백로그를 준비하고 우선순위를 정렬한다.

프로덕트 백로그는 프로덕트 오너가 고객과 시장의 반응을 통하여 제품에 필요한 요소들을 준비한다고 보면 된다. 또한 어떤 백로그가 우선순위로 처리되어야 하는지 판단해야 한다.

필자는 다음과 같은 속성들을 포함하여 작성한다.

팀의 구조와 업무 방식에 따라 어느 정도 달라질 수 있으니 단순 참고용으로 사용해 주세요.

2. 스프린트 진행을 위한 스프린트 플래닝 미팅을 진행한다.

프로덕트 백로그가 준비되면, 개발팀과 PO는 스프린트 플래닝 미팅을 진행한다. 해당 미팅에서 PO는 해당 스프린트에 어떤 프로덕트 백로그를 처리해야 되는지 개발팀과 공유하며, 개발팀과의 피드백을 진행한다.

개발팀과 해당 스프린트에 어떤 프로덕트 백로그를 처리할지 결정되면 스프린트 백로그를 진행한다.

3. 프로덕트 백로그를 이용해 스프린트 백로그 생성

개발팀은 진행해야 될 백로그의 목표 달성을 위해 필요한 태스크를 생성하고 담당 인원을 배정, 일정을 조율한다. 이 회의는 해당 태스크를 담당할 실질적인 개발 인원들이 모여 진행하며, 그 외 인원은 배제된다.(내 경험에도 기타 인원, 예를 들어 대표나 PO 등이 있을 경우 심도 깊은 회의에 방해요소로 작용했다.)

4. 태스크 완수를 위해 업무를 진행하며, 매일 대일리 스크럼을 진행한다.

해당 태스크에 이슈는 없는지 빠른 대응을 위해 개발팀은 매일 대일리 스크럼을 통해 서로의 현황을 공유한다.

5. 스프린트 일정이 끝난 후 스프린트 결과물 및 스프린트 리뷰를 진행한다.

스크럼팀은 스프린트 일정이 끝난 뒤 결과물을 공유한다. 또한 해당 스프린트가 잘 진행되었는지 리뷰를 진행한다.

이렇게 일련의 스프린트를 마무리하고, 다시 1번으로 돌아와 발생한 백로그를 해결해 나가며 점진적으로 제품을 완성해 나간다.

스크럼을 하면서 주의해야 할 점은, 스프린트 달성 시 "경험할 수 있는 기능의 완성"을 목표로 잡는 것이다.

경험할 수 있는 기능은 제품을 만들어 나가는 팀원들에게 큰 동기부여가 되며, 고객들의 피드백 등 유저 스토리를 획득할 수 있는 아주 중요한 단위이기 때문이다. 특히나 학생창업이었던 우리 팀원들은 버튼이 버그 없이 작동되는 것만 봐도 서로 기뻐 소리를 질렀다.

아무튼, 이런 스크럼을 통해 얻은 이점들은 다음과 같다.

- 프로덕트 백로그를 통해 당장 우리가 해야 되는 업무를 명확히 공유

-기존 PRD 보다 작은 단위의 프로덕트 백로그를 통해 애자일 하고 유연한 제품 개발 가능

-개발팀이 직접 목표 달성을 위해 계획 수립 및 태스크에 집중할 수 있는 환경 조성

-작더라도 경험할 수 있는 기능의 완성을 통한 동기부여 및 유저스토리 획득

이제 막 2번의 스프린트를 진행했고 많은 결과물을 얻진 못했지만, 팀원들도 스크럼 시스템에 대해 긍정적인 반응을 보이고 있다. 특히 기능의 완성에 초점을 두던 PRD와는 다르게, 왜, 무엇을 해결하는지가 명확한 프로덕트 백로그와 해당 백로그 해결을 위한 간섭 없는 스프린트 백로그 작성이 크게 긍정적으로 작용했다고 답했다. 아직 부족한 부분 또한 있겠지만, 스크럼 프레임워크가 잘 유지되도록 열심히 관리해야겠다는 마음을 먹기엔 차고 넘치는 반응들이었다.