Atlassian의 스프린트 리뷰를 소개합니다
Atlassian의 스프린트 리뷰 소개
- Dan Radigan 글, 시니어 애자일 전도사
- JIRA, JIRA Agile
- 2015년 2월 4일
이 기사는 애자일 의식 시리즈의 세번째입니다. 저희가 어떻게 스프린트 계획(sprint planning)과 스프린트 회고전(sprint retrospectives)을 하고 있는지 확인해 보세요.
금요일 늦은 저녁, Atlassian 사무실 도처에서는 박수와 함성 소리를 들을 수 있습니다. 여기서 저희는 열심히 일하고, 열심히 놀고, 스프린트 리뷰라는 형태로 성공을 축하합니다.
스프린트 리뷰는 회고전이 아닙니다. 스프린트 리뷰란 디자이너, 개발자, 제품 책임자로 이루어진 전체 팀의 노고를 보여주는 것입니다.
Atlassian에서는 캐주얼한 스프린트 리뷰를 지향합니다. 팀 구성원들은 비공식적인 시연을 보기 위해 책상 주위에 모이고 그 반복 주기(iteration)에 그들이 한 일을 설명합니다.
스프린트 리뷰는 질문을 하는 시간이자 새 기능을 시험해보고 피드백을 주는 시간입니다. 성공을 공요하는 것은 애자일 팀을 구축하는 중요한 한 부분입니다.
스프린트 리뷰로 들어가기 전에, 왜 팀의 '완료' 정의가 애자일 의식에서 그토록 중요한지 먼저 알아봅니다.
스텝 1: ‘완료(done)’ 정의하기
JIRA의 보통의 사용자로서, 작업(task)을 '진행 중'에서 '완료'로 옮기는 것보다 더 흐뭇한 것은 없습니다. 애자일 카드가 슝하고 날라가는 것은 팀에서 달성하고자 착수한 작업을 끝마쳤다는 뜻입니다.Done and done!
결승선을 넘고 작업을 완료하기 위해선 훌륭한 계획과 '완료'의 분명한 정의 그리고 집중된 수행이 요구됩니다. 이 중 대부분이 스프린트 계획 sprint planning동안 일어나는데, 성공적인 스프린트 리뷰와 스프린트를 위해서 팀은 계획보다 조금 더 일할 필요가 있습니다. 팀은 '완료'가 뜻하는 바와 마찬가지로 작업을 전달하는 방법에 대해서도 분명히 하는 개발 문화를 만들어야 합니다.
전달 문화 (A culture of delivery)
효율적인 팀들은 각 그리고 매 작업 항목에 분명한 프로세스들과 개발 문화를 수반합니다. 다음 질문들을 사용해 여러분의 프로세스를 평가해 보고, 팀에 최적화 되었는지 확인해 보세요:- 스토리들이 구현 (implementation)되기 전에 제품 책임자, 디자이너, 엔지니어링 팀에 의해 잘 정의되었는가?
- 모두가 팀의 기술 공학적 가치와 문화를 이해하고 실천하는가?
- 지속 가능한 애자일 개발 agile development을 장려하기 위한 코드 리뷰 code review와 자동화된 테스팅, 지속적인 통합 continuous integration에 관한 분명한 정의와 필요 조건이 있는가?
- 팀에서 스토리를 마친 뒤, 버그가 많이 드러나진 않는가? 다시 말하자면, 정말 '완료'되었는가?
각 작업 항목의 '완료' 정의하기
'완료'에 대한 명확한 정의는 팀이 각 작업 항목의 최종 목표에 집중하도록 도와줍니다. 제품 책임자가 작업을 팀의 백로그에 추가하면, 인수 조건을 정의하는 것이 그 또는 그녀의 프로세스에서 주요한 부분이 됩니다. 사용자 스토리에서 완료는 무엇을 의미할까요? Atlassian에서, JIRA 팀은 인수 조건과 테스팅 노트가 JIRA 안의 사용자 스토리 나머지와 일치하는지 추적합니다. 그러한 방식은, 전체 팀에게 모든 이슈를 성공으로 이끌 분명한 시야를 갖도록 합니다. 인수 조건과 테스팅 노트란 무엇일까요?- 인수 조건 Acceptance criteria: 사용자 스토리가 제품 책임자의 기준에 만족스럽게 구현되는지 확인하는데 사용되는 매트릭스
- 테스팅 노트 Testing notes: 개발 앤지니어가 더 향상된 기능 코드와 자동화된 테스트를 쓰도록 하는 품질 유지 팀의 짧지만 집약된 안내
스텝 2: 팀 축하하기
Atlassian 의 핵심 가치 중 하나는 "팀 플레이"입니다. 스프린트 리뷰란 팀과 반복 주기동안 이룬 모두의 성취를 축하하는 즐거운 시간입니다.저 희는 보통 사무실의 모든 이들이 주말에 앞서 긴장을 푸는 금요일 오후에 스프린트 리뷰를 주최합니다. 스프린트 리뷰는 회고전과 동의어가 아니므로, 꼭 반복 주기 이후에, 그러나 회고전보다는 전에 실시해야 합니다. 외부 참가자는 언제나 환영하지만, 미팅은 대체로 제품 책임자, 전체 개발 팀, 그리고 스크럼 마스터로 구성됩니다. 저희는 각 반복 주기 당 30분에서 1시간을 모범 사례로 권장합니다.
저희가 스프린트 리뷰를 사랑하는 이유는 이를 통해 팀의 건강과 사기를 지킬 수 있기 때문입니다. 스프린트 리뷰는 팀 구축의 모든 것입니다.
리뷰는 적대적이지 않고, 시험도 아닙니다 - 팀에서 자신의 작업을 시연하고, 질문에 응대하고, 피드백을 얻는 공동의 이벤트입니다.
만약 스프린트 리뷰가 팀에 긍정적인 활동이 되지 않는다면, 그것은 다음을 나타냅니다:
- 팀이 너무 많은 일을 맡고 반복 주기동안 끝마치지 못한다
- 기존의 기술적 부재로 팀이 어려움을 겪고 있다
- 코드 베이스에 새로운 버그가 나타나지 않는다고 확신하도록 기능들이 지속 가능하게 개발되지 않는다
- 팀의 개발 실행이 조율되지 않는다.
- 제품 책임자가 반복 주기 사이에 우선순위를 변경하고, 요구사항 변경으로 개발 팀이 부차적인 작업을 하고 있다
스텝 3: 거리 극복
팀 이 분산되어 있는 회사는 애자일 의식을 여는데 지역적인 문제를 갖게 됩니다. 스프린트 리뷰도 예외는 아닙니다. JIRA 팀은 전세계 - 시드니, 그단스크, 사이공, 샌프란시스코에 구성원들이 있습니다. 그러나 팀이 분산되어 있음에도, 스프린트 리뷰는 저희 팀 문화의 중요한 부분을 차지하고 있습니다. 팀 구성원들은 비공식적인 비디오를 만들어 Confluence 페이지에 공유함으로써 전체 팀이 볼 수 있도록 합니다.이러한 비공식적인 비디오들은 시차에도 불구하고 모두가 개발의 최신 진척 상황을 알 수 있도록 합니다. 개발자가 직접 설명하는 기능 데모를 보는 것은 다음 두 가지 방면에서 팀을 강화합니다:
- 제품 이해: 팀 전체가 기능의 의도, 원리, 구현에 대해 듣게 됩니다. 이는 전체 제품에 대한 팀원 모두의 이해를 넓힙니다.
- 팀 구축: 비디오는 팀 내에 더 넓은 인맥을 갖도록 합니다. 우리 각 개인은 제품의 모든 측면 뒤에 누가 있는지 알게 됩니다. 이렇게 만들어진 연결 고리는 지리적 거리에도 불구하고 우리를 유대가 더 긴밀하고, 더 화합하는 그룹으로 만들어 줍니다.
댓글