Atlassian에서 스프린트를 계획하고 진행하는 방식을 소개합니다
Atlassian의 스프린트 계획 방법 소개
- Dan Radigan 글, 시니어 애자일 전도사
- JIRA, JIRA Agile
- 2015년 1월 7일
이 기사는 애자일 의식 시리즈의 두 번째입니다. 스프린트 회고전 sprint retrospectives 또한 어떻게 하고 있는지 확인해 보세요!
새
해가 오면 사람들은 새롭게 목적 의식을 다지게 되는데, 소프트웨어 세계에서는 더 나은 소프트웨어의 선적을 다짐합니다. 새해동안
실행에 다시 촛점을 맞추고, 돌발 상황을 최소화하고, 전체적으로 더 높은 품질 코드를 보증하기 위해
Atlassian에는 스프린트 계획의 애자일 의식에 매우 의존하고 있습니다. 저희가 확인한 가장 도움이 되는 네 가지 원칙을
다음에서 살펴 보십시오.스텝 1: 미팅 전에 로드맵을 확인하세요
시간은 우리 생각보다 빨리 흘러갑니다. 따라서 새해의 첫 두 주동안 여러분의 프로젝트 로드맵을 리뷰하는 것이 좋습니다. 로드맵은 에픽 epics과 버젼 versions이 라는 두 개의 중요한 애자일 개념을 컨텍스트에 설정하는데, 에픽과 버젼은 애자일 프로그램 계획의 근간을 제공하고 작업 기간이 길수록 전달을 추적하는데 효과적입니다. 스프린트 계획 미팅 전에 로드맵이 최신이고 전체 팀이 볼 수 있는지, 에픽과 버젼이 JIRA 안에서 올바르게 목록화되고 있는지 확인해 보십시오.
스텝 2: 사전 미팅
스프린트 계획은 다음 두 개의 주요 태스크를 수반합니다. 백로그 정리와 다가오는 스프린트에서 완료할 작업 결정입니다. Atlassian은 실제 스프린트 계획 전에 갖는 제품 책임자와 스크럼 마스터 간의 별도 미팅에서 백로그 정리가 가장 잘된다는 것을 알아냈습니다.Atlassian에서 이 사전 미팅은 전체 개발 팀에게 선택 사항입니다.
백로그 정리란?
백로그 정리는 백로그를 건강하게 합니다. 건강한 백로그란:- 각 작업 항목의 우선순위를 정하고, 가장 중요한 작업은 목록의 제일 위에 놓습니다
- 개발 팀이 수행을 시작할 수 있는 완성된 사용자 스토리를 포함합니다
- 각 작업 항목에 최신 견적서를 포함하고 있습니다
팀 활동: 어떤 팀들은 추정(estimation)에 고전합니다. 스토리 포인트는 추정 작업에 건전한 틀을 제공합니다. 팀과 무언의 추정 silent estimation이
라는 활동에 참가해 보십시오. 먼저 화이트 보드에 세로 칸을 나눠 스토리 포인트 값(0.5, 1, 2, 3, 5, 8, 13,
20, 40, 100)을 적습니다. 그런 다음, 팀원들에게 가장 타당하다고 생각하는 칸에 사용자 스토리를 배치하도록 합니다.
대부분의 스토리가 한 숫자에 몰릴 것입니다. 그리고 만약 스토리 포인트 값에 이견이 있다면 그 이유에 대해 토론해 봅니다.
스텝 3: 실제 스프린트 계획 미팅
스프린트 계획 미팅의 촛점은 스프린트 목표 (스프린트 동안 마칠 수 있으리라 팀원들이 믿는 작업의 양) 를 설정하고 의견을 같이하는 것입니다. 제품 책임자, 스크럼 마스터, 그리고 전체 개발 팀 모두가 참석해야 합니다.Atlassian 은 미팅에서 다룰 스프린트에 대해 각 주(week)별로 적어도 한 시간씩 할애하도록 권장합니다. 예를 들어 두 주짜리 스프린트에 대한 스프린트 계획 미팅은 두 시간으로 잡고 시작합니다. 스프린트 계획은 주 초로 날을 잡는 것이 이상적입니다. 그렇게 하면 주말까지 팀의 컨텍스트와 작업 흐름은 방해를 덜 받습니다.
경험을 통해 배운 것: 스프린트 회고전과 스프린트 계획 미팅을 함께 하지 마십시오. 팀이 회고전을 소화할 충분한 시간적 여유를 두어 효과적으로 스프린트 계획에 참여할 수 있도록 하십시오 - 점심식사 시간을 그 사이에 끼우는 것도 좋습니다.
미
팅을 시작할 때, 스크럼 마스터는 팀의 회고전과 관련된 실천 항목을 제시합니다. 그 다음, 제품 책임자가 제품이나 시장에 대한
최신 정보를 알려주어 모든 참가자가 같은 정보를 공유하고 폭넓게 맥락을 이해할 수 있도록 합니다. 결과 보고 후, 제품 책임자가 주축이 되어 실제 계획에 대한 대화를 시작합니다. 대화를 시작하며 제품 책임자는 팀의 평균 벨로시티 (보통 1 스프린트에 완료된 작업의 양)를 사용해 스프린트 동안 작업할 한 세트의 스토리를 편집합니다. 이를 "스프린트 예측"이라고 하는데, 고객에게 전달할 가치를 최대화 하도록 합니다. 제품 책임자가 또한 고려해야 할 세 가지 요인은 다음과 같습니다:
- 공휴일, 휴가, 팀 전체 행사
- 백로그에서 스토리의 우선순위 (이상적으로, 가장 상위에 랭크되어 있는 항목을 추천)
- 주력 작업이 어떻게 제품을 최종 목표에 도달하도록 할 것인가 (그리고 도달할 수 있는가)
프로 팁: 제품 책임자는 스프린트 마커를 사용해 벨로시티를 계산할 수 있습니다.
만 약 신생 팀이라 기존 벨로시티 데이터가 없다면, 제품 책임자는 스프린트 예측을 제안할 수 없습니다. 대신 팀 전체 활동을 할 수 있는데, 각 구성원의 동의가 중요하기 때문입니다. 첫 단계로, 팀은 예측에 관해 최선의 판단을 내리고, 몇 개의 스프린트 동안 시행착오를 겪으며 일합니다. 일단 팀의 벨로시티 (JIRA의 벨로시티 차트에 의해 멋지게 시각화된) 가 수치로 구축되면, 그 수치를 스프린트 예측에 사용합니다.
한번 제품 책임자가 스프린트 예측에 대한 아이디어를 제시하면, 팀은 그것을 승인(그리고/혹은 조정)하고 스프린트를 위한 실천 계획에 합의할 수 있습니다.
프로 팁: 팀에서는 각 스프린트의 기술적 부채(technical debt )를 줄일 방법을 고려해야 합니다. 팀 백로그 상의 버그를 하일라이트 표시해주는 퀵 필터 quick filter를
만드는 것은 팀이 코드 베이스의 다양한 영역 안의 사용자 스토리에 대한 작업에 착수할 때 중요한 버그를 스프린트에 들어오도록
하일라이트하는 손쉬운 방법입니다. "기술 부채" 퀵 필터는 버그에 대한 뷰를 제한하기 위해 JQL "(버그) 입력"을 사용합니다.
추가적인 이슈 타입을 포함시킬 필요가 있다면 JQL 쿼리를 확장하기만 하면 됩니다.
스
프린트 계획의 다음 단계는 스토리를 검토하고 각 스토리를 완성하기 위해 요구되는 작업이 무엇인지 적는 것입니다. 팀 계획으로서,
누군가가 각 JIRA 티켓 안의 핵심 포인트를 잡아내야 합니다. 그렇게 하면 결정과 근거 모두를 나중에 확인하기 쉽습니다.
팀에서는 다음과 같은 질문들을 검토해야 합니다...- 스토리의 정의가 그것을 적은 이후로 달라졌는가? 팀에서 검토해야 할 새로운 문맥상의 정보가 있는가?
- 스토리의 추정은 여전히 유효한가? 전체 팀원이 그 추정에 합의하는가? 그렇지 않다면, 스크럼 마스터는 재 추정을 통해 팀을 안내해야 합니다.
- 이 스토리를 끝마치기 위해 어떤 태스크가 요구되는가? 서브 태스크를 이용해 작업을 비교하고 흐름을 최적화합니다. 만약 팀이 작업을 나눌수 있는 고유한 스토리를 발견한다면, 그 태스크를 독립된 스토리로 격상시킵니다.
- 이 스토리의 테스팅 결과는 무엇인가? 어떻게 테스팅을 자동화할 수 있는가?(매뉴얼 테스트 스크립트는 근본적으로 기술 부채임을 기억하자.)
- 전문가 기술 파트가 요구되는가? 어떻게 하면 다른 팀원을 방해하지 않고 전문가의 시간을 최적화할 수 있는가?
- 이 스토리가 제품 아키텍쳐에 어떻게 영향을 미치는가? 팀이 설계와 코드 리뷰에 참여시킬 필요가 있는 특정 인물이 있는가?
- 스토리 사이에 종속성이 존재하는가? 이러한 종속성들을 고려해 볼 때 스프린트 동안 모든 작업을 완료할 수 있는가?
프로 팁: 스프린트 계획을 하는 동안, 팀이 스프린트 예측을 만들면서 스프린트에 스토리를 넣고 빼는 것이 간단합니다. 스프린트에 넣거나 뺄 때 이슈를 우클릭 하기만 하면 됩니다.
4. 준비하시고, 출발!
미 팅의 이러한 관점에서, 팀은 스프린트 예측을 편안하게 생각해야 합니다. 스프린트의 끝에 팀이 실제로 무엇을 선적하도록 전념할 것인지에 대해 스프린트 계획을 마치면서 회의실 안의 모두에게 구두 승인을 받는 것도 좋은 방법입니다. 또한, 각 팀원이 적어도 한 가지의 태스크를 갖도록 하고 일이 중복되는 사람이 없도록 하십시오.팀 업무와 사기는 자연스레 스프린트마다 등락을 거듭합니다. 이러한 변화는 스프린트 계획에서 자주 드러나지만, 그것을 바로 그때 그 자리에서 파들어가고 싶은 유혹을 물리치십시오. 대신에, 팀의 회고전을 이용해 어떤 이슈가 팀 사기에 영향을 미쳤는지 이해해 봅니다. 문화와 개발 관심사에 빨리 반응하는 팀이 더 행복하고, 더 생산성 있으며, 더 좋은 코드를 씁니다.
여러분의 팀은 스프린트 계획에 어떤 비책을 사용하십니까? 댓글을 남겨 여러분의 생각을 공유해 주세요!
Dan Radigan에 대하여
플
로피 디스크 (여러분도 아시는, 바로 그 5.25 인치의 플로피 디스크)를 쓰던 시절부터 소프트웨어는 제게 열정이 되었습니다.
코드와 삶 모두에서 최선의 경험은 애자일이라는 것을 배운 것처럼, 애자일은 제게 직업적으로 그리고 개인적으로 큰 충격을
주었습니다. 여러분은 기술, 사진, 그리고 오토바이 타기의 교차로에서 저를 만나실 수 있을 겁니다. 트위터에서 저를 찾으세요: @danradigan
댓글