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에서는 무엇을 더 잘할 것인가?
스크럼 팀의 운영과 결과가 비록 좋을지라고 회고를 중단해서는 안된다. 회고는 팀이 일을 더 잘 진행할 수 있도록 지속적인 방향을 제공한다.




댓글

댓글 쓰기

이 블로그의 인기 게시물

macOS가 갑자기 부팅이 되지 않을 경우 데이터 복구 또는 백업 방법

이미지
어느날 갑작스럽게 Mac이 부팅 되지 않을 때, 그 안에 담겨진 소중한 자료들을 복구 할 수 있는 방법을 소개 합니다. 최악의 상황인 HW 문제가 있다면 소중한 자료들의 확보는 분명 어렵겠지만, OS적인 문제로 부팅이 되지 않을 경우는 다음과 같은 시도를 통해 확보가 가능할 수 있다. Mac 제품 특히 저장 장치가 SSD인 Mac은 저장장치가 메인 보드에 장착되기 때문에 일반 노트북처럼 2.5인치 내장 저장장치를 꺼내 다른 컴퓨터에 연결할 수 없다. 이런 경우 수리 센터에 맡길 수 있겠지만, 데이터 복구는 개인 정보 때문에 지원받지 못할 수 있다. 그렇다면 어떻게 하면 될까? 바로 '외장 저장장치'에 최신 macOS를 설치 후(시동 디스크 생성과 동일), 이 외장 저장장치로부터 macOS을 부팅하여 Mac 내부에 있는 저장장치에 접근이 가능할 수 있고, 데이터도 복구를 할 수 있다. 1. MacBook 또는 iMac 하드웨어 설정 초기화(NVRAM 초기화) 사용하다가 갑자기 어느날 macOS가 부팅이 안되면 우선 머리가 하얗게 되어 아무런 생각이 없을 것이다. 부팅을 여러번 시도할 것이고, 그래도 안된다면 수리 센터를 생각해 볼 것이다. 비용도 비용이지만 소중한 내 자료를 백업 가능할지 모르겠다. 일반 사용자가 하드웨어 설정(보통 이런 설정은 NVRAM에 저장됨)을 바꾸지는 않을 것이다. 하지만 설치한 하드웨어 또는 소프트웨어들에 의해 값들이 변경될 수 있다. NVRAM에 저장되는 정보의 예를 들면 무선랜에 연결되면 다음에 다시 연결될 수 있도록 연결된 무선랜의 이름과 암호를 저장한다. 이러한 하드웨어 설정들이 동작에 일부 영향을 줄 수 있다. 이 NVRAM을 초기화를 위해서는 전원 버튼을 누른 후 바로 'option' + 'command' + 'P' + 'R' 네 키를 동시에 누르면서  약 20초 동안 유지하면 된다. 애플 로고가 두 세번 보일 수도 ...
자세한 내용 보기

C++로 프로그래밍할 때 인자 또는 리턴 값으로 std::vector 등 STL 데이터 타입 처리하는 좋은 방법

C++ 프로그래밍할 때 std::vector 등 STL 데이터 타입을 호출하는 함수로 넘겨주거나 받아야 할 경우가 있다. 이런 경우 메모리 문제 또는 속도 문제 때문에 고민을 많이 할 것 같은데, C++11 이상을 지원하는 컴파일러를 사용하는 분이라면 이 글에서 도움을 받아 가기 바란다. 함수 인자로 넘길 때 이 경우는 사용이 명확하다. Call by Reference으로 데이터를 넘기면 된다.  Call By Reference로 인자로 넘기는 방법은 pointer 를 사용해도 되지만, reference을 사용하는 것이 좋다. void foo1(std::vector & data) {   ... } void foo2(std::vector const& data) {   ... } void foo3(std::vector data) { } int main(int argc, char* argv[]) {   std::vector my_data {10, 20, 30};   foo1(my_data);   foo2(my_data); } 위 코드에서 foo1()과 foo2()는 Call by Reference로 값을 넘기는 반면에 foo3()는 Call by Value로 main()에서 my_data를 넘기게 된다.  foo1()의 data는 main()의 my_data를 참조(reference)하고 있어서 foo1()에서의 데이터 변경은 main()의 my_data에 영향을 주게 된다. 그리고 foo2()는 main()의 my_data를 참조는 하지만 수정을 할 수가 없는 것이라서 단순히 값만 참조할 수 있게 된다. 반면 foo3()에서의 data는 main()의 my_data를 넘기는 순간에 값을 복사하기 때문에 메모리가 증가하게 된다. 또한 foo3()에서 data를 ...
자세한 내용 보기

Git 저장소를 병합하는 방법(How to merge repositories in Git)

GIT 저장소를 다른 저장소에 병합하는 방법 Git? Git은 컴퓨터 파일의 변경 내용을 추적하고 여러 사람들일 공유하는 파일에 대해 협업할 수 있도록 파일의 변경을 제어하는 버전 제어 시스템이다. 기존에 CVS, SVN 등 다양한 버전 제어 시스템들이 나왔지만, 최근에는 Git으로 통일되는 것 같다. Git은 분산 리비전(개정) 관리 시스템으로서 속도, 데이터 무결성 및 분산 된 비선형 작업 진행을 지원하는 것이 목표이다.  Git은 Linux 커널 개발을 위해 2005년 리누스 토발즈(Linus Torvalds)가 개발 되었으며, 다른 커널 개발자들도 초기 개발에 기여했다. 대부분의 다른 분산 버전 제어 시스템과 마찬가지로 Client-Server 버전 제어 시스템과는 다르게 중앙 서버와 관계없이 모든 컴퓨터의 Git 디렉토리는 파일 변경 이력(버전)을 추적할 수 있는 분산형 저장소이다. Client-Server 버전 제어 시스템으로 많이 사용했던 SVN(Subversion)은 네트워크 연결이 안될 경우 독립적인 위치에서 동시에 개발이 진행될 때 코드 병합과 이력 관리에 많은 어려움이 있었다. Git은 이런 기본적인 문제점들을 해결하면서 보다 진보적인 방법들을 제공한다.  인터넷 검색을 통해 보다 세부적인 내용과 더불어 다양한 기능들에 대해 찾아 보기 바란다. 서로 다른 저장소를 한 곳에 병합하는 방법 프로젝트 특성에 따라 한 개 이상의 저장소들에서 개발이 진행되다가 저장소의 병합이 필요할 때가 있다. 특정 디렉토리를 생성하여 복사해서 추가하면 되겠지만, 이련 경우에는 기존 저장소의 수정 이력(버전) 정보는 포기해야 한다.  쉽게 기존 저장소의 수정 이력 정보를 포함하여 저장소를 병합하는 방법이 있다. 우선 다음과 같이 세 개의 저장소가 있다고 가정한다. git/project1 git/project2 git/project3 project2와...
자세한 내용 보기