블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

애자일 스크럼과 JIRA를 이용한 구현 방법


근래에 강의했던 스크럼 방법론과 JIRA를 통한 구현 방법에 대한 교육 자료 입니다.

상업적 용도가 아닌 사내 교육이나 스터디등으로 자유롭게 사용이 가능합니다.



SOAPUI로 유명한 SmartBear의 ALM 툴들

ALM | 2013.12.31 01:35 | Posted by 조대협

SOAPUI로 유명한 SmartBear(http://smartbear.com가 얼마전에 LoadUI라는 부하 테스트 툴을 내놓더니

요즘들어 보니 정말 많은 툴들을 내놓고 있다.


Selenium과 같은 웹 테스트 자동화 툴인 TestComplete

- 웹뿐 아니라 테스트 탑 및 Flash까지 테스트가 가능하다.


Requirement 관리, 애자일 Sprint관리, Test Case관리 까지 가능한 ALMComplete

JIRA + GreenHopper + TestLink 이런 느낌?


코드리뷰 툴에서 부터, 자동 빌드 툴 그리고 시스템 모니터링 툴까지 갖추고 있다.

Atlassian과 비슷한 느낌?


Atlassian이 자유도가 높은 형태라면, SmartBear는 딱 프로세스가 잡혀진 느낌 각각의 장단점은 있겠으나..

둘다 쓸만한 툴인듯.



왠만큼 바쁘더라도 새로운 것을 공부하거나, 기존에 해왔던 기술들이 어느정도 성숙했다고 느끼면 꼭 글을 써서 블로그에 정리하고는 했는데, 이번달에는 정말 바뻤나 봅니다. 12월인데, 포스팅한 글이 하나도 없네요. 안되겠다 싶어서, 예전부터 프로젝트 사용에 주로 사용하던 jira에 대한 글을 몇일간 정리해서 올립니다. 좀 길기는 하지만 jira를 이용하는 사람들에게 도움이 될거라 생각합니다.




JIRA에 대한 소개

http://bcho.tistory.com

조대협

Atlassian jira는 버그 트랙킹 시스템에서 시작해서, issueIssue 기반의 전체적인 프로젝트 관리를 할 수 있게 하는 툴이다. 클라우드를 이용한 호스팅 서비스와, 설치형 서비스 양쪽을 모두 지원하며, 10 사용자의 경우 설치형의 경우 10$를 지불하면 라이센스를 받을 수 있고, 호스팅형의 경우 매달 10$ 정도면 서비스를 사용할 수 있다. 100 사용자 라이센스를 구매하더라도 4,000$ 밖에 되지 않는다. 다른 상용 프로젝트 관리 시스템과 비교해보면 상당히 저렴한 가격임에도 불구하고, 실제 사용해보면 그 기능과 편의성에 놀라지 않을 수 없다. Jira에 대한 선전성글로 보일 수 있겠지만, 선전을 해줘도 될만큼 훌륭한 제품이고 가격또한 적절하다. 이외에도 소스코드 관리나 CI를 위한 자동빌드 툴, 팀 채팅 서비스,코드리뷰 도구등 개발에 필요한 많은 도구들을 제공하고 있다. 아직까지 써보지 않았다면 꼭 둘러보기를 바란다.

그러면 jira로 어떻게 프로젝트를 관리할 수 있을까? 먼저 가상의 서비스를 생각해보고 시나리오를 정의해보자.


가상의 프로젝트

Facebook Server Side Architecture (이하 SSAG) 그룹을 별도의 웹사이트에서 운영할 수 있게 하는 사이트를 개발한다고 해보자 이 사이트를 통해서 해당 그룹의 멤버들은 글을 읽을 수 도 있고, 올리거나, 삭제 편집 그리고 검색을 할 수 있다. 이 서비스의 이름을 Yurry라고 하자


주요 기능

먼저 서비스의 주요 기능을 정의하고 액셀로 먼저 정리를 해보자

바로 Jira에 등록하지 않고 먼저 액셀로 정리를 하는 이유는, 기능을 정의하고 나면, 빠진 것이 많을 수 도 있고, 요구사항이 잘못 기술 되었을 수 도 있기 때문에, 먼저 액셀로 만들어 놓고 다른 팀원 (특히 개발,기획,UX)들과 함께 리뷰하면서 수정하기 위함이다. 아래는 초기 버전정도의 기능 정의서로 생각하면 되고, 개발이나 기획 그리고 UX 사람들과 몇번의 리뷰를 거치면서 조금더 상세화 되어야 한다.



이때, 두 단계 정도로 나눠서 Feature를 기술 하는데, Feature Level 1의 경우에는 일반적으로 생각할 수 있는 기능으로 보면 된다. (누구나 이해할 수 있는 레벨) 통상 20개 정도가 적절하다. Feature Level 2는 상세 기능을 정의하는데, 이때는 Scrum Story 기술 방법을 사용한다

“as a {user}, I want to do {something}”

의 형태를 취하는데, 어떠한 사용자가 시스템을 통해서 어떠한 기능을 한다는 것을 서술하는 것으로, 마치 UML Use Case와 같은 개념을 내포하고 있다.

기타 자세한 사항은 Description에 서술한다.

이런 Feature list를 정의할 때 중요한것은 크게 3가지 정도로 들 수 있다.

- Story (Flow or sequence) : 먼저 가장 중요한 것은 전체적인 Feature가 스토리 형태로 흐름을 가져야 한다. Level 1 Feature들을 순서대로 이어 놓으면 사용자가 서비스를 사용하는 흐름 형태가 되어야 한다. 예를 들어 위의 경우 사용자 로그인 > 글 읽기 > {글쓰기 | 좋아요 선택하기 | 검색하기} 와 같이 흐름이 되어야 한다. 위의 예에서는 Level 2 Feature는 나열식이 되기는 하였지만 조금 더 디테일한 경우에는 마찬가지로 순서성을 지키면 이해하기가 편하다.
나중에 이 Feature들을 리뷰 할때, 위에서 부터 Feature를 순서대로 리뷰를 하면 사용자 스토리에 따라서 리뷰를 하기 때문에 조금 더 빠짐없이 리뷰가 가능하다.

- Testable : Feature는 테스팅이 가능한 수준으로 디테일하게 서술되어야 한다.앞서 설명한 바와 같이, 스토리대로 각 기능등이 정의 되어 있으면, 스토리를 따라서 테스트 케이스로 만들 수 있다

- Designable : 마친가지로 디자이너가 기능에 있는 스토리에 따라서 UX를 만들 수 있는 정도로 충분히 기술되어야 하며, 특히 입력이나 출력을 받을 수 있는 필드가 충분히 기술되어야 한다.


UX Prototyping

다음으로, UX에 대한 프로토타입을 구현한다. 필수과정은 아니지만, 기능을 명확하게 하고 빠진 부분이 없는지 흐름이 잘못된곳은 없는지를 체크하기 위해서 UX 프로토타입을 구현해보는 것이 좋다. 이러한 UX 프로토타입을 wireframe이라고 한다.

다음은 balsamiq라는 프로토타입 디자인 도구이다.



Figure 1.http://balsamiq.com/ 의 프로토타입 툴

http://mashable.com/2012/06/07/mockup-tools/ 에 보면 몇가지 유용한 프로토타입 툴들이 소개 되어 있다.

또는 UX 자바스크립트를 사용할 예정인 경우 예를 들어, Bootstrap등을 이용할 경우에는 자바스크립트 디자인 툴을 사용해서 프로토타입을 만들어보는 것도 좋다 이 경우에는 만들어진 프로토타입을 거의 구현단계에 그대로 사용할 수 있기 때문에 구현 기간을 줄일 수 있다. 복잡한 UX가 아닌 경우에는 이러한 방법도 효과적이다.

다음은 layoutit이라는 bootstrap 디자인 도구 이다.



Figure 2. Layoutit 서비스 화면

http://mashable.com/2013/10/20/bootstrap-editors/ 를 보면 bootstrap 디자인툴이 소개되어 있다. 아래는 실제로 layoutit 도구를 사용하여 Yurry 서비스를 프로토타입핑을 한 예이다.




여기까지 진행됬으면 Feature list가 어느정도 필터링되고 다음어져서 완성이 되었을 것이다.


jira agile board

자아 준비가 끝났으면 이제 jira feature들을 등록해보자. Feature를 등록하기 전에 jiraagile board에 대해서 알아볼 필요가 있다.

스크럼 애자일 방법론을 보면 스크럼 보드라는 것이 소개되는데, 해야할일 (To do 또는 Backlog), 진행중인 일 (in progress), 완료된 일 (Complete)로 나눠서, 각 일(Issue)를 포스트잇으로 만든 후, 진행 단계에 따라서 각 단계로 포스트잇을 이동해서 붙이는 방법이다.




[1]

Figure 3. 스크럼 보드

이런 스크럼 보드를 웹으로 만들어 놓은 것이 jira agile board라는 기능이다. 이 기능을 사용하면 같은 장소에 있는 팀원 뿐만 아니라 원격지에 있는 팀원까지 같이 스크럼 보드를 공유할 수 있는 장점을 가지며, 각 해야할 일(Issue)에 대해서 디테일한 내용을 description에 서술함으로써 조금 더 자세한 Issue 관리가 가능하다.


[2]

Figure 4. jira agile 보드.

jira의 상단 메뉴에서 Project > Create Project 메뉴를 이용해서 프로젝트를 생성한다.



다음으로, 상단 메뉴의 Agile 메뉴에서 Mange board를 이용하여 Agile 보드를 생성한다. 여기서는 Scrum 방법론을 사용할 것이기 때문에, Scrum board를 선택하고 프로젝트를 선택한다.



여기까지 수행하였으면, agile board가 생성되었다.




Issue 종류

자 그럼 이제 앞서 정의한 Feature들을 jira agile 보드에 입력하기전에. Issue를 입력할때, 어떤 필드들을 입력해야 하는지 먼저 알아보자.

Jira에 입력되는 해야할일 feature들을 “Issue”라고 정의하는데, Issue에는 몇가지 타입이 있다.

    Epic

하나의 Sprint에 걸쳐서 끝나지 않고, 여러 Sprint에 걸쳐서 종료되며, 여러 Story들의 집합이다. 주로 Major Feature들을 중심으로 정의한다. Level 1 Feature가 적절하다.

Epic을 정의할때, 하나의 팁중의 하나는 꼭 User Story 단위로만 할것이 아니라, 사용자가 직접적으로 관계가 없는 일에 대해서도 정의할 필요가 있는데, 예를 들어, Infrastructure Set up이나, 디자인 작업,문서 작업등이 이에 해당한다.

    Story

“as a {user}, I want to {do something}”에 해당하는 사용자 직접적으로 사용하는 기능이다. 이 때 Story Point라는 것을 입력할 수 있는데, Story Point는 개발에 걸리는 시간 또는 난이도 등으로 지정할 수 있는데, 필자의 경우에는 “1=개발자 한명이 개발할 수 있는 분량으로 정의하고, 0.5,1,2,3.. 등의 단위를 사용한다.

    Chore

Chore는 개발을 해야 하는 부분이지만 사용자와 직접적으로 관계되지 않는 개발 내용을 정의한다. 예를 들어 “Server Logging 구현”, “데이타 베이스 분리와 같은 작업등을 정의한다. Chore 역시 Story와 마찬가지고 Story Point를 부여할 수 있다.

    Task (Optional)

Task는 해야하는 일이지만, 구현에 관련되지 않으며, 일정이 없는 경우에 해당한다. 예를 들어 디자인 문서 작성, 기획과 업무 협의 등이 해당한다.

    Issue

Issue 는 말 그대로 Issue이다. 메니져들이 관리하는 Issue, 예를 들어서 클라우드 계약, 서버 Hang up, 솔루션 결정 들과 같이 메니져들이 관리해야 하는 항목이다.

    Bug

버그는 테스트 엔지니어에 의해서 테스팅 되고, 버그로 리포팅 된 타입이다.

    Sub Task

Sub Task가 중요한 내용인데, Story Chore를 개발하기 위해서는 여러 가지의 실제적인 개발 작업이 필요하다. 예를 들어 “as a user, I want to read posting”이라는 Story가 있을때, “OPEN API를 호출하여 최근글을 JSON으로 호출하여 출력한다.” “API 호출을 로깅한다와 같이 디테일한 개발 테스크로 나뉘어 지는데, 이를 Story Chore같은 Issue 아래 Child (Sub) Task로 등록할 수 있다.

이때 하나의 팁은 이 Sub Task는 각 개별 개발자에게 할당되며 0.5~2일 정도에 끝날 수 있는 테스크로 정의되어야 하며, 만약 2일 이상이 될 경우 다른 Sub Task로 나누어 주는 것이 좋다.

여기서 주의할점은 Story Chore과 실제 개발해야 하는 Issue이고 Story Point를 부여할 수 있으며, 테스트 엔지니어에 의해서 테스팅이 되는 부분이다.

jira는 자유도가 매우 높은 도구라서 이러한 Issue Type등을 지정할 수 있다. 아래는 jira Project > Administration 메뉴에서 Issue Type을 정의하는 부분이다. 위에서 설명한 Issue Type들에 맞춰서 Customize 하였다.




Epic 등록

Issue 타입에 대해서 이해를 했으면 이제 먼저 Epic을 등록해보자. 앞에서 등록한 Feature Level 1 Issue Epic으로 등록하면 좋다.  먼저 agile board Plan 모드(우측 상단에 모드가 있음)에서 Create Epic을 눌러서 아래와 같이 Epic을 등록한다.



여기서 한가지 주목할만한 점은 원래 Feature List에 있던 페이스 북 연동” Epic에 등록되지 않고 새롭게 “Infrastructure”라는 Epic이 등록되었다. “페이스북 연동이라는 Feature는 요구 사항이기는 하지만 다른 기능 개발에 전제사항으로 포함되는 기능이기 때문에 별도로 Epic으로 등록하지 않았으며 대신 개발과정에서 서버,데이타 베이스 셋업, 배포 환경 자동화와 같은 인프라 작업이 생길 수 가 있는데, 이러한 작업은 Feature List에는 정의되어 있지 않았기 때문에, Epic 정의 단계에서 새롭게 정의하였다.


Issue 등록 및 맵핑

다음으로 Issue (Story,Chore,Issue,Issue)등을 등록한다. 상단 메뉴의 Issues 메뉴의 Create Issue를 이용하면 된다. 만약에 등록해야 할 Issue가 많을 경우에는 Excel Import할 수 있다.

https://confluence.atlassian.com/display/JIRA/Importing+Data+from+CSV 를 보면 Excel CSV로 바꿔서 Import 하는 방법이 설명되어 있다.

이 때 몇 가지 필수 필드를 등록해야 한다.


1)   Component

Component는 시스템의 컴포넌트를 정의한다. Yurry 시스템의 구조가 서비스를 제공하는 앞단의 서비스 웹 사이트(Service Web Site), 시스템을 배포하는(Deployment System)으로 구성이 되어 있다면 Component Service Web Site Deployment System 두개로 구성된다. 이러한 컴포넌트 설계는 Feature가 다 정의된 후 아키텍쳐 설계를 거쳐서 시스템을 구성하는 컴포넌트를 정의한 후에 이 컴포넌트를 Component로 사용하면 좋다.

Component는 상단 메뉴의 Projects > 해당 프로젝트 선택 > Administration 메뉴 > Components 메뉴에서 추가할 수 있다.




2)   Priority

다음으로 Priority인데, 해당 Issue가 얼마나 중요한지를 나타내는 것으로 Blocker, Critical, Major, Minor, Trivial 식으로 나뉘어 진다. 일반적으로 Major를 선택하면 되고,

       Blocker의 경우 해결되지 않으면 프로젝트가 진행될 수 없는 경우

       Critical은 프로젝트 진행은 가능하나 해결하지 않으면 정상적인 서비스 개발이 어려운 경우

       Major 꼭 개발해야 하는 경우

       Minor 개발은 해야 하나 없어도 상관 없는 경우

       Trivial 있으나 없으나 크게 상관 없는 경우

 

식으로 중요도를 나눌 수 있다. 프로젝트에 따라서 의미를 정의해서 사용하면 되고, Blocker의 경우에는 공통적으로 프로젝트 진행을 할 수 없는 수준으로 사용하면 된다.




3)   Issue 생성

이제 실제로 Issue를 생성해보자 상단 메뉴의 Issues > Create Issue 메뉴를 이용항 Issue를 등록한다. Summary 부분에 제목을 등록하고, 알맞은 Priority를 선택한 후, Issue에 해당하는 Component를 선택한다. 다음으로 Assignee 부분에 해당 Issue에 대한 Owner를 지정한다. 그리고 마지막으로 Description 부분에 앞의 Excel Sheet에서 만든 Detail Description을 채워 넣는다.




4)   Epic 맵핑

이제 모든 Story를 등록하였으면, agile board가 다음과 같은 형태가 될것이다.



EPCIS에서 맨아래 “Issues without epcis”를 클릭하면 우측 하단에 EPIC이 맵핑되지 않은 Issue들이 리스트업된다. Issue들을 drag & drop해서 좌측에 표시된 EPIC과 맵핑 시킨다.

    만약에 Issue를 등록했음에도 agile 보드의 back log에서 보이지 않는 경우 https://answers.atlassian.com/questions/102966/no-issues-displaying-in-scrum-backlog 를 참고하기 바란다.


Release Version 정의와 맵핑

릴리즈의 개념을 먼저 이해하자, 릴리즈는 작동 가능한 서비스 가능한 상태로 만드는 것이다. 정확하게 이야기 하면 Production 서비스로 올리는 것을 릴리즈라고 한다. 요즘의 애자일 방법에서는 Short Release라는 전략을 사용하는데, 아주 짧은 주기로 서비스나 소프트웨어를 릴리즈한다. 그렇다고 릴리즈마다 매번 Production에 배포 하는 것이 아니라 서비스로 배포가 가능한 형태로 만들거나, 어느 정도의 기능등이 마무리 되었을 때 릴리즈를 한다.

보통 이상적인 경우 매 Sprint가 끝날 때 마다 Release 되는 것이 좋지만, 하나의 Sprint 내에서도 긴급 Release가 될 수 도 있고 (버그 수정, 긴급 반영등) 또는 개발하는 기능이 클 경우 여러 Sprint에 걸쳐서 Release를 할 수 도 있다.



어떠한 기능을 언제 Release 할것인가를 정의하는 것을 “Release Planning” 이라고 한다. jira에서는 이러한 release의 개념을 지원하는데, 애자일 보다 좌측에 “Version”이라는 탭을 클릭하면 아래와 같이 출력된다.



여기서 “Create Version” 이라는 버튼을 누르면 Version을 생성할 수 있고, 이 때 해당 버전을 개발하는 기간 “From-To” 을 명시 할 수 있다

이렇게 버전 정보를 생성한후, 아래 그림과 같이 agile board에서 Issue들을 drag&drop하여release 버전에 맵핑할 수 있다. 개발 목표 완료일을 맵핑할 수 있다.즉 어떤 기능들이 어느 Release 버전에 포함될 것인가를 맵핑할 수 있다는 것이다. 이는 product 관리 관점에서 매우 중요한데, 1.0에서는 어느기능까지 지원하고 2.0에서는 어느 기능 까지 지원하겠다는 것을 명시적으로 지정하는 것이다. 이러한 release 계획에 따라 테스팅, 마케팅, 영업등 다른 조직이 함께 움직인다.

 




Sprint Planning

여기까지 진행했으면, Story 들이 어떤 기능 개발에 (EPIC)에 맵핑이 되는지 그룹핑이 되었고, 각 기능들이 어느 버전에 (언제) 완료될지가 맵핑 되었다. 그러면 이제 각 Story들을 개발하는데, 얼마의 노력(resource / time)이 필요한지를 측정해보자.


1)   스토리 포인트 부여

앞에서 이미 Story Chore에 대해서 설명하면서 스토리 포인트의 개념에 대해서 설명하였다. 여기서 이 단계에서 스토리 포인트를 부여하는데, BackLog에 있는 Issue를 클릭하면 오른쪽에 “Estimate” 라는 항목이 나온다. 여기에서 스토리 포인트를 부여하면 된다.




2)   Sprint 생성 및 Issue 맵핑

이제 Backlog가 완성되었다. 이제 Sprint를 생성하고 Backlog에 있는 Issue들 중에, 이번 Sprint에 진행할 Issue들을 맵핑해보자.

아래 그림 처럼 애자일 스크럼 보드에서 “Create Sprint”를 선택하면 Sprint가 생성된다. 이때 Sprint 이름에 기간 “(Dec.16~Dec.27)”과 같은 식으로 지정해놓으면 기간을 파악하는데 도움이 된다.



다음으로 Backlog에 있는 Issue들을 drag&drop으로 Sprint로 이동하여 Sprint로 에 맵핑한다.

그 후에 팀원들이 모여서 해당 Store Chore들을 구현하는데 필요한 Sub Task들이 있으면 정의 한다. (Issue에서 More > Create SubTask 메뉴를 사용하면 된다.)



다음으로 해당 Issue SubTask를 수행할 사람을 Assign 메뉴를 이용하여 개발자에게 할당한다.



이작업이 끝나면 해당 Sprint에 할당된 Story Chore (Story Point들이 있는 Issue)에 대한 스토리포인트의 Sprint Issue들 아래 “Estimate”로 나타난다. 이를 통해서 해당 Sprint에서 처리할 Story Chore들의 양이 적절한지 판단할 수 있다. 위의 그림의 경우 총 Estimate 7, 한사람이 working day 기준 1주반 정도면 구현 가능한 양이다. 만약 팀이 4명 정도고, Sprint 10일이라면 40정도가 MAX가 된다. 버퍼를 20~30%로 생각하면, 28~30 정도의 스토리포인트가 적절하다고 볼 수 있다. 이 버퍼는 팀의 업무 스타일에 따라서 유동적으로 설정한다. Sprint를 대략 3번 정도 해보면 어느정도의 버퍼가 필요한지 산정할 수 있다.


Sprint 시작

이제 Sprint 계획도 다 끝났고, 드디어 Sprint를 시작할 준비가 되었다. 애자일 스크럼 보드/Plan 메뉴에서 “Start Sprint” 버튼을 누르면 Sprint가 시작된다.

Sprint가 시작되면 agile board에서 Work 메뉴를 들어가 보면 변화가 생긴 것을 볼 수 있다.



앞에서 설명한 포스트잇 기반의 스크럼 보드 처럼 TO DO/In Progress/Done 형태로 3개의 영역으로 나뉘어 지고, 모든 Issue들은 TO DO에 위치한다. Sub Task(그림에서 YU-21) 의 경우 위의 그림과 같이 YU-12와 같은 Story Chore등 다른 Issue 아래에 다른 색으로 표시된다.


Sprint 진행

Issue 처리


1)   Issue의 상태 업데이트

지정된 담당자는 Issue에 대한 작업을 시작했으면, 작업의 상태를 “To Do”에서 “In Progress”로 변경한다. agile board / Work 모드에서 해당 Issue drag & drop을 이용하여 In Progress로 옮기거나 Issue 디테일에 들어가서 “Start Progress” (사용하는 워크 플로우에 따라 다를 수 있음) 을 눌러서 상태를 바꿔 준다.



마찬가지로, In Progress에서 작업이 끝나면 Done (또는 Close. 사용하는 워크플로우에 따라 다름)을 눌러서, 상태를 옮겨준다.


2)   Comment를 이용한 진행 상태 추가

Jira에 각 Issue에는 comment를 달 수 있는 기능이 있는데, 해당 Issue를 해결하는 데 필요한 내용이나 다른 사람과 커뮤니케이션한 내용(이메일/전화/메신져) 내용들을 붙인다.

이유는, 해당 Issue를 해당하는데 담당자가 무슨일을 했는지에 대한 로그를 남기는 것이다. 향후 다른 사람이 해당 업무를 받거나 또는 비슷한 문제를 해결하고자 할 때 선임자가 어떤식으로 업무를 해결했는지를 찾아볼 수 있도록 하는 것이다.

기술적인 질문을 하는 경우에도 이메일 보다는 Comment에 내용을 달아놓고, 질문을 하고자 하는 사람에게 Issue assign 시켜서 jira를 통해서 커뮤니케이션을 하면 별도로 이메일 내용을 jira에 붙일 필요가 없이 커뮤니케이션이 가능하다. (Comment가 붙으면, watching하는 사람이나 또는 assign된 사람,owner에게 자동으로 이메일 notification이 간다.)

경험상 코드 수정이나 기능에 대한 comment 내용들은 대단히 도움이 되는데, comment를 자세히 적도록 팀의 문화를 바꾸는 것은 대단한 노력이 필요하다. 필자의 경우에는 미국계 미들웨어 회사에서 일을 할 때, enhancement bug 수정에 대한 communication에 대해서 본사 개발자가 jira와 유사한 Issue 트랙킹 도구를 통해서만 communication을 하도록 프로세스가 잡혀있었다. 그래서 자연히 접하게 되었는데, 향후에 비슷한 문제가 생겼을 때 Issue 트랙킹 도구만 검색해도 유사한 문제와 현상 그리고 해결 방법을 다른 사람들의 커뮤니케이션 쓰레드를 통해서 많은 힌트를 경험이 있다. (실제로 다른 사람들도 그렇게 사용하였다.)

이런 경험 때문에 컨설팅을 할때나 또는 실제 개발에 적용할 때 이런 문화를 적용하고자 노력을 많이 했었는데, 엔지니어적인 특성들 때문인지 보고서처럼 몬가 적고 기록하는데 익숙하지 않은 탓인지 적응이 상당히 힘들었던 경험이 많다. (소스코드에 주석 많이 안다는 것과 같은 원리)

Issue comment를 적을 때에는, “내가 휴가를 가더라도 다른 사람이 Issue에 기록된 Comment만 보고도 업무를 인수받을 수 있는 정도의 수준적어 주는 정도의 디테일로 기록하는 것이 좋다.


3)   Resolve 처리

처리가 끝난 Issue“Done” 처리 할 때 사용중인 워크플로우에 따라서, “Resolution” 을 수동으로 입력해줘야 하는 경우가 있다. “Resolution”을 명시적으로 Complete나 다른 완료 상태로 바꿔 주지 않고, Unresolved 상태로 놔두게 되면 jira에서 해당 task를 제대로 끝나지 않은 상태로 인식하는 경우가 있다.

Jira 에는 팀이 가지고 있는 전체 Issue 대비 끝난 Issue를 추적하는 기능이 있다. 이 기능을 이용하면 전체 프로젝트 팀의 진행 상태를 알 수 있다.



그림과 같이 위의 붉은색 그래프가 열려 있는 Issue 이고, 아래 초록색이 해결한 Issue의 수이다. 이 해결한 Issue는 상태를 “In Progressà Resolved(Testing)”으로 변환할대 초록색으로 변하게 되는데, 이때 반드시 Resolution을 선택해주지 않으면 아래 초록색 그래프에 반영되지 않는다. 앞서 설명했듯이 워크플로우에 따라 Done이나 Resolve를 선택하면 자동으로 Resolution이 선택되는 경우가 있는데, 만약 현재 사용하는 워크플로우가 자동으로 Resolution을 선택해주지 않는 경우 이렇게 반드시 설정해줘야 한다.





여기서 Resolution을 선택해주지 않으면 Resolved 또는 Close가 되었다 하더라도, 실제 시스템에서는 해결하지 않은 것으로 인식해서 “Resolved”카운터가 증가하지 않는다. (위의 그래프에서 녹색 그래프가 올라가지 않는다.)

그리고 ResolveIssue Agile 보드에서 아래와 같이 Issue #에 선이 그어진 상태로 표시된다



만약에 현재 Resolved 처리하거나 Close 처리한 Issue중에서 위와 같이 Issue #에 줄이 쳐져 있지 않다면, 반드시 Resolution을 확인하고, UnResolved 상태로 되어 있다면, 해당 Issue Reopen 하신후, 다시 Resolve하고 이때 반드시 Resolution을 입력해줘야 한다.


4)   워크 플로우

Jira의 가장 큰 특징 중의 하나가 상당히 많은 부분에 대해서 Customization이 가능하다는 것이다. 그 중에서 강력한 기능중의 하나가 워크 플로우 기능이다. 지금까지 설명한 프로세스는 To do/In progress/Closed와 같은 일반적인 스크럼 기반의 워크 플로우지만, bug feature, test case와 같은 Issue 타입에 따라서 워크 플로우가 다를 수 있다. jira에서는 이렇게 각각 다른 Issue 타입에 대해서 다른 워크 플로우를 정의 및 정의할 수 있도록 지원한다.




5)    Version Control System 연동을 이용한 Issue(Task)별 코드 변경 추적

Jira Issue들 즉 Story Chore를 개발 내용이 어느 소스코드에 반영되었는지 까지 추적할 수 있는 기능을 제공한다. SVN이나 git commit을 할 때 해당 Issue #를 넣어서 Commit을 하게 되면 아래와 같이 해당 Issue에 관련된 소스코드 변경 부분을 jira에서 링크로 해서 직접 코드 변경(또는 반영) 부분을 보여준다.

설정 방법

https://confluence.atlassian.com/display/JIRA/Integrating+with+a+Source+Control+System


[3]

특히 버그 수정을 했을 때, 버그 수정을 위해서 어떤 부분을 변경했는지를 추적할 수 있기 때문에 대단히 편리하다. 이 기능이 유용하기는 하지만, 개발한 코드를 commit할 때 마다 Issue 번호를 넣는 건 습관화 되지 않으면 상당히 귀찮은 일이다. Issue Comment를 부지런히 남기는 것처럼, 코드 commit시 마다, Issue #를 넣도록 습관을 변경하는 것이 중요하다.

이런 방식으로 Issue를 진행 및 해결하면서 Sprint를 진행한다. 만약에 중간 중간에 필요한 Issue Task가 나오게 되면 추가를 하고 앞서 진행한 방식과 같은 방법으로  Sprint에 추가하여 진행하되, Sub Task들은 Story Chore를 구현하기 위한 것이기 때문에, Sprint에 추가하는 것이 것이 타당하지만, 새로운 Story Chore등은 Planning때 정의한 것이 아니기 때문에 추가 요구 사항이 된다. 처음 Planning 당시 팀의 사이즈에 맞는 분량의 양만 정했기 때문에, 마구잡이로 현재 진행중인 Sprint에 넣게 되면, 야근(?)이 발생하게 된다.

그렇다고 딱 StoryChore Freeze해서 무조건 한다는 것은 맞지 않을 수 있다. 초기에 Sprint 설계시 요구사항 분석을 잘못했을 가능성이 있기 때문에 빠진 Story Chore가 있을 수 있다.

일단 Sprint 진행중, 새로운 Story Chore가 생긴다면 넣고 빼는 것에 상관 없이 생성해서 BackLog에 넣어 놓는다. 그리고 꼭 먼저 진행해야 하는 경우 현재 Sprint에 넣고, 현재 Sprint에 포함된 다른 덜 중요한 내용을 빼내서 다시 Backlog로 내려놓는 방법이 타당하다.

그렇다고 부담없이 넣다 뺐다 하라는 것이 아니라, 꼭 필요한 경우에만 융통성을 발휘해서 유동적으로 진행을 하라는 것이다. 만약 Sprint에 들어가 있는 Story Chore를 자주 변경하게 되면 전체 팀의 프로젝트 진행에 있어서 혼선을 줄 수 있고 특히나 여러 지역에 분산된 팀의 경우에는 여파가 크다.


6)    몇가지 팁

agile board / Plan 모드에서 상단의 sprint 제목 우측을 보면, 아래와 같이 To do / In progress / Done 상태별 Issue들의 Story Point 들을 합산해서 보여준다. 이 값을 보면 현재 Sprint를 진행하면서 해야할일, 하고 있는 일, 끝난 일의 비중을 쉽게 알 수 있다.



agile board / Plan 모드에서 진행중인 Sprint Issue들과 Backlog Issue들은 drag&drop을 이용해서 순서 조정이 가능하다. 중요한 Issue들을 위로 놓아서 관리하는 것이 편리하다.



agile board 상단을 보면 Quick Filter가 있는데, 이는 Configure 메뉴를 이용하여 Customization이 가능하다. Filter를 잘 정의해 놓으면 검색이나 진행 중인 Issue들을 필터린 해서 보는데 매우 편리하다.



일반적으로 특정 Component , 이슈별, 사람별 Filter를 미리 정의해놓고 사용하면 편리하다.


Sprint 종료

이렇게 Issue들을 진행하고 Sprint가 끝나는 기간이 되면 해당 Sprint를 종료해야 한다. Sprint를 종료하는 방법은 agile board > Work에서 좌측 상단의 Sprint 명을 클릭하면 아래와 같이 Complete Sprint라는 버튼이 나타나고 이 버튼을 누르면 해당 Sprint가 종료된다.



이때 종료되지 않은 Issue들은 다시 모두 Backlog로 내려가게된다.


새로운 Sprint 시작

다음 새로운 Sprint를 바로 시작할 수 있는데 권장 사항은 이 시기에 스크럼 회고(Retrospective)를 진행하면서 지난 Sprint에서 잘한 것, 못한것 그리고 개선해야 할 것을 논의하면서 프로세스를 개선해나가는 것이 좋다.

경험상 팀장급 (Scrum이나 애자일에서는 Chicken이라고들 부르던데.)은 빠진 자리에서 회고를 하는 것이 좋다. 일반 개발자나 팀원들이 눈치를 보느냐고 제대로 된 토론이 이루지지 않을 수 있기 때문이다. 반드시 프로세스 개선을 위한 의견들을 논의하고 다음번에 반영하는 것이 좋다. 또는 회고중에 나온 내용을 간단히 메모해서 이메일로 Chicken에게 보내서 향후 개선을 요청할 수도 있다.

Chicken들도, 회고에는 Chicken 끼리의 자체적인 회고를 하면서 자체적인 개선 작업을 수행하는 것이 좋다.

회고가 끝난후에, 앞서 진행했던 Sprint Planning 작업부터 다시 수행한다.


Jira의 확장


Dashboard

Jira Home 화면을 개인별 또는 프로젝트별로 dashboard를 구성할 수 있다. 여기서 여러가지 현황을 볼 수 있도록 만들 수 있는데, 몇가지 추천할만한 항목으로는

    사용자별 Issue 할당 현황 : 팀원별로 할당된 Issue의 수를 모니터링 하면, 어느 팀원에게 일이 몰리는지를 알 수 있고, 이를 바탕으로 적절하게 Issue를 분산해서 배치할 수 있다.

    Block,Critical,Major 이슈 개수 : Blocker Critical 이슈들은 프로젝트를 진행하는 데 문제가 될 수 있으므로 항상 모니터링 하는 것이 좋다.

    Created vs Resolved Graph : 이슈가 생성되는 추이 vs Resolve되는 추이인데, Sprint 끝으로 갈 수 록 Resolved Graph가 생성되는 그래프를 쫓아 가야 한다. 팀의 Velocity를 측정할 수 있는 부분으로, 만약에 생성되는 그래프가 올라가는 속도가 Resolved 속도 보다 빠르게 증가한다면 해당 Sprint내에 일을 끝낼 수 없다는 의미이고 Resolved Graph가 완만하게 증가하고, Created Graph가 증가 속도가 둔화되면 프로젝트가 제대로 되고 있다는 의미가 된다.

    나에게 할당된 이슈 : 당연히 나한테 할당된 이슈는 모니터링되고 봐야 하고.

    내가 Watching하고 있는 이슈 : 또한 내가 Watcher List에 들어가 있는 이슈도 모니터링 되어야 한다.

    다른 프로젝트의 Progress : 몇 개의 프로젝트를 동시에 진행하는 PM의 경우에는 여러개의 프로젝트에 대한 progress를 모니터링 하는 것이 좋다.



Figure 5. jira dashboard 예제

[4]

jira에서 dashboard gadget등을 이용해서 얼마던지 Customization이 가능하다. 별도의 규칙은 없고 각 업무에 맞게 잘 만들어서 사용하면 되는데, 참고할만한 팁은, Dashboard를 만들 때 팀내의 역할에 따라서 다른 형태의 Dashboard를 만들어서 사용하면 효과적이다. PM의 경우 여러 개여 프로젝트의 Progress Issue에 대해서 집중적으로 관리가 필요할 것이고, 개발자의 경우에는 자기에게 할당된 Issue, 자신이 Watching하는 Issue들을 집중적으로 관리할 필요가 있다. 운영팀의 Incident dash board에 장애 이력을 장애가 발생한 시스템의 분포도, 장애의 원인 분포도 (네트워크 에러, 사람 실수, 설정 오류), 달력으로 장애 발생 횟수를 표시 하는 등을 할 수 있다.


모바일 클라이언트

아무래도 시대가 모바일 & 스마트폰 시대이다 보니, 당연히 jira도 스마트폰용 애플리케이션이 있다. 단순하게 스마트폰에서 이슈를 보거나 Comment를 다는 정도로 생각할 수 있겠지만, 생각보다 재미있는 기능들이 많다.


[5]

그림에서 가운데 처럼 채팅 형태로 Comment를 달 수 있는 기능도 있고, Issue를 등록했을 때 맨 오른쪽 그림처럼 이슈가 등록된 위치는 구글 맵을 통해서 나타내 줄 수 도 있다.

당연히 기본적인 리스트를 보여주는 기능도 제공한다. 외부이동이 많은 세일즈 엔지니어나 컨설턴트 또는 장애 처리를 해야 하는 Operation 엔지니어들에 매우 편리하다. 특히 채팅 기능의 경우 SMS와 같이 문자를 받는 형태로 Comment를 붙일 수 있기 때문에 이메일로 Notification을 받는 것 보다 훨씬 빠르게 해당 issue에 대한 Communication이 가능하다.


Add ons

Jira는 다양한 확장 플러그인을 제공한다. https://marketplace.atlassian.com/ 에 가면 유/무료 플러그인을 구매하여 jira를 확장할 수 있다. 또는 jira admin 메뉴에서 add on을 검색해서 자동으로 다운로드 및 설치를 하게할 수 있다. (정말 쉽다.)


[6]

Figure 6. Tempo Timesheets for JIRA 플러그인

위의 그림처럼 우리가 이 장의 앞에서 소개한 Excel 기반의 Tracking 시스템 형태로 jira를 운영하는 플러그인이나 Gantt chart 플러그인등 다양한 플러그인 조합을 통해서 팀의 스타일에 맞는 형태의 jira Customization이 가능하다.


정리

필자의 경우 애자일 팀을 운영하면서 IBM Jazz, Mantis,Bugzilla Trac, Redmine 등 많은 툴을 사용해봤는데, jira가 저렴한 가격대에 정말 실용적인 기능들을 많이 제공한다.

적절한 수준의 복잡도와 Customization을 통한 유연성을 제공하는데, 무엇보다 중요한 것은 툴  보다는 프로세스이다. 어떤 개발 프로세스를 정립하고 팀이 적응하느냐가 문제이지 어떤 툴을 사용하느냐는 그 다음 문제이다.

흔히 이런형태의 툴을 도입하는 과정을 보면 도입하는 당사자만 재미있어 하고, 구축에만 힘을 쏟다가 정작 팀 전체의 프로세스를 바꾸고 적용하는데 실패하는 경우를 많이 봤다.

툴을 구축하는 것보다 단순한 프로세스로 먼저 팀 전체가 움직일 수 있도록 적용하고, 다음 점점 툴과 프로세스를 고도화해 나가는 것을 고려해보자. 본인의 경험상 툴 셋업과 프로세스 정의가 끝난후 최소한 2~3개월은 지속적으로 노력해야 팀에 적용이 된다. 그 전까지 Issue를 제대로 close하지 않거나 내용을 제대로 적지 않거나 등의 여러가지 프로세스를 따르지 않는 경우가 많이 발생한다. 그래서 초기 2~3개월 동안은 Scrum Master Issue들을 관리하면서 일일이 개인들에게 mentoring을 하면서 프로세스를 따르도록 해야 한다.

 


'ALM > JIRA' 카테고리의 다른 글

Atlassian JIRA를 이용한 애자일 Scrum 프로젝트 관리  (15) 2013.12.20
JIRA 클라이언트  (0) 2008.11.07
Atlassian JIRA를 이용한 프로젝트 관리 (기초편)  (0) 2008.04.04
JIRA와 SVN 연동  (1) 2008.03.03

JIRA 아이폰 앱이 무료랍니다.

ALM/Task Management | 2010.05.04 11:43 | Posted by 조대협

http://itunes.apple.com/us/app/jira-mate/id293904930?mt=8
원래 유료앱으로 알고 있는데, 무료로 바뀌어 있네요.
JIRA 사용하시는분들 유용할것 같습니다.
참고하세요

JIRA용 UI 디자인툴.

ALM/Task Management | 2009.10.07 17:46 | Posted by 조대협
JIRA를 Task Management 도구로 사용할때, UI Requirement를 만들때는 PPT등을 사용해야 합니다. Balsamiq Mockup이라는 도구가 있는데, 이 도구를 이용하면 JIRA상에서 간단한 UI를 쉽게 디자인해서 Task에 붙일 수 있습니다.


호주에서 ARAIN씨가 소개해주셨습니다. ㄳ :)

JIRA 4가 Releae되었습니다.

ALM/Task Management | 2009.10.07 11:17 | Posted by 조대협

Atlassian의 JIRA4가 릴리즈되었습니다.
대쉬보드 SNS와 연동등 사용성이 한층 강화되었습니다. 역시 Atlassian은 실망 시키지 않는군요.
혹시 사용해보고 사용기 올리시는 분 있으시면 알려주세요.
저는 프로젝트 들어가야지나 사용해볼 수 있겠네요.

Adapting JIRA For Scrum
Scrum을 JIRA로 구현하는 방법인데, 간단하지만 실용적인 가이드 입니다. 확장 여지는 있지만 기본 방향은 권장할만 합니다. 참고하세요.
TAG ALM, JIRA, Scrum
PDF 버전입니다.

Overview

프로젝트에서 중요한 포인트중의 하나는 팀의 운영과 관리이다. 프로젝트에 Unified Process나 Waterfall model과 같은 기존의 방법론을 사용하더라도, 그 방법론에는 자세한 task 관리 프로세스에 대해서는 거의 정의가 되어 있지 않다. 

반대로 요즘 유행하는 Agile 방법론의 경우, task 관리에 대한 전략과 수행 방법을 기술하고 있지만, 실제 프로젝트를 관리하는 관점에서는 전체 스케쥴에 대한 예측과 관리가 어렵기 때문에(불확실성의 문제), SI 프로젝트등에서는 쉽게 적용할 수 없는 문제를 가지고 있다.

또한 실제 프로젝트에서는 이미 고객이나 주관사의 방법론을 표준으로 사용하고 있기 때문에 Agile 방법론을 적용하는 것이 쉽지 않다. 

이 문서의 목적은 위 두 가지 접근 방법의 문제점을 상호 보완하여, 전체 프로세스는 기존의 전통 방법론을 따르고, 전체 프로세스의 각 단계를 Agile 방법론으로 보완하여, 실질적인 task 관리 방법론을 구축하고자 하는데 목적이 있다. 

Agile 방법론은 요즘 들어 가장 인기 있고 가벼운 방법론 중에 하나이다. 이 방법론의 특징은 구성원간의 협업 (Collaboration)을 중요시 하는 사상을 가지고 있다. 본 문서에는 이 사상을 기반으로 하여, 일일 Task 관리를 하는 기법을 중심으로 설명하고자 한다. 

Agile 방법론에는 XP,AUP,Scrum,Lean 등 여러가지 구체적인 방법론 들이 있는데, 아래 도표를 보면 알 수 있듯이, 근래에 들어서는 Scrum이 가장 인기있고 많이 사용되는 방법론이다.


 출처 http://crankypm.com/2008/10/poll-results-software-development-methodologies-agile-vs-waterfall/

 Scrum

 Summary

그럼 먼저 Scrum 방법론에 대해서 살펴보도록 하자.


Scrum은 기본적으로 Iterative and incremental 개발 방법에 기초를 한다.

Scrum은 몇 개의 Iteration으로 구성되는데, 이 Iteration을 Sprint라고 부르며 각 Sprint는 1~4주 정도의 기간을 갖는다. 이 Sprint는 일종의 Timebox의 개념을 가지며 한번 정해진 Sprint의 기간은 변경될 수 없다는 것을 전제로 한다. 

다음으로 Scrum에는 고객의 요건으로부터 작성된 Product Backlog라는 것을 가지고 있다. 쉽게 이야기 하면 “대략적인 할일 목록”이다. 구현 단계에 Scrum을 적용할 경우에는 SRS (Software Requirement Specification)이나 TRS (Technical Requirement Specification)들의 목록이 Product Backlog의 항목으로 적절하다.

Product Backlog의 항목을 팀 미팅을 통해서 이번 Sprint에 구현할 항목을 선택한다. 항목의 선택은 Product Backlog 항목의 우선순위(Priority)를 통해서 선택이 되고, 이 선택된 항목들을 구체적으로 구현하기 위해서 TASK로 쪼게 진다. 이 task 목록은 이번 Sprint에서 구체적으로 해야 할 일을 정의하고 되고 이 목록 리스트를 Spring Backlog 라고 부른다.

 Sprint Backlog의 task 들은 스케쥴이 지정되어 팀의 담당자에게 Assign된다. 팀은 이 Sprint Backlog를 가지고 정해진 기간동안의 Sprint를 구현한다. 

Sprint중에 매일 아침 팀원들은 10~20분 정도의 Daily Scrum Meeting 이라는 회의 시간을 갖는데, 이 시간 동안, 팀원들은 어제 한일과 오늘 한일에 대해서 간략하게 보고하고, 기술적인 질의 사항에 대한 문의나 (팀원들의 도움을 받을 수 있는), RISK 사항등을 고융한다. 이 Daily Scrum Meeting을 통해서 팀은 현재 Sprint의 진행 상황을 공유할 수 있다.

 Sprint가 끝난 후에 팀은 프로젝트의 stakeholder (고객)과 간단한 Review 미팅을 갖는데, 주로 이번 Sprint 에서 구현한 내용을 간단한 형태의 DEMO로 소개를 하고 Feed back을 받아서 Product Backlog를 업데이트 하고 다음 Sprint를 준비한다.

 Review가 끝난 후에는 팀원끼리 Sprint에 대한 회고 (Restrospective)의 시간을 갖는데,

 이 시간에는 Sprint에서 Scrum 방법론을 적용했을 때의 잘되었던 점과 잘못되었던 점을 토론하여 Scrum 운영 프로세스에 반영하여 팀의 Scrum 운영 방식을 성숙화 시킨다.

Role in Scrum

Scrum에서는 이 프로세스를 적용하기 위해서 몇 가지 역할을 정의하고 있다.

Product Owner

Product Owner는 요구 사항을 정의하고, Product Backlog를 업데이트 하는 역할을 맏고 있다. 가장 중요한 역할은 Product Backlog내의 Item 에 대한 우선 순위를 정하고, 정해진 구현 기간 내에 프로젝트 팀의 ROI (Return Of Investment)를 극대화 하는 책임을 가지고 있다. Product Owner는 직접 Sprint에는 참여하지 않고, Sprint 전에 Backlog의 업데이트후, Spring review에 구현 내용이 요구 사항에 맞춰서 적절하게 구현되었는지 확인하는 작업에만 참여한다. 

Team

Team은 Product Backlog의 내용에 따라 Sprint에서 구현하는 역할을 맏는다. 

Scrum Master

Scrum Master는 Project Manager도 아니고, 3자의 입장에서 Team과 Product Owner가 Scrum 방법론을 제대로 수행할 수 있도록 돕는 역할을 수행한다. 예를 들어 Product Owner가 Sprint중에 요건을 추가하려고 할 때 이를 제지하거나, Team이 Scrum을 수행하는 데 어려움이 있을 때 이를 돕는 역할을 한다. 종종 Scrum Master의 역할과 Product Owner의 역할을 한 사람이 겸임하는 경우가 있는데, Scrum Master의 역할중의 하나가 Product Owner가 Sprint중에 영향을 줄 수 있는 요건 변경을 막아야 하는 역할이기 때문에, 겸임할 수 없다. 

지금까지 Scrum 방법론에 대해서 간략하게 설명하였다. 그러나 이 Scrum 방법론은 태생이 제품 개발을 위한 프로세스로 개발되었다. (Product Owner와 같은 용어에서 알 수 있듯이..) 그래서 Requirement나 기능의 추가/삭제가 비교적 자유로운 In house 개발이나 패키지 솔루션 개발에서는 사용될 수 있을지 몰라도, 구현해야 하는 Requirement의 범위가 고정적인 Enterprise 프로젝트에는 적용하기가 어렵다. 그래서 다음은 경험을 바탕으로 하여 Customize 한 Enterprise 프로젝트에서의 Scrum 프로세스에 대해서 설명하고자 한다.

 ALM / Task Management Process

Process Design Principals (프로세스 디자인 방향)

ALM / Task Management Process 의 기본 디자인 방향은 기존의 전통적인 개발 방법론을 대체하는 것이 아니라, 기존의 방법론은 전체 개발 프로세스를 커버하고, ALM / Task Management Process 는 Scrum 방법론에 기반 하여 각 단계에 대한 TASK 관리를 위해서 사용된다.


전체 프로젝트 관리로는 사용되지 않고, 각 수행 그룹에서 사용된다. (예를 들어 전체 프로젝트가, 고객 지원 업무, 빌링, 포탈 등으로 구성되어 있을 때 전체 프로젝트 관리는 전통적인 개발 프로세스에 기반하여 프로젝트가 관리되고, 빌링팀, 포탈팀 등 각 개발 단위팀에서는 ALM / Task Management Process 방법론을 이용하여 팀을 관리한다.)

Team Structure for ALM / Task Management Process

ALM/Task Management을 실제 팀에서 수행하기 위해서 팀 구조와 역할 정립이 필요하다.

l        Project Manager : 전체 프로젝트를 관리 하는 역할을 한다. 큰 프로젝트의 경우 PMO나 여러 개발 단위의 PM을 정의하며 주로 전통적인 개발 프로세스를 기준으로 프로젝트를 관리한다. 단 ALM / Task Management Process의 개념을 이해하고, ALM / Task Management Process와 기존의 개발 프로세스를 연계 시키는 역할을 맏는다.

l        Project Leader : 작은 조직이나 프로젝트에서는 PL이 없이 PM이 PL역할을 함께 하는 경우가 많으며, 실제 개발팀을 가지고 Implementation을 리드하는 사람이다. 실제로 ALM / Task Management process를 이용하여 팀의 Task를 관리한다.

l        ALM Process Coach : 특이한 Role일지도 모르겠는데, Scrum의 Scrum Master와 같은 역할로 생각하면 된다. Process가 팀에 완전히 정착되기 까지는 팀에 대한 교육과 프로세스에 대한 지속적인 Mentoring이 필요하다. ALM Process Coach는 팀의 프로세스를 set up하고, 팀이 프로세스를 준수하도록 도우며, 개선하는 역할을 진행한다.


실제로 모 금융 프로젝트에서 ALM / Task Management Process를 적용해본 적이 있는데, PM이 두개의 팀을 운영하고 있었다. 그중에 A팀에 본인이 투여되었고, ALM / Task Management Process와 System을 구축하여 A팀에서 적용하여 효과를 보자 PM이 다른팀(B팀)에도 본 프로세스를 적용해 주기를 요청하였다. 그래서 System을 공유해줬으나, B팀에는 별도의 코칭을 제공하지 않았다. 프로세스를 제대로 준수하는지, 상태 업데이트는 제대로 하는지에 대한 코칭이 없었는데, 1개월후 A팀은 Task Management Process에 어느정도 적응을 하여, 효율적으로 만족 스럽게 사용하고 있었으나, B팀의 경우 이 프로세스와 시스템 사용이 또 다른 Burden이 되서 실업무 따로, 시스템 운영 따로 되는 결과를 만들어 냈다. 그만큼 ALM / Task Management Process를 적용하기 위해서는 성숙단계까지 지속적인 관찰과 코칭이 필요하다.

 Step 1. Prepare Product Backlog

Product Back log는 실제로 구현되어야 하는 기능 목록을 나열한다.

목록은 고개의 요구 사항으로부터 도출 되는데, 일반적으로 SRS (Software Requirement Specification)이나 TRS (Technical Requirement Specification)로부터 도출이된다. 구체화 되고 정확하고 상세한 목록을 도출 해야 한다. 비즈니스 요건 같은 경우를 목록으로 도출하였을 경우에는 종료 조건이 모호해질 수 있고 그런 경우 종료에 대한 기준이 모호해 질 수 있다.

Product Back Log의 항목은 다음과 같다.

1) NO

ITEM에 대한 ID

2) Item

실제 구현 요건

3) Description

요건에 대한 간략한 설명

4) Estimated Resource

얼마나 많은 Resource가 소요되는 가에 대한 예측치를 기록한다. 이 값에 따라 추후 PLANNING에 반영한다. 이 값은 초기 예측 값으로 매번 Sprint가 종료될 때 마다 새롭게 업데이트 한다. 업데이트 기준은 기존에 수행한 Sprint의 Item의 실제 수행 시간을 기준으로 앞으로 수행할 Item의 상대적인 개발 난이도등을 측정하는 방법으로 예측할 수 있다.

5) WIKI URL

Back Log의 Item의 이름과 Description만 가지고는 정확한 요건을 알 수 없다. 그래서, 해당 Item에 대해서 정확한 요건 (Requirement description 또는 Use case)을 알기 위해서는 별도의 문서를 참조해야 한다. 문서는 MS-WORD와 같은 형태로 공유 파일 폴더에 들어가 있거나 Subversion과 같은 SCM에 저장이 되어 있거나 Wiki에 작성되어 있을 수 있다. 여기에는 Item과 요구 사항에 대한 추적성을 유지하기 위해서 해당 문서에 대한 위치 (파일 위치나, WIKI URL)을 기술한다.

6) Priority

Item에 대한 우선 순위를 지정한다. 이 우선 순위에 따라서 Sprint를 스케쥴링 하기 때문에 Product Back Log에서 매우 중요한 부분이다.

Priority의 설정은 비즈니스에 대한 영향이 큰 기능, 필수 기능, 그리고 난이도가 높은 기능, 비기능적 요건 등에 대해서 우선 순위를 높게 설정하는 것을 권장한다. 특히 비기능적 요건은 성능이나 안정성등에 관련되는 경우가 많고 이러한 요건들은 아키텍쳐에 많은 영향을 주고 아키텍쳐는 후반으로 갈수록 변경이 어렵기 때문에 초반에 구현 및 검증 작업을 수행해야 한다.

7) Status

Status는 해당 Item의 진행 상황을 의미한다. 이미 아직 진행전이지, 진행중인지 완료가 되었는지를 표현한다. 필드의 값은 프로젝트 상황이나 프로세스에 맞춰서 변화한다. (QA 검증중, 운영 서버에 반영됨 등)

8) Estimated Value of item (Optional)

이 항목은 Item의 비즈니스적인 가치에 대해서 점수를 메기는 방법으로 SI개발보다는 제품 개발이나 In House 개발등에 유용한 항목이다. 이 값의 조정을 통해서 Product Owner는 정해진 기간내에 최대의 ROI (Return Of Investment)를 낼 수 있도록 Back Log의 우선 순위를 지정할 수 있다. 

Step 2. Release Planning

해야할 일의 목록 (Product Back Log)가 정의 되었으면, 언제 어떤 일을 해야할 지를 정의해야 한다. 일반적으로 말하는 스케쥴링인데. Release Planning에서는 프로젝트의 큰 Mile stone을 정하는 작업을 한다. Release 시기 마다 작동 가능한 Product을 Release한다. (모든 기능이 완료되지 않았다 필 수 기능이 완성 되었으면 Release한다. ) Release된 시점에서 QA팀에게 Release version을 넘겨서 Testing을 수행하고 구현된 부분에 대한 품질을 보장 받는다. 이러한 활동은 모든 개발이 끝난 시점에서 Big bang 방식으로 통합하고 테스트 하는 기존에 방식에 비해서 위험을 조기에 발견할 수 있고, 그 위험을 해결하는 비용을 줄일 수 있다. (복잡한 문제일 수 록 나중에 발견되면, 더 고치기가 어렵다.)

그리고 이 Release version을 고객에게 DEMO를 통해서 요구사항과 부합하는 지 확인하고, 잘못된 부분에 대해서 수정할 수 있는 기회를 갖을 수 있다.

이 단계에서 해야하는 구체적인 작업은 다음과 같다.

1)       주요 릴리즈 일정 지정
2)       릴리즈 일정별 Product backlog 내의 Item 지정

이 단계에서 완성된 Release Plan은 Project 관리 입장 (Project Management Officer)에서 전체 스케쥴 WBS (Work breakdown structure)와 맵핑이 되서 관리팀 관점에서 스케쥴 관리를 용이하게할 수 있다.

Step 3. Sprint Planning

Release Planning이 끝난 후에는 각 Release를 달성하기 위해서 Release Planning을 Sprint로 나눈다.

전통적인 Scrum 방법론에서는 다음과 같은 절차로 Sprint를 계획한다.
l        팀원의 가용 시간
l        Product Back Log Item을 구체적인 Task로 분할
l        Task 에 대해서 수행 시간을 예측
그러나 이 전통적인 접근 방법은 몇가지 문제를 가지고 있다. 먼저 Task 에 대한 수행 시간 예측후에 가용 인력에 Assign하는 방식인데, 이는 각 팀원의 능력이 동일함을 전제로 하고 있다. 그래서 실제 프로젝트에서는 다음가 같은 방법을 권장한다.
l        Product Back Log Item을 Task 로 분할 
l        Task를 팀장이 적절한 사람에게 배분
l        배분된 사람이 Task의 수행 시간을 예측 하도록 함 

이 작업을 좀더 상세하게 설명해보면

 Sprint는 보통 1주~4주 정도로 정의된다. Sprint의 기간을 정의할 때 기준중의 하나는 고객의 요구 사항 변경이나 작업에 대한 변경도가 얼마나 많은가? 예측된 작업 일정이 충분한가? 와 같이 불확실성이 높을 수 록 Sprint 주기는 짧게 잡는 것이 좋고, 불확실성이 적고 스케쥴이 안정적으로 정의될 수 있는 경우에는 길게 잡는 것이 좋다.

 필자의 경우에는 보통 2주 정도를 Sprint주기로 관리를 한다.

Sprint를 정의할 때 먼저 Sprint 기간과, 가용 Resource를 바탕으로, Release Plan에 의해 정의된 Product Back log Item들의 예측 기간(Estimated Resource : Man/Day)를 기준으로 Sprint에 Product Back log Item 들을 할당한다. 

해당 Sprint의 기간과 수행할 Back Log Item을 정의하는 일은 PM/PL이 수행하는 것을 권장한다.

Scrum 방식이 유연 해도, 스케쥴 자체는 프로젝트 진행에 있어서 가장 중요한 RISK FACTOR중의 하나이며, 팀원간의 협의를 해서 진행한다 하더라도 고객 입장에서는 꼭 끝 맟춰야 하는 부분이기 때문에, 우선순위 지정과 스케쥴 조정은 그에 대한 책임을 지고 있는 프로젝트 관리자가 하는 것이 RISK 관리 측면에서 합리적이다.

 선별된 Product Back Log Item은 실제로 수행되기 위해서 구체적인 TASK로 나뉘어진다.

TASK는 어떤 사람이 무슨 일은 한다는 구체적인 정의로, 명확한 종결 조건을 가지고 있어야 한다. 예를 들어 “Logging 기능의 설계” 는 언뜻 보면 적절한 TASK로 생각될 수 있지만 설계에 대한 종료 조건이 명확하지 않다. 즉 “Logging 기능 설계 문서를 WIKI에 업데이트” 또는 “Logging 설계 REVIEW 회의”와 같이 산출물이나 회의와 같이 어느정도 정해진 종결 조건을 정의하게 되면 TASK를 관리하기가 용이하다. ( “Logging 기능의 설계” Task만 있다면 문제지 위에 예를 든 종료 조건이 다른 Task로 정의되어 있으면 괜찮다)

 실제 TASK관리를 해보면, “구현 TASK”가 끝났다고는 하는 경우 개발자 본인의 역량에 따라서 Coding만 되고 실제로 기능이 작동하지 않거나, 의도하지 않은 설계대로 구현되어 있는 경우가 생각보다 많기 때문에, 이런 경우 프로젝트를 관리하는 입장에서 “구현 보강” 이라는 새로운 TASK를 만들고 새롭게 RESOURCE와 시간을 할당해야 하는 부담을 가지게 되기 때문에, TASK에 대한 종료 조건을 명확히 하는 것은 매우 중요하다. 

1:1:1 법칙

 Task를 정의하는데 가이드를 제시하면, Product Back Log Item은 분석/설계, 구현, 테스트 이 3가지로 크게 분리될 수 있다. 어떤 구현 테스트를 하기 위해서 요건에 대한 분석 및 설계가 필요하다. 비록 미리 다 설계가 되어 있는 부분이라도, 실제 구현에 있어서는 국지적인 설계 변경이 필요하거나, Prototyping (설계 검증을 위한) 들이 필요하기 때문에 분석/설계에 대한 시간은 소요된다.

다음으로 테스트는 구현된 내용을 바탕으로 검증을 해야 하는데, 특히 비기능적인 요건은 시스템 테스트를 하지 않더라도 최소한 자기 PC에서 성능 테스트 (이를 Micro benchmark test라 한다.)를 하고 단위 테스트를 수행해야 하고, 구현이 아닐 경우라도 설계나 요건 분석등의 문서상 산출물은 REVIEW 시간을 필요로 하기 때문에, 일반적으로 분석/설계, 구현,테스트에 대한 시간 및 Resource 할당 비율은 1:1:1이 된다.

Task 수행의 위의 3단계가 종료될 때 마다 주요 Task에 대해서는  어떤 형식으로든지, 리뷰 회의를 갖는 것을 권장한다. (Peer Review, Team Walkthrough etc)

 20% 버퍼의 법칙

이렇게 Task list를 도출하고 나면 각 Task에 수행 시간과  담당자를 지정해야 한다.

Task list 도출과 이 과정은 팀원들과 함께 수행되어야 하는데, 팀원들의 능력과 근무 가능 시간이 각각 다르기 때문에 팀원의 의사가 매우 중요하다. 팀원과 미팅을 통해서 해당 Task를 수행 가능한 사람에게 Assign 하고, Assign을 받은 사람과 수행 시간을 논의하여 결정한다. 되도록이면 Assign 받은 사람의 수행 시간에 대한 결정과 의견을 존중하는 것을 권장한다. 실제 Task에 대한 시간을 Estimation해보면, 경험상으로 충분한 시간으로 Task 수행시간을 Assign 하게 하고 Buffer율을 20%를 두도록 해도, 실제 수행해보면 그보다 20~50%의 시간이 모자라는 경우가 태반이고, 이는 초반 프로젝트 스케쥴 관리에 Risk factor가 된다. 보통 1~2개월간의 Sprint 기간에는 이런 스케쥴 예측에 대한 오차 범위가 크게 나타나는데 이를 반영해서 일정을 잡고, 2개월 후에는 팀의 스케쥴 측정에 대한 경험이 쌓여서 점점 더 정확하고 세밀한 스케쥴 관리가 가능하게 된다. 

 이렇게 만든 Sprint의 Task 목록, 예측 시간, 담당자의 목록을 Sprint Back Log 라고 하고 다음과 같은 형태로 작성이 가능하다. 


위와 같이 엑셀을 사용해서 Sprint 스케쥴을 관리할 경우에는 Task의 스케쥴을 우측에 날짜 박스를 만들어놓고, 수행 기간을 칠해 놓는 방식으로 그래프 형태로 스케쥴을 관리할 수 있다. 

Release Planning과 Sprint Planning을 정리해보도록 하자.

기본 원리는 큰 스케쥴을 작은 단위의 스케쥴로 나누어서 관리하는 방법으로, 기존의 전통적인 방법론이 가지고 있는 스케쥴 단계를 Release Plan으로 나누어서 관리한다.

Release Plan은 PMO에서 관리될 수 있는 단위의 프로젝트 주요 Mile stone이 되며, 각 Release Plan은 실제 개발팀이 수행할 하루 단위의 개인 스케쥴로 정의되는 Sprint Plan으로 나뉘어서 관리 된다.


Step 4. Sprint Tracking

Sprint 계획이 끝났으면, 계획에 따라서 프로젝트를 수행한다.Sprint의 Task 진행 상황을 추적하기 위해서 몇 가지 기법을 지원하는데 다음과 같다.

Daily Scrum

Daily Scrum은 일일 오전 업무 공유(보고가 아닌) 회의이다., Scrum에서 가장 유용하고 중요한 기법 중의 하나이다.

Scrum 팀은 매일 오전에 같은 자리에 모여서 어제 자신이 한일과 오늘 자신이 해야할 일을 짧게 발표한다. 전체 회의 시간은 30분을 넘지 않도록 한다. 이와 함께 자신이 진행하고 있는 Task를 Close하는데 필요한 시간을 같이 이야기 한다.

이 과정에서 팀원은 다른 팀원의 Task 진행 상황을 Share할 수 있고, 만약 일의 진행에서 문제가 있는 부분이나 도움을 받고 싶은 부분은 이 회의 과정에서 이슈로 제기하여 다른 사람의 도움을 받거나 PM이 일정을 조정할 수 있도록 한다.

PM 관점에서는 Daily Scrum을 통해서 지정된 Task의 진행 상황을 매일 추적할 수 있다.

PM은 회의에서 공유된 일정을 바탕으로 Sprint Back Log 를 업데이트 하는데, 중요한 점은 각 Task의 종료시까지 남은 시간을 반드시 기록한다. 이 데이터는 처음 계획 대비 현재 상황이 어떻게 되고 있는지를 판단할 수 있게 해주는 중요한 지표가 된다.. 

이상적인 프로젝트 진행이라면 위의 Sprint Planning (칠해진 부분)이 끝나는 다음날 남은 작업 시간이 0 이 되어야 한다. 만약 연장 작업이 계속 되더라도 칠해진 블록의 범위는 변경하지 않고,  남은 날짜만 계속 업데이트 해간다. 그러면 추후에 결과가 계획 대비해서 얼마나 초과되어서 끝났는지를 확인할 수 있다. 

진행중에 고객 요건 변경이나 구현의 난이도에 의해서 스케쥴을 바꿔야 할 경우가 있는데, 전통적인 Scrum 방법론에서는 Sprint가 한번 계획된후에 Sprint 중간에는 바꾸지 못하도록 가이드 하고 있다. 변경이 생겼을 경우 Sprint를 중지하고 다시 Sprint 계획을 하도록 하는데, 국내 SI프로젝트와 같은 상황에서는 이를 매우 통제하기가 어렵기 때문에, 개인적으로는 융통성 있게 Task 를 추가하거나 일정을 변경하는 것을 반영하는 것을 권장한다. 단. Sprint 전체 스케쥴에 최소한의 impact를 줄 수 있는 범위내에서 변경을 하되, 새롭게 발생한 Task가 있을 때 그만큼 다른 Task에 대한 일정을 미루는 것을 전재로 해야 한다.

Burn down chart

Sprint Product Back Log를 위와 같은 방법으로 Update하면, 매일 남은 작업 일 수를 계산할 수 있는데, 이를 그래프로 표현한 것을 Burn down chart라고 한다.


이상적인 Burn down chart는

(remaining time)=(total work)/(current date)

의 형태를 띄어야 한다. 그리고 실제 프로젝트의 remaining time역시 이 이상적인 곡선에 근접해야 하는데, Burn down chart를 매일 업데이트 함으로써, 이상인 그래프에서 실제 프로젝트의 remaining time 그래프가 얼마나 벗어 나는가를 측정함으로써 프로젝트의 일정상 위기 요소를 파악하고 대비할 수 있다.

Burn down chart는 프로젝트 룸의 칠판이나 또는 시스템의 Dash board나, Daily Scrum 을 통해서 공유되는 것이 좋은데, 프로젝트 팀원 역시 사람이고, 사람은 Visual 한 개념을 통해서 현재 상태를 파악하고 프로젝트의 위험도를 좀더 체감할 수 있기 때문에, Risk 요소에 대해서 심각도를 서로 공유하는데 잘 사용될 수 있고 이는 실제 팀의 사기에 영향을 줄 수 있다. 

Task Status

다음으로 각 Task에 대해서 상태를 관리해야 한다. 위의 예시에서 보여준 Sprint Product Back Log의 Status 부분을 말하는데, 이 부분은 사실 매일 Daily Scrum 미팅을 하고 엑셀로 프로젝트를 관리하는 경우에는 크게 중요하지 않지만, 좀더 전문화되고 정교한 Task 관리 절차를 만들거나 시스템으로 구축하고자 할때는 제일 필수적인 부분이다.

시스템으로 구축할 경우에는 해당 TASK를 Daily Scrum 때 뿐만 아니라, 항상 상태를 업데이트 해서 팀원이나 운영 조직간에 자주 의사 소통을 할 수 있고, 저장된 상태나 값을 기반으로 여러가지 지표를 뽑아 낼 수 있다.

Task Status는 Task의 상태 흐름에 따라 정의 되는데 이를 Task Workflow라고 한다. Task Workflow는 최대한 단순해야 하며, 관리 지향적이기 보다는 실무 중심적이어야 한다.

 또한 Workflow가 적용되는 업무의 특성별로 잘 정의되어야 한다. (개발의 Task workflow와 Bug의 Task workflow는 분명히 달라야 한다.) 

다음은 Task workflow의 예이다.


l       
Open (생성됨) 새롭게 생성되고 정의된 TASK로, 담당자가 지정되지 않은 TASK이다.
l        Assigned (할당됨) TASK가 담당자와 협의를 거쳐 지정되게 되고, 수행 시간이 ASSIGN되고 스케쥴링 된 상태이다. 이때 반드시 담당자가 TASK의 내용을 이해하고 자신에게 ASSIGN되었다는 것을 인지해야 한다.
l        Need more information (추가 정보 필요) 만약에 할당 받은 Task의 내용이 명확하지 않거나 추가 정보가 필요할 경우 Need more information으로 상태를 바꾸고 PM/PL에게 Task의 재정의를 요청하는 상태이다.
l        In Progress 지정된 (진행중) TASK를 개발자가 작업을 시작했을 때 “진행중” 인 상태를 나타낸다.
l        Postponed (연기됨) 진행중인 작업이 어떤 이유(Product Bug, 환경 준비 미비)로 인해서 더 이상 진행할 수 없을 때, PM과 상의하여 해당 Task를 “지연” 상태로 변경한다.
l        Resolved (해결됨) 개발자가 할당된 TASK를 완료하고 종료조건을 충족하였을 때, “해결됨” 상태로 바꾸고 PM에게 작업이 완료되었음을 알린다.
l        Closed (종료됨) PM은 개발자가 완료한 작업을 TASK의 지시사항대로 제대로 종료되었는지 확인하고, 종료조건을 충족하여 제대로 완료되었을 경우에는 “종료” 상태로 바꾸거나, 만약 제대로 종료가 되지 않았으면 상태를 Assigned로 바꿔서 다시 개발자에게 할당한다.

Step 5. Ending Sprint

정해진 기간 동안 Sprint가 종료되면, Sprint를 정리 한다.Sprint의 종료 조건은 팀에 따라 정할 수 있는데 크게 아래 조건들을 많이 사용한다.
l        정해진 시간
l        Task 종료
l        예산 종료시 까지

어떤 조건을 사용하던지, 가장 중요한 것은 명시적인 종료 조건을 정의 해야 한다는 것이다.
좋은 종료 조건의 예
1)       구현의 경우  : 단위 테스트 100% 성공, Code Coverage Rate 60% 달성
2)       설계 단계 : 메시지 채널 설계 문서 고객 확인 받음
3)       설계 단계 : Prototype 작성 및 A,B,C,D 기능 동작 확인
4)       기간 BASE 경우 : 3/19일까지 코드 분석된 내용 리뷰 (이 경우, 컨설팅이나 Code Inspection, 탐색적 테스팅 같이 특정 기간과 예산을 가지고 진행하는 경우에는 기간 단위의 종료 조건을 사용하는 경우도 있다. )

Review Sprint

Sprint가 종료된 후에는 Sprint에서 구현된 산출물을 Review하는 단계가 필요하다. 요건에 따라 적절하게 구현이 되었는지 품질은 만족해야 했는지 등의 검증이 필요하다.

단순히 Sprint에서 무엇 무엇을 했고, 잘됐다 안됐다가 아니라, 실제 구현 코드, 산출 문서, 테스트 결과등의 구체적인 자산을 가지고 Review를 수행해야 한다.

이 과정에서는 고객을 참여 시켜서, 자산에 대해서 간략한 데모를 고객에게 수행한다. 이 데모는 고객 보고를 위해서 별도의 PPT나 데모 준비를 하는 것이 아닌 Informal한 리뷰이다. Formal한 리뷰는 Release 시기별로 진행하도록 하고, Sprint Review 준비를 위해서 별도의 시간이나 Resource를 낭비하지 않도록 한다. 

Test

특히 Sprint가 Implementation인 경우, Implementation이 제대로 완료되었는지 아닌지를 확인할 수 있는 방법은 Testing 밖에 없다.

Sprint Planning에서 Implementation의 경우 Test Task를 반드시 포함시켜야 하고, Review과정에서는 이 Test 결과를 Review하도록 한다. Test는 기능적 테스트 뿐만이 아니라 , 안정성이나 성능과 같은 비기능적 요건에 대한 Test도 반드시 포함되어야 한다.

 Sprint별 테스트를 통해서 잠재적인 문제를 빨리 찾아낼 수 있고 필요에 따라서 디자인이나 아키텍쳐에 대한 변경을 가할 수 있다. 

 Scrum을 사용하는 실제 구현 팀에 대해서 테스팅 구현은 다음과 같은 구현을 권장한다.
l        단위 테스트 (Unit Test) : 개발자가 개발 컴포넌트 단위로 테스트 수행
l        회귀 테스트 (Regression Test) : 테스트 했던 내용을 다음 테스트에도 포함 시켜 새로운 코드 추가나 변경이 기존 기능에 영향을 주지 않는 지 매번 검증
l        테스트 자동화 (Test Automation) : 테스트를 자동화 하여 회귀 테스트를 지원하고, 테스팅의 효율성을 극대화 함
l        점진적 통합 (Contiguous Integration) : 일일 빌드등을 통해서 BIG BANG방식의 코드 통합이 아닌 점진적 통합 전략을 사용함 

[!] 위의 내용은 본 문서에서 다루고자 하는 범위가 아니기 때문에 좀더 자세한 부분은 ALM/Test Automation 과 ALM/Build Automation 을 참고하기 바란다.

Code Review

Code Review는 완성된 산출물을 같이 Review하여 Defect를 찾아내고, 좀더 좋은 개선 방안에서 의견을 수렴하는 자리다. 일반 Review와 달리, 특정 산출물을 가지고 진행한다는 것이 다른데, 주로 Design이나 Implemented code와 같은 구현에 밀접한 산출물을 가지고 진행한다.

Code Review는 원래 Code Inspection이라는 개념에서부터 시작했다. Code Inspection 전문적인 지식을 가지고 있는 팀이 정형화된 프로세스에 따라서 Code를 Review하고 Defect를 발견하는 과정을 정의 한다. Code Inspection은 Assembly 로 코딩하던 시절에 시작되었고, 요즘과 같이 많은 코드와 변경 사항이 있는 시스템에서는 적용하기가 적절하지 않다. 그래서 좀더 비형식적인 Code Review 형태가 개발되었는데, Team Review, Walkthrough, Peer Review등이 그것에 속한다. 

[!] Code Inspection은 특정 룰을 바탕으로 하기 때문에 자동화된 툴을 통해서도 어느 정도 효과를 볼 수 있다. Code Inspection을 위한 팀과 프로세스를 구성하는 것보다 Test 과정에 Inspection 도구를 사용하면 최소한의 비용으로 효과를 볼 수 있으며, Open source 기반의 Inspection 도구로는 PMD, FindBugs를 권장한다.

 어떤 형태로건, 비형식적인 Code Review는 준비 시간이 짧고, 그에 비해서 Defect나 시스템 개선에 대한 효과가 상대적으로 크기 때문에, Sprint 말에는 Code Review를 수행하는 것을 권장하며, Sprint 중간에라도, 구현 Task 가 끝났을때는 비정기적으로라도 Code Review를 수행하는 것을 권장한다. 

[!] 위의 내용은 본 문서에서 다루고자 하는 범위가 아니기 때문에 좀더 자세한 부분은 ALM/Collaboration 을 참고하기 바란다.

 Code Review를 진행함에 있어서 중요한 점은 Code Review도 Resource와 시간이 투여되는 작업인 만큼 하나의 Task로 정의되어 관리 되어야 한다.

Code Review시에는 Code Review 결과를 Wiki등에 Meeting Minutes (회의록) 형태로 기록 해야 하며, Review 과정에서 나온 내용들은 Action Item으로 정리되어 Sprint Back Log내에 Task로 생성되고 관리되어야 한다.

Step 6. Update product backlog

Review가 끝났으면 Review 과정에서 나온 추가 요건이나 변경 상황을 반영하여 Product Back Log를 업데이트 한다. 팀이 모여서 우선 순위를 재 조정하고, 요구 사항을 좀더 구체화 하며, 예상 소요 시간을 업데이트 한다.

사람들은 프로젝트를 수행하면서 배우게 되고, 실력적으로 진화하게 된다. 그래서 요구 사항이나 예측치는 그때 상황에 따라 계속 업데이트 되어야 한다. Product Back Log 는 고정된 것이 아니라 항상 변경되고 실상황을 반영해야 한다.

Step 7. Retrospective

 Sprint가 종료되고 모든 작업이 끝나면, 팀에서 운영중인 방법론 자체에 대한 Review가 필요하다. 팀에서 운영중인 Task Management Process는 처음에 셋업 되면 많은 시행 착오를 겪게 된다. 수행 시간 예측이나, Sprint 주기 설정, Task 관리 프로세스 등등 많은 과제들이 있는데 Sprint의 경험을 기반으로 회고를 수행함으로써, 프로세스를 발전시킬 수 있는 방향을 찾을 수 있다.

가장 간단한 수행 방법은 PM이 이메일이나 종이를 이용하여 이번 Sprint에 “무엇이 잘되었는가?” 와 “무엇이 잘못되었는가”를 수집한다음에 SWOT 분석

(http://en.wikipedia.org/wiki/SWOT_analysis )  등을 통해서 개선 방안을 찾아볼 수 있다.

 Process Summary

지금 까지 설명한 프로세스를 개념을 한 그림으로 정리해보면 다음과 같다.


 Implementation

실제로 Task Management Process를 구현하는 몇 가지 방법에 대해서 설명한다. 가장 중요한 점은, 어떤 툴을 사용하느냐가 아니라 어떤 프로세스를 사용하느냐이다.

종종 ALM / Task Management Process를 현업에 적용해보면 문제가 프로세스에 대한 인식이나 성숙된 적용이 없이, 툴을 도입해서 툴에 이끌려가는 경우가 많다. 그래서 프로세스 자체가 또 다른짐이 되고 실제 업무 따로 Task 관리가 따로 이루어 지는 경우를 많이 봤다.

어떤 툴을 사용한다고 해도, 조직과 업무에 맞는 현실적이고 실행 가능한 프로세스를 사용하는 것이 가장 중요하며, 이를 위해서는 1~2개월 정도의 시행 착오 기간이 생길 수 있고 가급적이면 이 기간 중에는 프로세스를 관리하고, 이해 당사자들이 제대로 프로세스를 준수 하는 지를 챙길 수 있는 Coach를 두는 것을 권장한다.

Jump start with Excel

소규모의 팀에서 이 Task Management Process를 사용하기 위해서는 툴과 도구를 설치하는 시간에 대한 소모를 줄이기 위해서 Microsoft Excel만을 사용해도 충분하다. 보통 단일팀에서 10명 이하라면 약간 불편하긴 하지만 빠르게 방법론을 적용할 수 있고, 만약에 시스템을 적용하더라도, 가장 중요한 것은 프로세스이기 때문에 구축 전에 미리 Excel을 이용하여 프로세스를 적용해보고 단계적으로 발전 시켜가는 것을 권장한다.

Excel Template은 http://bcho.tistory.com에서 다운 받을 수 있다.

Implement Task management process with Atlassian Product

회사내에 자체적으로 ALM을 구축하고자 할때는 Atlassian Product를 추천한다.

Atlassian은 JIRA라는 Issue tracking 시스템을 가지고 있는데, 태생 자체가 Task 와 같은 프로젝트 관리 관점 보다는 Bug Tracking 관점의 접근이기 때문에 툴과 Process에 대한 Customizing이 필요하다 그러나 상대적으로 가격이 매우 저렴하고, (Professional Version이 250만원선) 전세계적으로 매우 널리 사용되기 때문에, 관련 자료나 Plug in 들이 많다.

또한 CI나 테스팅 툴, SCM 도구들과 잘 통합이 되는 장점도 가지고 있다.

아래는 ALM/Task Management process 구축을 위한 Atlassian 제품을 이용한 권장 구축 아키텍쳐 이다.


1)       Task Management : Sprint에서 관리되는 각종 Task를 관리한다. Atlassian의 JIRA(이슈 트랙킹) 시스템으로 구축하되, Product BackLog Item과 Sprint Back Log Item이 서로 Parent/Child 관계로 맵핑이 되어야 하기 때문에 Issue에 대한 Parent/Child 관계는 JIRA Professional Version 이상에서만 지원한다.

2)       Product Back Log Mgmt : Product Back Log에는 Product Back Log Item들과 그에 대한 자세한 설명 (예를 들어 Use case)이 들어간다. Product Back Log Item은 JIRA내에 Parent Task로 등록해서 관리할 수 있기 때문에 이에 대한 연관 관계를 JIRA내에 확장 필드로 등록하여 Wiki와 JIRA 사이에 상호 추적이 가능하도록 구축한다.
그 위에 Zagile의 Wiki Smart라는 플러그인을 사용할 수 있는데, Wiki Smart를 사용하면, Product Back Log Item 입력등을 위키 형식이 아니라 좀 더 정형화된 폼을 이용해서 사용할 수 있다.

3)       WBS Mgmt : 전체 프로젝트의 WBS를 관리할 때 통상적으로 사용하는 도구가 MS Project이다. http://www.the-connector.com/ 에서 제공하는 플러그인은 MS-Project의 Task와, JIRA의 Task를 연계 시켜준다. 이 도구를 이용하여, MS-Project를 이용한 WBS 관리와 JIRA를 통한 실제 Task 관리를 연동 할 수 있다.

4)       Integrated view : JIRA와 Wiki는 각각의 View를 가지고 있기 때문에 한눈에 원하는 화면을 보기도 어려울 수 있고 이로 인해서 툴의 사용 효율성이 떨어질 수 있다. zAgile의 Portal 도구는 Atlassian의 툴을 하나의 View로 통합할 수 있는 기능을 제공한다.

5)       Personalized view : 각 이해 당사자 Customer/PM/PL/개발자 별로 봐야 하는 화면이 틀리다. Customer나 PM은 프로젝트의 진척도나 위험도등의 간단한 Dash board를 보고 싶어하며, 개발자는 자신에게 할당된 작업상황에 대한 모니터링을 원한다. zAgile Portal은 개인화 기능을 제공함으로써 역할별로 원하는 화면을 만들 수 있도록 한다.

 Implement Task management process with VersionOne

다음으로 Version One (http://www.versionone.com )이라는 전문화된 Task Management 도구가 있다. AUP나 Scrum과 같은 Agile 방법론을 기반으로 하고 있기 때문에 본 Task Management Process에도 적용이 잘 된다.

 또한 패키지 판매와 함께, Hosting service도 제공하기 때문에 프로젝트 수행후 빠지는 SI 성 프로젝트에서 임시로 사용하기에는 그만이다. (1 Project의 경우 제한된 인원 내에서 무료로 사용할 수 있으니,작은 조직에서 툴을 Evaluate 할 경우 추천한다.)

 단 Issue tracking에 주 목적을 두고 있기 때문에 ALM의 Build Automation이나 Test Automation등의 통합에 문제가 있을 수 있다.

 Conclusion

Agile 방법론이 아무리 실용성을 강조하더라도, Risk관리 측면이나 일정 비용을 가지고 프로젝트를 진행하는 현실에서는 Agile의 목표가 불 명확한 방법론은 적용하기가 어렵다. 그래서 전체 프로젝트에 대한 큰 Mile stone은 기존 방법론을 적용하고, 그 아래에서 Agile 방법론을 팀의 Task 관리 기법으로 사용하도록 디자인 된 것이 ALM / Task Management Process이다.

 ALM/Task Management Process를 실제로 구현하는데 가장 중요한 것은 어떤 전문화된 시스템이나 도구가 아니라, 팀이 최대한의 효율을 낼 수 있는 프로세스이다. 도구는 프로세스를 도와주기 위해서 존재하는 것이지, 도구에 프로세스나 팀이 이끌려 가서는 안된다.

Reference

Methodology

1) SWOT Analysis : http://en.wikipedia.org/wiki/SWOT_analysis
2) Scrum in 5 minutes : http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf
3) Scrum primer : http://scrumtraininginstitute.com/home/stream_download/scrumprimer

Tools

1) Atlassian : http://www.atlassian.com
2) JIRA : http://www.atlassian.com/jira
3) Confluence Wiki : http://www.atalssian.com/confluence
4) JIRA & MS Project Connector : http://www.the-connector.com/
5) zAgile  : http://www.zagile.com
6) VersionOne : http://www.versionone.com





 

ALM-Project Management

ALM/Task Management | 2008.12.24 10:43 | Posted by 조대협
ALM의 이슈트랙킹 시스템을 통한 프로젝트 관리 방법입니다.
아래 그림이 구현하고자 하는 내용의 모두라고 볼 수 있습니다.
  •  PM : 요구 사항을 시스템에 등록하고 각 요구 사항에 대해서 스케쥴링을 한후에 각 요구사항을 해당 개발팀의 팀장에게 ASSIGN합니다.
  • PL : PL은 각 요구사항을 분석하여 실제 작업(TASK)로 쪼게고 개발자의 스케쥴과 역량 그리고 작업의 심각도와 긴급도에 따라서 개발자에게 ASSIGN합니다.
  • 개발자 : 개발자는 진척 상황을 TASK에 COMMENT로 로깅하고, 각 TASK에 연관된 단위 테스트 케이스를 작성하여 진행을 합니다.
  • PM은 요구 사항을 개발 PL뿐만 아니라, QA 팀에도 ASSIGN하는데 QA 팀에서는 각 요건을 검증할 수 있는 테스트 케이스를 개발 초기단계 부터 작성합니다. 이 테스트 케이스들 (실제로 구현된 JUnit과 같은 구현체)은 Test case management 라는 툴에서 관리 됩니다. 한번 등록된 테스트 케이스들은 이 툴에서 다시 Invoke될 수 도 있고, 그 결과 역시 시스템에 다시 레코딩이 됩니다.
  • 테스트 과정에서 발생된 문제는 Defect Management System(버그 추적도구)에 의해서 리포팅이 되고 각 버그는 하나의 TASK로 PM->PL을 거쳐 개발자에게 다시 ASSIGN이 됩니다.


    이 일련의 프로세스가 ISSUE TRACKING시스템을 통해서 구현되고 각각의 TASK가 추적성을 갖게 됩니다.

이것이 ALM의 PROJECT MANAGEMENT모듈의 개념입니다.
어떤 툴을 사용하느냐, 개발팀의 모델이나 일정 수준에 따라서 Variation이 상당히 많습니다. 그외에 PM이나 고객을 위해서 DASHBOARD를 제공하거나 개발자를 위해서 Eclipse에 플러그인(Mylyn)을 제공하거나 환경적인 설정 방법도 상당히 많습니다. 제대로 적용하면 상당히 효과가 좋은 모듈이지만 반대로 잘못하면 자체가 짐이 되버리는 경우가 많기 때문에 도입시에 많은 고려가 필요한 부분입니다.

개인적으로 JIRA,Mantis,Bugzilla를 프로젝트에서 사용해봤고, Trac,Polarion,Code Beammer, Rally Enterprice, VersionOne등의 이슈관리 도구들을 테스트해봤지만 개인적으로 가장 사용하기 편하고 유연성이 있으며 가격대비성능(ROI)가 높은 도구는 JIRA인것 같습니다.

JIRA 교육용 자료

2008.07.29 16:03

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

JIRA는 Atlassian사에서 개발한 Issue Tracking System이다. 원래 이 "이슈 관리 시스템"은 버그 추적 시스템에서 시작되어서 현재는 버그뿐만이 아니라 일반적인 이슈에서 부터 프로젝트 관리까지를 지원한다.

본 프로젝트에서는 JIRA를 프로젝트 스케쥴에 대한 관리도구와 개발원간에 작업을 배분하고 커뮤니케이션하는 도구로 사용한다.

  • Issue

지라에서는 각각의 작업을 이슈라는 단위로 관리하고 이슈의 종류를 다음과 같이 정의하였다.

  • User Story
    사용자의 요구 사항이나 개발의 대상이 되는 기능이다. User Story를 구현하기 위해서 각각의 User Story는 구체적인 작업인 Task를 하위작업으로 가지고 있다.
  • Task
    User Story의 하위 작업으로 User Story를 위해서 개발자가 실제로 작업해야 하는 각각의 단위 작업을 의미한다.
  • Bugs
    개발과정중에 보고된 버그
  • Enhancement Request
    기능 개선 요청으로 기능 추가 작업이다.
  • Issue 단위의 작업 절차 

이 이슈단위로 작업을 진행하는 절차를 정리해보면 다음과 같다.

  • 먼저 PM이 요구 사항을 취합하여 User Story를 작성한다.
  • 다음으로 User Story를 구현하기 위해서 실제 Task들을 해당 User Story 아래에 생성한다.
  • 다음으로 생성된 Task들을 개발자에게 지정(Assign) 한다.
  • 또는 Assign 되지 않은 작업에 대해서 개발자가 스스로 작업을 가지고 가서 작업을 진행한다.

실제로 하나의 예를 들어보자.

프로젝트 진행을 위한 환경 설정을 하기 위해서 개발 환경 설정이라는 이슈를 이슈#1에 User Story 타입으로 생성하였다.
다음으로 JIRA의 환경 설정 SubVersion의 설치, ANT설치를 각각 Task로 생성하고 JIRA 환경 설정은 choi씨에게 지정하였다. choi씨는 지라에 로그인하여 자신에게 "JIRA 환경 설정" 에 대한 Task가 지정되어 있음을 확인하고 해당 이슈를 진행한후 Close 하였다.

이와 같은 시나리오를 거치게 된다.

  • JIRA 사용법

자바스터디 지라 사이트에 접속한다. IP는 http://211.115.216.55:9000/jira 아이디와 비밀번호는 bwcho75@지메일에 신청하여 발급 받는다. 발급받은 아이디와 비밀번호로 로그인을 한다.

사용자 삽입 이미지

로그인후에 HOME 을 보면 위와 같은 화면이 나오는데, 이 화면은 화면 우측 위쪽에 "Configure ON|OFF" 에서 ON을 누르면 HOME 에 자신이 필요한 기능들을 추가하거나 삭제하여 마음대로 초기화면을 구성할 수 있다. 현재 보이는 초기화면은 Calendar를 추가한 화면이다.
오른쪽에 "Open Issues: Assigned To Me"에 이슈가 리스팅 되어 있는 것이 보이는데, 이는 나에게 작업을 하도록 할당된 이슈이다.
또는 Home에서, "Filter Issues:" 메뉴에서

All을 선택하면 전체 이슈
Assigned to me 는 나에게 작업을 하도록 할당되어 있는 이슈
Reported by me 는 내가 보고한 이슈이다.

User Story등은 PM이 생성하고 일반 개발자들이 생성할일이 없으며, 일반 개발자들이 생성할 수 있는 이슈의 종류는 User Story아래에 있는 Task나 Enhancement Request (기능 개선 요청) 또는 버그이다.

아래 화면은 지정된 이슈를 클릭한 화면인데,

사용자 삽입 이미지

  • 왼쪽 상당의 상태는 현재 "Status : In Progress" 상태이다. 이는 현재 Task를 개발자가 받았고 실제로 작업을 진행중인 상태라고 표시되는 것이다.
    처음에 생성되고 개발자에게 지정되거나 또는 지정이 안된 상태의 이슈들은 진행이 아직 안되어 있는 것이기 때문에 "Status : Open" 으로 출력 된다. 이를 진행으로 바꾸기 위해서는 "Avaliable Workflow Actions"에서 "Start Progress"를 누르면 상태가 "In Progress"로 변경된다.
  • 만약에 이슈를 다른 사람에게 할당해야 할 경우에는 좌측 중간의 "Assign this issue"메뉴를 클릭하여 다른 사람에게 Issue를 할당할 수 있다.
  • 만약에 이 이슈가 자신이 해결할 수 없을 경우에는 PM에게 해당 이슈를 할당하여 PM이 적절한 사람에게 이슈를 할당하도록 한다.
  • 이슈에 대한 진행 내용은 빠짐없이 왼쪽 메뉴의 "Comment on this issue"를 이용하여 진행 현황등을 기록하고, 만약 PM이나 다른 사람과 의사소통이 필요할 경우에도 Comment를 단 후에 담당자에게 Assign하는 식으로 의사 소통을 진행한다.
  • 해당 이슈 해결이 끝난 경우에는 "Resolve Issue" 메뉴를 이용하여 이슈가 해결된 상태로 변경하고, 만약 이슈에 대한 검증이 필요할때는 해당 담당자에게 할당한다. 이런 흐름은 예를들어 개발을 완료한후에 QA조직에 테스트를 요청할 경우 이러한 흐름을 따르게 된다.
  • 테스트와 검증이 모두 완료되면 "Close Issue"를 통해서 해당 이슈를 완전히 종료 한다.
  • 본 프로젝트에서는 일반적인 환경 설정등의 작업은 개인이 CLOSE를 해도 되지만 개발에 관련된 Task는 Resolved 상태로 바꾼후에 PM에게 다시 Assign하여 PM이 CLOSE할 수 있도록 한다.

정리하면

  1. PM이 User Story를 만든다.
  2. PM이 거기에 해당되는 Task들을 생성
  3. PM이 Task를 개발자에게 배분
  4. 개발자가 해당 Task를 받은후 "In Progress" 상태로 바꾼다.
  5. 개발자가 진행 내용이나 의사 소통이 필요한 정보를 Comment로 적는다. (이때 필요하면 Attach 메뉴를 이용하여 파일을 첨부할 수 도 있다.)
  6. 개발자가 개발을 완료 하면 상태를 Resolve Issue 를 이용하여 상태를 바꾸고 PM에게 다시 이슈를 Assign한다.
  7. PM은 Resolved된 이슈들이 제대로 반영되었는지를 확인한후에 Close상태로 변경한다.

이번글에서는 이슈 처리에 대한 워크플로우와 프로젝트에서 사용할 이슈의 종류에 대해서 알아보았다. 다음글에서는 "버전" 에 따른 스케쥴 관리 방법에 대해서 알아보겠다.

'ALM > JIRA' 카테고리의 다른 글

Atlassian JIRA를 이용한 애자일 Scrum 프로젝트 관리  (15) 2013.12.20
JIRA 클라이언트  (0) 2008.11.07
Atlassian JIRA를 이용한 프로젝트 관리 (기초편)  (0) 2008.04.04
JIRA와 SVN 연동  (1) 2008.03.03

JIRA와 SVN 연동

ALM/JIRA | 2008.03.03 20:49 | Posted by 조대협


문서가 가로로 스크롤되서 못봤었네..
commit할때 간단하게 Issue #를 적어주면 된다.

http://confluence.atlassian.com/display/JIRAEXT/JIRA+Subversion+plugin

To link a commit to a JIRA issue, the commit's text must contain the issue key (eg. "This commit fixes TST-123").

'ALM > JIRA' 카테고리의 다른 글

Atlassian JIRA를 이용한 애자일 Scrum 프로젝트 관리  (15) 2013.12.20
JIRA 클라이언트  (0) 2008.11.07
Atlassian JIRA를 이용한 프로젝트 관리 (기초편)  (0) 2008.04.04
JIRA와 SVN 연동  (1) 2008.03.03
TAG JIRA, SVN