초보 애자일 코치의 좌충우돌 코칭 경험기 - 5

Updated:

PM, 스크럼 마스터와 협의하여 프로젝트의 스프린트 주기는 2주로 결정하였다.

초보코치는 애자일 문화가 정착될 수 있도록 아침에는 스크럼 팀의 Daily Scrum 미팅에 참여하고 스크럼 마스터들과 팀원을 코칭했다.

애자일로 프로젝트를 하게되면, 주간보고는 어떻게 될까?

Scrum of Scrums

SI프로젝트의 경우 매주 주간보고가 있다. 초보코치는 기존의 주간보고 보다는 Scrum of Scrums 라는 회의로 대체하기로 했다.

Scrum of Scrums 는 스크럼팀 간의 이슈나 공통으로 해결해야 될 이슈에 대해서 얘기하는 회의로서, 기존의 주간보고와는 다음과 같이 다르다.

기존의 주간보고는 일정, 진척율, 이슈에 관해 주로 PM이 보고를 했다면, Scrum of Scrums 는 팀 간에 있는 이슈를 기록하고 추적하고 관리한다. 또한, PM 이 발언하기 보다는 Scrum Master 들이 주로 Scrum 팀 내에서 해결하지 못하는 이슈 위주로 발언하도록 한다.

다음은 추적되는 Scrum of Scrums 항목이다.

  • 이슈내용
  • 제기자
  • 담당자
  • 완료요청일
  • 상태(완료여부, 미완료)
  • 미완료누적

해당 내용은 스프린트 기간 내에 수시로 현행화해서 투명성과 민첩성을 높인다.

다음 Scrum of Scrums 를 할 때, 지난 주에서 미완료 된 이슈항목만 복사해서 “미완료누적” 열에 표시를 하고 최우선 적으로 처리하도록 노력한다. 그 다음 스프린트에서도 완료가 안되었다면, 미완료누적에 표시가 두 개로 늘어날 것이다.

출처:https://ichi.pro/ko/seupeulinteu-libyu-silhaeng-bangbeob-202825207700741

스프린트 리뷰

스프린트 리뷰란?

스프린트가 완료되면 스프린트 리뷰를 수행해야 된다. 스프린트 리뷰는 애자일 활동에서 매우 중요한 활동으로서 고객에게 전달한 가치 (그것이 프로그램이 되었던, 화면이 되었던…) 에 대해 피드백을 받는 시간이다.

참여자는 스크럼 팀, 스크럼 마스터, PO 이며 짧게는 2시간에서 반나절 정도 스프린트 마지막 날 또는 마지막 하루 전날에 수행할 수 있다.

스프린트 리뷰 진행 및 역할

스크럼 팀에서는 스프린트 기간동안 작업한 데모를 준비해야 된다. 리뷰는 문서로 보고하는 주간보고가 아니며, 이는 애자일 핵심가치에도 어긋난다. 실제 동작하는 소스를 가지고 고객에게 피드백을 받아야 한다.

또한, 스크럼 마스터가 진행을 하겠지만, 실제 화면이나 동작하는 소스코드를 설명할 때는 실제 개발한 개발자가 설명하는 것이 좋다. 직접적인 설명이 가지는 장점은 PO 와 직접적인 커뮤니케이션을 통해 의사소통 비용을 줄이고, 개발팀에 성취감이나 자부심을 느끼게 할 수 있다.

PO는 무엇을 해야 될까? 2시간 또는 반나절 동안 스프린트 기간 내 개발한 모든 것을 확인하는 것은 쉽지 않다. PO 는 리뷰 때 그것을 확인하는 것이 아니라 스프린트 기간 동안 스크럼 팀에서 개발한 내용을 미리 확인하고, 실제 리뷰 시간에는 본인이 중점적으로 질문하거나 피드백 줄 결과물에 대해서 리뷰를 해야 된다.

이렇게 하기 위해서는 투명한 일감관리가 전제가 되어야 하며, 스토리 완료에 대한 기준 (Definition of Done) 이 명확해야 된다. DoD 가 명확하지 않을 경우 품질이 떨어질 수 밖에 없으며, 이것은 결과적으로 PO 와 스크럼 팀간의 신뢰에 영향을 끼치게 된다.

다음 작업

스프린트 리뷰에서 나온 피드백을 기준으로 다음 스프린트의 계획을 세운다. 원래 계획했던 일감들이 없어지거나 뒤로 밀리기도 하고, 뒤에 있던 일감이 PO 의 피드백에 따라 앞으로 배치될 수도 있다. 스프린트 리뷰에서 완료가 안되거나 수정이 필요한 스토리의 경우 다음 스프린트 또는 Clean-up 스프린트에서 해소하도록 한다.

  • 초보 코치의 느낌점
    • Scrum of Scrums 는 PO, PM, Scrum Master 들이 참여하지만, 필요에 따라서 개발과 관련된 이슈만 논의하는 회의를 개설하는 것도 코치는 고민해 볼만 하다. Scrum of Scrums 가 규모가 커지고, 참여자가 많아지면 개발 외에 프로젝트 관리, 비즈니스 같은 다양한 이슈가 논의될 수 있으며 이러할 경우 시간에 쫓겨 개발관련 이슈는 묻힐 수 있다. 따라서, 상황에 따라 개발관점에서의 Scrum of Scrums 를 만들어도 효과가 좋다.
    • 스프린트 리뷰에서 데모가 목적이 되어서는 안 된다. 완료 기준을 달성하고 피드백을 받기 위한 목적이며, 이러한 활동의 최종 목적은 결국 변화에 적응하기 위함이다.
    • 스토리에 따라 처음부터 완벽한 완료기준을 가질 수 없는 경우도 있다. 따라서, 스프린트 계획을 수립할 때 완료기준이 명확한 일감부터 앞쪽에 배치해야 된다. 또한, 스토리를 도출할 때 INVEST 중 I(Independent – 독립적이다)를 기억할 것이다. 독립적인 스토리와 적절한 스프린트 계획이 선행되어야 스프린트 리뷰에서 원하는 목적을 달성할 것이다.
    • 완료기준은 때때로 PO와의 협의가 필요할 수 있다. 예를 들어, UI 기획자가 아직 투입이 안되었는데 화면의 디자인까지 완료기준으로 삼는다면 해당 스토리는 완료할 수 없을 것이다. 이러한 제약사항을 고려하여 완료기준을 세울 때 A 스프린트까지는 Backend 기능을 완료기준으로 하고, B 스프린트에서는 UI 를 포함하여 완료기준으로 삼을 수도 있을 것이다. 즉, 완료기준을 어디에 두는지에 따라 해당 스토리는 한번에 끝나지 않을 수도 있다. SI 프로젝트의 경우 오픈 전 몇 개의 스프린트는 통합테스트만을 위한 스프린트로 계획을 세울 수도 있다.

Related Posts :


< EOF >