나는 이번 프로젝트에서 스크럼을 제대로 써보고 싶다!
나를 포함한 우리 팀원 전부 스크럼에 대한 이해를 높이기 위해 스크럼(Agile Software Development with Scrum) - 켄 슈와버, 마이크 비들 을 읽었다. 아직 나처럼 스크럼을 잘 모르는 사람이라면 혹은 제대로 알고 싶다면 이 책을 읽어보기를 추천한다.
이 글은 스크럼을 도입하기 전에 꼭 알아야 하는 개념을 위 책을 바탕으로 정리한 글이다.
스크럼
스크럼은 애자일 프로젝트 관리 프레임워크이다. 스크럼을 도입한다는 것은, 다음과 같은 의미이다.
- 어떤 작업을 어떻게 할지 팀이 직접 정한다.
- 여러 잡음에서 벗어나서 스프린트를 통해 가장 우선순위가 높은 일부터 해결한다.
- 일일 스크럼을 시행하여 팀원들과 이슈를 공유하고 서로 도와주고 감시한다.
- 스크럼 팀은 과정이 아니라 결과로 평가 받는다.
- 팀이 경험을 통해 계속 배우고, 지속적으로 개선하도록 유도한다.
스크럼을 제대로 이해하기 위한 핵심 개념들을 하나씩 살펴보자.
제품 백로그
제품 백로그는 제품을 만들기 위한 일들을 우선순위에 따라 나열한 것을 말한다.
꽤나 평범해 보이는 이 제품 백로그는 어째서 등장하게 된 것일까?
어떤 팀은 개발을 하는 도중에 계속해서 이 기능을 만들다 저 기능을 만들다 결국, 하나에 집중하지 못해 생산성이 떨어진다. 개발팀은 원해서 여러 잡음에 휩쓸리는 것은 아니다. 이러한 일들이 생기는 이유는 회사의 경영진이나 관리자 혹은 친근한 팀 동료들이 개발자들에게 직접 가서 ‘이 기능도 추가해주세요’ 라고 쉴틈 없이 요청하기 때문이다.
제품 백로그는 단 한명만 작성할 수 있다. 바로 제품 책임자(Product Owner)이다. 제품 백로그가 있는 한 그 누구도 직접 개발자에게 직접가서 ‘이 기능도 추가해주세요’라는 말 할 수 없다. 그리고 개발자들은 이 제품 백로그에 있는 일만 할 수 있다. 제품 백로그라는 장치를 통해 개발자들은 잡음으로부터 해방될 수 있다.
제품 백로그의 특징을 다시 정리하자면,
- 제품 백로그는 제품을 만들기 위한 일을 우선순위에 따라 나열한 것이다.
- 제품 백로그는 제품 책임자만 작성할 수 있다.
- 어떤 기능, 일을 추가하고 싶으면 제품 책임자를 설득해야 한다.
- 개발자들은 제품 백로그에 있는 일을 한다. → 스프린트
일일 스크럼
소프트웨어 개발은 엄청난 의사소통을 필요로 하는 복잡한 프로세스다.
팀에게 있어서 일일 스크럼 회의는 의사소통의 장이다.
일일 스크럼은 매일 정해진 시각에 정해진 시간동안 3가지 사항에 대해 공유하는 회의다.
- 지난 일일 스크럼 이후로 무엇을 했는가?
- 지금부터 다음 일일 스크럼까지 무엇을 하려고 하는가?
- 업무를 하는데 무엇이 방해되는가?
일일 스크럼의 특성은 몇가지 더 있다.
스크럼 마스터
스크럼 마스터는 팀이 스크럼을 잘 활용할 수 있게 관리하는 역할이다. 스크럼 마스터는 팀원들이 일일 스크럼에 꼭 참여하도록 유도하고, 일일 스크럼의 진행도 맡는다. 뿐만 아니라 스크럼 마스터는 팀의 업무 효율, 생산력 증가를 위해 ‘무엇이든’ 할 수 있는 사람이다. 스크럼 팀에는 무조건 스크럼 마스터가 있어야 하고 트러블 슈팅이 가능해야 하므로 전문성이 높은 사람이 맡는다.
시간 준수
일일 스크럼은 정해진 시간이되면 시작한다. 몇몇 인원이 늦더라도 스크럼은 시작된다. 그리고 스크럼 마스터는 팀원들의 일일 스크럼 지각 및 결석을 예방하기 위해 벌칙이나 벌금을 정하기도 한다.
일일 스크럼은 짧은 시간동안 진행하는 것이 좋다. 일의 설계에 대한 얘기를 하거나 혹은 문제를 직접 해결하려 하면 안된다. 그런 얘기는 다른 회의를 추가적으로 열어서 해야하는 것이다. 팀원들이 스크럼의 시간을 예측불가능하다고 생각하게끔 만들면 안된다.
스크럼 참관
스크럼은 스크럼 팀 외부의 사람 예를들어 회사의 관리자들도 참여할 수는 있다. 이들이 참여할 수 있는 이유는 스크럼 팀이 제대로 프로젝트를 진행하고 있는지 확인할 수 있어야 하기 때문이다. 다만 스크럼에 참관하는 인원은 최소화해야 한다. 왜냐하면 일일 스크럼은 항상 팀원들이 솔직하게 정보를 공유할 수 있는 자리여야 하기 때문이다.
발언권
일일 스크럼회의에서 팀 외부의 사람은 발언을 해선 안된다. 스크럼 시간이 변질되거나 시간이 지체될 수 있기 때문이다. 혹시나 참관자가 발언을 한다면 스크럼 마스터가 제지해야 한다. 아무리 그 사람이 회사의 경영진이어도 말이다.
장애 요소 식별
스크럼 마스터는 팀원들이 일일 스크럼 시간에 말하는 업무에 방해되는 요소들을 정리하고 빠르게 해결해줄 필요가 있다. 만약 이것이 바로 해결되지 않는다면 해당 팀원은 다음날 일일 스크럼에서 또 같은 장애를 말할 것이다. 다음날 말하지 않는다면 그것은 더 큰 문제이다. 팀원은 스크럼 팀 및 스크럼 마스터가 장애 요소를 잘 해결해주지 못한다는 생각을 갖게 될 것이며 앞으로 장애 요소를 말하길 꺼려하고 직접 해결하려 할 것이다. 어떠한 이유로든 장애 요소를 제거하지 못한다면 스크럼 마스터는 다음 일일 스크럼에서 이 사실을 보고해야 한다.
의사결정
어떤 팀원들은 미결정사항을 장애물로 여길 수 있다. (예를 들어 “이걸 해야할지, 저걸 할지 모르겠다”) 이럴 경우 스크럼 마스터는 가능하다면 즉시 결정을 내릴 책임이 있다. 다만 스크럼 도입 초반에 스크럼 마스터가 팀의 너무 많은 결정을 내리지 않도록 주의해야 한다. 대부분의 팀에서 혹은 조직에서 직접 의사결정하는 것에 낯설기 때문에 발생하는 일이며, 스스로 결정할 수 있게 도와야 하기 때문이다. 때때로 팀은 어떤 결정이 위험하거나 민감한 사항이라고 생각될 때 다른 누군가가 대신 결정해줄 것을 요청한다. 이 경우 스크럼 마스터는 팀과 함께 일일 스크럼이 끝난 후 결정을 내린다. 확신을 갖기 위한 정보가 부족하다면 최대한 빠르게 입수해야 하고 대부분의 경우 재빠른 결정이 다른 누군가가 결정해주기를 기다리면서 일을 뭉개고 있는 것 보다 낫다. 왜냐하면 팀은 다른 누구보다 무엇이 좋은 대안인지 잘 알고 있기 때문이다.
스프린트
개발팀은 스프린트라고 불리는 한정된 기간 동안 일을 한다.
스프린트는 목표를 향해 전력질주하는 한 번의 반복 주기이다. 팀은 스프린트 기간동안 어떠한 방해도 받지 않고 목표 달성에 집중한다.
스프린트의 기간을 30일로 잡았을 때, 팀은 30일 동안의 목표를 백로그에서 선택한다. 팀은 이 때 정한 목표를 수행하기 위한 일만 할 수 있으며, 그 방식은 어떤 방식으로도 가능하다. 어떤 기능도 스프린트 도중에 새롭게 추가할 수 없으며 제품 백로그에 추가된 후 다음 스프린트를 기다려야 한다. 대신 팀은 스프린트 주기마다 결과물을 내놓아야 한다.
스프린트 계획
스프린트의 계획은 두번의 회의를 통해 정한다.
-
제품 책임자(PO), 관리자, 사용자를 만나 다음 스프린트에서 무엇을 개발할지 정한다.
이전 스프린트의 종료 시점에서 있었던 결과물을 바탕으로 제품 백로그에 어떤 변화가 적당한지 토론하고 수정한다. 다음 스프린트 동안 개발 가능하다고 믿는 것들을 제품 백로그에서 선별한다.
-
팀이 직접 어떤 방식으로 개발할지 정한다.
스프린트 목표에 맞게 스프린트 백로그를 정의한다. 스프린트 백로그는 제품 백로그와는 다르게 상세한 태스크들의 목록이다. 각 태스크는 대략 4시간에서 16시간 안에 완료할 수 있을 만큼 충분히 자세하게 명시되어 있어야 한다. 스프린트 백로그는 일부밖에 작성할 수 없을 때 많다. 팀은 스프린트 백로그를 스프린트 기간 내내 수정한다. 스프린트 기간동안 팀은 예상보다 태스크가 많다는 것을 혹은 적다는 것을 알게된다.
잡음 제거
스프린트 기간 동안 팀은 자유롭게 방임된다. 팀 외부의 어느 누구도 팀이 스프린트 동안 하고 있는 업무의 범위나 성격을 바꿀 수 없으며 새로운 기능이나 기술을 추가해서도 안된다. 업무 방식에 대한 간섭도 금지된다. 팀은 스스로 판단하기에 적합하다고 생각하는대로 행동할 권리가 있다.
방임에 대한 위험성
스프린트 기간 동안 팀을 방임해야 한다는 사실에 관리자들은 위험하다고 생각할 수 있다. 과연 그럴까?
- 관리자는 가능한 최고의 사람들을 팀에 배정했다.
- 일일 스크럼에 참여하여 매일 팀의 업무 보고를 들을 수 있다.
- 팀이 하려고 하는 일은 스프린트 목표와 제품 백로그에 정의되어 있다.
- 최악의 경우 달력상의 30일(스프린트 기간)을 낭비하는 것에 지나지 않는다.
스프린트는 직원들이 할 일이 무엇인지 알고 그것을 해낼 수 있다는 것을 놓고 관리자와 내기를 하는 것과 같다.
스프린트 검토
팀은 스프린트 기간이 끝난후 관계자들(관리자, 고객 등)에게 결과를 발표해야 한다. 결과물을 보여주고 스프린트 목표를 얼만큼 달성하였는지 검토한다. 관계자들과 팀 내부에서 이번 스프린트 과정을 검토하여 무엇을 잘했고 무엇을 못했는지 그리고 어떤 기능이 추가되면 좋을지 얘기한다. 이 단계에서 더 나은 다음 스프린트를 위해 스크럼 방식을 팀에 맞게 커스텀할 수 있다. (스프린트 기간 등) 특히 처음 스크럼을 도입한 팀은 스프린트 검토 단계를 잘 활용해 팀에 적절한 스크럼 방식을 찾아가야 한다.
스크럼 실천하기
스크럼은 다음과 같은 순서로 시행하면 된다.
- 스크럼 마스터, 제품 책임자(PO) 선정
(반복)- 제품 백로그 작성
- 스프린트 계획
- 스프린트 + 일일 스크럼
- 스프린트 검토
(반복)
