[번역] 소프트웨어 개발 게임(Software Development Game)

2012. 11. 4. 18:32QA

<서울등축제에 등장한 도깨비 등. 포스퀘어 같은 애플리케이션의 뱃지로 적당하지 않을까? >

 

Stickyminds.com 에 실린 “The Software Development Game” 이라는 글을 번역해서 올려봅니다.

 

 최근 화두가 되었던 게이미피케이션과 관련해 구글링을 하던 중, 사실은 이 글의 저자 중 한 명인 조나단 콜(Jonathan Kohl)“Software Testing is a Game”이란 글이 먼저 눈에 띄었습니다. 하지만 일단 조나단 콜이 먼저 그 글을 쓰기에 앞서 작성한 “The Software Development Game”이란 글을 먼저 읽어보는 것이 도움이 될 것 같습니다.

 

이 글은 소프트웨어 개발 과정에 어떻게 게이미피케이션을 도입할 지에 대한 가이드라고 보여집니다.

어떻게 보면 간단하게 수행될 수 있을 것 같기도 한데, 그 과정이 쉬워보이지만은 않아 보입니다.

제 개인적으로도 게임 퍼블리셔의 테스트 팀에 있을 때, 매달 각 장르별로 제일 많은 버그를 등록한 테스터들에게 실제로 트로피를 만들어 주는 것을 생각해 본 적이 있었습니다.

FPS는 밀리터리 피겨로 된 트로피를, RPG는 칼과 방패로 장식된 트로피를 주는 것이었죠. 생각만하고 실천에 옮기지를 못해 결과에 대해서는 알 방법이 없습니다만, 나름 테스터들에게 모티베이션이 되지 않았을까 생각해 봅니다.

 

번역 및 포스팅에 대해서는 저자인 조나단 콜의 승인을 받았습니다.

 

원글 출처: http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=ART&ObjectId=17705  

조나단 콜의 “Software Testing is a Game” 포스트: http://www.kohl.ca/2012/software-testing-is-a-game/

The Software Development Game

By Jonathan Kohl and David McFadzean

 

많은 팀들이 소프트웨어 개발 프로세스를 선택하고 수용하는 과정에서 많은 난관을 겪고 있다. 우리는 소프트웨어 개발 팀이 프로세스와 툴, 그리고 기술과 관련해 맞닥뜨리게 되는 다양한 문제들을 해결하기 위해 소프트웨어 개발 게임(SDG; Software Development Game)이라는 전략을 개발했다. SDG는 당신이 어떤 프로세스를 선택하더라도 게임이라는 컨셉을 사용해 요구에 맞게 수용할 수 있도록 도와줄 것이다.

 

어떻게 소프트웨어 개발이라는 심각한 작업이 게임처럼 다루어 질 수 있을까? 만약 당신이 여유있는 시간에 재미를 위해서 게임을 즐긴다면, 게임 역시 심각하게 다루어져야 할 비즈니스 중의 하나다. 스포츠는 그 자체를 지원하는 하나의 완벽한 사업군을 가진 프로 리그를 가지고 있다. 또한 군대에서는 전략을 테스트하고 병사를 훈련하기 위해 워게임을 활용하고 있다. SDG는 비록 어떤 공식적인 수학적 모델링을 사용하고 있지는 않지만, 이 두 개의 게임 이론에 많은 영향을 받았다. 그리고 또한 최근에 화두가 되고 있는 게이미피케이션(gamification)의 영향도 받았다. 

 

게임 이론(Game theory)은 경제학, 군사 분야, 비즈니스, 인공지능, 그리고 생물학적 진화론 등에서 다양하게 사용되고 있는 수학적 원리다. 게임 이론의 핵심은 모든 상황을 게임이라는 측면에서 협동 모드와 경쟁 모드로 분류하는 것이다. 어떤 게임은 승패를 가리기 위해 제한된 시간을 가지고 있고, 또 다른 게임들은 퀘스트와 같이 경험에 기반하고 계속 진행할 수 있는 형태를 가지고 있기도 하다.

 

최근에는 다양한 분야에서 게이미피케이션이라는 개념을 도입하고 있다. 게이미피케이션은 어떤 과제를 달성했을 때 보상을 제공하는 것과 같이 간단하게 정의될 수도 있고, ‘어떤 비즈니스와 관련된 모든 행위가 게임과 유사한 시스템으로 전환될 수 있다는 식으로 복잡하게 해석될 수도 있다. 반복적인 일을 하더라도 소셜 혹은 게임과 관련된 환경 하에서는 그렇지 못할 때보다 생산성이 더 높을 수 있다. 연구자들은 어떻게 일반적인 작업 환경에서도 이런 잠재적인 모티베이션을 이끌어 낼 수 있는지 알기위해 노력하고 있다[1].

 

소프트웨어 개발 팀에게는 종종 팀의 비전과 목적, 그리고 행동 수칙(rules of conduct)이나 공식적으로 다루어져야 하는 사례 등이 비공식적으로 만들어지고 때론 강요되기도 한다. 이로 인해 조직 내에서 개발 팀의 미션과 목적이 혼돈되는 결과를 가져오기도 한다. 최상의 경우라고 하더라도 이러한 비공식적인 행동들은 서로간의 오해를 불러일으키고 커뮤니케이션의 붕괴를 가져온다. 최악의 경우에는 조직 내에서 각 리더들이 제시하는 목표가 서로 일치하지 않는 상황도 발생한다. 이중 어떤 경우라도 팀 구성원과 조직은 모두 가치 창조에는 아무런 도움도 되지 않는 업무를 처리하는데 시간을 소비할 수 밖에 없게 된다.

 

게임 이론 자체가 수학적인 모델을 활용하고 있기도 하지만, 게임과 관련된 행위들을 분석해 보는 것도 역시 효과적이다. 우리는 사람들이 어떻게 그들의 의사결정 과정을 효율적으로 만들어가는 지에 대해 게임 이론에 입각해 연구한 것을 본적이 있다. SDG 에서는 팀이 목표를 공유하고, 특정한 이슈에 대해 명확한 개요와 일관적인 행동 방향을 제공하며, 의사 결정 프로세스를 시각화하기 위해 게임과 유사한 프로세스를 제공한다. SDG는 기존에 즉흥적으로 수행되고 정치적이며, 팀 구성원들에게 불명확했던 프로세스를 구조적이고 신뢰할 수 있는 프로세스로 바꾸어준다. 의사 결정 과정의 게임화를 통해, SDG는 소프트웨어 개발팀이 내부적인 사항들을 결정하고 기록하고, 그들이 보유하고 있는 기술과 프로세스, 도구를 조합할 수 있도록 도와준다. 또한 이는 현존하는 정책과 프랙티스들을 수용하도록 도와주는 프레임워크로 작용하기도 하고, 팀 회고 이후 개선을 위해 제안된 변경사항을 수행되도록 도와주기도 한다.

 

소프트웨어 개발 업무를 리딩하면서 게임 이론에 영향을 받고 있을 무렵, 피터 슈버(Peter Suber)가 고안한 노믹(Nomic)[2]이라는 게임에 기반해 소프트웨어 개발 게임 프레임워크를 만들자고 제안한 것은 나의 동료 데이빗이었다. 노믹은 플레이어들의 의사결정 과정에 초점이 맞추어진 게임으로, 최초의 게임 룰에 대해 플레이어들의 동의하고, 룰을 변경하기 위해 어떤 안을 제안하고 투표를 통해 이를 결정하는 과정을 다루고 있는 게임이다. 따라서, 게임의 규칙을 변경하는 것이 하나의 유효한 무브(Valid move)”로 간주된다. 노믹은 온라인으로도 플레이가 가능하며, 플레이어들은 시간이 흐를수록 새로운 아이디어와 변화를 만드는 것에 적응해 간다. 이는 또한 잦은 환경 변화를 겪을 수 밖에 없는 소프트웨어 개발팀에게도 훌륭하게 적용될 수 있었다.

 

게임의 규칙

SDG를 즉각 구현하기 위해서 소프트웨어 개발팀은 최소한의 규칙과 학습 조직 그들이 만들기 위한 것을 만들기 위해 필요한 역량을 끊임없이 발전시킬 수 있는 그룹 - 을 만든다는 목표를 가지고 있어야 한다.[3] 게임이 발전하느냐 마느냐는 온전히 플레이어(팀 구성원)에게 달려있다. 게임이 문제없이 진행된다면 그들은 좀 더 생산적이고 효율적으로 업무를 수행할 수 있게 될 것이며, 좀 더 나은 의사결정을 할 수 있을 것이다. SDG는 어떤 직급과 단위에도 적용될 수 있다. 실무진, 관리자, , 혹은 개인 모두에게 적용될 수 있는 것이다. SDG가 유용하다는 것이 증명된다면 좀 더 많은 사람들이 게임에 참여할 수 있을 것이다.

 

데이빗이 퍼실리테이터(facilitator)로서 이 작업에 참가했다. 그가 게임의 컨셉을 만들고 팀 구성원들에게 프로세스와 게임의 목적에 대해 교육했다. 데이빗이 주도적인 역할을 수행할 것에 대해 팀이 동의하자, 그는 게임 플레이를 위한 최초의 게임 규칙을 설명하고 모든 팀 구성원들이 이 최초의 규칙들에 대해 동의하는지 알아보기 위해 회의를 소집했다. 개발팀의 위키에 최초의 게임 규칙들을 설명하는 페이지가 만들어졌다.

 

 

규칙 1:

게임의 최초 목적은 플레이어가 최상의 선택과 결정을 할 수 있도록 하는 학습 조직을 만드는 것이다. 앞에서 설명한 바와 같이, 이 규칙은 게임을 플레이하고 있는 조직의 다른 미션과 통합되기 위해 조정될 필요가 있을 것이다.   

 

규칙 2:

모든 플레이어들은 모든 규칙의 변경에 만장일치로 동의해야 한다. 투표에 관한 규칙 중 가장 처음에 명시되어 있는 것은 모든 제안이 만장일치로 통과해야 한다는 것이다. 대부분의 게임에서는 교착상태를 피하려고 이 부분을 일찌감치 다수결의 원칙으로 바꾸고는 하는데, 규칙을 정하는 초기에는 쉽게 실수를 범하기 마련이므로 유의할 필요가 있다.

 

규칙 3:

제안이 추가되고, 수정되고 혹은 규칙을 폐지할 수 있다. 이는 게임에서 만들어질 수 있는 규칙인 여러가지 무브(Move)”에 대해서 설명하고 있는 것이다. 여기에는 새로운 규칙과 존재하는 규칙의 변경, 혹은 이미 존재하는 규칙을 삭제하는 행위가 포함된다. 게임은 일반적으로 점점 자세한 사항으로까지 발전해간다. 예를 들어, 특정한 상황에서 특정한 클래스의 플레이어에게 투표 거부권을 부여한다든지, 수정될 수 없는 불변의 법칙이라는 카테고리를 만든다든지, 혹은 해결책, 목표, 표준 그리고 가이드라인과 같은 새로운 유형의 행위를 만들어 낼수도 있다.

 

규칙 4:

모든 규칙은 논리적으로 모순이 없어야한다. 모든 규칙에 논리적인 모순이 없다는 것을 확인함으로써 페어 플레이를 권장하고, 플레이어들로 하여금 규칙들을 정상적인 상태로 유지하도록 동기부여할 수 있다. 그렇게 된다면 일관적이지 못한 상황이 발생할 때마다(고의적이든 혹은 우연히든) 플레이어들은 이러한 모순을 규칙의 수정이나 삭제를 통해 해결하려고 노력하게 될 것이다.

 

데이빗은 게임에 참가한 모든 팀에게 게임 플레이에 관한 가이드를 주었다. 모두가 최초의 규칙들에 대해 동의한 다음, 팀은 가장 어려운 주제 중의 하나인 “C++ 코딩 표준 정하기를 해결하기 위한 업무에 착수했다. 코딩 표준을 정하는 것은 어느 개발팀에게나 발생할 수 있는 논쟁 거리 중의 하나다(직업으로 코딩을 하는 사람이라면 이 일이 얼마나 어려운지 쉽게 이해할 수 있을 것이다. 그렇지 않은 사람들은, 서로 다른 정당이나 종교가 합의점을 찾는 일이라고 생각하면 된다).

 

코딩 표준에 대한 제안이 상정되고 다수결에 회부되었다. 투표가 끝나고나서 그 회의 내용과 결정된 코딩 표준안이 개발팀의 위키에 저장된다. 게임 안에서 코딩 표준을 결정하고 나서, 코딩 표준은 그것 스스로 게임의 룰이 되었다. 소프트웨어 개발 정책과 프랙티스를 결정하고나서, 팀은 이를 준수하고 변경사항을 관리할 수 있는 매커니즘을 만들게 된 것이다 

 

게임 발전 시키기

SDG에는 커뮤니케이션, 이슈 제기, 투표 상정을 위한 제안, 투표 중지, 결과 검수하기 등의 프레임워크가 필요하다. 데이빗은 이를 위해 위키, 대면 회의, 이메일, 그리고 회사 내부에서만 사용되는 인스턴트 메신저 등을 다양하게 활용했다. 퍼실리테이터로서 그는 질문에 답변하고, 개요를 설명하고 SDG라는 개념 하에서 제기될 수 있는 잠재적인 팀 이슈들을 지속적으로 관찰하고 관리했다.

 

예를 들어, 한 팀 구성원이 다른 동료에게 빌드에 표준이 없는 것에 불만을 제기했다면, 데이빗은 문제를 제기한 그 사람에게 그 이슈가 팀이 해결해야 할만큼 중요한 이슈인지를 물어볼 수 있다. 만약 그렇다면, 그 팀 구성원에게 팀을 위한 제안을 하도록 하고 다른 사람들이 그 안에 대해 투표를 하도록 할 수 있다. 이러한 제안은 아래처럼 간단할 수도 있다. “깨진 빌드는 심각한 생산성 이슈입니다. 우리 중 일부는 주어진 업무를 완수하는 대신 깨진 빌드를 고치는데 시간을 할애해야 합니다. 빌드 문제를 해결해야 한다는 것에 모두 동의하고 이를 해결할 수 있는 아이디어를 마련해야 합니다.” 문제를 해결해야 한다는 것에는 모두가 쉽게 공감할 수 있기 때문에 이것은 아주 간단한 제안처럼 보일 수도 있다. 하지만 정작 어려운 것은 이 주제에 대해 실질적인 행동을 함께 취해야 한다는 것이다. 만약 제안이 애매모호하다면, 팀 구성원들은 더 구체적인 아이디어와 대안을 제시해 초안을 더 명확하게 만들 수 있다. 애매모호한 제안은 토론과 논쟁을 통해서 좀 더 구체적인 것이 될 수 있다. 또한 이상적으로는 모든 제안마다 오너십과 그에 따른 책임이 부여되어야 한다. 우리의 경험에 따르면, “깨진 빌드는 반드시 새로운 코드가 형상 관리 시스템에 커밋되기 전에 수정되어야 한다와 같이 좀 더 구체적인 제안일수록 좀 더 쉽게 행동으로 옮길 수 있었다.

 

어떤 문제에 대해 해결책을 마련한다는 것은 시간이 걸리는 작업일 뿐더러, 회의를 질질 끌게 만드는 원인이 되기도 한다. 어떤 사람들은 그룹이 아닌 홀로 생각할 때 더 좋은 해결책을 찾기도 하고, 회의가 끝난 다음에 팀 구성원들과 함께 이를 논의하기도 한다 

 

팀은 또한 프로세스를 효율적으로 만들기 위해 특정한 기법을 사용하는 것에 동의했다. 시스템에 제안이 올라오고 투표가 수행되었다. 만약 상정된 제안에 좀 더 구체적인 정보가 필요하다면, 이메일을 통해 공유되거나 다양한 의견을 청취하기 위해 퍼실리테이터가 회의를 소집하거나 투표를 중단하기도 한다.

 

, 그럼 이제 당신이 빌드 문제를 고치자는 의견에 합의한 팀원이라고 생각해보자. 당신 역시 깨진 빌드로 인해 고통받는 사람 중의 하나이고, 당신이 제안한 대안이 효과가 있다고 가정하자. 당신은 이 대안을 여러번 스스로 테스트하고, 당신이 발의한 이 제안이 팀에 긍정적인 영향을 끼칠것이라고 확신하고 있다. 당신은 SDG 안에서 당신의 제안이 받아들여지도록 다른 사람들에게 충분한 설명도 했다. 하지만 투표 결과, 다수결에서 선택되지 못했다. 당신은 크게 실망했고, 당신의 안 대신 선택된 다른 대안도 없었다. 당신은 당신의 방법이 옳다는 걸 알고 있지만, 왜 이렇게 된걸까? 만약 당신이 선택받기를 원한다면, 당신에게는 정치가들이 하는 방법이 필요하고, 지원을 위해 로비를 벌일 필요가 있다. 다음과 같은 방법이 도움을 줄 수 있을 것이다 

 

l  당신의 제안이 가지는 이점에 대해 팀원들을 교육하기

l  제안에 대한 투표에서 영향력을 가지는 키맨을 설득하기

l  회의론자 설득하기: 당신의 제안이 수치적으로 향상된 결과를 보여줄 수 있으며 문제가 해결되었는지 확인하기 위해 시스템 상에서 정기적으로 체크가 가능하다는 것을 알려주기

l  공식적으로 제안하고 투표에 임하기

l  이 모든 것을 다 했다면, 당신의 로비가 효과를 거두어서 투표에서 선택되기를 기도하기

 

일단 한 번 팀 구성원들이 이 프로세스에 적응하기 시작하면, 그들이 어떤 의견이라도 심지어는 자기 잇속만 챙기려는 제안조차도 - 제안할 수 있다는 것을 깨닫기까지 그리 오랜 시간이 걸리지 않을 것이다. 만약 어떤 변화를 일으키고자 하는 합의만 이루어질 수 있다면, 그 배경에 어떤 의도가 있다고 하더라도 문제될 것이 없다. 팀 구성원이 현재에 사용하고 있는 기술에 지겨워하고 새로운 것에 관심을 가지는 것만큼 자연스러워 보이는 일도 없다. “나는 더 이상 자바 웹 앱을 만드는 일을 하고 싶지않아. 모바일 프로젝트에서 일하고싶어.”라고 말하는 것이 이기적으로 보일지도 모른다. 하지만 만약 이런 내용을 사내 게시판에 올려본다면, 관리자들을 포함해 얼마나 많은 사람들이 당신의 의견에 동조하는지 알고 놀랄지도 모른다. 관리자들은 시대에 뒤떨어지지 않기 위해 조직에 새로운 기술을 도입하는 것이 필요하다고 느끼고, 제품 관리자가 경쟁사들이 무엇을 하고 있는지 조사할 수도 있지만, 그렇다고 그 누구도 바쁜 개발팀에게 요즘은 뭘 하고 싶은지 물어보면서 괴롭히고 싶어하지는 않는다.[4]

 

자주 그리고 솔직하게 이런 이슈를 포럼에 올리지 않아도 이런 종류의 아이디어는 쉽게 이해될 수 있다. 가장 나쁜 경우는 불만을 가진 팀 구성원이 다른 사람에게 바로 불평을 터뜨리거나, 체제전복적이고 부정적인 방법을 통해 새로운 기술 플랫폼을 구축하려고 할 때이다. 이와 관련된 업무를 하는 사람에게 이러한 요구사항이 있다는 것을 알리고 그들이 시제품을 구매해 준다면, 이는 변화를 도입하는 강력한 수단이 될 것이며 심지어는 그것이 어느정도 이기적인 목적에서 출발한 것일지라도 효과를 볼 수 있을 것이다.

 

데이빗의 팀이 여러가지 제안에 대해 제안하고 투표를 진행하면서, 규칙은 점점 늘어가기 시작했다. 규칙을 카테고리화하는 것이 필요했다. 가장 강력한 두 개의 룰은 규칙은 게임 자체에 적용된다규칙은 소프트웨어 개발 행위에 적용된다였다. 가장 초기에 정해진 SDG 룰에 더해, 룰 변경에 관한 규칙, 제안(제안을 만들거나 철회하기), 투표 규칙(어떤 것이 다수를 의미하는가), 그리고 다중 투표(타이 브레이커와 같은 것)에 대한 규칙들이 더해졌다. 소프트웨어 개발과 관련해서 규칙은 팀의 정책(비전 명시, 따라야할 프로세스)과 개발 표준(코딩 표준, 코드 리뷰, 그리고 빌드와 테스팅 행위)에 따라 구분되어졌다. 규칙이 늘어날수록, 팀 구성원들은 그들이 보유하고 있는 전문지식과 어디에 흥미를 가지고 있느냐에 따라 특정 분야에 집중하게 되었다. 규칙은 스스로 게임 플레이를 원활하게 진행하는 방향으로 발전했고, 소프트웨어 개발 시스템의 기술적 컴포넌트들을 관찰하게 만들었으며, 향후 제품을 만들어가야 할 방향을 안내해 주었다. 만약 필요하다면, 관리자와 다른 이해 관계자들도 이 작업에 참여할 수 있었다.

 

또한 SDG는 반복적인 업무에 게이미피케이션의 측면을 적용함으로써 더욱 더 발전할 수 있다. 게임 퀘스트처럼, 그리 쾌적하지 않은 반복적인 업무에 대해서도 보상이 주어질 수 있다. 예를 들어, 출장은 어렵고 힘든 일이 될 수 있는데, 이런 경우 팀은 팀에서 가장 많이 출장을 다니는 사람에게 팀 위키에서 별도의 칭호를 수여해 줄 수도 있다. 또한 가장 최근에 빌딩의 화재 경보 시스템을 깨뜨린 사람에게, 혹은 빌드를 가장 자주 깨먹는 사람에게 상을 주는 것처럼 유머러스한 보상도 가능하다.

 

이런 특별한 SDG의 예들은 일상적인 개발 팀의 활동들을 통해 좀 더 구체화될 수 있으며, 어떻게 커뮤니케이션을 만들어가고 향후에 어떻게 일들이 진행되어야 하는지에 대한 결정을 좀 더 쉽게 내릴 수 있게 해줄 것이다.

 

 

SDG가 효율적인 이유

지금까지의 이야기가 하나의 팀에 한 번만 적용되었던 것은 아니다. 데이빗은 지난 몇 년 동안 다양한 SDG의 사례들을 다양한 회사와 여러 팀에 적용해 왔다. 우리는 이를 통해 문제를 해결하고 의사를 결정하는 과정을 명시함으로써 커뮤니케이션을 향상시키고 혼란을 줄일 수 있음을 발견했다. 개발팀에서 생기는 많은 오해들이 팀이나 개인이 무엇을 달성해야 하는지에 대한 서로 다른 기대와, 조직의 목표에 대한 합의가 없는 데에서 비롯된다. 모든 결정은 민주적으로 수행된다. 모든 사람이 의견을 상정할 수 있고, 모든 변경사항에 대해 팀 구성원들이 투표하고, 투표는 모두 익명으로 진행된다. 이런 과정을 통해 팀 구성원들은 스스로가 조직에 꼭 필요한 사람이라고 느낄 수 있을 것이다. SDG는 문제를 제기하고, 필요에 따라 내부적인 절차를 조정함으로써 외부 환경의 변화에 적응하는 것을 도와준다. 이런 방식으로 현존하는 절차와 도구를 바꾸는 프레임워크가 되는 것이다. 만약 게임 프레임워크 자체가 더 이상 도움이 되지 않는다면, 이를 발전시키기 위해 기존의 규칙을 바꿀 수도 있다. 회사에서 이렇게 게임과 유사한 컨셉을 활용한다는 것은, 특정 그룹 안에서 발생하는 자연스러운 행동 역학(behavioral dynamics)을 유도할 수 있게 된다는 것을 의미한다. 게임 자체가 스스로 수정될 여지가 있기 때문에 팀은 새로운 환경에 적합하지 않는 융통성 없는 프로세스에 고착되어 있을 필요가 없다. 규칙은 항상 수정될 수 있고, 심지어 더 이상 어떤 가치도 제공하지 않는다고 판단되면 폐지될 수도 있다.

 

처음에는 경영진과 다른 리더들이 SDG를 성가신 것으로 받아들일 수도 있다. 경영진과 팀 구성원들 모두에게 게임은 단지 개발팀이 오너십을 가진 부분에만 적용된다는 것을 명백하게 해 둘 필요가 있다. 게임을 수행하는 팀은 현존하는 기본 정책이나 경영진에 의해 만들어진 결정을 뒤엎으려 해서는 안된다. 예를 들어, 팀 구성원들은 승진이나 보너스에 대해서나, 현존하는 제품 라인의 폐기 등에 관해 투표를 해서는 안된다. 다른 이해관계자들이 담당하는 분야에 대해 그들이 주목할 만한 이슈를 제기할 수는 있지만, 현존하는 조직 구조와 정책은 온전하게 유지되어야 한다. 만약 리더가 다른 영역에도 이런 게임 기법을 적용하기를 원한다면 상관없지만, 그전에 다른 조직을 약화시킬 목적으로 이 게임을 사용해서는 안된다. 리더들은 이 게임을 통해 회사의 비전이 제품과 서비스에 항상 간단하고 일관되게 적용될 수 있도록 해준다는 것을 알게 될 것이다. 팀의 목표와 행동이 점점 더 일치해져 갈 것이며, 의사 결정 프로세스가 투명해지고 이를 통해 어떤 제안이 상정되었을 때 경영진들은 이와 관련해 언제, 그리고 왜 이런 기술적인 방향을 고려해야 하는지를 알게 될것이다.

 

SDG는 팀의 의사결정, 특히 팀 스스로 결정하고 조직해야 하는 모든 일에 관해 도움을 줄 수 있다. 또한 팀의 화합을 도모하고 다양한 의견을 개진하고 이에 대한 합리적으로 반론을 제기하는 것을 도와줄 수 있다. 만약 조직 내에 어떤 심각한 문제가 있다면, SDG는 조직의 목표를 달성하기 위해 프로젝트와 테스크가 가야할 방향을 변경하는데 도움을 주는 프레임워크를 제공해 줄 수 있는 것이다.

 

SDG를 적용할 수 있는 가장 멋진 기회는 바로 회고가 끝난 다음 회고에서 결정된 변경사항을 적용하려고 할 때이다. 릴리즈 이후에 우리가 부닥쳤던 문제의 개요를 파악하고 해결책을 찾기위해, 그리고 단지 다음 회고까지 그것들을 잊어버리기 위해 우리는 얼마나 많은 멋진 회의를 거쳐왔던가? 그 동안, 우리는 그런 회의에 집중하느라 실질적인 일들은 거의 하지 못했다. 좋은 의도를 가지고 있음에도 불구하고, 이러한 결정을 실제 행동으로 옮기게 해주고, 진행 상황을 구체적으로 측정하도록 해줄 수 있는 방법이 없다면, 우리가 가지고 있는 아이디어조차도 결국은 잊어버리게 될것이다. SDG를 통해 회고에서 나온 아이디어들이 다음 회고까지 잊혀져 버리는게 아니라, 게임을 통해 구현될 수 있는 것이다.

 

결론

소프트웨어 개발 프로세스는 광범위하게 적용되기에는 어려운 컨셉이다. 한 팀에게는 제대로 적용된다고 하더라도 그 부분이 반드시 다른 팀에도 제대로 적용된다고 보기 힘들다. 팀의 어떤 부분이 제대로 작동하지 않는지, 혹은 어떤 핵심 컴포넌트가 없는지를 알아보려고 프로세스를 시험해 보려는 경우, 그 다음에 어떻게 이런 부분을 변형시키고 개선해 가는지가 아주 중요하다. 어떤 프로세스가 실패했을 경우, 이에 대한 적절한 반응은 당신과 당신 팀에게 도움이 되는 것들을 찾아서 수행할 필요가 있다라는 것이다. 이 반응은 당연히 합리적이다. 하지만 과연 어떤 것이 당신에게 도움이 되는 구체적이고 확실한 방법인지 어떻게 알아낼 것인가? SDG가 그 답을 줄 수 있을 것이다. 소프트웨어 개발 게임에서 사용된 몇 가지 성공요소를 간추려 보면 다음과 같다.

 

소프트웨어 개발 게임에 구현할 사항들

1.     간단한 게임 플레이 규칙으로 시작하라(우리가 제시한 예제를 사용해도 좋음)

2.     게임 플레이를 안내하고 회의를 관장하고, 투표 결과와 업데이트된 규칙을 기록할 퍼실리테이터를 두라.

3.     시작은 간단하게, 그리고 게임 스스로가 발전하게 놔두어라. 너무 많은 것을 하려고 하지 마라.

n  팀 정책을 개발하고 이를 조직의 목표와 일치시켜라.

n  회고에서 나온 아이디어를 구현하기 위해 이러한 게임을 활용하는 것을 고려해보라.

4.     팀내 모든 구성원들에게 현존하는 프로세스가 어떤 것이며, 이를 기록하고 비준받고, 이를 명시하기 위해 게임을 활용하라.

5.     규칙이 거추장스러운것이 되지 않도록 하라.

n  항상 규칙을 간단명료한 형태로 유지하라.

n  만약 규칙의 개수가 너무 많아진다면, 이를 적절한 수로 줄이도록 하라

6.     게임의 규모가 커질수록, 관리자를 도와줄 수 있는 추가적인 역할을 도입하라.

--------------------------------------------------------------------------------------------------------------------------

조나단 콜(Jonathan Kohl)은 세계적으로 알려진 컨설턴트이며 테크니컬 리더이다. 캐나다의 캘거리, 앨버타에 근거를 두고 있으며, 콜 컨셉트(Kohl Concepts, Inc.)의 창립자이자 핵심 소프트웨어 컨설턴트이다. 테스팅으로 팀을 지원하는 것과 함께, 조나단은 회사의 아이디어를 결정하고 이를 제품에 구현하는 것을 돕고 있으며, 또한 그들이 소프트웨어를 개발할 때 이를 코치하고, 리더들이 그들의 전략ㅇ르 결정하고 구현할 수 있도록 도와주고 있다. 그는 또한 인기있는 작가이자 연사로 알려져 있다.

 

캐나다 캘거리, 앨버타에 거주하고 있는 데이밋 맥퍼드진(David McFadzean)은 좀 더 나은 결정을 하게 함으로써 인텔리전스를 증가시키는 빌딩 테크놀로지에 많은 관심을 가지고 있다. 데이빗은 25년 이상의 경력을 가지고 있다. 인공지능에 대한 학문적 소양을 배경으로 데이빗은 여러 스타트업 기업에서 일해왔으며, 여기에는 그가 창업에 동참한 두 개의 회사도 포함되어 있다. 또한 그는 코더, UX 디자이너, 소프트웨어 아키텍트, 제품 관리자, 트레이너, 개발 관리자, 중역으로서의 역할을 수행해 왔다. 특히 그는 기술적인 스타트업 기업이 성공한 기업으로 성장하는 것을 도와주는 것에 많은 관심을 가지고 있다.

 



[1] 저자 주: 게이미피케이션과 게임 이론이 필수적으로 연관되는 것은 아니다. 하지만 어느 정도 중복되는 것도 사실이다.

게임 이론을 이해하는 것이 게이미피케이션을 만드는데 도움을 주며, 게이미피케이션이라는 개념이 게임 이론을 구현하는

 것을 강화해 주기도 한다.

 

 

[3] Senge, Peter. (1990, 2006.) The Fifth Discipline: The Art and Practice of the Learning Organization, Doubleday.

 

[4] 역자 주: 누구도 먼저 알아주기 않기 때문에 스스로 의견을 제공하라는 것임

  • 프로필사진
    hslth2012.11.21 16:13

    매번 너무 훌륭한 번역 감사합니다.
    Python 개발자 이지만 게임QA를 꿈꾸는 입장에서
    매우 좋은 자료들을 얻어갑니다.
    다시한번 감사합니다.

    • 프로필사진
      BlogIcon 검은왕자2012.11.22 10:24 신고

      좋게 봐주셔서 감사합니다. QA를 하시는 데 조금이라도 도움되면 좋겠네요. 꿈 이루시길 바랍니다. ^^