애자일(Agile)과 스크럼(Scrum)과 지라(JIRA) 이야기

오늘은 애자일(Agile), 스크럼(Scrum), 지라(JIRA)에 대해서 이야기해보려고 합니다. "애자일을 적용하여 개발하자!", "스크럼 프로세스를 통해서 개발하자!" 을 외치면서 진정 우리가 이렇게 일하고 있는가? 돌이켜 보게 되었는데요. 이번 기회에 애자일과 스크럼에 대해서 정확하게 이해하려고 노력하였으나 생각보다 잘 정리된 내용을 찾지 못해서 여러가지 자료들을 종합하여 현재 제 수준에서 정리해보았습니다. 아래 내용의 많은 부분은 다른 훌륭한 분들의 생각 중에 제가 동의하는 내용을 가지고 왔습니다.
(최대한 출처를 남겼는데요. 혹시 실제와 다르거나 잘못된 점이 있거나 문제가 된다면 알려주세요. ^^;)

 

• 애자일 소프트웨어 개발

• 용어 이해하기 (지라 기반으로 용어 소개)

 

 

<애자일 소프트웨어 개발>

애자일(Agile)에 대해서는 그 어떤 설명보다도 아래 2가지 글을 보고 곰곰히 생각해보는 것이 가장 중요합니다.

• 애자일 소프트웨어 개발 선언 - http://agilemanifesto.org/iso/ko/manifesto.html

• 애자일 선언 이면의 원칙 - http://agilemanifesto.org/iso/ko/principles.html

 

 

<애자일과 스크럼>

가끔 대화를 나누다보면 애자일과 스크럼을 동일한 개념으로 사용하는 분을 만나게 됩니다. 하지만 이 글을 보신 분이라면 애자일과 스크럼을 구분하실 수 있으실 겁니다. 애자일과 스크럼은 비슷한 것 같지만 사실 다른 레이어의 용어입니다. 애자일과 같은 레이어의 단어는 워터폴(Waterfall)이라는 개념일 것 같고요. 스크럼과 같은 레이어의 단어는 칸반(Kanban)입니다. (참고: 애자일 방법론의 종류)

 

 

(참고) 애자일 소프트웨어 개발 https://ko.wikipedia.org/wiki/애자일_소프트웨어_개발
(참고) Agile Vs. Waterfall in Software Development https://saigontechnology.com/blog/agile-vs-waterfall-in-software-development

 

<애자일 방법론의 종류>

• Scrum

• Kanban

• Lean

• Extreme Programming (XP)

• Feature Driven Development (FDD)

• Dynamic Software Development Method (DSDM)

 

(참고) Introduction To Agile Development https://www.softwaretestinghelp.com/agile-scrum-methodology-for-development-and-testing/
(참고) Agile Methodology & Model: Guide for Software Development & Testing https://www.guru99.com/agile-scrum-extreme-testing.html

 

<스크럼>

다음은 스크럼인데요. 스크럼(Scrum)은 프로젝트관리를 위한 상호,점진적 개발방법론이며, 애자일 소프트웨어 공학 중의 하나입니다. 스크럼(Scrum)은 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있습니다. (=> 애자일과 스크럼은 같은 의미가 아니고 애자일 방법론 중의 하나가 스크럼)

 

 

(참고) SCRUM Process https://brainhub.eu/blog/differences-lean-agile-scrum/
(참고) Introduction To Agile Development https://www.softwaretestinghelp.com/agile-scrum-methodology-for-development-and-testing/

 

<스크럼에서 사용하는 용어>

• 스프린트 (Sprint): 반복적인 개발 주기. 계획 회의부터 제품 리뷰가 진행되는 날짜까지의 기간이 1 스프린트.
  예) 회사에서 정하는 이터레이션이 개발 주기가 될 수도 있음.
  
  

• 이슈(Issue): 이슈(Issue) 타입은 지라(JIRA) 기반으로 소개합니다.

  • 에픽 (Epic): 에픽은 많은 사용자 스토리, 많은 작은 단위 업무로 나눌 수 있는 업무의 큰 틀. 하나의 Sprint에 걸쳐서 끝나지 않고, 여러 Sprint에 걸쳐서 종료되며, 여러 Story들의 집합. 주로 Major Feature들을 중심으로 정의합니다.

  • 스토리 (Story): 서비스 고객에게 가치를 줄 수 있는 기능을 서술한 것입니다. 각 스토리는 기술적 전문 용어가 아닌 비즈니스 언어로 작성하는 것이 좋습니다.
    예) [(역할을 가진) 사용자]는 [행위 / 목표]를 수행하여 [이유]를 한다.

  • 태스크 (Task): 에픽 or (사용자) 스토리의 하위 작업으로 에픽 / (사용자) 스토리를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업
    예) 유사 기능 조사, 테스트 시나리오 작성 등

  • 서브태스크 (Sub-Task): (사용자) 스토리의 하위 작업으로 에픽 / (사용자) 스토리를 완료하기 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업
    
    

• 백로그 (Backlog)

  • 제품 백로그 (Product Backlog): 제품에 대한 요구사항을 모아둔 곳

  • 스프린트 백로그 (Sprint Backlog): (제품에 대한 요구사항 중에) 해당 스프린트에 진행할(한) 요구사항을 모아둔 곳
    
    

• 스프린트 운영

  • 그루밍 (Grooming): “다음 스프린트에 들어가기 전에 PO(PM)가 다음 스프린트에 개발할 기능에 대해서 대략적으로 리뷰 하는 행위” (스프린트 진행 중에 일어남)
    [WHY]
    - 다음 스프린트에 대한 가시성 확보 (미리 생각할 시간을 줍니다.)
    - 개발 개시 전 리뷰를 통해서 개발 가능성, 기획상 구멍을 찾아서 수정할 시간을 갖음
    [HOW]
    - 1시간 정도로 사용자 스토리나 UX 프로토타입을 리뷰
    - 가급적 실제로 돌아가는 UX 목업이 좋음 (애니메이션 복잡도 등을 미리 예측 가능)
    
    

  • 스토리포인트 미팅 (Story point meeting): 등록된 사용자 스토리의 개발 추정 기간을 산정. 많이 활용하는 개발 추정 도구는 "플래닝 포커". 보통은 제품 백로그(Product Backlog)에 스토리포인트를 추정합니다. 경우에 따라 스프린트 백로그(Sprint Backlog)의 스토리를 다시 추정하기도 합니다.
    (참고) 애자일 스크럼과 JIRA https://www.slideshare.net/Byungwook/jira-61442816

     

  • 플래닝 포커 (Planning poker): 플래닝 포커, 다른 말로 스크럼 포커 라고도 불리는데, 이는 추정을 위한 합의 기반 기술.(consensus-based technique)로써 대부분 소프트웨어 개발에 있어서 개발 목표를 위한 공수 산정이나 상대적 규모산정에 사용된다. 숫자를 숨기는 이런 방식은 구성원들의 편향적인 고정관념을 피할수 있게 해준다. 플래닝 포커는 광대역 델파이(Wideband delphi)의 한 형태라고 합니다.
    (참고) 플래닝 포커 https://ko.wikipedia.org/wiki/%ED%94%8C%EB%9E%98%EB%8B%9D_%ED%8F%AC%EC%BB%A4

• 계획 미팅 (Planning meeting)
  
  The What – PO(PM)가 스프린트의 목표와 어떤 백로그(backlog)가 그 목표에 기여하는지 설명합니다. 스크럼팀은 다음 스프린트 동안에 종료(Done)할 백로그를  결정합니다.
  The How – 개발팀은 스프린트 목표를 달성하기 위한 필요한 작업 계획을 세웁니다. 궁극적으로 스프린트 계획의 목표는 개발팀과 PO(PM) 간의 노력과 가치 기반 협상입니다. (일정 수준의 노력으로 가장 가치가 높은 작업을 선정하고 실행 계획을 세우는 것)
  The Who – 개발팀과 PO(PM)없이 스프린트 계획 미팅을 할 수 없습니다. PO(PM)은 그가 원하는 가치 기반 목표를 정의합니다. 개발팀은 그 목표를 어떻게 달성할 수 있는지 혹은 달성할 수 없는지 이해할 필요가 있습니다. 만약에 둘 중 하나라도 이 이벤트로부터 놓친 것이 있으면 계획 미팅은 거의 불가능합니다.
  The Inputs – 스프린트 계획에서 가장 중요한 시작점은 제품 백로그입니다. 제품 백로그는 잠재적으로 현재 스프린트의 일부가 될 수 있는 ‘스터프(stuff)’ 리스트를 제공합니다. 스크럼팀은 또한 점진적으로 수행된 기존 작업을 살펴보아야 하고 팀이 수행할 수 있는 양(Capacity)에 대해서 고려해야 합니다.
  The Outputs – 스프린트 계획 미팅에서 가장 중요한 산출물은 팀이 스프린트의 목표를 설명할 수 있다는 것과 그들이 목표를 향하고 있는 업무를 어떻게 시작할 수 있는 설명하는 것입니다. 이것이 스프린트 백로그로 보여집니다.
  (참고) Sprint planning https://www.atlassian.com/agile/scrum/sprint-planning
  
  

• 스프린트 리뷰 (Sprint review)
  
  Step 1: 종료기준을 정의합니다. (Define 'done')
  - 받아들일 수 있는 기준 (Aceeptance criteria)
  - 테스트 방법 기록 (Testing notes)
  Step 2: 서로 축하합니다. (Celebrate the team)
  Step 3: 공유합니다. (Reach across geographies)
  (필요하다면) 데모
  (참고) Agile Sprint Reviews https://www.atlassian.com/agile/scrum/sprint-reviews

• 회고 미팅 (Retrospective meeting): 잘한 것, 반성할 것, 개선할 것에 대한 이야기를 나누는 시간
  
  “팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.”
  10 스프린트 회고하기 https://agileit.tistory.com/23
  Agile Retrospectives  https://www.atlassian.com/agile/scrum/retrospectives
  

• 소멸 차트 (Burn down chart): 시간 대비 남아 있는 일의 양을 표현. 작업물 or 백로그(bakclog)를 수직축에 표현하고 수평축에는 시간을 표현함. 즉 작업물의 진행 차트. 모든 작업들이 완료되는 시점을 예측하는데 유용

 

 

 

<마지막으로 항상 기억해야 할 것>

하나의 완벽한 방법은 없고 스프린트를 진행하면서 "일이 되는 방향"으로 스크럼팀이 점진적으로 개선하는 것이 중요합니다.