ALM / Task management process Table ofcontents 자바스터디조대협 (http://bcho.tistory.com) Overview... 2 Scrum... 3 Summary... 3 Role in Scrum... 5 Product Owner... 5 Team... 5 Scrum Master... 5 ALM / Task Management Process... 6 Process Design Principals ( 프로세스디자인방향 )... 6 Team Structure for ALM / Task Management Process... 6 Step 1. Prepare Product Backlog... 7 Step 2. Release Planning... 9 Step 3. Sprint Planning... 9 Step 4. Sprint Tracking... 12 Daily Scrum... 12 Burn down chart... 13 Task Status... 14 Step 5. Ending Sprint... 15 Review Sprint... 15 Step 6. Update product backlog... 17 Step 7. Retrospective... 17 Process Summary... 18 Implementation... 19 Jump start with Excel... 19 Implement Task management process with Atlassian Product... 19 Implement Task management process with VersionOne... 21 Conclusion... 21 Reference... 21
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을실제팀에서수행하기위해서팀구조와역할정립이필요하다. Project Manager : 전체프로젝트를관리하는역할을한다. 큰프로젝트의경우 PMO나여러개발단위의 PM을정의하며주로전통적인개발프로세스를기준으로프로젝트를관리한다. 단 ALM / Task Management Process의개념을이해하고, ALM / Task Management Process와기존의개발프로세스를연계시키는역할을맏는다. Project Leader : 작은조직이나프로젝트에서는 PL이없이 PM이 PL역할을함께하는경우가많으며, 실제개발팀을가지고 Implementation을리드하는사람이다. 실제로 ALM / Task Management process를이용하여팀의 Task를관리한다.
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를계획한다. 팀원의가용시간 Product Back Log Item을구체적인 Task로분할 각 Task 에대해서수행시간을예측그러나이전통적인접근방법은몇가지문제를가지고있다. 먼저 Task 에대한수행시간예측후에가용인력에 Assign하는방식인데, 이는각팀원의능력이동일함을전제로하고있다.
그래서실제프로젝트에서는다음가같은방법을권장한다. Product Back Log Item을 Task 로분할 각 Task를팀장이적절한사람에게배분 배분된사람이 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 Back Log : Sprint Planning 단계에작성됨 위와같이엑셀을사용해서 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 의종료시까지남은시간을반드시기록한다. 이데이터는처음계획대비현재상황이어떻게되고있는지를판단할수있게해주는중요한지표가된다.. 종료까지남은날짜 Daily Scrum 에서업데이트
이상적인프로젝트진행이라면위의 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 의예이다. Open ( 생성됨 ) 새롭게생성되고정의된 TASK 로, 담당자가지정되지않은 TASK 이다. Assigned ( 할당됨 ) TASK 가담당자와협의를거쳐지정되게되고, 수행시간이 ASSIGN 되고스케쥴링된상태이다. 이때반드시담당자가 TASK 의내용을이해하고
자신에게 ASSIGN되었다는것을인지해야한다. Need more information ( 추가정보필요 ) 만약에할당받은 Task의내용이명확하지않거나추가정보가필요할경우 Need more information으로상태를바꾸고 PM/PL에게 Task 의재정의를요청하는상태이다. In Progress 지정된 ( 진행중 ) TASK를개발자가작업을시작했을때 진행중 인상태를나타낸다. Postponed ( 연기됨 ) 진행중인작업이어떤이유 (Product Bug, 환경준비미비 ) 로인해서더이상진행할수없을때, PM과상의하여해당 Task 를 지연 상태로변경한다. Resolved ( 해결됨 ) 개발자가할당된 TASK를완료하고종료조건을충족하였을때, 해결됨 상태로바꾸고 PM에게작업이완료되었음을알린다. Closed ( 종료됨 ) PM은개발자가완료한작업을 TASK의지시사항대로제대로종료되었는지확인하고, 종료조건을충족하여제대로완료되었을경우에는 종료 상태로바꾸거나, 만약제대로종료가되지않았으면상태를 Assigned로바꿔서다시개발자에게할당한다. Step 5. Ending Sprint 정해진기간동안 Sprint가종료되면, Sprint를정리한다. Sprint의종료조건은팀에따라정할수있는데크게아래조건들을많이사용한다. 정해진시간 Task 종료 예산종료시까지어떤조건을사용하던지, 가장중요한것은명시적인종료조건을정의해야한다는것이다. 좋은종료조건의예 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을사용하는실제구현팀에대해서테스팅구현은다음과같은구현을권장한다. 단위테스트 (Unit Test) : 개발자가개발컴포넌트단위로테스트수행 회귀테스트 (Regression Test) : 테스트했던내용을다음테스트에도포함시켜새로운코드추가나변경이기존기능에영향을주지않는지매번검증 테스트자동화 (Test Automation) : 테스트를자동화하여회귀테스트를지원하고, 테스팅의효율성을극대화함 점진적통합 (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