Jira를 사용한 Agile 개발 방법 #1 - 주요 용어 정리

Agile 개발 방법론을 사용하다보면 정말 내가 사용하는 방법이 맞을까? 라는 생각이 들 수 있다.

사용자 스토리, 작업, 버그, 에픽 등 용어들이 나오면 헷갈리기 시작한다. 여기서는 자주 사용하는 기능들에서 일반적인 용어들을 정리해서 Agile 개발 방법을 이해해 보자.

백로그(Backlog)

문제(Problem)

Jira Software에서는 사용자 스토리(User Stories), 작업(Tasks) 및 버그(Bugs)를 "문제(Issues)"로 정의한다.

사용자 스토리(User Story)

의미
사용자 스토리는 가장 작은 작업 단위로 제품 소유자(PO, Product Owner)가 스케치하면 전체 제품 팀이 세부 요구 사항을 공통적으로 결정한다. 이 요구사항들은 스토리와 곧 나오는 스프린트을 위한 구현 항목을 정의하는데 도움이 되는 세분화 된 작업이다.

백 로그의 각 사용자 스토리에는 기능 코드와 자동화된 테스트 코드가 모두 필요하다. 테스트 팀이 자동화 테스트를 수행하는 동안 일부 팀이 개발자에게 기능 코드를 할당하지만 단일 엔지니어가 전체 세트를 제공하는 것이 더 효과적이라는 것을 알게되었습니다.

형식
As a {type of user}, I want {goal} so that I {receive benefit}.

예제
고객으로서 작년 예산을 돕기 위해 작년에 구매한 항목을 볼 수 있도록 계정을 만들 수 있기를 원합니다.

Agile 추정(Agile Estimation)

의미

첫 번째 스프린트를 시작하기 전에 백 로그의 스토리를 예측하여 작업 완료까지 걸리는 시간을 결정하는 것이 중요하다.

그렇다면 애자일 추정이란 무엇인가? 전통적인 소프트웨어 팀은 일, 주, 달 등의 시간 형식으로 작업 시간을 추정했다. 그러나 많은 Agile 팀은 Story Point로 전환했다. Story Point는 피보나치 수열(0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 ..)과 같이 작업의 상대적인 노력으로 등급을 매긴다. 직관적으로 들리지 않겠지만, 그 추상화는 팀이 업무의 어려움을 둘러싼 더 강력한 결정을 내리도록 강요하기 때문에 실제로 도움이 된다.

예상치는 또한 팀원 수에 따라 다음 스프린트에 추가해야하는 작업량을 측정하는 데 도움이 된다. 몇 차례의 스프린트가 끝나면 팀은 각 스프린트를 얼마나 많은 작업을 할 수 있는지 파악할 수있게 되어 과장을 피할 수 있다.

Jira Software에서는 백 로그로 이동하여 각 문제 에 대한 예상 필드에 숫자를 입력하여 문제를 예측할 수 있다 .

스프린트 계획 회의 목적

스프린트 계획은 스프린트 전체에서 성공할 수 있도록 전체 팀을 구성한다. 회의가 시작되면 제품 소유자는 우선 순위가 지정된 제품 백 로그를 갖게 된다. 그들은 개발 팀과 각 항목에 대해 토론하고 그룹은 관련된 노력을 종합적으로 추정한다. 그러면 개발 팀은 제품 백 로그에서 팀이 수행 할 수 있는 작업의 양을 요약 한 스프린트 예측을 수행한다. 그 작업 본문은 스프린트 백 로그가 된다.

Burndown Chart

Burndown Chart는 Sprint에서 수행 할 실제 작업량과 예상 작업량을 보여준다. Burndown Chart의 가로 x 축은 시간을 나타내고 세로 y 축은 문제를 나타낸다.

Burndown Chart를 사용하여 Sprint의 남은 총 작업을 추적하고 Sprint 목표를 달성 가능성을 예상할 수 있다. 반복을 통해 나머지 작업을 추적함으로써 팀은 진행 상황을 관리하고 그에 따라 대응할 수 있다.

스크럼 팀은 개발을 시간이 지정된 스프린트로 구성한다. Sprint가 시작될 때, 팀은 Sprint 중에 얼마나 많은 작업을 완료 할 수 있는지 예측한다. Burndown Chart는 Sprint 전체의 작업 완료를 추적한다. x 축은 시간을 나타내고, y 축은 Sprint 포인트 또는 시간으로 측정 된 작업의 양을 나타낸다. 그런 다음 스크럼 팀은 Burndown Chart를 사용하여 팀원들이 Sprint가 끝날 때까지 예측된 작업을 완료하는 데 얼마나 떨어져 있는지 모니터링한다.

일관되게 예측을 충족하는 팀은 조직 내에서 민첩성에 대한 강력한 광고이다. 그러나 항목이 완성되기 전에 선언함으로써 숫자를 퍼지도록 유혹해서는 안된다. 단기간에 좋게 보일지도 모르지만 장기적으로 이것은 학습과 개선을 방해할 수 있다. 이 시나리오에서는 Burndown Chart를 사용하는 팀이 궤도에 머물기 위해 필요한 조치를 취할 기회가 많아 결국 Sprint 목표를 달성 할 수 있다.

Sprint 완료 및 보고서

Sprint가 끝나면 완료해야 하고, 그 보고서를 검토할 수 있다.

Sprint 보고서는 완료된 작업, 완료되지 않은 작업 및 Sprint가 시작된 후에 추가 된 작업을 나열한다.

그리고 다음과 같은 질문을 던지다.

• 팀이 Sprint 예측을 충족했는가?
• Sprint 중간에 작업이 추가되었거나 제거 되었는가?
• Sprint 내에 완료되지 않은 업무가 있는가?
• 만일 그랬다면 왜 그랬나?

Sprint 회고 미팅

Sprint가 완료 된 후 팀은 약 60분 정도 회고 미팅을 진행 한다. 

회고 미팅 목적은 개발 문화와 제품을 개선하기 위해 신속한 피드백을 얻는데 있다. 회고는 팀 운영이 잘 되고 있는지 여부를 이해하는데 도움을 준다.

해결되지 않는 이슈나 원활하게 운영되지 않은 것을 찾아 시간을 투입하여 창의적인 솔루션을 찾고 실행 계획을 수립한다. 지속적인 개선은 Agile 팀 안에서 개발을 유지하고 촉진시키는 것이다.

회고 미팅에서는 다음과 같은 질문을 던진다.

• 우리는 Sprint 동안 무엇을 잘 했는가?
• 우리는 뭘 더 잘 할 수 있었을까?
• 우리는 다음 Sprint에서는 무엇을 더 잘할 것인가?

스크럼 팀의 운영과 결과가 비록 좋을지라고 회고를 중단해서는 안된다. 회고는 팀이 일을 더 잘 진행할 수 있도록 지속적인 방향을 제공한다.