블로그

이 글은 애자일 스프린트 시리즈 중 마지막 글입니다. 스프린트 계획, 스프린트 검토 및 스프린트 회고를 수행하는 방식에 대해 알아보겠습니다.

 

스탠드업은 애자일 개발에서 가장 핵심적인 부분 중 하나이며, 잘못 이해되는 경우가 많은 개념입니다. 제대로 이해합시다

 

- 나 홀로 스탠드업으로는 애자일 팀이 되지 못합니다. 스탠드업은 자존심에 바람을 넣거나 직무를 정당화하는 자리가 아닙니다. 계획을 세우는 시간도 아닙니다. 계획은 스프린트 계획 시간에 세우면 됩니다. 장애물을 유일하게 언급하는 시간도 아닙니다.

막다른 길에 갇혔다면 도움을 요청하세요!

 

이번 글에서는 장애물을 효과적으로 처리하는 방법과 Atlassian에서 사용하는 요령에 관해 이야기하겠습니다. 여러분의 스탠드업(과 전반적인 애자일 프로그램)을 멋지게 만들어 드리고 싶습니다.

 

그렇다면 스탠드업(Stand-ups)이란 무엇일까요?

 

미식축구나 럭비 등 여러 스포츠에서, 팀은 각 경기 전에 모여 작전회의(허들)를 합니다. 허들은 전략적입니다.

경기 내내 팀에 지속해서 정보를 주고, 선수 간 연대감을 유지하며, 각 선수의 역할을 조정합니다.

소프트웨어 팀의 경우 스탠드업은 팀의 허들과 같습니다. 흔히 일일 스크럼이라고 하는데, 모든 사람이 팀의 전망과 현황을 정확히 인식하도록 '우리'를 강화합니다.

 

바꿔 말하면 스탠드업은 핵심 팀(제품 소유자, 개발자 및 스크럼 마스터)이 관여하는 일일 회의입니다. 이 회의의 분위기는 팀마다 다르지만, Atlassian에서는 다음 3가지 간단한 질문을 바탕으로 구조를 마련합니다.

 

  • 어제 무슨 업무를 수행했습니까?
  • 오늘 무슨 업무를 수행 중입니까?
  • 현재 방해가 되는 문제는 무엇입니까?

 

이런 질문을 통해 현황을 파악하고 팀에 장애가 되는 요소를 확인할 수 있습니다.

또한, 모든 사람이 팀에 기여하고 있다는 상태를 공유하면서 팀이 강화됩니다.

매일 각 구성원의 성공사례와 계획을 공유하는 과정을 강화해 나가면 모든 구성원이 조직에 대한 팀의 전반적인 기여도에 대해 기쁨을 느끼게 됩니다.

 

개인적 차원에서 보면 내가 무슨 말을 할지 알고 스탠드업에 들어가는 것이 중요합니다.

스탠드업의 활기가 증폭되고 모두 적극적으로 참여하는 분위기가 유지되기 때문입니다.

Atlassian에서는 각 개인이 JIRA Agile 보드를 사용하여 빠른 필터로 담당 프로젝트를 파악합니다.

스탠드업을 준비하는 데 함께 사용할 수 있는 2가지 필터는 '내 이슈만 보기 (only my Issues)' 필터와 '최근 업데이트(recently updated)' 필터입니다. 이 2가지 필터를 함께 사용하면 나에게 할당된 이슈 중 최근 업데이트된 이슈들이 표시됩니다.

 

 

ProTip: 가장 널리 쓰이는 '내 이슈만 보기' 필터 커스터마이즈 방법은 JIRA Toolkit Add-On에서 참가자 필드를 추가하는 것입니다.

이렇게 하면 그냥 나에게 할당된 이슈가 아니라 내가 작업한 이슈들이 추가됩니다. 이 필터에 대한 JQL은 다음과 같습니다.

assignee = currentuser() or participants in (currentuser())

 

Atlassian의 스탠드업 (Stand-ups)

 

스탠드업은 일괄적 접근방식의 회의가 아닙니다. Atlassina에서는 팀마다 맞춤형 스탠드업을 통해 모든 사람의 참여도와 관여도를 유지합니다. 완전히 똑같은 형태의 스탠드업이 없습니다.

 

스탠드업을 올바르게 구성하는 방법을 자세히 알아보고, 몇 가지 예를 살펴보겠습니다.

 

  1. 모두에게 편한 시간 선택하기 - Atlassian에서는 한 장소에 근무하는 팀들에 대한 스탠드업이 대부분 오전 9시부터 10시 사이에 진행됩니다. 전체 직원이 그날 상황을 파악할 수 있으며 아무도 일찍 출근할 필요가 없습니다. 서로 다른 근무지의 팀들은 모두에게 편한 시간을 선택하게 됩니다. 예를 들면, JIRA Service Desk 팀은 샌프란시스코와 시드니에 분산되어 있습니다. 이들의 스탠드업은 샌프란시스코 시간 기준 오후 3시 30분에 진행됩니다. 물론 오후의 스탠드업이 통상적인 것은 아니지만, 지구 반대편 시드니에 근무하는 동료들과 연락하기에는 아주 좋은 방법입니다.
  2. 스탠드업의 효율성 유지하기 - Atlassian에는 형식에 구애되지 않고 스탠드업 시간을 정함으로써 참여하는 직원들의 집중도와 스탠드업 효율성을 유지하는 팀들이 많습니다. 모든 직원이 책임감을 느끼고 참여하도록 돌아가면서 시간을 기록합니다. 스탠드업 시간은 최대 15분으로 제한합니다. 팀의 규모가 작습니까? 그렇다면 스탠드업 시간을 더 짧게 운영해 보세요.
  3. 캐치볼 하기 - JIRA 팀은 팀원들끼리 비치볼 던지기를 해 모든 직원의 참여도를 유지합니다. 바로 옆 사람이나 이미 볼을 받았던 사람에게는 볼을 던질 수 없습니다. 집중할 수밖에 없습니다! 이 기법을 시도해보지 않았다면 모두의 참여도를 유지하는 방법이니 꼭 시도해 보세요!
  4. 스탠드업을 팀 회고에 포함하기 - 스탠드업이 여러 애자일 문화의 일부이긴 하지만, 그렇다고 스탠드업의 효과성을 팀이 회고 중에 논할 수 없다는 뜻은 아닙니다. Atlassian에는 매일 만나는 팀도 있고, 일주일에 세 번 만나는 팀도 있습니다. JIRA Agile 팀은 회고를 진행하면서 스탠드업을 팀에 맞게 개선하는 방법을 정기적으로 논의합니다. 팀이 스탠드업에서 가치를 찾지 못하고 있다면 그 이유를 논의하세요. 뭔가 변화를 줘보세요! 스탠드업은 애자일 그 자체입니다.

 

ProTip: 일부 Atlassian 팀들은 Crontabs 및 Pandora, 해당 팀의 JIRA 월보드를 연동하고 있습니다. Crontabs는 스탠드업 시작 15초 전에 Pandora (및 팀에서 좋아하는 음악)를 로딩해 참가자들을 주목시킴으로써 스탠드업이 정시에 시작될 수 있도록 합니다. 팀의 월보드는 팀에서 그날 집중해야 할 사안들을 강조해 주지시킵니다.

 

 

분산 배치된 팀들을 위한 HipChat + 스탠드업

 

Atlassian의 직원들은 원격 근무를 포함해 전 세계 12개 사무소에 분산 배치되어 일하고 있습니다. 우리는 HipChat을 통해 지리적 위치에 상관없이 모든 직원이 서로 소통하며 일하도록 하고 있습니다.

Atlassian은 팀마다 모든 팀원이 서로 연락할 수 있는 팀 방이 있습니다. HipChat의 한 가지 특징은 일상적인 프로세스(Bot)를 자동화하는 외부 서비스와의 연동 기능입니다

우리는 스탠드업 Bot와 Chatty라는 2가지 Bot를 이용해 모든 직원이 소통할 수 있도록 하고 있습니다.

 

스탠드업 보트(Bot)

 

스탠드업 보트를 이용하면 특히 시간대가 다른 팀들의 경우 스탠드업 상태 보고 및 검색이 편리해집니다. 스탠드업 보트를 연동시키려면, http://botlab.hipch.at/에서 HipChat에 연결하십시오. 스탠드업 시간이 되면 팀 방에서 다음의 명령어만 입력하면 됩니다.

 

/standup

 

누구나 비동기적으로 보고할 수 있고, 팀 방에 문의해 팀원들의 업무 현황 파악도 간편하게 할 수 있습니다. 아래 명령어만 입력하면

 

/standup

 

보트가 모든 직원의 스탠드업 보고서를 리턴해줍니다.

 

 

Chatty

 

Chatty는 스탠드업 시간이 되면 팀 방에 알려주는 보트입니다. Chatty 관련 자세한 내용은 BitBucket에서 확인할 수 있습니다.

 

 

스탠드업을 통해 팀원들이 모두 모여 팀 전체의 업무 현황을 파악할 수 있습니다. 팀 위치와 관계없이, 스탠드업을 통해 팀을 긴밀하게 연결하고 생산성을 높일 수 있습니다. 장기적으로 부담 없고 즐거운 스탠드업을 통해 참여도를 유지함으로써 지루한 절차로 인한 부정적인 효과를 줄일 계획입니다.

 

더 많은 내용을 알아보고 싶으시다면 아래 애자일 코치 사이트를 방문해 보십시요.

 

 

 

 

특히 업무가 많이 몰릴 때는 정말 중요한 작업에 집중하지 못하는 경우가 있습니다.

당사 Atlassian의 24시간 해커톤인 ShipIt에서는 무엇보다 최고의 가치를 제공하는 데 중점을 뒀습니다. 우리는 가장 효과적인 방식으로 애자일 방식을 사용했습니다(24시간 이내에 끝냈습니다).

 

계획

  • 백로그를 작성합니다. (화이트보드에 포스트잇 부착) 새로운 문제점 또는 아이디어는 백로그로 보내서 현재의 스프린트가 끝난 후 우선순위를 정할 수 있습니다. 스프린트 진행 중에는 우선순위 또는 범위를 변경할 수 없습니다.
  • 스프린트? 네. 스프린트. 1시간 30에 걸쳐 스프린트를 합니다. 특정 스프린트에서는, 모든 직원이 적절한 범위를 설정하고 현실적인 목표를 세웠으며 마지막 결과물을 만들어냈습니다.
  • 스프린트 진행 후 우리는 회고하면서 10분 동안 데모를 합니다. 부분적인 작업을 중단하고 그림에 집중하는 것은 매우 중요합니다.
    • 업무가 팀의 최종 목표에 맞게 진행되고 있습니까?
    • 그다지 중요하지 않은 업무에 너무 많은 시간을 소비하고 있지 않습니까?
    • 이런 문제 해결 방식이 나중에 ShipIt에서 마찰을 빚지 않을까요? 모든 걸 다 버리고 새로이 구성해야 합니까?
    • 제가 도와야 팀원이 있습니까?
    • 제가 다른 사람의 도움을 받아야 합니까?

어떻게 되었습니까?

이 방식은 아주 생산적이고 효과적이라고 생각합니다. 어떻게 그럴 수 있는지 의아해하실 겁니다. 글쎄요.

 

ShipIt에서 1등 한 팀입니다.

아주 효과적입니다!


About Ivan Loire

Atlassian developer

View all posts by Ivan Loire »


Atlassian의 스프린트 리뷰를 소개합니다

Atlassian의 스프린트 리뷰 소개

 

이 기사는 애자일 의식 시리즈의 세번째입니다. 저희가 어떻게 스프린트 계획(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: 개발 앤지니어가 더 향상된 기능 코드와 자동화된 테스트를 쓰도록 하는 품질 유지 팀의 짧지만 집약된 안내

구현하는 동안 명확한 이슈를 갖는다면 모두가 성공할 수 있습니다. JIRA를 사용하면 필드를 라인에 추가하는 것이 쉬워집니다. 관리자는 이슈의 'admin'을 클릭하기만 하면 됩니다. 

스텝 2: 팀 축하하기

Atlassian 의 핵심 가치 중 하나는 "팀 플레이"입니다. 스프린트 리뷰란 팀과 반복 주기동안 이룬 모두의 성취를 축하하는 즐거운 시간입니다.

저희는 보통 사무실의 모든 이들이 주말에 앞서 긴장을 푸는 금요일 오후에 스프린트 리뷰를 주최합니다. 스프린트 리뷰는 회고전과 동의어가 아니므로, 꼭 반복 주기 이후에, 그러나 회고전보다는 전에 실시해야 합니다. 외부 참가자는 언제나 환영하지만, 미팅은 대체로 제품 책임자, 전체 개발 팀, 그리고 스크럼 마스터로 구성됩니다. 저희는 각 반복 주기 당 30분에서 1시간을 모범 사례로 권장합니다.  

저희가 스프린트 리뷰를 사랑하는 이유는 이를 통해 팀의 건강과 사기를 지킬 수 있기 때문입니다. 스프린트 리뷰는 팀 구축의 모든 것입니다.

리뷰는 적대적이지 않고, 시험도 아닙니다 - 팀에서 자신의 작업을 시연하고, 질문에 응대하고, 피드백을 얻는 공동의 이벤트입니다. 

만약 스프린트 리뷰가 팀에 긍정적인 활동이 되지 않는다면, 그것은 다음을 나타냅니다:

  • 팀이 너무 많은 일을 맡고 반복 주기동안 끝마치지 못한다
  • 기존의 기술적 부재로 팀이 어려움을 겪고 있다 
  • 코드 베이스에 새로운 버그가 나타나지 않는다고 확신하도록 기능들이  지속 가능하게 개발되지 않는다 
  • 팀의 개발 실행이 조율되지 않는다.
  • 제품 책임자가 반복 주기 사이에  우선순위를 변경하고, 요구사항 변경으로 개발 팀이 부차적인 작업을 하고 있다

주) 힘겨운 반복 주기는 어느 팀에나 때때로 찾아 옵니다. 왜 팀의 회고전이 반복 주기를 바꾸는지 이해하는 시간을 갖고 다음 스프린트를 위한 이슈 처리 계획을 만들어 보세요.

스텝 3: 거리 극복

팀 이 분산되어 있는 회사는 애자일 의식을 여는데 지역적인 문제를 갖게 됩니다. 스프린트 리뷰도 예외는 아닙니다. JIRA 팀은 전세계 - 시드니, 그단스크, 사이공, 샌프란시스코에 구성원들이 있습니다. 그러나 팀이 분산되어 있음에도, 스프린트 리뷰는 저희 팀 문화의 중요한 부분을 차지하고 있습니다. 팀 구성원들은 비공식적인 비디오를 만들어 Confluence 페이지에 공유함으로써 전체 팀이 볼 수 있도록 합니다. 

이러한 비공식적인 비디오들은 시차에도 불구하고 모두가 개발의 최신 진척 상황을 알 수 있도록 합니다. 개발자가 직접 설명하는 기능 데모를 보는 것은 다음 두 가지 방면에서 팀을 강화합니다:  

  • 제품 이해: 팀 전체가 기능의 의도, 원리, 구현에 대해 듣게 됩니다. 이는 전체 제품에 대한 팀원 모두의 이해를 넓힙니다. 
  • 팀 구축: 비디오는 팀 내에 더 넓은 인맥을 갖도록 합니다. 우리 각 개인은 제품의 모든 측면 뒤에 누가 있는지 알게 됩니다. 이렇게 만들어진 연결 고리는 지리적 거리에도 불구하고 우리를 유대가 더 긴밀하고, 더 화합하는 그룹으로 만들어 줍니다.

마지막으로 드리는 조언

스프린트 리뷰가 생소한 팀들은 스프린트 리뷰를 회고전에 맞추고자 하는 강한 유혹을 받습니다. 스프린트 리뷰는 스프린트 회고전과 독립된 의식입니다. 여러분이 힘들여 얻은 열매를 맛보는 시간을 가지십시오. 자유롭게 업적을 축하하십시오. 효율적인 스프린트 리뷰는 팀의 사기와 동기 부여를 높입니다. 저희 JIRA 팀에게 이 의식의 발상은 매우 중요하며, 바로 그런 이유로 저희는 비젼 선언문에 "밀고 나가고, 축하하라"를 추가하였습니다. 

 

Dan Radigan에 대하여

플 로피 디스크 (여러분도 아시는, 바로 그 5.25 인치의 플로피 디스크)를 쓰던 시절부터 소프트웨어는 제게 열정이 되었습니다. 코드와 삶 모두에서 최선의 경험은 애자일이라는 것을 배운 것처럼, 애자일은 제게 직업적으로 그리고 개인적으로 큰 충격을 주었습니다. 여러분은 기술, 사진, 그리고 오토바이 타기의 교차로에서 저를 만나실 수 있을 겁니다. 트위터에서 저를 찾으세요: @danradigan

View all posts by Dan Radigan »

Atlassian의 스프린트 계획 방법 소개

 

이 기사는 애자일 의식 시리즈의 두 번째입니다. 스프린트 회고전 sprint retrospectives 또한 어떻게 하고 있는지 확인해 보세요!

새 해가 오면 사람들은 새롭게 목적 의식을 다지게 되는데, 소프트웨어 세계에서는 더 나은 소프트웨어의 선적을 다짐합니다. 새해동안 실행에 다시 촛점을 맞추고, 돌발 상황을 최소화하고, 전체적으로 더 높은 품질 코드를 보증하기 위해  Atlassian에는 스프린트 계획의 애자일 의식에 매우 의존하고 있습니다. 저희가 확인한 가장 도움이 되는 네 가지 원칙을 다음에서 살펴 보십시오. 

스텝 1: 미팅 전에 로드맵을 확인하세요

시간은 우리 생각보다 빨리 흘러갑니다. 따라서 새해의 첫 두 주동안 여러분의 프로젝트 로드맵을 리뷰하는 것이 좋습니다. 로드맵은 에픽 epics과  버젼 versions이 라는 두 개의 중요한 애자일 개념을 컨텍스트에 설정하는데, 에픽과 버젼은 애자일 프로그램 계획의 근간을 제공하고 작업 기간이 길수록 전달을 추적하는데 효과적입니다. 스프린트 계획 미팅 전에 로드맵이 최신이고 전체 팀이 볼 수 있는지, 에픽과 버젼이 JIRA 안에서 올바르게 목록화되고 있는지 확인해 보십시오. 

스텝 2: 사전 미팅

스프린트 계획은 다음 두 개의 주요 태스크를 수반합니다. 백로그 정리와 다가오는 스프린트에서 완료할 작업 결정입니다. Atlassian은 실제 스프린트 계획 전에 갖는 제품 책임자와 스크럼 마스터 간의 별도 미팅에서 백로그 정리가 가장 잘된다는 것을 알아냈습니다.

Atlassian에서 이 사전 미팅은 전체 개발 팀에게 선택 사항입니다. 

백로그 정리란?

백로그 정리는 백로그를 건강하게 합니다. 건강한 백로그란:

  • 각 작업 항목의 우선순위를 정하고, 가장 중요한 작업은 목록의 제일 위에 놓습니다 
  • 개발 팀이 수행을 시작할 수 있는 완성된 사용자 스토리를 포함합니다 
  • 각 작업 항목에 최신 견적서를 포함하고 있습니다

Atlassian 의 팀들은 스프린트 계획에 앞서 며칠동안 짧은 백로그 정리 미팅을 가집니다. 이 미팅을 30분으로 잡고 다음 두 스프린트 동안 가장 맡고 싶은 이슈를 선별하십시오. 때론 수행 과제를 자세히 알 수 없거나 제품 책임자에게 컨텍스트에 대한 정보를 물어봐야 하는 아이템들이 발견되곤 합니다. 사전 백로그 정리의 백미는 여기에 있습니다. 미팅은 이런 간격을 채울 수 있어 실제 스프린트 계획동안 방해 (혹은 시간 낭비)가 되지 않습니다. 이와  같이, 사전 백로그 정리는 스프린트 계획동안 팀이 스프린트 선택 사항을 고려하고 필요하다면 다음 스프린트의 아이템을 결정할 더 많은 시간적 여유를 제공합니다.   

팀 활동: 어떤 팀들은 추정(estimation)에 고전합니다. 스토리 포인트는 추정 작업에 건전한 틀을 제공합니다. 팀과 무언의 추정 silent estimation이 라는 활동에 참가해 보십시오. 먼저 화이트 보드에 세로 칸을 나눠 스토리 포인트 값(0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100)을 적습니다. 그런 다음, 팀원들에게 가장 타당하다고 생각하는 칸에 사용자 스토리를 배치하도록 합니다. 대부분의 스토리가 한 숫자에 몰릴 것입니다. 그리고 만약 스토리 포인트 값에 이견이 있다면 그 이유에 대해 토론해 봅니다.

스텝 3: 실제 스프린트 계획 미팅

스프린트 계획 미팅의 촛점은 스프린트 목표 (스프린트 동안 마칠 수 있으리라 팀원들이 믿는 작업의 양) 를 설정하고 의견을 같이하는 것입니다. 제품 책임자, 스크럼 마스터, 그리고 전체 개발 팀 모두가 참석해야 합니다. 

Atlassian은 미팅에서 다룰 스프린트에 대해 각 주(week)별로 적어도 한 시간씩 할애하도록 권장합니다. 예를 들어 두 주짜리 스프린트에 대한 스프린트 계획 미팅은 두 시간으로 잡고 시작합니다. 스프린트 계획은 주 초로 날을 잡는 것이 이상적입니다. 그렇게 하면 주말까지 팀의 컨텍스트와 작업 흐름은 방해를 덜 받습니다.

경험을 통해 배운 것: 스프린트 회고전과 스프린트 계획 미팅을 함께 하지 마십시오. 팀이 회고전을 소화할 충분한 시간적 여유를 두어 효과적으로 스프린트 계획에 참여할 수 있도록 하십시오 - 점심식사 시간을 그 사이에 끼우는 것도 좋습니다.

미팅을 시작할 때, 스크럼 마스터는 팀의 회고전과 관련된 실천 항목을 제시합니다. 그 다음, 제품 책임자가 제품이나 시장에 대한 최신 정보를 알려주어 모든 참가자가 같은 정보를 공유하고 폭넓게 맥락을 이해할 수 있도록 합니다.    

결과 보고 후, 제품 책임자가 주축이 되어 실제 계획에 대한 대화를 시작합니다. 대화를 시작하며 제품 책임자는 팀의 평균 벨로시티 (보통 1 스프린트에 완료된 작업의 양)를 사용해 스프린트 동안 작업할 한 세트의 스토리를 편집합니다. 이를 "스프린트 예측"이라고 하는데, 고객에게 전달할 가치를 최대화 하도록 합니다. 제품 책임자가 또한 고려해야 할 세 가지 요인은 다음과 같습니다:

  • 공휴일, 휴가, 팀 전체 행사
  • 백로그에서 스토리의 우선순위 (이상적으로, 가장 상위에 랭크되어 있는 항목을 추천) 
  • 주력 작업이 어떻게 제품을 최종 목표에 도달하도록 할 것인가 (그리고 도달할 수 있는가) 

프로 팁: 제품 책임자는 스프린트 마커를 사용해 벨로시티를 계산할 수 있습니다.

만약 신생 팀이라 기존 벨로시티 데이터가 없다면, 제품 책임자는 스프린트 예측을 제안할 수 없습니다. 대신 팀 전체 활동을 할 수 있는데, 각 구성원의 동의가 중요하기 때문입니다. 첫 단계로, 팀은 예측에 관해 최선의 판단을 내리고, 몇 개의 스프린트 동안 시행착오를 겪으며 일합니다. 일단 팀의 벨로시티 (JIRA의 벨로시티 차트에 의해 멋지게 시각화된) 가 수치로 구축되면, 그 수치를 스프린트 예측에 사용합니다.  

velocity

한번 제품 책임자가 스프린트 예측에 대한 아이디어를 제시하면, 팀은 그것을 승인(그리고/혹은 조정)하고 스프린트를 위한 실천 계획에 합의할 수 있습니다. 


프로 팁: 팀에서는 각 스프린트의 기술적 부채(technical debt )를 줄일 방법을 고려해야 합니다. 팀 백로그 상의 버그를 하일라이트 표시해주는 퀵 필터 quick filter를 만드는 것은 팀이 코드 베이스의 다양한 영역 안의 사용자 스토리에 대한 작업에 착수할 때 중요한 버그를 스프린트에 들어오도록 하일라이트하는 손쉬운 방법입니다. "기술 부채" 퀵 필터는 버그에 대한 뷰를 제한하기 위해 JQL "(버그) 입력"을 사용합니다. 추가적인 이슈 타입을 포함시킬 필요가 있다면 JQL 쿼리를 확장하기만 하면 됩니다.

 

스프린트 계획의 다음 단계는 스토리를 검토하고 각 스토리를 완성하기 위해 요구되는 작업이 무엇인지 적는 것입니다. 팀 계획으로서, 누군가가 각 JIRA 티켓 안의 핵심 포인트를 잡아내야 합니다. 그렇게 하면 결정과 근거 모두를 나중에 확인하기 쉽습니다. 팀에서는 다음과 같은 질문들을 검토해야 합니다... 

  • 스토리의 정의가 그것을 적은 이후로 달라졌는가? 팀에서 검토해야 할 새로운 문맥상의 정보가 있는가? 
  • 스토리의 추정은 여전히 유효한가? 전체 팀원이 그 추정에 합의하는가? 그렇지 않다면, 스크럼 마스터는 재 추정을 통해 팀을 안내해야 합니다.  
  • 이 스토리를 끝마치기 위해 어떤 태스크가 요구되는가? 서브 태스크를 이용해 작업을 비교하고 흐름을 최적화합니다. 만약 팀이 작업을 나눌수 있는 고유한 스토리를 발견한다면, 그 태스크를 독립된 스토리로 격상시킵니다.
  • 이 스토리의 테스팅 결과는 무엇인가? 어떻게 테스팅을 자동화할 수 있는가?(매뉴얼 테스트 스크립트는 근본적으로 기술 부채임을 기억하자.)
  • 전문가 기술 파트가 요구되는가? 어떻게 하면 다른 팀원을 방해하지 않고 전문가의 시간을 최적화할 수 있는가?
  • 이 스토리가 제품 아키텍쳐에 어떻게 영향을 미치는가? 팀이 설계와 코드 리뷰에 참여시킬 필요가 있는 특정 인물이 있는가?
  • 스토리 사이에 종속성이 존재하는가? 이러한 종속성들을 고려해 볼 때 스프린트 동안 모든 작업을 완료할 수 있는가? 

이런 상세한 활동을 건너 뛰고 싶은 강한 충동이 생깁니다. 하지만 일단 스프린트가 시작되면 잘 짜여진 계획에는 많은 이득이 따릅니다. 여기서의 촛점은 어떻게 작업을 끝낼 것인지 이해하는 것인데, 스크럼 마트터는 팀원 간의 대화를 촉진해야 합니다. 모든 이들이 듣는 것이 중요한데, 이렇게 하면 일단 계획이 시작되면 팀이 주인의식을 갖게 되기 때문입니다. 


프로 팁: 스프린트 계획을 하는 동안, 팀이 스프린트 예측을 만들면서 스프린트에 스토리를 넣고 빼는 것이 간단합니다. 스프린트에 넣거나 뺄 때 이슈를 우클릭 하기만 하면 됩니다. 

 

4. 준비하시고, 출발!

미팅의 이러한 관점에서, 팀은 스프린트 예측을 편안하게 생각해야 합니다. 스프린트의 끝에 팀이 실제로 무엇을 선적하도록 전념할 것인지에 대해 스프린트 계획을 마치면서 회의실 안의 모두에게 구두 승인을 받는 것도 좋은 방법입니다. 또한, 각 팀원이 적어도 한 가지의 태스크를 갖도록 하고 일이 중복되는 사람이 없도록 하십시오.

팀 업무와 사기는 자연스레 스프린트마다 등락을 거듭합니다. 이러한 변화는 스프린트 계획에서 자주 드러나지만, 그것을 바로 그때 그 자리에서 파들어가고 싶은 유혹을 물리치십시오. 대신에, 팀의 회고전을 이용해 어떤 이슈가 팀 사기에 영향을 미쳤는지 이해해 봅니다. 문화와 개발 관심사에 빨리 반응하는 팀이 더 행복하고, 더 생산성 있으며, 더 좋은 코드를 씁니다. 

여러분의 팀은 스프린트 계획에 어떤 비책을 사용하십니까? 댓글을 남겨 여러분의 생각을 공유해 주세요!

 

Dan Radigan에 대하여

플로피 디스크 (여러분도 아시는, 바로 그 5.25 인치의 플로피 디스크)를 쓰던 시절부터 소프트웨어는 제게 열정이 되었습니다. 코드와 삶 모두에서 최선의 경험은 애자일이라는 것을 배운 것처럼, 애자일은 제게 직업적으로 그리고 개인적으로 큰 충격을 주었습니다. 여러분은 기술, 사진, 그리고 오토바이 타기의 교차로에서 저를 만나실 수 있을 겁니다. 트위터에서 저를 찾으세요: @danradigan

View all posts by Dan Radigan »

 

Atlassian의 회고전: 어떻게 이루어지는가


 

애자일을 시작하고 싶으신가요?

이전부터 있던 GreenHopper 제품에 대해 이제야 안내를 하는 것은 여러가지 이유가 있습니다.

우선 GreenHopper 가 무엇인지 모르는 분을 위해 간단해 설명드리면 JIRA 를 기반으로 하여 애자일 개발환경을 구현해주는 JIRA 플러그인입니다.

아래 영상을 통해 GreenHopper 가 어떻게 Agile 도구로 사용될 수 있는지를 보시기 바랍니다.

 

 

(주) 골드피처

GreenHopper에 대해 안내하기 전에 먼저 애자일이 무엇인지 알아야 하는 분이 계시다면 ScrumSprint 나 Backlog 그리고 Kanban 등에 대해 먼저 공부해 보실 수도 있으며 이미 많은 자료들이 인터넷에 나와 있습니다.

그렇지만 국내 개발현실에서 개념적인 자료나 도서를 읽고 그것을 바로 실제 프로젝트에 도입하는 분이 과연 얼마나 있을 지 의문이 됩니다. 

그래서 다음과 같은 방법으로 실질적인 툴을 통해 접근해 보시는 것은 쉽게 가능하지 않을까 생각됩니다.

 

  1. JIRA 를 이용하여 프로젝트의 이슈와 프로젝트 관리를 수행 (tick) 이미 사용하고 있다면 바로 아래로 넘어가시면 됩니다.
  2. GreenHopper-제품 (JIRA 플러그인) 를 JIRA에 설치 (tick) 라이센스를 구매하시거나 평가 라이센스를 이용하십시요.
  3. 현재의 프로젝트에 대한 Scrum 혹은 Kanban 보드 생성 (tick) 애자일개념이 전혀 없다면 일단 Kanban으로 시작하십시요.
  4. Kanban (or Scrum) 보드를 이용하여 프로젝트 진행사항의 시작화 (tick) 이 부분이 제일 중요하며 팀 혹은 회사사람들이 자주 왕래하는 곳에 큰 모니터를 설치해 모두 볼 수 있게 해야 합니다.

 

애자일 개발 방법론에는 여러가지가 있을 수 있지만 현재 GreenHopper 에서 지원하는 방법론은 Scrum과 Kanban 두가지 입니다.

이 두가지 방법에 대한 자세한 설명이나 비교는 다른 여러자료들을 참조해 보시기 바라며 이 글은 GreenHopper 에서 이 두가지 방법론을 JIRA 위에서 구현해 놓았는지를 위의 동영상으로 확인보는 것을 먼저 권해 드립니다.

그리고 Scrum에 관해서는 Scrum을 책읽는데 적용해보기 라는 블로그글을 참조해 보시면 대략 감을 잡으실 수 있으실 것입니다.

 

가장 중요한 점은 프로젝트의 진행사항에 대한 시각화를 위한 보드 사용이라는 점과 이 보드를 프로젝트 진행자들 모두가 수시로(지나다니면서도) 확인가능하도록 하는 것입니다.

이것은 마치 드라마감독이 한편의 드라마 시나리오를 구성할 때 커다란 보드에 포스트잇으로 각 주인공의 스토리를 구성하는 아래의 방식과 유사합니다. (배우는 프로젝트 이슈로 보고 매월(시간)은 이슈의 상태로 보면 될 것입니다)

이렇게 하면 글로서 드라마의 내용을 모두 읽어보지 않고도 핵심적인 내용을 아래의 보드만 보고도 대략 알 수 있는 것과 같이 프로젝트도 마찬가지가 되는 것입니다.

 

 2012.112012.122013.012013.022013.03
주인공 AA와 B,C만남A와 C대립 A와 B 대립A와 B의 결혼
주인공 BA와 B만남B와 C만남   
등장인물 CA와 C만남 교통사고기억회복미국으로 이민

 

 

애자일 이라는 것이 익숙하지 않은 사람도 GreenHopper 툴을 사용하다보면 자연스럽게 개념을 잡아 나갈 수 있을 것입니다.

 

GreenHopper가 나온지 꽤 오래 되었음에도 여태까지 소개글이 없었던 것은 애자일 개념을 모르고는 GreenHopper를 사용하기 너무 어려운 부분이 있었기 때문입니다.

하지만 최근 GreenHopper 가 버전 6 로 업그레이드 되면서 기존의 JIRA 사용자들이 매우 쉽게 애자일 개념을 몰라도 일단 사용이 가능할 정도로 기능이 향상되었습니다.

 

이제는 JIRA의 대시보드와 GreenHopper의 Scrum 혹은 Kanban 보드를 화면에 띄어놓고 사용하는 것이 얼마나 유용한지 직접 체험해 보십시요.