Agile 프로젝트 퀵가이드(7) : Starting편-의사소통 및 품질계획 수립
Updated:
스크럼 프로젝트의 관리 지표
스크럼 프로젝트에서 관리하는 주요 지표는 팀의 속도와 번다운 차트이다.
속도는 한 스프린트 당 완료되는 일감의 양으로 각 스프린트 끝에 완성된 제품 백로그의 크기를 합친 것입니다.(완료되지 않은 일감은 제외)
속도는 스프린트가 종료될 때마다 측정되어 남아있는 일감을 주어진 기간 안에 끝낼 수 있는지 진단하기 위해 사용됩니다. 팀의 속도가 예상보다 저조하다면 속도를 개선시키기 위한 변화를 고민해야 합니다. 또한 스프린트 회고와 지속적인 프로세스 개선을 통해 팀 속도가 향상되도록 팀원 모두가 헌신하는 노력이 필요합니다. 그러나, 지속적인 프로세스를 개선과 장애물 제거의 노력에도 불구하고 팀 속도가 더 이상 향상되지 않는다면 해당 수치가 그 팀의 최고 속도가 됩니다.
번다운 차트는 매 전체 일감의 크기와 매 스프린트 완료시 남아 있는 일감의 양을 계산하여 차트로 나타낸 것입니다. 프로젝트 초반에 팀 속도 예상치를 가지고 계산한 baseline 목표와 실제로 스프린트 완료시 측정된 값을 비교함으로 목표에 얼마나 근접한지를 시각적으로 판단할 수 있습니다.
- [ 번다운 챠트 예시 ]
번다운 차트에서 잔여 일감과 함께 관리해야 할 항목은 전체 일감의 양입니다. 초반에 도출된 전체 백로그의 일감 양은 시간이 지나감에 따라 증가될 소지가 높습니다. 팀의 최고 속도에도 불구하고 잔여 일감이 줄어들지 않는다면, 전체 일감이 늘어났을 가능성이 크다는 이야기지요. 그리고 스프린트마다 팀이 전력질주를 하더라도 잔여 일감 목표치를 달성하지 못하는 실패를 경험하게 될 수 있습니다. 이 경우 잔여 목표를 맞추기 위해 초과 근무 등이 발생하며 이러한 현상이 반복된다면 팀은 번아웃되어 버릴 것입니다.
결과적으로 전체 일감의 양이 늘어나는 현상을 감지하기 위해서는 번다운 차트를 관리해야 합니다. 무엇보다 근본적인 전체 일감의 양이 팀 속도와 역량을 넘어서지 않는 범위 안에 속하도록 백로그에 대한 관리를 해야 합니다. 또한 이는 프로젝트 관리자만의 책임이 아니며 제품 관리자와 스크럼 팀간 상호 이해와 협력을 바탕으로 한 공동의 책임을 필요로 합니다.
- 일감 양
- 속도 측정 및 번다운 차트의 잔여 일감 양을 위해서는 제품 백로그의 일감 크기가 추정이 되어 있어야 하지만, 일감 크기 추정 작업을 보통 Skip하는 경우가 많으므로, 일감 크기 대신 일감 개수로 산출하기도 한다.
- 이 때, 각 일감의 크기는 편치가 크지 않는 고른 값을 갖고 있어야 할 것이다.
스크럼 프로젝트의 의사소통 관리
프로젝트에서의 의사소통은 크게 2가지로 분류할 수 있습니다. 진척 및 상황 관리를 위한 이해관계자와 주기적인 소통, 그리고 개발과 관련된 팀원간 소통이 있습니다. 보통은 진척 및 상황 관리를 위한 부분만 의사소통 계획 수립을 합니다. 특히 Weekly/Monthly Report 등의 주기적인 보고와 중간보고, 단계별 완료 보고 등 고객사를 위한 회의 위주로 되어 있습니다. 그 외에 baseline에 대한 변경을 검토하는 변경관리 미팅(물론 잘 이루어지지 않지만), 그 외에 위험/이슈 미팅 등이 추가로 계획할 경우도 있습니다.
이에 반하여 스크럼 프레임워크에서는 4가지 형태의 Communication 방법을 제안하고 있습니다. 일일 스크럼(Daily Scrum)과 스크럼 계획 미팅, 스크럼 리뷰와 회고 미팅이 있습니다. 그리고 스크럼팀이 여러 개인 경우, 팀간 소통을 위하여 SoS 미팅(Scrum-Of-Scurm)이라는 확장된 스크럼 미팅이 있습니다.
아래의 표는 스크럼 Communication 방식을 사용하여 기존 의사소통 대체하여 계획을 수립할 수 있음을 예시로 보여줍니다.
기존에 고객과 가졌던 주기적인 보고는 스크럼 리뷰 미팅으로 대체될 수 있으며, 수치에 치우친 보고보다 스프린트에서 계획되었던 스프린트 백로그가 완료되어 실제적으로 동작하는지 여부를 확인하는 과정을 가집니다.
- Weekly / Monthly를 없앤다면 진척 보고는 어떻게 해야 하나?
- 기존의 보고 방식은 이번주에 계획된 목표와 실적을 비교하고 Gap은 얼마이고, 증감량이 어떻게 되는지 등의 숫자에 얽매어 있었다. 이 방식은 수치를 gathering하고 계산하기 위해 적잖은 Effort가 들뿐더러, Gap이 발생한 실제 원인일 분석하여 해결하기 보다는 숫자 가리기나 현실적이지 않은 Catch-up 방안을 수립하여 또다시 보고에 얽매이는 악순환이 발생되게 한다.
- 스크럼 프로젝트의 관리 지표에서 언급했듯이, 스크럼 프로젝트의 진척율 관리는 번다운 차트로 충분하다.
- 스크럼 리뷰 회의시 번다운 차트를 보고하여 전체 진행상황을 제품책임자 및 참여자에게 모두 공유하는 것이 좋다.
- 단, 번다운 차트는 상시 관리되는 것이 좋다. 팀원들이 JIRA와 같은 도구를 통하여 Daily로 일감 상태를 업데이트하고 있다면 번다운 차트 또한 매일 업데이트가 가능하다. 만약 프로젝트가 계획대로 가고 있지 않다면 SoS 미팅에서 번다운 차트를 미리 공유하여 리뷰 미팅시 논란이 되지 않도록 하게 하자..
현재 포스팅은 스크럼 프로젝트 시작 단계에서 해야 할 의사소통 계획 부분을 다루고 있기 때문에 실제 각 미팅에서 의사소통을 어떻게 하는지에 대한 세부적인 내용은 실행 편에서 다루고 이정도에서 마치겠습니다.
스크럼 프로젝트의 위험/이슈 관리
[ SOS(Scrum-Of-Scrum) 회의체 구성 ]
프로젝트 위험과 이슈는 SoS 회의체를 구성하여 SOS 회의에서 논의하는 것이 좋습니다. SOS 회의체는 스크럼팀간 의사소통 및 위험/이슈 공유를 위한 것으로 스크럼 마스터, 개발리더 경우에 따라서 제품 책임자 및 해당 어젠다와 관련 있는 이해관계자를 포함하는 Virtual한 회의체입니다.
SOS의 어젠다는 스크럼 팀이 Daily Scrum에서 식별된 위험 요소, 장애물이 될 수 있습니다. 따라서, SOS 미팅은 가급적 스크럼 팀별 Daily Scrum 미팅이 끝난 시간 이후에 시작할 것을 추천합니다. Daily Scrum과 SOS 미팅을 통해 자연스럽게 어젠다를 공유하면서 위험/이슈가 드러나게 됩니다.
SOS 미팅은 정기적으로 주 1회 이상 실시하도록 하며, 프로젝트 초반이나 위험/이슈가 많은 경우 또는 해결해야 할 이슈가 급박한 경우, 즉시 소집될 수 있도록 계획합니다.
[ 위험/이슈 추적 및 Action Item 관리 ]
SOS 미팅을 통해 바로 장애물에 대한 해결책이 논의될 수도 있지만, 추가적인 작업과 시간이 소요된다거나 모니터링이 필요하다면 이를 위한 추적관리가 필요합니다. 이 부분은 일반적인 프로젝트 관리 기술과 같다고 볼 수 있겠죠. 위험/이슈인지 여부가 판단되었다면 SOS 회의록과 함께 위험/이슈 항목과 및 Action Item 등을 기록으로 남겨 추적관리가 되도록 합니다.
위험/이슈와 Action Item 등은 기존의 Word나 엑셀과 같은 고정된 양식의 문서 형태보다는 컨플루언스 또는 JIRA와 같은 도구를 사용하여 보다 효과적으로 관리할 수 있다습니다.
이제 다음 Staring 퀵가이드 마지막 편에서는 컨플루언스 / JIRA 도구를 활용한 효율적인 스크럼 환경을 만들어보도록 하겠습니다.
< EOF >