칸반에서 스크럼까지: 애자일 방법론 선택

Atlassian의 Micros Scale 팀이 칸반에서 스크럼으로 전환한 이유

Nelly Sattari 작성자: Nelly Sattari
주제 찾아보기

건강한 엔지니어링 팀이 되기 위한 한 가지 요소는 스스로 체계화하는 팀이 되는 것입니다. 역할과 책임이 명확하며 신중한 계획을 통해 프로젝트를 제공하는 데 노력하는 팀이 되어야 합니다.

작년에 저희는 Atlassian 내부 개발자 경험 플랫폼인 PaaS(서비스형 플랫폼)를 만드는 데 중점을 둔 Micros Scale이라는 새 팀을 구성했습니다. 작업의 범위가 정해져 있고 타임라인이 명확하기 때문에 더 집중적이고 목표 지향적이며 능동적으로 점진적인 작업을 완료하는 데 더 노력하게 되었습니다.

하지만 이전에는 팀에 임시적인 운영 작업이 많아 스프린트를 제대로 계획하지 못했습니다. 팀 작업 수용량의 최소 55%가 KTLO(운영 유지) 교대에 할당되었습니다. 그래서 그 당시에 저희에게 가장 적합한 방법론은 칸반이었습니다.

Tuckman 모델에 따르면 Micros Scale 팀은 형성 단계에 있었으며 작업 수용량 계획, 스프린트 계획, 목표 설정, 팀 돌아보기, 그루밍 및 스토리 정교하게 만들기, 추정, 프로젝트 세부 사항 등을 포함하여 몇 가지 개선할 영역이 있었습니다.

Tuckman 모델 이미지

어떤 애자일 방법론이 적합했을까요?

Micros Scale에는 매우 복잡하고 고객에게 공개적으로 기한을 발표한 두 개의 주요 프로젝트가 있습니다. 즉, 빠른 제공이 매우 중요합니다. 저희는 제공 방식에 대한 확신이 필요했으며 애자일 전문가처럼 계획을 세우고 싶었습니다. 팀이 스스로 체계화하고 공동의 목표를 달성하고 경험에 의거하기를 바랐습니다.

저희는 다음과 같은 질문을 통해 애자일 접근 방식을 다시 평가했습니다.

  • 매 반복에 대해 목표를 설정하여 고유한 테마를 가진 목표를 제공하는 것이 가능한가?
  • 1~2주 동안 산출물의 범위에 대해 이행 약속을 할 수 있는가?
  • 작업해야 할 요구 사항을 자세히 설명하고 확정할 수 있는가?
  • 작업의 우선 순위를 변경해 달라는 임시 요청의 빈도가 낮고 급격한 변경이 발생할 가능성이 적은가?
  • 팀이 애자일 프로세스를 처음 접하며 성숙도가 낮은가?


이러한 질문에 대한 답이 '예'였기 때문에 팀에 가장 적합한 애자일 방법론은 스크럼이라는 것을 깨달았습니다. 결정을 내리는 데 사용한 추가 세부 정보는 다음과 같습니다.

 

 

 

 

애자일 방법론

무슨 내용인가?

도움이 되는가?

그 이유는 무엇입니까?

스크럼

스크럼은 명확한 로드맵과 우선 순위가 지정된 작업에 관한 것이며 칸반은 팀에 임시로 제기되는 작업을 시각화하는 것입니다.

명확하고 미리 정의된 백로그가 있으며 개선 및 우선 순위 지정이 필요합니다. 갑작스럽고 우선 순위가 높은 요청으로 가득했던 이전의 팀과는 달리 작업이 예측 가능합니다.

스프린트 중간에 스토리를 변경해서는 안 됩니다.

더 유연한 접근 방식을 취할 수 있습니다. 이 경우에는 scrumban(스크럼과 칸반의 하이브리드)입니다.

스크럼은 아직 기능을 중심으로 배우고 있는 애자일 팀에는 더 쉽게 도입할 수 있습니다. 스크럼은 가드레일을 제공하는 리추얼과 기한이 있어 더 규범적입니다.

아직 형성-격동 단계에 있는 새 팀과 새 팀원이 있으므로 스크럼이 있으면 더 성숙해질 수 있습니다. Tuckman 모델에 대해 읽어보세요.

칸반

진행 중인 작업을 제한하고 프로젝트 사이클 타임을 줄이는 데 집중합니다. 사용 사례는 팀에 작업의 시간 제한이 없고 약속한 타임라인이 없는 경우입니다. 요청이 팀에 들어오고 최대한 빨리 처리됩니다(서비스 데스크 팀의 SLA와 같이).

아니요

다른 팀이 우리에게 의존하고 있기 때문에 다른 팀이 계획을 세우는 데 참고할 수 있는 추정 타임라인이 필요합니다. 이행 약속 중 일부는 Atlassian 고객에게 공개적으로 발표되므로 고객을 염두에 두고 계획을 세워야 합니다. 서비스 데스크와 같은 단기 요청이 많지 않습니다.

우선 순위와 크기가 다양한 운영 요청을 많이 받는 팀에 적합합니다.

KTLO 부담이 많지 않고 작업 흐름은 팀 내 한 명의 역할을 통해 교대로 관리합니다. 원하는 경우 방해받는 역할을 칸반으로 실행할 수 있습니다.

스크럼 수용

엔지니어링 매니저의 주요 특징은 연결자, 나침반 및 코치 역할뿐만 아니라 지휘자처럼 행동하는 것이라는 점은 잘 알고 있습니다. 그래서 지휘자로서의 역량을 똑같이 키워야 했습니다. 이 목표를 달성한 방법은 다음과 같습니다.

애자일 관행에 대해 자세히 알아보기

Atlassian의 내부 학습 리소스는 애자일 관행에 대한 기술을 향상시키는 데 도움이 되었습니다. 저는 광범위한 애자일 방법론을 거쳤으며 애자일 코치와 상담했습니다. 다른 조직 및 팀에서 일한 경험에 대해 알아보기 위해 몇 명의 엔지니어링 매니저를 인터뷰했습니다.

DACI 사용

DACI 의사 결정 프레임워크를 사용하여 효과적이고 효율적인 그룹 의사 결정을 내렸습니다. DACI는 "추진자(Driver), 승인자(Approver), 기여자(Contributors), 및 정보 제공(Informed)"의 약자입니다. 팀에게 DACI 변경 제안을 안내하여 팀의 의견, 동의 및 지지를 받았습니다.

스프린트 템플릿 사용

스프린트 관리 프로세스를 생각해냈으며 더 합리적인 계획을 세우는 데 도움이 되도록 각 스프린트마다 템플릿을 만들었습니다. 스프린트 계획 템플릿에는 다음이 포함되어 있습니다.

  • 달성한 것을 명확하게 파악하고 축하하도록 이전 스프린트를 검토하는 방법.
  • 이전 스프린트를 회고 방식으로 되돌아보고 배운 점을 다음 스프린트에 적용하는 방법.
  • 스프린트 케이던스, 이름, 목표 및 목적이 무엇인가?
  • 얼마나 많은 스토리를 제공하기로 이행 약속을 하는가? 스프린트 범위가 무엇인가?
  • 업무 가능 상태를 기반으로 작업 수용량을 계획하는 방법.
  • 다음 스프린트를 위해 완벽하게 준비하려면 스프린트 중반에 어떤 활동이 필요한가?
  • 스토리를 작성하고 요구 사항을 자세히 설명하고 해결하는 방법.
  • 이행 약속을 한 스토리의 상태를 추적하고 완료하지 않은 스토리를 처리하는 방법.

Jira Software에서 스프린트를 사용하는 방법에 대한 유용한 자습서도 있습니다.

스크럼으로 전환하여 얻은 가치

저희는 스크럼으로 전환하여 다음과 같이 개선했습니다.

속도 개선

애자일 방법론에서 팀의 생산성을 측정하는 요소 중 하나는 속도입니다. 속도는 스크럼 팀이 스프린트 중에 완료하는 평균 작업량입니다. 저희는 팀이 무엇에 대한 이행 약속을 했고 어떤 것을 제공했는지 파악하기 위해 속도 차트를 사용합니다. 아래 속도 차트에서 회색 열은 팀이 작업 수용량에 따라 이행 약속을 한 스토리 포인트의 개수를 보여줍니다. 이것을 실제로 제공한 스토리 포인트의 개수인 파란색 열과 비교합니다. 그러면 팀에서 이것을 사용하여 향후 스프린트 예측을 조정할 수 있습니다.

속도 차트

위험을 조기에 파악

프로젝트 성공의 핵심은 위험을 조기에 파악하고 제안된 해결책을 생각해내는 것입니다.

저희는 목표와 스프린트 테마를 정의하면서 목표 달성을 위해 응집력 있는 스토리를 선택했습니다. 스프린트 중반 세션에서 팀은 스토리를 그루밍하고 개선하고 정교하게 만들었습니다. 정교하게 만드는 과정에서 다음과 같이 질문했습니다.

  • 무엇을 완료해야 합니까?
  • 이 일을 하는 이유는 무엇입니까?
  • 어떤 비즈니스 가치가 추가됩니까?

이것을 통해 엔지니어는 종속성을 파악하고 영향이 큰 티켓에 우선 순위를 지정하여 장애물을 제거할 수 있었습니다. 또한 작업 방식을 변경하고 팀이 프로젝트마다 더 효과적으로 집중할 수 있게 되었습니다.

축하하세요! 제공 완료

작업 수용량 계획 및 목표 설정은 의미 있는 동기 부여와 이행 약속을 투명하게 유지하는 데 대한 도전을 가져다 주었습니다. Atlassian PaaS 계정 샤드의 중요한 단계 하나를 성공적으로 제공했습니다. 또한 신뢰성, 복원력 및 컴플라이언스 목적을 위해 더 많은 AWS 리전을 대상으로 데이터 보존 프로젝트의 1단계를 제공할 예정입니다.

형성기에서 규범기로 전환

위에서 설명했듯이 Micros Scale 팀은 비교적 신생 팀이며 Tuckman 모델에 따르면 형성 단계에 있는 편입니다.

팀의 통일된 목표를 정의하는 것은 모두가 팀 목표를 달성하고 팀 동기 부여를 높이기 위해 서로 정렬하고 지원하도록 유도했습니다. 저희는 실패를 통해 되돌아보고 배우고 개선했습니다. 3개월 반 후에 Micros Scale에 50% 더 많은 팀원을 고용했으며 저는 규범기에 있는 이 팀을 자랑스럽게 생각합니다.

커뮤니케이션 개선

계획을 세우고 스프린트마다 전념하는 것은 팀 전체를 위해 무엇을 할 계획인지에 대한 가시성을 높이고 같은 언어를 사용하도록 해주었습니다. 엔지니어링 매니저 및 이해 관계자가 프로젝트 장애와 진행률을 추적하기가 훨씬 쉽습니다.

애자일 방법론을 선택하는 방법

  1. 문제를 발견하면 주저하지 말고 프로세스를 검토하세요. 팀원, 프로세스 및 도구에 대해 애자일한 방법으로 생각하세요.
  2. 팀 프로젝트 및 책임을 평가하여 팀에 가장 적합한 애자일 방법을 찾아보세요. 칸반 및 스크럼 비교 페이지에서 방법에 대해 자세히 알아보세요.
  3. 스크럼으로 전환하기로 결정한 경우 Jira 스크럼 보드를 사용하거나 Confluence 또는 즐겨 사용하는 도구로 템플릿을 만드는 것이 좋습니다.

각 스프린트마다 스프린트 계획 페이지를 만들어 지난 스프린트를 검토하고 되돌아보고 팀의 작업 수용량 및 스프린트 목표에 따라 다음 스프린트를 계획하세요. 제가 개인적으로 사용하는 Confluence 템플릿은 다음과 같습니다.

스프린트 계획 템플릿 이미지

제 전체 스크럼 템플릿에 포함된 작업 수용량 계획 템플릿은 다음과 같습니다.

스크럼 업무 가능 상태

그리고 제 스프린트 목표 및 범위 템플릿은 다음과 같습니다.

스프린트 목표 이미지

스프린트 중반에는 다른 페이지를 만들어 지난 주 동안의 팀 성과를 추적하고, 스프린트의 현재 진행률을 고려하여 다음 스프린트로 이월해야 할 스토리가 무엇인지 파악하고(그루밍이라고 함), 그루밍한 스토리를 자세히 설명(스토리 개선)하는 것이 좋습니다. 제 스프린트 중반 백로그 그루밍 및 개선 템플릿은 다음과 같습니다.

백로그 정리

팀마다 다르기 때문에 저희에게 효과가 있었던 것이 다른 팀에서는 효과가 없을 수도 있습니다. 스크럼이나 칸반, 또는 이 둘을 조합한 것, 예를 들어 scrumban 및 kanplan이 더 나은 방법론일 수도 있습니다. 팀의 특정 요구 사항을 평가하고 어떤 방법론이 팀에 적합한지 파악하는 것이 중요합니다.

다음 단계
애자일 자습서