Agile 프로젝트 퀵가이드(12) : Execution & Control편-스프린트리뷰

스프린트 리뷰란 ?

스프린트 리뷰는 스프린트 종료 시점에 목표를 달성했는지 스프린트의 작업 결과물을 확인하는 회의입니다.
스크럼에서는 스프린트별로 완료되는 제품 기능을 “제품 증분”이라고 표현하는데, 스프린트 리뷰에서 개발팀과 제품 책임자는 이번 스프린트에서 무엇이 완료되었는지 제품 증분에 대해 함께 확인하고 이에 대한 피드백을 받습니다.
“함께 확인”한다는 말은 실제 동작하는 제품의 기능을 시연하는 것을 의미합니다. 이 미팅에는 스크럼 팀 외에 제품에 대한 이해관계자를 초청하는 것이 필요할 수 있으며, 제품 이해관계자들로부터 제품 기능에 대해 “완료조건(DoD : Definition Of Done)”이 충족되는지를 검토하고 피드백을 받을 수 있어야 합니다.

스프린트 리뷰 준비

스크럼 마스터는 스프린트 리뷰 회의가 잘 진행될 수 있도록 다음의 절차대로 진행합니다.

1) Review 환경 준비

스프린트 리뷰 회의시간은 스프린트 길이에 따라 2~4시간 정도를 권장합니다.(길이가 4주일 경우 4시간) 스프린트 리뷰는 일관된 날짜에 진행할 수 있도록 사전에 계획하는 것이 바람직하며, 특히 리뷰에 필요한 참석자들이 리뷰 미팅에 참여 가능하도록 우선적으로 시간을 배려하여야 합니다. 또한 회의실의 크기가 참석자들을 충분히 수용할 수 있는지, 원격 참여일 경우 필요한 장비가 구비되었는지 미리 확인해 두는 것이 좋습니다.

2) Review에 사용할 자료 준비

스크럼 마스터는 리뷰의 진행과 필요한 역할을 조율하며 주관하는 책임이 있습니다. 팀원들과 함께 안건을 정리하고, 결과물을 누가 어떻게 선보일지 논의하십시오.
리뷰에 보통 쓰이는 자료들은 스프린트 백로그(사용자 스토리 목록), 개발 결과물(동작하는 S/W 기능) 등이며, 데모 순서에 따라 제품이 시연될 수 있도록 환경을 준비하며, 참여자의 피드백을 적을 수 있는 시트 양식 등을 준비해 놓습니다.

3) Sprint Review 회의 공지

고객 및 시스템 유관 조직에 일자, 장소, 데모할 기능(사용자 스토리)를 컨플루언스나 이메일을 통하여 미리 공지합니다. 참여 가능한지 확답을 받아 두십시오.

제품 시연 및 피드백

제품 시연은 스프린트의 목적이 달성되었음을 검토하고, 고객으로부터 제품의 가치에 반영할 만한 피드백을 받을 수 있는 자리입니다. 스크럼 마스터는 시연을 통해 필요한 피드백을 충분히 얻을 수 있도록 참석자에게 이번 스프린트의 개요를 간결하게 설명하고, 다음의 절차대로 진행합니다.

1) 완료된 제품 기능의 동작을 시연

• 개발팀은 고객 비즈니스 관점에서 쉽게 기능을 검토할 수 있도록 비즈니스(업무) 흐름을 기반으로 제품 기능을 시연합니다.
• 시연은 고객과 이해당사자 중심으로 진행하지만 실 사용자 그룹을 별도로 선정하여 데모 후 테스트에 참여시키면 더 효과적일 수 있습니다.
• 시연시 제품 아키텍쳐를 간략한 다이어그램으로 보여주거나, 기술 아키텍쳐와 기능 아키텍쳐를 함께 보여주어 제품 관계자의 이해를 돕습니다.
  

2) Sprint 목표 검증

• 스프린트 목표와 제품 백로그(사용자 스토리)를 실제 개발 결과와 비교해서 그 차이점을 논의합니다.
• 제품 증분 데모(시연)을 통해, 해당 제품 증분의 강점/약점, 팀이 겪은 난관/성공이 충분히 논의되도록 합니다.
  

3) 피드백 받기

• 스프린트 리뷰시 나온 의견을 피드백 결과서로 작성하여 고객과 공유합니다.
• 제품에 반영해야 할 피드백은 다음 스프린트 계획 수립에서 참고합니다.
  
  

스프린트 리뷰 주의사항

스프린트 리뷰 수행시 다음과 같이 되지 않도록 주의해야 합니다.

1. 2시간 이상 준비하지 말 것, 슬라이드 금지

• 회의 준비에 2시간 이상이 소요되지 않도록 한다. 2시간 이상 준비해야 하면, 보여줄 것이 없는 것이다.
• PPT나 그 비슷한 것을 준비하지 않도록 한다. 중요한 것은 개발한 제품 그 자체를 보여주는 것이다.
• 스크럼 마스터나 제품 책임자가 시연하지 말 것
• 스프린트 리뷰의 핵심은 제품 데모이다. 따라서 스크럼 마스터, 제품 책임자보다는 제품 증분을 구현한 개발자가 시연하는 것이 좋다.
  

2. 불완전한 데모(구현 결과)를 보여주지 말 것

• 스크럼 마스터는 미완성된 기능이 스프린트 리뷰 시 시연되지 않도록 팀원들과 함께 데모 시나리오를 계획해야 한다.
• 데모는 고객이 원하는 가치를 전달하는 가장 중요한 활동이다. 사전에 내부 테스트를 수행하여 품질을 지키는 것이 중요하다.
  

3. 스프린트 리뷰를 두려워하지 말 것

• 담당자가 결함이 두려워 데모에 소극적이라면, 스크럼 마스터는 고객의 요구사항이 제대로 구현되었는지 여부를 검증 받는 것이 중요하므로 작은 결함은 크게 문제 되지 않는다고 설득해야 한다.
• 개발한 SW가 전반적으로 작동이 안될 경우, 스프린트 내에서 테스트 활동을 제대로 하지 않은 것이다. 이런 상황이 발생하면 반성의 기회로 삼으면 좋다.
  

4. 리뷰 is not 보고

• 스프린트 리뷰 회의는 제품 책임자와 함께 완료된 제품 기능을 검토하고 피드백을 받는 자리이지만, 스크럼 가이드북에서는 이를 비공식적인 미팅으로 간주하고 있다.
• 이는, 제품의 기능을 검토한다는 것은 제품 가치를 최적화하기 위해 완료된 기능은 무엇이고 다음에 무엇을 해야 할지 의논하는 목적을 가지며, 작업 진척을 보고하고 결과물을 평가하는 자리가 아니기 때문이다.
• 그럼에도 불구하고 스프린트 리뷰 회의는 평소에는 잘 만나지 않는 개발팀과 고객이 만날 수 있는 자리여서 그런지, 많은 프로젝트에서 기존의 주간보고나 정기 보고회를 대체하는 용도로써 사용하고 있다.
• 중요한 것은 공식/비공식 여부가 아니며 또한 작업의 진행 경과와 성과를 평가하는 목적이 아닌 제품에 대해 건전한 피드백과 협력을 촉진하기 위한 것임을 인지해야 할 것이다.
  
  

스프린트 리뷰에 대한 쟁점 사항들

스프린트 리뷰에 대한 몇가지 쟁점들이 있습니다. 이는 앞서 이야기한 스프린트 리뷰 절차와 위배되는 사항도 있는데, 필자의 경험상 아래에 소개하는 내용들이 실제에서 벌어지는 상황이며 현실적인 것들입니다.

1. 시연과 완료 선언
스프린트가 끝나가는 시점에서 스프린트 리뷰 회의를 통해 금번 스프린트에서 개발된 제품의 완성 여부를 시연을 통해 일일히 검토하고 확인하는 것은 시간적으로 충분하지 않을 수 있습니다. 사실, 스프린트 리뷰에서는 시연만이 목적이 되어서는 안됩니다.

백로그의 완료 여부를 결정하기 위해서는 스프린트가 진행하는 도중에 미리 제품 책임자에게 검토 요청을 하고 확인받는 것이 선행되어야 합니다. 또한 검토 요청을 하기 위해서 해당 기능이 테스트되어야 하겠지요.
미처 완성되지 않은 제품 기능을 시연을 목적으로 보여주려고 dummy코드를 만들거나 의도한 코드만 동작되도록 하기 보다는 백로그의 완료 조건에 부합하도록 기능을 완료시키는 것이 우선의 목적가 되어야 합니다.

하지만, 많은 프로젝트에서 시작 초반부터 1주기의 스프린트 기간 안에 백로그 테스트까지 완료하기란 쉽지 않을 것입니다.
따라서, 스프린트 앞 부분에서는 고객 가치에 부합되며 빠르게 완료할 수 있는 일, 프로젝트 초반에 미리 결정되어야 할 중심으로 백로그를 완성시키고자 하는 스프린트 계획 수립이 필요합니다. 스프린트 계획이 전략적으로 잘 세워져야 스프린트 내에 백로그 완료가 가능하며 리뷰 또한 원활하게 흘러게 되는 것입니다.

2. 리뷰 회의는 공식적 미팅인가
스크럼 가이드북에서는 스프린트 리뷰 회의를 비공식적인 미팅으로 간주하고 있습니다. 흔히 제품 기능의 완료를 공식적으로 획득하는 자리라고 생각하겠지만, 앞서 이야기하였듯 기능 검토를 통한 완료 승인은 리뷰 이전에 이미 획득되어야 합니다. 리뷰 회의에서는 제품 가치를 최적화하기 위해 완료된 기능은 무엇이고 다음에 무엇을 해야 할지 의논하는 목적을 가집니다.

또한, 작업 진척에 대한 상황 보고나, 결과물을 평가하는 자리가 아닙니다. 그럼에도 불구하고 스프린트 리뷰 회의는 평소에는 잘 만나지 않는 개발팀과 고객이 만날 수 있는 자리여서 그런지, 많은 프로젝트에서 기존의 주간보고나 정기 보고회를 대체하는 용도로써 간주됩니다. 개발팀 입장에서는 아직 제품의 기능이 완벽히 동작하지 않는 상태에서 리뷰 회의에 보고할 대용물로써 프로젝트 진척 상황을 보고하기도 하구요. 그러나 이와 같은 현황 보고는 SOS 미팅을 통해 이미 이루어졌어야 하는 것입니다. 중요한 것은 공식/비공식을 떠나, 애자일을 적용한다는 것은 있는 그대로 보여주고, 수시로 검토하고 확인하며, 더 나은 가치와 대안을 얻기 위해 건전한 피드백과 협력을 촉진하는 것임을 인지하는 것입니다.

3. 고객의 참석이 저조하다면
짧은 주기의 스프린트 종료시마다, 제품 책임자 및 제품 기능에 상당한 영향을 가지는 이해관계자를 초청하여 스프린트 리뷰를 진행하기가 쉽지 않습니다. 프로젝트 참여가 본인의 주 담당 업무가 아닐 경우, 시간을 내어 피드백을 주는 것은 그들의 우선순위에 있지 않습니다.
또한 실제 제품을 사용하는 고객 또는 제품 사용자들을 상대하는 최전선의 업무 담당자들이 제품 책임자로 선정되지 않기 때문에, 이들에게서 피드백을 얻는 것 또한 쉽지 않습니다. 실제 사용자들을 만날 수 있는 기회를 갖는 건, 통합테스트가 마무리되고 사용자 테스트를 할 때가 되기 마련이지요. 따라서, 애자일 프로젝트를 하려고 할 때에 거듭 강조하지만 제품과 관계 있는 고객의 주기적인 참여가 가능하도록 필요한 조치들이 미리 수반되어야 할 것입니다.

이상으로 쉬운 듯 하면서도, 어려운 스프린트 리뷰에 대해 마칩니다.

< EOF >