즐거운 12월, "회고전"의 시간이 왔습니다! 연말은 반성의 시기입니다. 저희 팀에서는 구성원들은 다음과 같은 질문들을 생각해 봅니다:

  • 잘된 것은 무엇인가? 
  • 나는 어떤 업적을 이루었는가?
  • 나는 어떤 것을 개선하고 싶은가?
  • 올해 못한 것 중 내년에 하고 싶은 것은 무엇인가?

그렇습니다, 12월은 매년 저희에게 "회고전 (Retrospective)"을 할 시간입니다. (멋진 애자일 용어입니다)

회고전(Retrospective)이란 스프린트나 반복(Iteration), 혹은 제품출시 후 여는 미팅을 말합니다. 이는 애자일 팀들에게 배우고, 성장하고, 제품과 개발 문화를 개선하는 기회를 제공합니다.

또한 성공 사례를 조명하고 문제점을 제기하여 팀이 끊임없이 과정을 개선하도록 합니다. 저희는 팀의 회고전을 한 시간으로 설정하고 있습니다.

다음은 전형적인 Atlassian 스크럼 팀의 회고전을 처음부터 끝까지 정리한 것입니다. 연습 내용을 제안하오니 여러분도 한 번 시도해 보세요.

 

간단 용어정리

Icon
  • 스크럼 (Scrum) : 스크럼은 일정을 정확하게 지키기 위한 노력으로 탄생한 개발 방식. 전력을 다하는 개발 환경을 만들어주는 방법으로서 스프린트라는 개념을 도입하여 이 스프린트 기간동안 전력을 다해 업무를 처리한 후 반성, 다시 반복을 수행하는 방식입니다.
  • 백로그(Backlog) : 진행하는 개발(프로젝트)을 통해 어떤 기능 혹은 디자인을 추가 할 것인지를 결정하고 여기에서 결정된 기능을 백로그(Backlog) 라고 함. 스케쥴 선정 (플랜)의 중요한 기초자료.
  • 사용자 스토리 (User Story) : 실제 사용자에게 정말 가치있는 기능을 간단명료하게 기술한 것으로 스크럼의 제품 백로그(Product Backlog)와도 유사. 결국 고객의 요구사항을 효과적으로 명세하기 위한 실천법.
  • 스프린트(Sprint) : 스크럼의 기본단위. 대략 2주에서 1개월의 짧은 시간을 책정하여 집중력있게 개발에 임하는 시간 단위로 그 결과로 항상 눈으로 확인(실행)할 수 있는 결과물이 나와야 함.
  • 스토리 포인트 (Story Point) : 사용자 스토리의 크기를 나타내는 단위이다. 즉, 사용자 스토리를 구현하는데 소요되는 비용으로 릴리즈 계획 및 승인 테스트 계획의 토대가 됨.
  • 조력자 (Facilitator) : 회의의 목표를 벗어나지 않고 매끄럽게 진행되도록 참가자들의 관심과 참여를 유도하는 역할자

  • 속도 (벨로시티, Velocity) : 애자일 팀이 일정 기간 동안 완료한 사용자 스토리에 대한 스토리 포인트의 총합. 남아있는 사용자 스토리, 리소스, 출시일 등의 적합성 여부를 예측 및 판단하는데 활용 가능. 실제로는 팀이 주어진 기간(스프린트) 내에 완료 할 수 있는 업무의 양으로 단위는 팀에서 추정한 스토리 포인트가 됨.

 

(tick) 애자일에 대한 더 자세한 내용은 SW 공학센터 보고서인 애자일소프트웨어개발 문서를 참조하세요.

애자일도입에 앞서

Icon
Icon

  • 신속하고 민첩한 개발을 위해 도입한 애자일 개발방법론이 오히려 프로젝트를 실패하게 만드는 경우가 있음. 애자일 방법론에 대한 반감은 변화에 대한 단순한 반응은 아닌 애자일을 형편없이 실행하는 조직에 대한 반응일 경우가 대부분임. 애자일 프로젝트는 알지 못하는 사이에 CEO, PM, 계획·교육관련 실수를 하는 사람들, 애자일과 관계없는 개발측면의 문제들로 인해 큰 어려움을 겪음.

  • 이에 따라 애자일 전문가들이 지적하는 애자일의 도입과 실행에서 불거지는 공통적인 실패요인들에 대해 다음과 같이 살펴 도록 함

■ 실패요인 1: 명확한 이유 없이 애자일을 도입하는 경우

  • 애자일 도입에 대한 기대효과를 파악하지도 측정방법을 수립하지도 않고 애자일을 도입하는 경우가 있음
  • BigVisible Solutions 의 Principal Agile coach 인 Mike Dwyer 가 다음을 제시함
    1. 팀 전원이 공동 목표에 추구해야 함
    2. 매 스프린트 (sprint), 주기 (iteration), 프로젝트마다 요구되는 결과를 조사해야함
  • ISV Ultimate Software Group 의 Agile Software Development Director 인 Lisa Crispin 는 다음을 제시함
    1. 애자일 방법론이 모든 프로젝트와 개발 조직에 적합하지는 않기 때문에 현재 프로젝트에 적합한 방법론인지 체크해야 함
    2. CxO 수준의 임원들은 애자일 방법론이 전 개발 프로세스에 긍정적인 영향을 주기 위해 소프트웨어 프로젝트를 수행하는 모든 부서와 긴밀히 협업해야 함

 

(tick) 출처 : SW 공학센터 웹진 : 37호_동향_브리핑_애자일_적용과_프로젝트를_실패하게_만드는_5가지_공통요인.pdf

 

1. 조력자(Facilitator): 
팀 밖으로 시야를 넓히자

성공적인 회고전을 위해서는 토론을 주관하고 미팅을 순조롭게 진행하는 강력한 조력자의 도움이 필요합니다. 많은 팀에서 스크럼 마스터나 팀 내의 누군가를 팀 회고전의 조력자로 선정합니다.

그러나 저희 Atlassian은 회고전의 진행을 팀 외부인에게 맡게 하는 것이 더 좋은 결과를 가져온다는 것을 알게 되었습니다.

그렇게 하면 모든 사람이 완전히 참여할 수 있고 어느 누구도 회고전을 진행하는 과도한 부담을 지지 않아도 되니까요. 보너스로, 진행자는 다른 애자일 팀에서는 어떻게 일하는지를 한 눈에 파악할 수 있고, 이는 Atlassian 내 애자일 팀 간의 지식 공유를 가능하게 합니다.

2. 스프린트 스코어: 
각 스프린트에 대한 팀 분위기 파악

회 고전을 시작할 때, 조력자는 모든 참가자들에게 숫자 1(끔찍한)에서 부터 10(놀라운)까지를 포스트 잇 노트에 쓰도록 합니다.

이 숫자들은 스프린트에 대한 직감적인 레벨 체크로서, 참가자들이 스프린트에 대해 대체로 어떻게 느끼는지를 반영합니다. (이 부분은 구조화 되지 않도록 설계되었습니다. 자세한 매트릭스는 조금 뒤 탐구해 보도록 하죠.) 참가자들이 자신이 작성한 숫자를 다른 이들에게 보여주지 않도록 한 후, 이것을 진행자에게 넘기도록 합니다.

그 다음, 모든 점수의 합을 더하고 인원수로 나누어 평균을 계산합니다. 모두에게 결과를 발표하고, 지난 회고전의 값과 비교해 봅니다.

 

선택사항: 스프린트 스코어 대신에 참가자들에게 4분간 포스트 잇 노트 위에 "스프린트를 묘사한" 그림을 그리도록 해봅니다. 이 방법은 서먹한 분위기를 없애고 두뇌를 활용하도록 하는데 효과적입니다.

3. 애자일 리포트: 데이터를 통한 통찰력 개선

일반적인 스프린트 스코어는 스프린트에 대한 질적 조사와 팀의 사기를 재보기 위해 설계되었습니다. 스프린트 뒤의 양적 데이터를 이해하는 것 또한 중요한데, JIRA Agile에는 Atlassian에서 회고전동안 팀의 토론을 인도하고 양적 정보를 모으기 위해 사용하는 세 개의 주요 보고서가 있습니다. 각 보고서는 팀의 애자일 과정에 대한 깊은 통찰을 제공하고 있으므로, 여러분께  팀 회고전의 성공적 진행을 도울 다음의 보고서들을 추천합니다.

Icon

 

스프린트 보고서와 스프린트 번다운 차트

스프린트 리포트는 완료된 작업, 아직 완료되지 않은 작업, 그리고 스프린트가 시작된 후 추가된 모든 작업들을 목록화합니다. 번다운 차트는 시간 순으로 완료된 작업의 비율을 보여줍니다. 

질문:

  • 팀은 스프린트 예측에 도달했는가? 
  • 팀의 번다운은 모든 이들이 예측한 대로인가? 
  • 스프린트 도중에 추가되거나 제거된 작업이 있는가? 
  • 스프린트에서 작업이 완료되지 않았는가? 만약 그렇다면, 이유는 무엇인가? 

목표:  실제 딜리버리와 비교해 스프린트가 어떻게 예측하는지 이해합니다. 스프린트 동안 번다운 측정 진행을 사용합니다.  

벨로시티(Velocity) 리포트

벨로시티 리포트는 지난 7번의 스프린트 동안 완료 예측된 작업과 실제 종료된 작업의 양을 추적합니다.

질문:

  • 이번 스프린트 동안 팀의 벨로시티는 무엇인가? 
  • 그 추세는 증가하고 있는가, 감소하고 있는가, 유지되고 있는가? 

목표:  팀의 생산량을 시간 순으로 추적해 봅시다. 팀은 헌신(Commitment)과 완료된 값이 유사하기를 바라고 있습니다. 또한 새로운 애자일 팀에서 벨로시티는 시간 순으로 증가해야 합니다.  

컨트롤 차트

컨트롤 차트는 사이클 타임을 보여줍니다: 사이클 타임은 이슈를 완료하는데 걸리는 시간입니다. 

질문:

  • 이슈의 사이클 타임이 일정하게 유지되는가?
  • 유사한 스토리 포인트 값을 가진 이슈들은 종료까지 동일한 시간이 걸리는가?

목표: 사이클 타임을 줄여봅시다. 같은 스토리 포인트 값을 공유한 개별 스코어들이 비슷한 사이클 타임을 갖는 것을 입증해 보세요. 더 자세한 내용은 컨트롤 차트 블로그에서 확인하실 수 있습니다:

 컨트롤 차트를 이용해 개발을 최적화 하는 6가지 중요한 방법

 저희 Atlassian은 다음 스프린트에 대한 팀의 개인적 희망을 조사할 때 회고전을 이용하기도 합니다. 저희는 이것을 시작/중지/계속이라고 부르는 운동을 통해 하고 있습니다.

스프린트 스코어(2단계)와 애자일 리포트(3단계)가 팀이 토론 주제를 만드는데 도움이 됩니다. 회의실 내 모두가 충분한 포스트 잇 노트와 잘 써지는 마커펜을 받았는지 확인하세요.

화이트 보드를 세 부분으로 나누고 "시작","중지","계속"이라고 적습니다. 타이머를 5분으로 설정하고 각 칸에 적고 싶은 것을 쓰도록 합니다.

4. 시작 / 중지/ 계속: 
주요 토론 주제를 이끌어내는 방법

  • 시작: 팀에서 시작해야 할 것은 무엇인가? 
  • 중지: 팀이 중지해야 할 것은 무엇인가? 
  • 계속: 팀이 계속해야 할 것은 무엇인가?

5분이 지나면, 모두를 한 사람씩 일어나(이것이 중요합니다) 포스트 잇을 각 칸에 붙이고 큰소리로 읽어 모두가 보고 들을 수 있도록 합니다. 

5. 점 투표: 토론의 주제를 공정하게 결정

일단 모두가 자신의 피드백을 보드에 붙이면, 관련된 것끼리 피드백을 정리합니다.

보드를 쭉 훑어보고 하나 이상의 포스트 잇에 여러 번 언급된 주제가 있는지 봅시다. 만약 있다면, 보드 한 곳에 비슷한 주제의 피드백들을 모아둡니다.

같은 주제와 애로사항을 반영하고 있다면 다른 칸에 있는 포스트 잇을 가져와 섞는 것도 괜찮습니다. 

다음으로, 모두에게 시작과 중지 칸에서 3번 투표(팀원 수에 따라 줄여도 됩니다) 할 수 있는 기회를 줍니다. 모두 일어나도록 해서 자신이 고른 포스트 잇에 점을 찍도록 합니다.

모두 투표를 마친 후, 각 칸에서 가장 표를 많이 받은 3개씩을 가져와 토론을 시작합니다. 이것들이 토론의 주제가 됩니다.

6. 토론: 합의와 조치 사항을 도출

팀 투표 후에, 토론에 들어갑니다. 큰소리로 불평하도록 두는 것보다 해결안을 찾아 나가도록 토론을 이끌어 갑니다.

토론 내내 기록합니다. 그룹이 한 주제에 대해 합의에 이르면, 조치사항을 반복해 확인하고, 담당자를 정합니다.

이 모든 내용을 Confluence의 회고전 페이지에 기록하고, 조치 사항의 담당자를 @맨션 (언급기능)합니다.

회고전 대부분의 시간을 정해진 주제에 대해 토론하는데 사용합니다.

회고전 토론은 30분에서 1시간 정도를 목표로 합니다.

성공적인 회고전(retrospective)은 위의 각 토의 항목이 엄격한 시간내에 이루어져 선택된 주제가 적절한 범위를 가지고 토의가 이루어질 수 있도록 해야하며, 조력자(Facilitator)는 토론그룹이 하나의 중요 주제에 집중하도록 하여 연관되는 제품 책임자와 함께 행동(action)을 일으킬 수 있도록 이끌어 주어야 합니다..

 

ProTip: 팀의 백로그에 JIRA 이슈를 만들어 피드백을 더 활발하게 만들어 보세요. 그렇게 하면 팀의 백로그 내에 남아있는 작업들과 함께 개발 문화 개선도 같이 추적할 수 있습니다. 단순히 Confluence에서 피드백을 하일라이트 처리하고 JIRA 툴팁 아이콘을 선택해 JIRA로 불러오기만 하면 됩니다.

7. 결과 공표: 결과를 분명히 전달 

전체 팀과 회고전을 공유하는 것은 매우 중요합니다. Confluence를 사용해 회고전의 결과와 기록을 공유하세요.  저는 보통  Retrospective blueprint 에 페이지를 열고 모임 내내 기록하고 있습니다. 모임의 마지막에, 제가 해야 할 일은 팀에 공표하기 위해 '저장'을 누르는 것 뿐이지요!

알려주세요!

여러분의 팀에선 회고전을 어떻게 운영하십니까? 여러분의 조직은 피드백을 모으고 개발 문화를 개선하기 위해 어떤 모범 사례를 사용하고 있나요?