애자일 방법론 — 스크럼

애자일이라는 소프트웨어 개발 방법론이 있습니다. 짧은 주기의 개발 단위를 자주 반복해서 하나의 큰 소프트웨어를 완성해 나가는 방법론이죠. 이 애자일이라는 방법론 안에는 스크럼과 칸반이라고 하는 하위 방법론들이 있습니다.

이 두가지 방법론이 무엇인지는 이곳에서 확인하실 수 있습니다.

스크럼 방법론

스크럼 방법론이 적용된 프로젝트는 다음과 같은 프로세스를 가집니다.

1. 백로그에 이슈 만들기

백로그는 유저 스토리, 태스크, 버그로 구성됩니다.

우선, 프로젝트를 하면서 해결해야 할 이슈들을 정리해야합니다. 이슈는 다음과 같이 3카테고리로 나눌 수 있습니다.

1. 태스크
2. 버그
3. 유저 스토리 : 누가 왜 그 행위를 하는가?

여기서 유저 스토리는 사용자는(누가) 프로필 사진을 변경하기 위해(왜) 수정 버튼을 누른다.(행위)
와 같이 정의되어야 합니다.

이렇게 정의한 이슈를 백로그에 적습니다. 백로그란 할일을 포스트잇으로 정리해서 칠판에 붙인다고 생각하면 됩니다.

백로그에 이슈들이 정리되었으면 이제 스프린트가 시작됩니다.

2. 스프린트 플래닝 미팅

새로운 스프린트를 시작하기 전에, 백로그에 쌓인 이슈들에 대해서 스토리 포인트를 예측해야 합니다. 각 이슈가 얼마나 걸릴지 대충 예측하는것이죠. 몇일 몇주 몇개월이 걸릴것 같다고 예상하는게 아니라 스토리 포인트로 예측합니다.

예를들어서, 30분동안 해결할 수 있을만한 문제를 1 스토리 포인트로 정의 해볼수 있습니다. 이런건 팀에서 상황에 맞게 정하면 됩니다.

이 스토리 포인트 미팅은 다음 프로세스로 진행 됩니다.

1. 스크럼 구성원들이 모두 미팅에 참여 합니다.
2. 이슈를 등록한 사람이 해당 이슈를 간략하게 설명하고, 이슈 담당자를 다같이 정합니다.
3. 모든 이슈에 대한 담당자가 정해졌으면 각 이슈에 대한 스토리 포인트를 예측하고 팀원들에게 자신의 스토리 포인트를 동시에 공유합니다. 그렇게 모든 이슈에 대한 스토리 포인트를 산정하고,
4. 그 스토리 포인트를 기준으로 스프린트 기간을 산정합니다.

스프린트 기간 산정은 이렇게 합니다. 스크럼 팀에 A, B, C, D 4명의 개발자가 있는데 A와 B는 하루에 10 포인트 C와 D는 5 포인트를 처리할 수 있다고 해봅시다. 그럼 이 팀의 하루 처리 포인트는 30포인트입니다.

만약 백로그에 있는 이슈들의 스토리 포인트의 합이 240인경우,
스프린트 기간은 240/30 = 8일이 됩니다.

3. 스프린트 시작하기

스프린트가 시작되면 백로그에 있는 이슈들을 In Progress로 이동시킵니다. 이제 남은 기간동안 본인에게 할당된 이슈들을 처리 하면 됩니다. 그리고 매일 아침 15분동안 간단하게 데일리 미팅을 갖습니다. 이 미팅에서는 어제 뭐했고, 오늘 뭐할거고, 어떤 이슈가 있었다 와 같은 진행사항을 간단하게 공유하는 자리입니다. 이 미팅을 통해 팀원들이 겪고 있는 어려움이나 해결방법들을 서로 공유하고 도울 수 있습니다.

이슈들은 Backlog -> Ready -> In Progress -> Review -> Done 총 5가지 상태를 거쳐 완료되게 됩니다.

4. 스프린트 종료 및 반복

스프린트가 종료되면 이번 스프린트 기간 동안 있었던 일들에 대해 리뷰를 해야 합니다.

1. 스프린트 기간 동안 모든 이슈를 해결했는가?
   정말 불가피한 일들을 제외하고는 모든 이슈 해결을 전제로 합니다.
2. 스프린트 기간 동안 이슈가 추가되거나 제거 됬는가?
   스프린트 중간에 이슈 변동은 최소화 해야 합니다.
3. 예측한 스프린트 기간이 얼마나 잘 예상 되었는지?
   이슈의 스토리 포인트가 예상보다 빠르거나 느렸다면 다음엔 그러지 않도록 주의합니다.

+) 스크럼 관리 도구 (지라)

지라를 통한 스프린트 관리

애자일은 만능이 아니다.

애자일이 폭포수 보다 절대적으로 뛰어나진 않습니다. 아래와 같은 단점들이 존재합니다.

• 급한 이슈에 대해서 유연하지 않음 : 스프린트 기간 동안은 이슈의 변동이 최소화 되어야 합니다. 하지만 이 문제는 스프린트 기간에 이런 갑작스러운 이슈에 대응하기 위한 추가 기간을 삽입해서 해결 할 수 있을것입니다.
• 스토리 포인트 예측의 어려움 : 스토리 포인트를 정확히 예측해서 깔끔하게 스프린트가 마무리 되게 하기가 어렵습니다. 한번도 개발해본적 없는 기능을 개발하다보면 실제보다 더 오랜 기간이 걸리는 경우가 허다합니다.
• 애자일 방법론 자체에 많은 준비 시간이 소요됨 : 스프린트 플래닝 미팅에서 팀원 모두가 이슈에 대해 논의하고 각 이슈에 대한 스토리 포인트를 합의해야합니다. 이런 과정이 많은 시간을 잡아먹습니다.
• 인원이 많아지면 비효율적임 : 소수의 팀원들이 끈끈하게 커뮤니케이션 할 때 스크럼의 장점이 극대화 됩니다. 5명 전후의 팀원이 가장 이상적이고 10명이 넘어가면 오히려 좋지 않다고 합니다.

애자일은 이상적인 상황에서 아주 효율적으로 동작하지만 잘 적용하지 않으면 오히려 해가 될 수 있습니다.

출처

https://wormwlrm.github.io/2018/09/09/Scrum-tutorial-for-adapting-agile-methodologies.html