2020.02.25

애자일 팀이 스프린트 약속을 지키는 5가지 방법

Isaac Sacolick | InfoWorld
스크럼 팀(Scrum teams)의 기본적인 작업 방식은 스프린트(Sprint)의 시작에서 우선 순위가 높은 작업을 할당한 다음, 스프린트가 완료될 때 해당 작업을 완전히 마치는 것이다. 

유능한 애자일 팀은 스프린트 약속을 초과 달성하고 스프린트의 끝에 기능하는 소프트웨어를 제공한다. 또한 속도를 측정하고 회고 미팅(retrospective meetings)에서 품질과 생산성 및 기타 척도를 개선하기 위한 프로세스 개선에 대해 토론한다.

그러나 약속을 이행하기는 간단한 일이 아니며 방해가 되는 장애물도 많다. 예를 들면 다음과 같은 과제가 있다.
 
  • 새로운 구성원으로 새롭게 구성된 팀은 작업 스타일, 협업 방법, 스킬 숙련도 등을 파악해야 한다. 신규 팀은 대부분의 경우 작업 리듬이 형성될 때까지는 속도를 측정할 수 없다.
  •  
  • 새로운 기술을 다루는 팀은 스토리를 정확히 분류하고 추정하는 방법을 알지못할 가능성이 높다. 마찬가지로, 레거시 기술과 코드 베이스 또는 빌드 및 배포 프로세스에 대한 기술 간극을 다루는 팀 역시 추정에 애를 먹을 수 있다.
  •  
  • 까다로운 제품 소유자 및 비즈니스 문화에 대처해야 하는 팀은 압박감에 스스로의 역량을 넘어서는 약속을 하게 된다.
  •  
  • 팀이 스스로의 제한 요소를 철저히 이해하지 못하는 경우가 종종 있다. 공휴일, 기업 회의 또는 기타 개인적인 일로 인해 업무를 할 수 없는 경우가 있다.
  •  
  • 프로덕션 시스템이 비교적 안정적이라면 애자일 팀은 일반적으로 프로덕션 사고를 지원하기 위해 개발 활동에서 얼만큼의 시간을 빼야 할지 추정할 수 있다. 그러나 추정일 뿐이며 경우에 따라 애자일 팀 전체가 프로덕션 문제 해결이나 근본 원인 조사에 상당한 시간을 투입해야 하는 경우도 있다.

애자일 팀과 일해본 필자의 경험으로 보면, 애자일 팀은 항상 이 가운데 몇 가지 문제와 씨름한다. 팀이 약속을 이행하고 속도를 높이는 경우에도 새로운 요구사항이 발생한다. 그러나 팀의 약속 이행을 방해하는 알 수 없는 부분이나 위험, 외부 이벤트를 관리하는 데 도움이 되는 도구와 실행 방안이 있다.

스크럼 팀이 스프린트 약속을 더 효과적으로 이행하는 데 활용할 수 있는 5가지 실행 방안은 다음과 같다.

1. 스크럼 미팅 중 팀 협업 개선하기
팀이 우선 순위를 검토하고 약속을 정하고 작업 현황을 추적하고 결과를 검토하고 프로세스 개선을 논의하는 데 도움이 되는 몇 가지 표준 스크럼 미팅이 있다. 각 미팅에서 팀은 약속에 대해 다양한 토론을 실시해야 한다.

스프린트 계획 미팅에서 애자일 팀은 사용자 스토리의 의도와 수락 기준을 검토하고 스토리 포인트의 크기를 최종 확정한다. 애자일 팀은 스스로 이해하지 못하는 스토리에 대해 약속을 하지 말아야 하며 복잡한 스토리는 더 작은 스토리로 분할해야 한다.

스크럼 스탠드업에서 스크럼 마스터의 가장 중요한 역할은 스토리 완료를 지연시키는 장애물을 제거하는 것이다.

마지막으로, 팀은 회고 미팅에서 약속 이행과 누락, 방해 요소에 대해 토론해야 한다. 팀이 약속을 이행하지 못하고 하나 이상의 스토리를 마치지 못한 경우, 약속과 스프린트 내의 의사 결정을 저해한 요소를 살펴보고 다음 스프린트를 위한 개선 방안을 생각해야 한다.

2. 스파이크를 사용해 기술 위험에 대처
스파이크(Spike)는 기술적으로 알 수 없는 부분과 위험을 검증하도록 고안된 사용자 스토리다. 스파이크가 성공할 때 얻는 비즈니스 가치는 제품 소유자가 우선 순위화한 사용자 스토리를 설계 또는 제공하는 방법에 대한 지식이다. 스파이크의 목적은 리서치를 수행하는 데 있고 많은 경우 시간이 정해져 있으므로 원하는 결과를 달성하지 못할 수도 있다.

수준이 높은 애자일 팀은 스파이크를 사용해 새로운 기술을 리서치하고 새로운 기술 구현을 테스트하거나 코드의 레거시 부분에 대한 기술적 가정을 검증한다. 성능과 안정성에 관한 엄격하고 비기능적인 수락 조건이 있는 코드를 개발하는 경우, 스파이크를 만들어 설계를 구현하고 테스트할 수 있다. 애자일 팀은 전체 개념 증명을 기술 및 설계 패턴을 확인하기 위해 고안된 일련의 스파이크로 정의할 수 있다.

3. 사용자 스토리를 더 작고 쉬운 단위로 분할
사용자 스토리를 작성할 때 고객 또는 최종 사용자에게 가치를 제공하기 위해 필요한 전체 기능으로 초안을 작성하는 것이 제품 소유자나 비즈니스 분석가에게는 더 편리하다. 그러나 이 스토리를 검토하고 구현을 세분화하는 애자일 팀 관점에서는 스토리의 수락 기준을 충족하기 위해 여러 가지 기능에 엔지니어링이 필요하다는 점을 인식하는 경우가 많다.

사용자 스토리의 복잡성을 인지하는 경우 일부 팀은 많은 수의 스토리 포인트를 추정한다. 스크럼 팀에 따라 다른 접근 방식을 취하기도 한다. 긴 스토리를 받은 다음 작은 스토리로도 애자일의 비즈니스 가치 제공 원칙을 충족할 수 있는 경우 분할한다. 이렇게 하면 더 작은 스토리의 완료 가능성을 높이고 팀에 여러 스프린트에 걸쳐 작업을 분할할 수 있는 선택권을 제공할 수 있다.

사용자 스토리를 분할할 수 없다면 시간을 투자해 작업 분류를 정의해야 한다. 분류는 스크럼 팀에서 필요한 작업에 대한 공동의 이해를 확보하는 데 도움이 되며, 작업을 할당할 수 있게 해주고 작업의 각 부분을 동시에 실행할 수 있는 기회를 열어준다.

4. 과도한 약속 대신 얕은 약속 
많은 애자일 팀은 제품 소유자로부터 매 스프린트에서 더 많은 스토리를 약속해야 한다는 압박감을 느낀다. 일부 애자일 팀은 스프린트 약속은 협상 대상이라고 생각하지만, 속도를 높이고 릴리스 날짜를 맞추거나 기술 부채를 해결하기 위해 더 많은 스토리를 약속해야 한다고 스스로 부담을 짊어지는 팀도 있다.

또 다른 옵션도 있다. 일부 애자일 팀은 완료 확실성이 높은 수의 스토리와 스토리 포인트를 약속한다. 그런 다음 여러 스토리를 ‘얕은 곳’에 두고, 예상보다 일찍 약속된 스토리를 완료한 경우에 한해 이 스토리를 끄집어 낸다.

필자는 까다로운 제품 소유자와 함께 일할 때 이 전술이 효과가 있음을 직접 확인했다. 협상에서 최소한 부분적인 승리라도 챙길 수 있기 때문이다. 또한 속도를 높이고자 하는 팀은 우선 순위가 높은 사용자 스토리에 대한 책임을 놓칠 위험 없이 얕은 약속을 할 수 있다.

5. 가장 높은 우선 순위를 완료하기 위한 스워밍(Swarming)
스프린트를 시작할 때 대부분의 스크럼 팀은 약속된 스토리를 검토하고 소유권을 할당하고 팀 구성원들에게 작업을 위임한다. 애자일 자기 조직 팀은 작업을 할당하기 위한 효율적인 방법을 찾는다. 지라(Jira) 및 애저 데브옵스(Azure DevOps)와 같은 툴로 할당을 공식화하는 팀도 있고 스크럼 스탠드업을 사용해 검토하는 팀도 있다.

자연스럽고 합리적인 한 가지 방법은 분할 정복(divide and conquer)이다. 스프린트 시작 시점에 여러 스토리가 할당되고 시작된다. 사용자 스토리의 우선 순위가 상호 비슷하고 스토리가 비교적 작으며 상호종속성이 거의 없을 경우 효과적이다.

우선 순위가 높고 복잡한 스토리를 다루는 팀을 위한 다른 기법은 스워밍이다. 팀을 여러 스토리에 걸쳐 분할하는 대신 무리를 이뤄(스워밍) 가장 우선 순위가 높은 스토리를 먼저 완료한다. 스워밍은 스크럼 팀 생산성을 높이고 가장 높은 스프린트 우선 순위 완료에 실패할 위험을 낮춰준다.

스크럼 팀은 스프린트 약속을 계획, 이행, 완료할 때 여러 실행 방안의 조합을 고려해야 한다. 이러한 실행 방안을 사용하는 애자일 팀은 먼저 약속에 대한 확신을 구축한 다음 약속 이행 성공률을 높인다. 그런 다음에 스프린트 속도를 높일 기회를 찾는다. editor@itworld.co.kr 


2020.02.25

애자일 팀이 스프린트 약속을 지키는 5가지 방법

Isaac Sacolick | InfoWorld
스크럼 팀(Scrum teams)의 기본적인 작업 방식은 스프린트(Sprint)의 시작에서 우선 순위가 높은 작업을 할당한 다음, 스프린트가 완료될 때 해당 작업을 완전히 마치는 것이다. 

유능한 애자일 팀은 스프린트 약속을 초과 달성하고 스프린트의 끝에 기능하는 소프트웨어를 제공한다. 또한 속도를 측정하고 회고 미팅(retrospective meetings)에서 품질과 생산성 및 기타 척도를 개선하기 위한 프로세스 개선에 대해 토론한다.

그러나 약속을 이행하기는 간단한 일이 아니며 방해가 되는 장애물도 많다. 예를 들면 다음과 같은 과제가 있다.
 
  • 새로운 구성원으로 새롭게 구성된 팀은 작업 스타일, 협업 방법, 스킬 숙련도 등을 파악해야 한다. 신규 팀은 대부분의 경우 작업 리듬이 형성될 때까지는 속도를 측정할 수 없다.
  •  
  • 새로운 기술을 다루는 팀은 스토리를 정확히 분류하고 추정하는 방법을 알지못할 가능성이 높다. 마찬가지로, 레거시 기술과 코드 베이스 또는 빌드 및 배포 프로세스에 대한 기술 간극을 다루는 팀 역시 추정에 애를 먹을 수 있다.
  •  
  • 까다로운 제품 소유자 및 비즈니스 문화에 대처해야 하는 팀은 압박감에 스스로의 역량을 넘어서는 약속을 하게 된다.
  •  
  • 팀이 스스로의 제한 요소를 철저히 이해하지 못하는 경우가 종종 있다. 공휴일, 기업 회의 또는 기타 개인적인 일로 인해 업무를 할 수 없는 경우가 있다.
  •  
  • 프로덕션 시스템이 비교적 안정적이라면 애자일 팀은 일반적으로 프로덕션 사고를 지원하기 위해 개발 활동에서 얼만큼의 시간을 빼야 할지 추정할 수 있다. 그러나 추정일 뿐이며 경우에 따라 애자일 팀 전체가 프로덕션 문제 해결이나 근본 원인 조사에 상당한 시간을 투입해야 하는 경우도 있다.

애자일 팀과 일해본 필자의 경험으로 보면, 애자일 팀은 항상 이 가운데 몇 가지 문제와 씨름한다. 팀이 약속을 이행하고 속도를 높이는 경우에도 새로운 요구사항이 발생한다. 그러나 팀의 약속 이행을 방해하는 알 수 없는 부분이나 위험, 외부 이벤트를 관리하는 데 도움이 되는 도구와 실행 방안이 있다.

스크럼 팀이 스프린트 약속을 더 효과적으로 이행하는 데 활용할 수 있는 5가지 실행 방안은 다음과 같다.

1. 스크럼 미팅 중 팀 협업 개선하기
팀이 우선 순위를 검토하고 약속을 정하고 작업 현황을 추적하고 결과를 검토하고 프로세스 개선을 논의하는 데 도움이 되는 몇 가지 표준 스크럼 미팅이 있다. 각 미팅에서 팀은 약속에 대해 다양한 토론을 실시해야 한다.

스프린트 계획 미팅에서 애자일 팀은 사용자 스토리의 의도와 수락 기준을 검토하고 스토리 포인트의 크기를 최종 확정한다. 애자일 팀은 스스로 이해하지 못하는 스토리에 대해 약속을 하지 말아야 하며 복잡한 스토리는 더 작은 스토리로 분할해야 한다.

스크럼 스탠드업에서 스크럼 마스터의 가장 중요한 역할은 스토리 완료를 지연시키는 장애물을 제거하는 것이다.

마지막으로, 팀은 회고 미팅에서 약속 이행과 누락, 방해 요소에 대해 토론해야 한다. 팀이 약속을 이행하지 못하고 하나 이상의 스토리를 마치지 못한 경우, 약속과 스프린트 내의 의사 결정을 저해한 요소를 살펴보고 다음 스프린트를 위한 개선 방안을 생각해야 한다.

2. 스파이크를 사용해 기술 위험에 대처
스파이크(Spike)는 기술적으로 알 수 없는 부분과 위험을 검증하도록 고안된 사용자 스토리다. 스파이크가 성공할 때 얻는 비즈니스 가치는 제품 소유자가 우선 순위화한 사용자 스토리를 설계 또는 제공하는 방법에 대한 지식이다. 스파이크의 목적은 리서치를 수행하는 데 있고 많은 경우 시간이 정해져 있으므로 원하는 결과를 달성하지 못할 수도 있다.

수준이 높은 애자일 팀은 스파이크를 사용해 새로운 기술을 리서치하고 새로운 기술 구현을 테스트하거나 코드의 레거시 부분에 대한 기술적 가정을 검증한다. 성능과 안정성에 관한 엄격하고 비기능적인 수락 조건이 있는 코드를 개발하는 경우, 스파이크를 만들어 설계를 구현하고 테스트할 수 있다. 애자일 팀은 전체 개념 증명을 기술 및 설계 패턴을 확인하기 위해 고안된 일련의 스파이크로 정의할 수 있다.

3. 사용자 스토리를 더 작고 쉬운 단위로 분할
사용자 스토리를 작성할 때 고객 또는 최종 사용자에게 가치를 제공하기 위해 필요한 전체 기능으로 초안을 작성하는 것이 제품 소유자나 비즈니스 분석가에게는 더 편리하다. 그러나 이 스토리를 검토하고 구현을 세분화하는 애자일 팀 관점에서는 스토리의 수락 기준을 충족하기 위해 여러 가지 기능에 엔지니어링이 필요하다는 점을 인식하는 경우가 많다.

사용자 스토리의 복잡성을 인지하는 경우 일부 팀은 많은 수의 스토리 포인트를 추정한다. 스크럼 팀에 따라 다른 접근 방식을 취하기도 한다. 긴 스토리를 받은 다음 작은 스토리로도 애자일의 비즈니스 가치 제공 원칙을 충족할 수 있는 경우 분할한다. 이렇게 하면 더 작은 스토리의 완료 가능성을 높이고 팀에 여러 스프린트에 걸쳐 작업을 분할할 수 있는 선택권을 제공할 수 있다.

사용자 스토리를 분할할 수 없다면 시간을 투자해 작업 분류를 정의해야 한다. 분류는 스크럼 팀에서 필요한 작업에 대한 공동의 이해를 확보하는 데 도움이 되며, 작업을 할당할 수 있게 해주고 작업의 각 부분을 동시에 실행할 수 있는 기회를 열어준다.

4. 과도한 약속 대신 얕은 약속 
많은 애자일 팀은 제품 소유자로부터 매 스프린트에서 더 많은 스토리를 약속해야 한다는 압박감을 느낀다. 일부 애자일 팀은 스프린트 약속은 협상 대상이라고 생각하지만, 속도를 높이고 릴리스 날짜를 맞추거나 기술 부채를 해결하기 위해 더 많은 스토리를 약속해야 한다고 스스로 부담을 짊어지는 팀도 있다.

또 다른 옵션도 있다. 일부 애자일 팀은 완료 확실성이 높은 수의 스토리와 스토리 포인트를 약속한다. 그런 다음 여러 스토리를 ‘얕은 곳’에 두고, 예상보다 일찍 약속된 스토리를 완료한 경우에 한해 이 스토리를 끄집어 낸다.

필자는 까다로운 제품 소유자와 함께 일할 때 이 전술이 효과가 있음을 직접 확인했다. 협상에서 최소한 부분적인 승리라도 챙길 수 있기 때문이다. 또한 속도를 높이고자 하는 팀은 우선 순위가 높은 사용자 스토리에 대한 책임을 놓칠 위험 없이 얕은 약속을 할 수 있다.

5. 가장 높은 우선 순위를 완료하기 위한 스워밍(Swarming)
스프린트를 시작할 때 대부분의 스크럼 팀은 약속된 스토리를 검토하고 소유권을 할당하고 팀 구성원들에게 작업을 위임한다. 애자일 자기 조직 팀은 작업을 할당하기 위한 효율적인 방법을 찾는다. 지라(Jira) 및 애저 데브옵스(Azure DevOps)와 같은 툴로 할당을 공식화하는 팀도 있고 스크럼 스탠드업을 사용해 검토하는 팀도 있다.

자연스럽고 합리적인 한 가지 방법은 분할 정복(divide and conquer)이다. 스프린트 시작 시점에 여러 스토리가 할당되고 시작된다. 사용자 스토리의 우선 순위가 상호 비슷하고 스토리가 비교적 작으며 상호종속성이 거의 없을 경우 효과적이다.

우선 순위가 높고 복잡한 스토리를 다루는 팀을 위한 다른 기법은 스워밍이다. 팀을 여러 스토리에 걸쳐 분할하는 대신 무리를 이뤄(스워밍) 가장 우선 순위가 높은 스토리를 먼저 완료한다. 스워밍은 스크럼 팀 생산성을 높이고 가장 높은 스프린트 우선 순위 완료에 실패할 위험을 낮춰준다.

스크럼 팀은 스프린트 약속을 계획, 이행, 완료할 때 여러 실행 방안의 조합을 고려해야 한다. 이러한 실행 방안을 사용하는 애자일 팀은 먼저 약속에 대한 확신을 구축한 다음 약속 이행 성공률을 높인다. 그런 다음에 스프린트 속도를 높일 기회를 찾는다. editor@itworld.co.kr 


X