agile 헨릭은총체적인접근방식을택하여관리자, 개발자, 스크럼마스터, 강사, 코치와같이서로다른역할을해보는것을즐긴다. 그는어떤역할이든지필요할때그역할을맡아서, 회사가뛰어난소프트웨어를개발하고훌륭한팀을만들도록열정적으로돕고있다. XP 헨릭은일본에서자랐지만지금은스톡홀름에서부인소피아와두아이와함께살고있다. 여가시간에그는지역밴드와함께음악을작곡하고베이스 Scrum 기타와키보드를연주하며뮤지션으로활발히활동하고있다. 더많은정보는 http://www.crisp.se/henrik.kniberg 사이트를참고하라. and XP from Scrum and XP thetrenches How we do Scrum164
from the Trenches Scrum and XP from the Trenches 스크럼입문 The Scrum Primer Ver. 1.1 1 피트디머 (Pete Deemer) 가브리엘베네필드 (Gabrielle Benefield) 크레이그라만 (Craig Larman) 바스보드 (Bas Vodde) 독자들을위한메모 : 인터넷에는스크럼에관한간단한자료들이많이있습니다. 이입문서는그러한자료들보다좀더자세한내용을설명하기위한것입니다. 그렇다고이자료가스크럼교육의최종단계를의미하지는않습니다. 스크럼을적용하려는팀은켄슈와버의두책 스크럼 : 팀의생산성을극대화시키는애자일방법론 (Agile Software Development with Scrum) 혹은 스크럼을통한애자일프로젝트관리 (Agile Project Management with Scrum) 를옆에둘것을추천합니다. 그리고훌륭한스크럼교육과강의가많으니그것들을활용해보십시오. 자세한정보는 scrumalliance.org 사이트를참고하세요. 아낌없는관심과아이디어를제공해준켄슈와버, 제프서더랜드박사, 마이 165 크콘에게감사드립니다. c 2008 피트디머, 가브리엘베네필드, 크레이그라만, 바스보드 1 최신버전은이곳에서확인하세요. http://scrumtraininginstitute.com/home/stream_download/ scrumprimer Certified Scrum Training Worldwide www.scrumti.com
크고작은회사들이전통적으로사용한소프트웨어개발방식은소위 폭포수모델 이라고알려진순차적인생명주기모델이다. V 모델과같이여러변종이있지만, 이것은전형적으로계획단계부터상세하게최종제품을설계하고이를세부사항까지문서화하는특징이있다. 설계대로구현하기위해필요한작업들을결정하고, 간트차트나마이크로소프트프로젝트같은도구를이용하여이것들을체계적으로정리한다. 각개별단계에대한상세한추정치들을모두합하여총개발시간에대한추정치를구한다. 프로젝트이해당사자들이이계획을철저히검토하여승인을하고나면비로소팀은일을시작한다. 팀구성원들은마치생산라인에서처럼자기에게할당된일을완성하여다음사람에게넘긴다. 모든작업이끝나면제품이테스트조직 ( 품질보증팀으로불리기도한다 ) 으로이관되어고객인도전에필요한테스트를수행한다. 전체프로세스에걸쳐애초에설계했던그대로제품이개발되도록하기위해계획이어긋나지않도록철저한통제가이루어진다. 이접근방법에는장점과약점이있다. 가장큰장점은매우논리적이라는점이다. 만들기전에생각하고, 모든것을문서화하고, 계획을준수하며, 가능한한모든것을조직화된상태로유지한다는것이다. 하지만큰약점도하나있다. 사람의문제가개입될때나타나는약점이다. 예를들어이접근방법에서는계획서를작성하는릴리스주기초반에계획서에반영할좋은아이디어들이모두나와야한다. 하지만우리모두가알고있 Scrum and XP 듯이좋은아이디어들은프로세스전체에걸쳐 ( 프로세스초반 / 중반에, 가끔은심 지어점심식사전에 ) 나타나며, 변화를허용하지않는프로세스는이러한혁신 을억압한다. 폭포수모델에서릴리스주기후반부에나타나는뛰어난아이 디어는선물이아니라위협이다. 166
from the Trenches 167 또한, 폭포수방식에서는중요한정보를전달하는일차방법으로문서화를매우강조한다. 내머리속에있는것들을최대한문서로작성해낼수있다면, 팀전체의머릿속에더욱잘전달할수있을것이고, 문서로만들었다는것은내가일을완료했다는명백한증거라는가정은매우합리적이다. 하지만현실에서는상세하게작성된 50페이지짜리요구사항문서를제대로읽는사람이별로없다. 또한사람들이읽더라도오해가자주일어난다. 내아이디어를문서로잘옮긴다하더라도온전히담아내지못하고, 그것을여러분이읽으면서또다시추상화하게되는것과같다. 여러분에게형성된이미지는처음에내가말하려고했던생각에서두단계나거친것이다. 심각한오해가일어나는것도놀랄일은아니다. 사람이개입되어있을때의또다른특징은실제적인경험을통해 아하! 하는순간이있다는것이다. 처음으로작동하는제품을사용해보는순간, 여러분은순식간에 이렇게했더라면제품이더나았을텐데 라는아이디어가한 20가지정도는떠오를것이다. 불행하게도이러한매우값진통찰은대개제품을수정하기가가장어려운때인릴리스주기종료시점에나타난다. 바꾸어말해전통적인방식을사용한다면, 제대로할수있게되었을때가비용이가장많이든다는것이다. 인간에게는미래를내다볼수있는능력이없다. 예를들어, 여러분의경쟁사에서예상치못했던발표를한다든지, 예기치못한기술적인문제들이터져서방향을수정할수밖에없는상황이온다든지말이다. 더욱이먼미래의불확실한것들을계획하는경우라면말할것도없다. 오늘, 지금부터 8개월뒤에여러분이한주를어떻게보낼것인지추측하는것은공상에가깝다. 정성들여만든간트차트가그동안실패했던이유가여기있다. 또한, 순차적인생명주기는일을넘겨주는사람과넘겨받는사람들간에적대적인관계를조장하는경향이있다. 그사람이명세서에없는것을만
들어달라고요구해요. 그사람이마음을바꿨어요. 내가관리하지않는것을내가책임질수는없어요. 이런경향은그다지재미있지않은순차적개발의또다른면을보여준다. 바로폭포수모델이제품을만드는사람들에게끔찍한결과를가져다준다는것이다. 최종제품은창의력과기술, 만든사람들의열정에크게못미친다. 사람은로봇이아니다. 사람이로봇처럼행동하기를요구하는프로세스는불행을초래한다. 경직되어있고변화에저항하는프로세스는그저그런제품을만들어낸다. 고객은최초에요구했던것을 ( 최소한두단계해석과정없이 ) 손에쥐겠지만, 그것이고객이정말로원했던것일까? 초기에모든요구사항을수집한다음그것을절대로변경하지못하게함으로써, 사람들이경험하면서새로운것들을발견하더라도고작초기아이디어수준의제품에서벗어날수없게만든다. 순차적인생명주기를따르는많은사람들은이러한문제들을반복해서경험한다. 그러나프로세스가너무나논리적으로보이기때문에문제가생겼을때의반응은대부분 우리가더잘했다면문제가없었을텐데. 와같이자신들을탓한다. 우리가계획을더많이하고, 문서를더잘만들고, 변화를더억제한다면모든것들이잘될거야라는식이다. 불행하게도많은팀들은반대의결과를얻게된다. 더열심히할수록상황 Scrum and XP 은더나빠진다! 폭포수모델에자신의이름을내건 ( 그리고많은자원을투자한 ) 경영진들도많다. 이들에게는근본적으로다른모델로바꾸는것이실수를 명백하게인정하는셈이된다. 그런데스크럼은근본적으로다른모델이다. 애자일계열의개발방법들은기존에잘알려진반복적이고점진적인생명주 기접근방식으로부터진화하였다. 이방법들은실제인간의삶 ( 제품개발에서 의학습, 혁신, 변화라는현실 ) 을반영하는접근방법이더나은결과를만들어낼 168
from the Trenches 것이라는믿음에서출발했다. 애자일원칙에서는초기에명세서를작성하느라많은시간을보내는대신, 작동하는소프트웨어를만들어사람들의손에신속하게전달할것을강조한다. 애자일개발은기능에따라팀을나누고거대하게계층구조를만드는대신, 자립적의사결정권한을가진교차기능팀을중시한다. 또한개발을진행하는내내지속적으로고객의개입을허용하면서빠르게반복하는데주목한다. 많은사람들이애자일개발이나스크럼을배우면서이방법이마치예전에자신들이그냥그렇게했던그때와비슷하다는느낌을가진다. 현재까지가장인기있는애자일방법이스크럼이다. 스크럼은 1986년 < 하버드비즈니스리뷰 > 에소개된제품개발그룹들의성공한실천법에서큰영향을받았다. 이기사에서 스크럼 이라는용어가처음소개되었다. 성공적인제품개발팀이럭비게임에서의자기조직화 ( 자율관리 ) 된스크럼대형과흡사하다는점에착안한것이었다. 이후스크럼은 1993년에켄슈와버와제프서더랜드박사에의해틀을갖추게되었다. 이제스크럼은야후, 마이크로소프트, 구글, 록히드마틴, 모토롤라, SAP, 시스코, GE, 캐피탈원 (CapitalOne), 미국연방준비제도이사회등크고작은회사에서사용되고있다. 스크럼을사용하는많은팀들이생산성과팀의사기측면모두에서두드러진개선이있었다고보고하고있으며, 몇몇사례에서는팀이완전히변화되었다고한다. 유행처럼한달이멀다하고바뀌는관리방식에넌더리가나있을제품개발자들에게있어서이러한변화는의미심장한것이다. 스크럼은단순하지만강력하다. 169 스크럼은프로젝트와제품혹은애플리케이션개발을위한반복적이며점진 적인프레임워크다. 스프린트라고하는작업주기를반복하며개발을진행
한다. 이러한반복주기는보통 1~4주정도이다. 스프린트기간은고정되어있다. 즉, 정해진날이되면일이끝나지않았더라도스프린트를마쳐야한다. 기간을절대로연장하지않는다. 이를가리켜타임박스 (timebox) 되었다고한다. 각각의스프린트를시작할때교차기능팀은우선순위가매겨진목록으로부터할일 ( 고객요구사항 ) 을선택한다. 팀은해당스프린트의종료시점에선택한항목들을완료할것을약속한다. 스프린트가진행되는동안에선택된항목들은바뀌지않는다. 매일팀전체가모여서로의진행상황을간단히설명하고앞으로남은일이얼마인지보여주는간단한차트를계속갱신한다. 스프린트종료시점에팀은이해당사자들과함께스프린트를리뷰하고, 팀이만든결과물을데모한다. 사람들은피드백을얻게되고다음스프린트에반영할수있다. 스크럼은스프린트의종료시점에실제로 완료 되어작동하는제품이나와야함을강조한다. 소프트웨어의경우에이것은코드가통합되었고완전히테스트되었으며잠재적으로출시가가능한상태임을의미한다. 주요역할, 산출물, 이벤트를그림1에요약하였다. Scrum and XP 170
from the Trenches 스크럼의핵심주제는 관찰하고적응하라 다. 개발은필연적으로학습과혁신, 깨우침을동반하기때문에, 스크럼은개발주기를짧게가져감으로써개발된제품과현재일하는방식의효능을관찰하고제품의목표와프로세스실천법들을조정해적응할것을강조한다. 이과정이끝없이이어진다. 스크럼에는중요한역할을하는세가지요소가있다. 제품책임자, 팀그리고스크럼마스터다. 제품책임자에게는제품의기능을식별하여우선순위를매겨서목록을만들고, 스프린트를시작할때어떤항목을목록의맨위에올릴것인지를결정함으로써투자수익률 (ROI) 을극대화할책임이있다. 그리고계속해서우선순위를재조정하거나목록을구체화한다. 상용제품일경우제품책임자는이윤과손실에대한책임도진다. 사내애플리케이션의경우, 제품책임자는 ( 이윤을창출하는 ) 상용제품만큼의 ROI 책임은없지만, 여전히매스프린트최소비용으로최대비즈니스가치를만들어내도록항목들을선택하여 ROI를극대화할책임이있다. 경우에따라제품책임자와고객이같은사람일때도있는데, 내부애플리케이션을개발하는경우에는흔한일이다. 하지만대부분의경우에는다양한요구사항을가진수많은사람들이고객일테고이러한경우에제품책임자의역할은여러개발조직에서볼수있는제품관리자나제품홍보관리자정도와유사하다. 하지만스크럼에서의제품책임자는일반적인의미의제품관리자와는조금다르다. 주요의사결정을프로젝트관리자에게위임하기보다, 직접우선순위를부여하고 2주혹은 4주의이터레이션이끝날때마 171 다결과물을검토하는등적극적이고빈번하게팀과소통해야하기때문이 다. 스크럼에는제품책임자의역할을수행하며제품의최종결정권을갖는 사람이반드시한명있어야한다는점은매우중요하다.
팀은고객이사용하게될제품 ( 예를들어, 애플리케이션이나웹사이트 ) 을개발 한다. 스크럼에서의팀은스프린트마다잠재적으로출시가능한수준의제 품을고객에게전달하기위해필요한모든전문가들이포함되어있는 교차 Scrum and XP 기능팀 이며, 매우높은수준의자율권과책임감을갖는 자기조직화 ( 자율관리 ) 팀 이다. 스크럼에서팀은팀관리자나프로젝트관리자에의해주도되기보다는자기조직화한다. 팀은어떤것을약속할것인지, 어떻게해야약속한것을가장잘달성할수있는지결정한다. 스크럼식으로말하자면팀은 돼지, 조직내다른사람들은 닭 에해당한다. ( 돼지와닭의비유는돼지와닭이 햄과달걀 이라는레스토랑을함께열기로결정했다가돼지생각에 나는정말로내살을베어내야하지만닭은그저달걀로참여만하겠군. 이라며거절했다는이야기에서따온것이다.) 스크럼에서팀은 7±2명으로구성되며, 소프트웨어제품의경우팀에는분석가, 개발자, 인터페이스설계자, 테스터가포함될수있다. 팀은제품을개발하고제품책임자에게어떻게하면제품을최고로만들지에관한아이디어를제공한다. 스크럼에서팀은스프린트동안에여러제품이나프로젝트를누비며멀티태스킹하는것을피하고, 하나의제품이제대로동작하는데 100% 집중해야한다. 안정적인팀이생산성이높기때문에팀원변경을가급적피한다. 하나의프로젝트에인원이많은경우에는여러스크럼팀으로조직화하여각팀이제품의서로다른기능에집중하면서서로밀접하게협력한다. 하나의완벽한고객중심기능이돌아가는데필요한모든일 ( 계획, 분석, 프로그래밍, 테스팅 ) 을수행하기때문에, 스크럼팀을기능팀이라고도부른다. 스크럼마스터는제품그룹이스크럼을배우고적용하여비즈니스가치를획득하도록돕는다. 스크럼마스터는자기가할수있는범위내에서모든것을하여팀이성공하도록돕는다. 스크럼마스터는팀의관리자나프로젝트 관리자가아니다. 대신스크럼마스터는팀에봉사하고외부의방해로부터 172
from the Trenches 173 팀을보호하며, 스크럼을익숙하게사용하도록제품책임자와팀을교육하고안내한다. 스크럼마스터는팀전체 ( 제품책임자와관리자들까지포함 ) 가스크럼의실천법들을제대로이해하고따르는지를확인하고, 조직이애자일개발을도입하여성공에이르기위해필요한여러어려운변화과정을잘통과하도록이끈다. 스크럼은팀과제품책임자가효과적으로일하는데방해가되는요소들이드러나도록하기때문에, 열정적으로그러한이슈해결을돕는전담스크럼마스터를두는것이중요하다. 만일그렇지않다면팀이나제품책임자가성공하기어려울것이다. 작은팀에서는팀원한명이이역할을수행할수도있겠지만 ( 역할을수행할때는작업량을낮추어준다 ), 일반적으로는팀마다한명의전담상근스크럼마스터를두어야한다. 뛰어난스크럼마스터가되는데는배경이나분야 ( 공학, 설계, 테스팅, 제품관리, 프로젝트관리, 품질관리등 ) 가별로중요하지않다. 스크럼마스터와제품책임자가같은사람이어서는안된다. 때때로, 스크럼마스터는팀원들로부터스프린트중간에새로운기능을추가할수있도록제품책임자를설득해달라는요청을받을수있다. 프로젝트관리자와달리스크럼마스터는사람들에게무엇을해야하는지말하거나그들에게업무를할당하지않는다. 단지그과정이잘진행되도록도와주고, 팀이스스로를조직하고관리하는것을지원할뿐이다. 만약스크럼마스터가과거에그팀의관리자였다면, 팀이스크럼을통해성공할수있도록기존의마음가짐이나소통방식을확바꾸어야할것이다. 과거에관리자였던사람이스크럼마스터역할을하게되는경우에는, 자신이맡았던팀이아닌다른팀을지원하는것이낫다. 그렇지않으면조직내역학관계에의한문제가발생할소지가있다. 스크럼에서는프로젝트관리자역할이없다는점에주목하라. 가끔 ( 이전 ) 프로젝트관리자가스크럼마스터역할을하려고할수있지만, 이것은성공
을보장할수없다. 기본적으로두역할은평상시책임측면과역할을성공적으로수행하기위한사고방식측면이근본적으로다르기때문이다. 스크럼마스터역할을완벽하게이해하고, 성공을위해필요한핵심기술들을개발하고자한다면스크럼얼라이언스 (Scrum Alliance) 에서제공하는공인스크럼마스터과정부터시작하면될것이다. 여기서언급한세가지역할외에, 제품을성공으로이끄는데에는관리자를포함하여여러공헌자들이존재한다. 스크럼내에서그들의역할은바뀌었지만여전히그들은소중하다. 예를들면, Scrum and XP 그들은스크럼의규칙과정신을존중함으로써팀을지지한다. 그들은팀이식별한장애요소를제거하는데도움을준다. 그들은자신들의전문지식과경험을팀에제공한다. 스크럼에서는, 과거에 보모 역할 ( 작업을할당하고, 상황보고를받는등세세한것까지관리하는여러가지형태의일 ) 을하던사람들에게팀의 현자 섬김이 ( 팀원들을멘토링하고코칭하며, 팀원들의장애제거와문제해결을도우며, 팀원들에게창의적인생각을불어넣고, 개발기술을안내하는 ) 역할을하라고주문한다. 이러한변화속에서관리자는자신들의관리스타일을바꾸어야할것이다. 예를들어간단하게해결책을결정하고팀에게그것을할당하는대신, 소크라테스식문답법을사용하여팀이문제의해결책을찾도록도와줄수있다. 스크럼의첫걸음은제품책임자가제품의비전을명확히표현하는것에서부 터출발한다. 제품에대한비전이나중에제품백로그라고부르는, 구체화되 고우선순위가부여된기능목록으로발전한다. 제품백로그는제품의수명 174
from the Trenches 이다할때까지존재 ( 하며진화 ) 한다. 제품백로그는제품의로드맵이다 ( 그림 2 참조 ). 어느시점에서나제품백로그가의미하는것은 앞으로팀이완료할수있는모든것을우선순위에따라정리한것 에대한단하나의선언이다. 제품백로그는오로지하나만존재한다. 이것은제품책임자가제품모든영 역의결정들에대해우선순위를부여해야한다는것을의미한다. 제품백로그에는다양한항목들이존재한다. 기본적으로새로운고객요청 기능 ( 모든사용자가장바구니에책을넣을수있다 ) 은물론이고기술적인개선목 175 표 ( 규모확장성을위해트랜잭션처리모듈을재작업한다 ), 탐구혹은연구작업 ( 신 용카드검증기능의속도향상해결책발굴하기 ) 그리고문제가별로없는경우에는 알려진결함 ( 주문처리스크립트오류조사및해결하기 ) 까지도포함할수있다.
( 결함이많은시스템은대개별도의버그추적시스템을사용한다.) 많은사람들이요구사항을 사용자스토리 로간결하게표현하고, 제품의최종사용자에게줄수있는가치라는관점으로기능을명확하게기술하는것을선호한다. 제품백로그의항목들중에서현재진행중인릴리스에포함시킬부분을릴리스백로그라고하며, 일반적으로제품책임자의주된관심대상은이부분이다. 제품책임자는고객의요구, 새로운아이디어나통찰, 경쟁업체의움직임, 기술적장애요소등의변화들을반영하여제품백로그를지속적으로갱신한다. 팀은제품백로그상의각항목들에대해필요한작업량을추정하여제품책임자에게전한다. 또한제품책임자는각개별항목들에대한비즈니스가치를추정할책임이있다. 하지만비즈니스가치를추정하는것은일반적으로제품책임자에게생소한일이다. 따라서스크럼마스터는제품책임자가비즈니스가치를스스로추정할수있을때까지도와줄필요가있다. 이두가지추정치 ( 작업량과가치 ) 와필요하다면리스크추정치까지고려하여, 제품 Scrum and XP 책임자는 ROI를극대화하고주요리스크를줄일수있도록백로그 ( 사실은일반적으로릴리스백로그분량에대해서만 ) 에우선순위를정한다. 앞으로살펴보겠지만, 이러한작업량및가치에대한추정치는사람들이학습함에따라스프린트마다새롭게바뀔수있다. 결과적으로제품백로그가계속해서진화해나가도록하는것이바로지속적인우선순위조정이다. 스크럼이제품백로그상의추정치를어떤식으로하라고규정하지는않지만 주당투입인원 과같은절대적인단위보다는 점수 로표현되는상대적인추정치를사용하는것이일반적이다. 시간이흐름에따라팀은매스프린트마다상대적으로얼마나많은점수를구현하는지추적한다. 예를들어스프린트당평균 26점이라는식이다. 이런 정보를바탕으로팀원들은모든기능을완료하는날이언제가될지, 혹은특 176
from the Trenches 정날짜까지몇개의기능을완료할수있을지예측할수있다. 제품백로그에있는항목들은규모면에서나투입되는노력면에서나다양하다. 제품백로그구체화워크숍이나스프린트계획회의를통해큰것들은작은항목으로쪼개고, 작은것들은합쳐하나로만들수있다. 스크럼에대한오해중하나는스크럼을할때상세한명세서를작성하면안되는것으로알고있는것이다. 사실이것은제품책임자와팀이얼마나상세한수준을원하는지 ( 백로그항목들간에도원하는수준이다를수있다 ), 팀의통찰력이어느정도수준인지등에달려있다. 필요한최소한의공간에중요한것을기술하라. 다시말해, 한항목에대해가능한모든세부내용들을기술하려하지말고, 나중에알아볼수있을정도로만분명하게작성하라. 낮은우선순위항목은구현하게될가능성이낮고아직큰덩어리형태로만기술되어있는만큼세부적인요구사항이많지않다. 하지만곧구현하게되는우선순위가높고잘게나누어진항목에대해서는세부사항이더많을것이다. 스프린트를시작할때스프린트계획회의를한다. 스프린트계획회의는두가지회의로구성되는데, 먼저하는회의를스프린트계획회의 1부라고부른다. 스프린트계획회의 1부에서는 ( 스크럼마스터의주도로 ) 제품책임자와팀이 ( 제품책임자가이번스프린트를실행하는데관심있어하는 ) 제품백로그에있는우선순위가높은항목들을검토한다. 제품책임자와팀은우선순위가높은항목들의목표와배경에대해논의하면서, 제품책임자머릿속에있는생각을 177 팀에게전달한다. 또한제품책임자와팀은모든항목들이반드시달성해야 할 완료의정의 도검토한다. 예를들면, 어떤항목이완료되었다는것은표 준에맞도록코드가작성되었고, 코드검토를마쳤고, 단위테스트주도개발
을사용하여구현되었고, 자동화테스트를 100% 통과하였고, 통합을마쳤고, 문서화가되었음을의미한다. 회의 1부에서는제품책임자가무엇을원하는지이해하는데초점이맞춘다. 스크럼규칙에따르자면 2부가진행되는동안연락이 ( 전화상으로라도 ) 닿을수만있다면 1부를마치고제품책임자가자리를떠나도좋다. 하지만 2부에참석하는것도나쁘지않다. 스프린트계획회의 2부는팀이하기로결정한항목들을어떻게구현할것인지상세한작업계획을수립하는데초점이맞춰져있다. 팀은제품백로그에서이번스프린트가끝날때까지완료하기로약속할항목들을선택하는데, Scrum and XP 제품백로그의맨위에서부터시작하여순차적으로진행한다.( 다시말해, 제품책임자가가장높은우선순위를부여한항목들부터시작한다.) 이것이스크럼의핵심실천법으로, 제품책임자가팀에일을할당하지않고팀이얼마나많은일을완료할것인지를스스로결정한다. 이렇게함으로써다른누군가가 정해준 것이아니라팀스스로분석하고계획하여내린결정이기때문에더욱믿을만한약속이된다. 제품책임자는직접적으로팀의작업량을강요할수없지만, 팀이제품백로그의첫번째항목 ( 즉, 제품책임자가가장중요하다고평가한항목 ) 부터고를것이라는것은안다. 팀은목록의아래쪽에서항목들을선택할수도있는데, 대개팀과제품책임자가해당항목이우선순위는낮지만우선순위가높은항목과함께구현하는것이쉽고더잘맞는다고본경우이다. 스프린트계획회의는흔히몇시간정도지속될것이다. 팀은일을완료하겠다는진지한약속을해야하고, 이러한약속을잘하기위해서는심사숙고해야한다. 팀이스프린트계획회의 2부를시작하면우선각팀원들이 스프린트에관련된일 을하는데얼마나시간을투입할수있는지추정한다. 즉, 팀원들의평균작업일에서회의참석, 메일작성 / 확인, 점심식사등으로소요되는시간을제외한다. 대부분사람들은스프린트에관련된일을하는데많 아야하루에 4~6 시간정도를쓰게된다. 178
from the Trenches 가용시간이정해지고나면다같이참여하여제품백로그의첫번째항목 ( 제품책임자의최우선순위항목 ) 부터각항목을개인작업단위로나눠스프린트백로그라불리는문서에기록한다 ( 그림 4 참조 ). 앞서언급한바와같이제품책임자는 2부가진행되는동안분명하지않은항목에대해 ( 심지어전화상으로라도 ) 명확한답을줄수있어야한다. 가용시간을모두채울때까지팀은제품백로그항목들을위에서부터순차적으로진행한다. 회의 2부가끝날때까지팀은모든작업에추정치 ( 대체로시간이나날짜단위로 ) 가부여된목록을완성하게될것이다. 스크럼은여러가지기술을익힌팔방미인을장려한다. 테스팅업무만하는 테스터 처럼 직함에맞춰일하는것 을지양한다. 다시말해팀원들이 일이있는곳으로가서 가능한만큼문제를해결하도록도울수있어야한다. 테스트할것이많으면모든팀원들이테스트를도와줄수도있어야한다. 그렇다고모두가제너럴리스트가되라는의미는아니다. 당연히일부는테스팅분야에특히뛰어나다거나일부는다른분야에더뛰어날수있다. 다만 179 팀원전체가함께일하며서로에게서새로운기술을배운다는의미가중요하 다. 결과적으로, 스프린트계획회의에서작업을생성하고추정하는동안 정 말잘할수있는작업 이라고사람들이모든작업에자원하는것은적절하
지도않고또그럴필요도없다. 대신에하나정도는새로운작업에자원하도 록하고그작업은의도적인학습이필요한것으로선택하는것이낫다.( 해당 작업을전문가와짝이되어진행하는식으로학습할수있다.) Scrum and XP 다른사람들이배워서하기에는시간이너무오래걸리거나학습자체가불가능해서존이라는친구가꼭그작업을해야만하는경우는거의없다. 혹시존이그림을그리는데예술적감각이있는유일한사람이고, 다른팀원들은죽었다깨어나도 졸라맨 조차그릴수없다고하자. 드물지만어쩔수없이존이그릴수밖에없는상황이발생했다면이그림작업이짧은스프린트안에완료할수있는지확인해봐야할것이다. 이런상황이드물지않다거나팀이학습을하더라도이상황이나아지지않는다면뭔가문제가있는것이다. 많은팀들은시각적인작업추적도구를사용한다. 예를들어벽을채울정 도크기의작업현황판을두고거기에작업항목을포스트잇같은것에적어 서붙여놓고스프린트가진행되는동안 할일 진행중 완료 칸으로옮 겨붙이는식이다. 그림 5 를참조하라. 180
from the Trenches 스크럼의한축은, 일단팀이약속을하고나면모든추가나변경사항은다음스프린트까지미뤄져야한다는것이다. 이것은만약스프린트도중에제품책임자가팀이작업하기원하는새로운항목이생기더라도, 다음스프린트가시작되기전까지는변경할수없다는것을의미한다. 만약외부상황이변하여우선순위를대폭변경해야하거나팀이계속일하는것이시간을낭비하는것이라면, 제품책임자나팀은스프린트를종료할수있다. 팀은진행하던스프린트를멈추고, 새로운스프린트를시작하는스프린트계획회의를실시한다. 스프린트를중도에멈추는것은보통큰혼란을가져온다. 따라서제품관리자나팀은중도하차라는극단적인결정을가급적피하게된다. 스프린트동안에목표를변경하지못하도록팀을보호해주면매우강력하고긍정적인효과를볼수있다. 첫번째, 팀이수행하기로한약속이변경되지않을것이라고확신을가질수있기때문에팀은완료하는데에만집중할 181 수있게된다. 두번째, 제품책임자가제품백로그에있는항목들에대해정 말로심사숙고하여우선순위를매기도록훈련시키는효과가있다. 이러한 스크럼규칙을준수함으로써제품책임자는두가지를얻게된다.
첫번째, 제품책임자는선택한작업목록을완료하겠다는팀의약속이현실적이고분명하다는확신을할수있다. 시간이흐름에따라팀은약속할항목을선택하고, 약속한기간에그것들을납품하는기술이크게향상된다. 두번째, 제품책임자는다음스프린트가시작되기전에제품백로그를원하는대로수정할수있는데, 항목의추가, 수정, 삭제, 우선순위변경이모두가능하다. 제품책임자가현재스프린트동안이미선택되어개발중인항목들을변경할수는없지만, 변경하고싶은것을참아야하는기간은길어야한스프린트만큼이다. 방향변경, 요구사항변경이나혹은여러분의마음을완전히돌아서게하는변경과관련된상처는이제사라졌으며, 이것은누구보다도제품책임자가스크럼에열정적이게하는이유가된다. Scrum and XP 스프린트가시작되면, 팀은또다른스크럼의핵심실천법인 일일스크럼 을하게된다. 일일스크럼은 (15분이내의 ) 짧은회의이며매일지정된시간에실시된다. 팀원전체가참석한다. 짧게끝내기위해모든사람들이서서진행할것을권한다. 팀은이시간에서로진행상황과장애요인들에대해공유할기회를갖는다. 일일스크럼회의에서는팀원들이한사람씩돌아가며다른팀원들에게다음의세가지 ( 딱세가지만 ) 를보고한다. (1) 지난일일스크럼이후무엇을완료하였는가? (2) 다음회의때까지무엇을마무리할계획인가? (3) 일하는데어떠한방해나장애요인들이있는가? 일일스크럼은관리자에게상황을보고하는회의가아니라는점에주의하 라. 이회의는자기조직적인팀이상황어떻게진행되고있는지서로알게 182
from the Trenches 하고서로에게도움을주는시간이다. 일부사람들이방해요인들에대해이야기하면스크럼마스터는팀원들이문제를해결하도록도와줄책임이있다. 일일스크럼회의동안에는토론을피하고오직세가지질문에답하는것에만집중해야한다. 만약토론이필요하다면일일스크럼이끝나고나서추가로회의를열어진행하도록한다. 추가회의에전원이꼭참석할필요는없다. 추가회의는팀이일일스크럼회의때들었던정보에적응하고자열게되는경우가많다. 말하자면또하나의 관찰하고적응하는 주기라고할수있다. 일반적으로일일스크럼회의에관리자나기타권위적인위치에있는사람들이참석하지않도록할것을권고한다. 관리자가참석하게되면팀이 감시를받는다 고느끼게된다. 매일일이척척진척되고있다고보고해야하는압력을느끼고, 문제가있어도알리는것을꺼리게된다. 결국팀의자기관리능력은저하되고, 관리자가세세한것들까지관리하려고할위험이있다. 대신에이해당사자가회의이후에팀을찾아가팀의진행을더디게하는방해요인들을해결하도록하는편이훨씬낫다. 매일팀원들은스프린트백로그에자신들의현재작업을완성하기위한남은시간의추정치를갱신한다 ( 그림 6참조 ). 모두갱신하고나면누군가팀전체의남은시간을합하여스프린트소멸차트를갱신한다 ( 그림 7참조 ). 이그래프는날마다팀이작업을마무리하기까지얼마만큼의일이남았는지에대한최신추정치 ( 인당시간단위 ) 를보여준다. 이상적으로이그래프는스프린트마지막날에 남은노력 0(zero effort remaining) 으로향하는하향곡 183 선을그린다. 이그래프를소멸차트라고부른다. 가끔은그래프가보기좋게 그려지기도하지만대개는그렇지가않다. 이것이제품개발의현실이다. 중 요한것은소멸차트가목표를향한팀의진척도를보여주는방식이다. 소멸
차트는현재까지시간을얼마나썼는지 ( 경과측면으로는의미없는사실 ) 가아니라앞으로얼마나남았는지의관점에서진척도를보여준다. 만약그래프가스프린트의종료일부근에완료할것같지않다면팀은일의범위를줄이거나여전히지속가능한속도를유지하면서도일을더욱효율적으로할수있는방향을모색한다든지하는조정이필요하다. 스프린트소멸차트를스프레드시트로만들어서보여줄수도있겠지만많은팀들은자신들의작업공간벽면에종이로붙여놓고펜을사용하여갱신하는것이더효과적이라고한다. 이러한 로우테크 / 하이터치 솔루션은컴퓨터를사용한차트보다신속하고, 간단하며보다더시각적이다. Scrum and XP 184
from the Trenches 스크럼에서잘알려져있지는않지만중요한지침이하나있다. 바로매스프린트의 5~10% 를반드시제품백로그를구체화하는작업에할애해야한다는것이다. 제품백로그를구체화한다는것은상세요구사항분석, 큰항목을작은항목으로나누고새로추정하는것, 혹은기존항목들에대해다시추정하는작업들이포함된다. 스크럼에서이작업을어떻게하라고언급하지는않지만, 우리는스프린트종료시점에팀과제품책임자가방해받지않고이작업에만전념할수있는집중워크숍을실시하라고권하고싶다. 2주길이의스프린트라면스프린트가끝날때쯤 5% 에해당하는반나절동안제품백로그구체화워크숍을실시한다. 이구체화활동은현재진행중인스프린트에서작업하고있는항목들에대한것이아니라앞으로구현하게될 185 ( 대개다음한두스프린트에예정돼있는 ) 항목들을대상으로실시한다. 이렇게워크숍을실시하면스프린트계획회의가상대적으로간단해진다. 제품백로그의항목들이명확하고추정도잘되어있기때문이다. 스프린트
계획회의때심각한질문이나발견, 혼동이있다는것은이구체화워크숍이 실시되지않았다는 ( 혹은제대로실시되지않았다는 ) 신호다. Scrum and XP 스크럼의핵심원칙중하나는 스프린트기간이절대로늘어나지않는다는것 이다. 스프린트는팀이약속했던작업을완료했는지와상관없이지정된날짜에종료한다. 일반적으로처음몇번의스프린트에서과다하게약속하는바람에목적을달성하지못하기도한다. 그런다음에는오히려너무목표수준을낮춰잡아서스프린트가일찍끝나기도한다. 하지만통상서너번째스프린트가되면팀은자신들이역량수준을알게되며그후로는스프린트목표를더욱잘달성하게된다. 팀은하나의스프린트길이를 ( 가령 2주로 ) 선택하고그것을변경해서는안된다. 스프린트길이를일관되게적용함으로써팀은해당기간에자신들이얼마나완수할수있는지를학습하게되며, 추정과좀더긴기간의릴리스계획을세우는데에도도움을준다. 또한팀의업무에리듬이붙게되는데이것을스크럼에서는종종팀의 심장박동 이라고부른다. 스프린트가끝나고나서팀은제품책임자와함께직전스프린트에대해검토하는스프린트검토회의를실시한다. 이회의를종종 데모 이라고잘못명명하곤하는데, 데모이라는단어로는이회의의진짜의도를제대로표현하지못한다. 스크럼의핵심아이디어는관찰하고적응하기이다. 일이어떻게돌아가는지보고배운다음에피드백을기반으로발전해나가는과정을반복하는것이다. 스프린트검토회의는제품에대해관찰하고적응하는활 동이다. 이시간을통해제품책임자는제품이나팀이지금어떻게진행되고 186
from the Trenches 있는지알게되고 ( 말그대로스프린트를검토하고 ), 팀은제품책임자와시장에어떤일이진행되고있는지알게된다. 결과적으로스프린트검토회의에서가장중요한것은팀과제품책임자가현재상황을파악하고, 조언을구하는등서로깊은대화를나누는것이다. 검토회의에는스프린트에서개발한것을데모하는것도포함되긴하지만대화를나누는것보다데모에초점이맞춰진다면균형이깨진것으로봐야한다. 유용하면서도간과하기쉬운지침이있다. 스크럼마스터가스프린트계획회의때정했던 완료의정의 를알고있다가스프린트검토회의중에팀이완료정의를만족시키지못한항목이있으면그것을제품책임자에게알려야할책임이있다는것이다. 이렇게함으로써결과물의품질에대한가시성이높아진다. 말하자면데모중에단지제품이잘동작한다는것을보여주더라도엉망으로작성된코드와테스트되지않은코드로작성된사실을속일수없다는것이다. 스프린트검토회의에는제품책임자, 팀원, 스크럼마스터가참석하며, 추가로고객, 이해당사자, 전문가, 임원, 그밖에관심이있는사람이라면참석할수있다. 스프린트검토회의중에행해지는데모부분이 프레젠테이션 처럼되어서는안된다. 슬라이드같은것을띄우지않는다. 스크럼에서의지침에따르자면데모를준비하는데 30분을초과해서는안된다. 만약이를초과한다면팀이뭔가잘못하고있는것이다. 말그대로팀은자신들이개발한것을데모하고참석자들은자유롭게질문하거나의견을말하면된다. 187 스프린트검토회의가제품을놓고서 관찰하고적응하는 시간이었다면그 다음에이어지는스프린트회고는프로세스관점에서 관찰하고적응하는 시간이다. 회고를생략하는팀들이있는데참으로안타까운일이다. 회고는
개선할영역을드러내도록하여실제로개선이이뤄지도록하는스크럼의주된메커니즘이기때문이다. 회고는팀이어떤것이잘되고어떤것이제대로되지않는지토의하고앞으로어떤변화를시도할지합의하는기회가된다. 팀과스크럼마스터가참석하며, 제품책임자도참석하면좋겠지만꼭참석해야하는것은아니다. 스크럼마스터가회고의진행자역할을맡을수도있지만, 중립적인입장의제삼자가진행을맡는편이더낫다. 가령스크럼마스터들끼리상대방의회고를진행하는것도좋은방법이다. 이렇게하면팀간시너지효과를창출할수있다. 스프린트회고를구성하는간단한방법을소개한다. 화이트보드를크게두칸으로나누고각각에 잘되고있는것 과 더잘할수있었던것 이라는이름을붙인다. 그리고각자돌아가며두군데모두넣고싶은항목들을추가하도록한다. 반복되는항목이있으면항목옆에체크표시를해서눈에띄게만든다. 그런다음근본원인을찾고다음스프린트에서시도할몇가지변화들에대해합의한다. 시도해보기로합의한내용들은다음스프린트회고때결과를검토한다. 회고가끝날때해볼만한실천법을하나소개한다. 화이트보드에붙여놓은항목들에 C, E, U 중하나를표시하는것이다. 여기서 C는스크럼때문에생긴것 (caused by Scrum), 즉스크럼을적용하지않았다면발생하지않았을것을의미하고, E는스크럼에의해드러난것 (exposed by Scrum), 즉스크럼을적용했든적용하지않았던간에발생할것이었는데, 스크럼을통해팀이알게된것을의미하고, U는스크럼과는관련이없는것 (unrelatedto Scrum), 가령날씨같은것을의미한다. 만약 잘되고있는것 칸에 C가많고 더잘할수있었던것 칸에 E가많다면, 설령 더잘할수있었던것 칸에항목들이많다고하더라도팀에게는좋은소식이다. 숨어있는문제를해결하기위한첫걸음은우선문제가드러나도록하는것이기때문이다. 스크럼은그것을가 Scrum and XP 188
from the Trenches 능케하는강력한촉매제다. 스프린트회고까지마쳤다. 스프린트를시작할때와비교하면완료된항목 도있고, 새로추가된항목도있고, 추정치를고친항목도있고, 릴리스목표에서제외된항목도있을것이다. 제품책임자는이러한변경사항들을릴리스백로그에 ( 그리고제품백로그에까지 ) 반영해야한다. 스크럼에는릴리스날짜까지진척상황을보여주는릴리스소멸차트도있다. 스프린트소멸차트와유사하지만세분화된작은작업단위가아닌상위수준의항목 ( 요구사항 ) 을다룬다는점이다르다. 처음제품책임자를맡은사람은소멸차트를왜만드는지, 어떻게만드는지모를수있으니스크럼마스
Scrum and XP 터가제품책임자를도와주어야한다. 릴리스백로그와릴리스소멸차트는 그림 8 과그림 9 의예를참고하라. 스프린트검토회의가끝나고나서제품책임자는새로운통찰이생기면제품백로그를갱신해도된다. 이제제품책임자와팀은또다른스프린트를시작할준비가됐다. 스프린트와스프린트사이에는공백기간이없다. 오후에스프린트회고를하고다음날아침 ( 주말을끼는경우도있다 ) 에스프린트계획회의를하는것이일반적이다. 애자일개발원칙중에하나는 지속가능한속도 를유지하는것이다. 적정수준의근무시간을일정하게유지해야지만이같은반복주기를꾸준히이어갈수있다. 스크럼이지향하는완전한모습은스프린트가끝날때마다잠재적으로출시 190
from the Trenches 가능한제품이나오는것이다. 출시가능하다는것은테스팅이나문서화와같은추가적인마무리작업이남아있지않다는것을의미한다. 스프린트마다모든일이완벽하게끝났다는것, 그래서스프린트검토회의가끝나자마자실제로제품을출시하거나배포할수있다는것을의미한다. 하지만많은조직들은개발실천법이취약하여이러한완전한모습을달성하지못하거나 기기가고장나서 와같은상황적인핑계거리를찾는다. 출시가능한제품이나오지않은경우를보면최종제품환경에서의통합테스트같은작업이아직남아있어서이다. 그래서남은작업들을처리하기위한 릴리스스프린트 가필요하다. 릴리스스프린트가필요하다는것은뭔가취약한점이있다는신호이다. 이상적으로는릴리스스프린트가필요하지않다. 굳이필요하다면제품책임자가판단하여제품이거의릴리스할준비가될때까지스프린트를계속하고, 그런다음출시준비를위한릴리스스프린트를실시한다. 팀이스프린트마다꾸준히리팩터링하고, 지속적통합을실시하고, 효과적인테스팅을하는등의개발실천법을훌륭히따른다면출시전안정화단계나기타마무리작업이거의필요없을것이다. 반복개발모델에서어떻게장기간의릴리스계획을세울수있느냐는질문을가끔받는다. 두가지경우가있다. (1) 신제품의첫번째릴리스인경우와 (2) 기존제품의이후진행할릴리스인경우다. 신제품을개발하거나개발하는중간에처음스크럼을도입하는경우에는 191 첫번째스프린트를시작하기에앞서초기제품백로그구체화작업을해야 한다. 이작업을통해제품책임자와팀이적정수준의제품백로그를만들어 낸다. 처음하는제품백로그구체화작업은며칠혹은몇주가걸리기도한
다. 이작업에는비전워크숍을실시하고일부요구사항에대해서는상세히분석하며첫번째릴리스에포함하기위한항목들에대해서추정하는작업이포함된다. 스크럼에서는잘만들어진제품백로그와제품이있는경우라면다음릴리스를위해릴리스계획을대단하게혹은길게할필요가없다. 제품책임자와 Scrum and XP 팀이제품백로그구체화작업을모든스프린트마다 ( 각스프린트의 5~10% 정도를투입하여 ) 실시하여지속적으로미래를준비하기때문이다. 이러한지속적인제품개발방식에서는엄청나게강조되는 준비-실행-마무리 라는절차가아예필요없어진다. 초기제품백로그구체화워크숍을하고스프린트마다지속적으로백로그를구체화함으로써팀과제품책임자는학습하는내용을근거로추정치, 우선순위, 내용을다듬고릴리스계획을세운다. 특정날짜로릴리스가지정되는경우가있다. 예를들어 이번버전 2.0은전시회가열리는 11월 10일에릴리스합니다. 와같은상황이다. 이런상황에서는시간이허락되는한가능하면많은스프린트를진행하면된다. 그러면가능한많은기능이구현될것이다. 어떤제품들은특정기능이구현되어야만완료되는경우도있다. 이런때에는해당기능을구현하는데시간이얼마걸리든지간에그기능을구현하지못하면제품을출시할수없을것이다. 스크럼에서는스프린트가끝날때마다잠재적으로출시가능한제품을만들어낼것을강조하기때문에, 이경우제품책임자는고객이일찍완료된결과물의혜택을볼수있도록중간릴리스를결정할수도있다. 사전에모든것을알수없으므로, 계획을세운다음조정해나가면서릴리스의전반적인방향을제시하고트레이드오프의사결정이어떤식으로내려질지 ( 예를들어범위와일정문제 ) 명확히하는것이중요하다. 계획은여러분을최종목적지로인도해줄로드맵이라고생각하자. 여행중에정확히어떤길 로갈지와같은결정들을정말로길을가면서결정하는것이다. 192
from the Trenches 대부분의제품책임자들은릴리스방식중에서하나를선택한다. 이를테면, 우선릴리스날짜를정하고그날짜에맞춰완료할수항목들로릴리스백로그를구성하는식이다. 정해진가격으로정해진날짜에정해진산출물 을만들어내야하는상황 ( 예를들어계약에따른개발의경우 ) 에서는적어도하나이상의인자에대해서불확실성과변경이일어나도약속을지킬수있도록버퍼를추가해서결정해야한다. 이점에있어서는, 스크럼이다른방법들과다르지않다. 조직내에서사용할애플리케이션을개발하는경우나시장에출시할제품을개발하는경우에상관없이조직은스크럼을도입함으로써기존의 프로젝트중심 개발모델에서 지속적인애플리케이션 / 제품개발 모델로옮겨가게된다. 더이상프로젝트시작, 진행중, 종료가없게된다. 그러므로기존의프로젝트관리자도존재하지않는다. 대신에제품책임자와자율관리팀이있어서제품이나애플리케이션이폐기될때까지 끝없이 이어지는 2주혹은 4주짜리스프린트를진행하면서지속적으로협업하게된다. 필요한모든프로젝트관리업무는팀과비즈니스책임자 ( 내부비즈니스고객이거나제품관리부서담당자 ) 가다루게된다. IT 관리자나프로젝트관리부서의누군가가하는것이아니다. 스크럼은일회성으로끝나는프로젝트성격의개발에도적용할수있다 ( 오랜기간사용할애플리케이션을새로만들거나발전시키는작업이아닌경우를말한다 ). 하지만이경우에도여전히팀과제품책임자가프로젝트를관리한다. 193 만약기존애플리케이션이여러개있고애플리케이션마다전담팀을두기 에는새업무량이충분하지않다면어떻게해야할까? 이경우에도안정적으 로오래지속되는팀을하나정해스프린트마다애플리케이션을바꿔가며개
발하도록할수있다. 이번스프린트에는 A 애플리케이션의백로그를개발하고다음스프린트에서는 B 애플리케이션의백로그를개발하는식이다. 이런상황이라면스프린트는흔히 1주일정도로짧다. 가끔은앞에서설명한방식으로진행하기에도백로그가충분하지않아서한스프린트동안에여러애플리케이션의백로그를처리해야하는경우도있다. 하지만한스프린트에서여러애플리케이션을다룰때는비생산적인멀티태스킹을야기할수있다는점에주의해야한다. 생산성에관한스크럼의기본가정은팀이한스프린트에서하나의제품이나애플리케이션에만집중해야한다는것이다. Scrum and XP 스크럼은단지구체적인실천법을모아둔것이라기보다는팀에게가시성을제공하는프레임워크이며가시성을바탕으로팀이 관찰하고적응하게 하는메커니즘이다. 스크럼은제품책임자와팀이효과적으로일하는데부정적인영향을미치는역기능이나장애요인들을드러냄으로써제품책임자와팀이그문제를해결할수있도록한다. 예를들어제품책임자가시장이나제품의기능을잘모르거나기능들의상대적인비즈니스가치를추정하지못할수있다. 혹은팀이작업량을추정하거나개발하는것에미숙할수있다. 스크럼프레임워크는이러한약점들을신속하게노출시킬것이다. 스크럼이개발중에발생하는문제를직접해결해주지는못한다. 하지만고통스러울정도로문제들을드러내어사람들로하여금짧은반복주기를통해문제해결방법을모색하고조금씩개선하는경험을갖도록하는프레임워크이다. 팀이작업분석이나추정기술이부족하여첫번째스프린트에자신들이 약속한것을전달하는데실패했다고치자. 팀은실패했다고느낄것이다. 하 194
from the Trenches 195 지만실제로이경험은앞으로그들이약속을할때더현실적으로심사숙고하도록하는데필요한첫걸음이다. 스크럼이역기능을드러내고팀이그것에대응하기위해무언가를하도록하는이같은패턴이바로스크럼을통해팀이두드러지게효과를볼수있는가장기본적인방식이다. 팀이흔히저지르는실수가있다. 스크럼실천법을따르자니무리가생기는경우에자신들을바꾸는대신도리어스크럼을바꾸려는것이다. 예를들어스프린트목표를달성하기어려워진팀이필요하다면스프린트기간을늘릴수있다고판단하는경우다. 이렇게하면앞으로도시간이절대부족하지않게된다. 결국자신들의시간을더잘추정하고관리하도록배울수있는기회는없어지는셈이다. 조직에경험있는스크럼마스터의코치나지원없이이런식으로가다보면그조직은자신들의약점이나역기능을그대로스크럼이란이름아래옮겨놓을뿐, 스크럼이제공하는진정한혜택을손상시키게된다. 진정한혜택이란, 좋은것과나쁜것을드러내고조직이스스로수준을향상시킬수있는기회를제공한다는것이다. 흔히저지르는또다른실수는, 단지스크럼에서명시적으로요구하지않았다는이유로어떤실천법을축소하거나금지해야한다고오해하는것이다. 예를들어, 스크럼은제품책임자가제품에대한장기전략을세워야한다고명시적으로언급하지않으며, 엔지니어들이고참엔지니어에게복잡한기술적인문제들에대한조언을구해야한다고언급하지도않는다. 스크럼은이러한이슈들에대해관련이있는개인들이올바른결정을하도록맡겨둔다. 대부분의경우 ( 다른많은것들도그렇지만 ) 위두가지는사려깊은실천법이라고할수있다. 또조심해야할것은관리자가자기팀에스크럼을강요하는경우다. 스크럼은팀에게스스로를관리할수있는공간과도구를제공하는것인데, 윗사람으로부터명령을받는다고반드시성공하는게아니다. 더나은접근방법
은팀이동료나관리자에게서스크럼을배우고, 전문적인교육과정을통해전반적으로이해한다음, 팀스스로정해진기간동안스크럼의실천법들을충실히따르기로결정하는것이다. 스크럼을적용해보고나서팀은자신들의경험을평가하고지속할지여부를판단하게될것이다. 좋은소식은대개첫번째스프린트가팀에게큰도전이되기는하지만첫스프린트가끝날때쯤이면벌써스크럼의혜택이드러난다는점이다. 그래서스크럼을새로도입한많은팀들이다음과같이이야기한다. 스크럼은힘들다. 하지만분명한것은우리가이전보다훨씬나아졌다는점이다! Scrum and XP 스크럼의효과는스크럼을직접적용하면서경험한팀들에의해다양한측면에서보고되고있다. 우리는야후에서 3년에걸쳐거의 200개에달하는팀, 총 2,000명이상의사람들을스크럼으로전환하도록도왔다. 여기에는야후포토 (Yahoo! Photo) 와같이고객과직접상대하는디자인중심의웹사이트팀에서부터야후메일 (Yahoo! Mail) 과같이수억명을고객으로하는핵심서비스의인프라팀에이르기까지다양한팀이있었다. 매년여러번에걸쳐스크럼을사용하는모든야후임직원 ( 제품책임자, 팀원, 스크럼마스터, 기능관리자등 ) 을대상으로조사를실시하면서, 그들에게기존에사용하던접근방법과스크럼의비교를부탁했다. 조사결과중일부를공개한다. 생산성 : 스크럼이좋았거나매우좋았다 (5 점척도에서 4, 5 점 ) 는 68%, 별로 이거나매우나빴다 (5 점척도에서 1, 2 점 ) 는 5%, 보통이다 (5 점척도에서 3 점 ) 는 27% 가응답하였다. 196
from the Trenches 팀사기 : 스크럼이좋았거나매우좋았다는 52%, 별로이거나매우나빴다는 9%, 보통이다는 39% 가응답하였다. 적응성 : 스크럼이좋았거나매우좋았다는 63%, 별로이거나매우나빴다는 4%, 보통이다는 33% 가응답하였다. 책임감 : 스크럼이좋았거나매우좋았다는 62%, 별로이거나매우나빴다는 6%, 보통이다는 32% 가응답하였다. 협업 : 스크럼이좋았거나매우좋았다는 81%, 별로이거나매우나빴다는 1%, 보통이다는 18% 가응답하였다. 제품책임자의추정치를기준으로팀생산성은평균 36% 향상되었다. 결 정권이자신들에게주어진다면팀원의 85% 는스크럼을지속할것이라고응 답하였다. (15% 는 아니오. 혹은 잘모르겠다. 라고응답하였다.) 197