[u] Story 의 naming convention 을 Story 방식으로 변경함.
팀 내 Rational Team Concert 적용을 위한 가이드 제작 중 유용한 팁이 있어 공유한다.
RTC 에서 Scrum 템플릿을 사용할 경우, 플래닝에 사용되는 work item 타입은 기본적으로 (범위가 큰 것부터 차례로) Epic, Story, Task, 이렇게 세 가지이다. Scrum에 문외한인 사람들뿐 아니라, Scrum 에 나름 익숙한 사람들도 계획을 잡기에 익숙해지기까지는 제법 많은 난관에 부딪힌다. 이에 내 경험을 바탕으로 나름의 노하우를 정리해보았다. 이 방식을 잘 익히고 따른다면 계획을 잡는데 많은 도움이 되리라 확신한다.
덤으로..
추가로..
스크럼이나 유사 Agile 방식에 익숙하지 않다면 Story 의 naming 이 생소할 수 있다. 생각해보면 간단하다. ‘고객/사용자가 이 제품(Product)으로 무엇을 할 수 있다.’ 의 형태이다. Story 를 이렇게 작성할 때 얻게되는 대표적인 이점은 아래와 같다.
혹 스크럼 형태의 Story 네이밍에 익숙하지 않다면 아래와 같은 방식도 시도해볼 수 있다. 하지만 처음 러닝 커브는 작을 지라도, 경험상 정통 스토리 방식이 더욱 효과적이다.
최근 조사 결과를 바탕으로 간략히 현 시대의 소프트웨어 개발 프로세스와 툴의 현황을 공유해본다.
먼저 소프트웨어 개발에 활용중인 프로세스들의 비중을 살펴보자.
다음은 조직내에서 Agile 이 어느 정도 받아들여지고 있느냐에 대한 설문이다.
마지막으로.. Agile 을 지원하는 툴로써 현 시대 제품들을 평가해본 결과이다.
나는 작년에 마음에 맞는 사람 몇 명과 제법 참신하고 효과적인 스터디를 만들어 운영해보았다. 그 경험은 값진 기억이 되었고, 추후 여건이 다시 갖추어지면 유사한 형태로 재도전해보고 싶다. 여기 그 방식에 대해 간략히 소개해볼 터이니, 관심 있는 사람은 직접 주변인들과 시도해보길 권해본다.
내가 만들었던 스터디는 조금 특이했다.
가장 큰 특징은 참여자들이 준비해올 것이 없었다는 점. 스터디 자료로는 Google Tech Talk, iTunes U(niversity) & Video Podcast, 인터넷 상의 각종 기술 세미나, 최신 툴 데모 동영상, 유명인 인터뷰 동영상 등이었다. 세어보진 않았지만, 대략 백여개 정도의 흥미로운 자료들을 모을 수 있었다.
1시간 정도 동영상을 함께 보고, 30분 정도 토론을 한다. 부족한 정보는 그때그때 인터넷에서 검색해볼 수 있고, 더 깊은 지식을 원하거나 직접 해보고 싶은 것들은 action item 으로 빼서 스터디 외 시간에 진행하기도 한다. 흥미로는 결과는 종종 스터디 참여자 이외의 사람들과도 공유했고, 또 과제 진행에 도움이 되는 일을 진행하기도 했다.
또한, 서로의 task plan 을 리뷰하면서 planning 기술을 늘려가기도 하고, 코드 리뷰로부터 나온 유용한 패턴들을 공유하는 자리로 활용한다.
별다른 준비 없이 참여만 하면 지식과 지혜를 얻어갈 수 있는 모임이었고, 이런 특성이 스터디를 오랫동안 유지하는데 큰 도움이 되었다고 믿는다.
여기에.. 매달말 회고(retrospective)를 진행했다. 회고에서는 지난 한 달동안 공부한 내용 되집어보고, 다음 한달간 공부할 커리큘럼을 짠다. 스터디 진행 방식에 있어 개선이 필요하다고 생각되는 것들을 논의해서 적용해본다. 주기적으로 동기를 부여하고, 부족한 부분을 지속적으로 보강하여 모임의 생명력을 유지해나가고 발전시키는 수단으로 효과가 높다.
이 모임은 매일 아침 7:30 에 모여 9시까지, 약 4달간 유지되었고, 일부 열성 멤버는 토요일에 모여 별도의 스터디(iPhone application programming)를 진행하기도 했다. 그러다 내가 다른 목표가 생겨 탈퇴하면서, 아쉽게도 현재는 운영되지 않는 상태다.
운영하면서 어려웠던 점들도 정리해보았다.
- 참여자들이 대부분 서로 다른 서브팀 맴버였고, 같은 서브팀 내에서도 개개인이 독립적으로 일하는 문화 때문에 시너지를 일으키는데 한계를 많이 느꼈다.
- 멤버들이 업무상 건물간 이동이 잦아, 일부 맴버들은 왔다갔다하는 불편을 겪기도 했다.
- 정식 업무가 아니라, 이른 아침 시간을 선택.. 참여 희망이 있어도 나오지 못하는 사람들도 종종 있었다. 멀리 사는 사람, 아침잠 많은 사람 등. 소수 인원으로 운영하다보니 두 명만 빠져면 스터디 진행에 큰 영향을 미쳤다. (내가 빠진이 운영 중단에 큰 영향을 미친 이유다.)
- 팀이 점점 (반 강제적으로) 늦게 퇴근하는 문화로 바뀌면서 아침 스터디에 대한 부담이 점차 가중되었습니다.
내가 이 스터디를 주창한데는 주변 개발자들이 세상 돌아가는 정보를 너무 모른다는 느낌을 평소 많이 받았다는 이유가 크게 작용했지만, 진행을 하면서 나 역시도 다른 멤버들로부터 많은 정보를 얻고 미처 생각하지 못했던 깨우침을 얻게된 값진 경험이었다.
RTC 를 처음 시작하려는 사람들에게 좋은 자료들을 정리해보았다.
한 팀에서 처음으로 RTC 를 사용해 과제를 진행해보고자 한다면, 팀원들을 한 자리에 모아놓고 아래대로 쭉~ 학습해보자. 중간중간 대화와 검색 등의 시간을 합쳐 총 2시간 정도의 workshop 이면 충분할 것이다. 물론 최소 1명은 RTC를 직접 사용해본 경험자가 필요하다.
1. (10분) 다음은 RSSOwl 이라는 오픈소스 프로젝트에서 RTC 를 사용하는 모습을 아주 간략히 보여주는 동영상이다. RTC 가 도대체 무엇을 제공해주는 툴인지, 그 전반을 짧은 시간 내에 훑어보기에 좋다.
2. (15분) 다음으로는 직접 RSSOwl 사이트를 방문하여 위의 짧은 동영상에서 놓친 세세한 부분들을 점검해보자.
RSSOwl – Reader for RSS | RDF | Atom Newsfeeds
데시보드도 훑어보고, 각 반복주기별 태스크 관리, 소스 코드와 결함, 빌드 상황들이 어떻게 보이고 관리될 수 있는지 체크해보자.
* 참고로, 포럼은 오픈 소스 프로젝트 운영에 필수 요소 중 하나이지만 RTC 가 제공하지는 않고 있다. 포럼이 필요하면 취향에 맞는 프리 포럼을 찾아 설치하자.
3. (1시간) 이제 아름프로님이 제작해주신 동영상 강의를 들어보자. 아래의 강의를 시작으로 총 7편, 약 1시간 분량이다.
툴 세팅에서 시작해 프로젝트를 만들고 일정 계획, 작업 내용 작성, 팀원에게 분배하고 과제를 진행하기 직전까지의 내용을 다룬다. 즉, 이 동영상을 잘 따라갔다면 RTC와 함께 과제를 시작할 준비까지 된 상태가 된다.
* 위 동영상은 Scrum 에 맞춰 작성되어 Scrum 에 익숙치 않은 사람들은 용어가 낯설 수 있다. 하지만 툴의 활용성을 파악하는데는 지장이 없을 터이니 걱정하지 말자.
4. (20분) 마지막으로 팀에서 작업할 실제 환경에서 RTC 클라이언트를 설치하고 서버에 연결하는 과정을 직접 시연 & 수행해보게 하자. 간략히 이곳저곳 기능을 살펴보며 궁금한 것들을 답해주자.
5. (10분) 작업 서버에 바로 붙어 이것저것 테스트해보기 부담스러워하는 팀원들이 있다면 누구나 테스트해볼 수 있는 Sandbox 사이트를 소개해주자.
Rational Team Concert Sandbox
미리 실제 과제 환경과 유사하게 프로젝트를 세팅해두면 좋고, 처음부터 다 해보고 싶은 사람은 직접 새로운 사이트를 만들어볼 수 있다. (풍차님의 설명 참조)
자~ 이 정도면 빠르게 시작하기 위한 기본은 어느정도 공유가 될 것이다. 이후부터는 사용해보면서 하나하나 배워나가는 기쁨을 누려보도록 하자.
새로 옮긴 팀에 Rational Team Concert [1] (이하 RTC) 를 적용하기 위해 노력 중이다. 지난 팀에서는 이러저런 이유들로 보수적인 성향이 너무 강해 중도 포기했었지만, 지금의 팀은 가능성이 높아 보인다. 특정 툴을 적용하다는 것이 중요한 것이 아니라 적절한 인프라를 구축하여 팀의 협업 능력을 극대화시킨다는데 목적이 있고, 현 시점에서 가장 훌륭한 툴이 Rational Team Concert 라 판단되어 진행중이다[2].
최근엔 지난 팀에서 RTC 를 전파할 때 한꺼번에 너무 많은 것을 이해시키려 한 경향이 컸었다는 생각이 든다. 따라올 수 있는 사람들은 따라왔지만, 제법 많은 사람들은 너무 많은 변화에 기겁을 하고 섵불리 도전하지 못했을 수도 있다. 여기에는 RTC 의 다양한 기능뿐 아니라 방법론과 사상도 포함된다. 예를 들어, 기본적인 개발 방법론에도 익숙치 않은 사람들에게 애자일이니 스크럼이니 하는 이야기까지 짧은 시간에 전파하려 한 것은 좋지 않은 시도였던듯 싶다.
그래서 이번엔 이런 이질적인 내용을 최소화하는 방법을 채택해보기로 하였다. 팀에서 업무를 진행하며 이루어지는 실제 활동들을 use case 로 잡아, RTC 를 사용했을 때의 모습을 긴 시간에 걸쳐 조금씩 보여주려 한다. 현재 잡아놓은 use case 들은 아래와 같다.
기본적인 활용에 익숙해지면 여러 동영상 자료들도 활용해 볼까 생각중이다.
거의 아무런 정보도 없이 이제 시작하는 프로젝트에 대해 일정을 내놓으라는 이야기를 너무 많이 들어왔고, 그 때마다 신뢰 구간 -50% ~ + 300% 의 일정이 그렇게 중요하냐고 묻으며 항의해보았다. 돌아오는 답변은, ‘그래도 일정은 필요하지 않느냐?’ 정도.. -_-a 결국 ‘일정을 위한 일정’ 만들기를 하게 된다.
어쩔 수 없이 일정을 내어주며, ‘이것은 신뢰성 10% 에요’ 라고 강조해보지만 절대 귀담아 듣지 않는다. 그 일정을 기준으로 종속된 모듈/기능 등을 고려한 전체 일정이 산출되고 임원들에게까지 보고된다. 그리고 기획과 마케팅 부서 역시 이를 기준으로 상품화 일정과 마케팅 일정을 등을 잡아 놓는다.
조금만 지나면 ‘신뢰성 10%’ 일정은 부메랑이 되어 개발자들을 옭아매기 시작한다. 진행중 (예외 없이) 예상치 못했던 문제들이 붉어져 나와도 ‘이미 윗선에 보고가 되어 있고 다른 부서들이 그에 맞춰 움직이고 있기 때문에 어쩔 수 없다. 무슨 수를 써서라도 이 때 끝내야 한다’는 식이다.
중간 관리자 몇 명만 설득해서 될 일은 아니다. 그들 대부분도 스스로를 피해자라 생각하고 있다. (틀린 말은 아니지만, 그들 중 윗사람들의 인식을 바꿔보려고 노력하는 사람은 단 한 명도 만나보지 못했다. 아쉽다.) 그래서 적어도 임원들까지는 제대로된 소프트웨어 개발 모델을 이해시킬 필요가 있다.
하지만 권위도 없고 직급도 낮은 사람들이 아무리 떠들어봐야 먹힐리 만무하다 (당장 바로 윗사람도 귀담아 듣지 않는데 -_-a). 책 좀 보라고 던져 주는 것도 아닌 듯 싶고.. 이런저런 생각을 해보다 우선 참조하기 좋은 블로그에 괜찮은 글을 하나 발췌해 놓기로 했다.
이 글은 스크럼 : 팀의 생산성을 극대화시키는 애자일 방법론 [1] (원서: Agile Software Development with Scrum [2]) 에서 발췌한 내용이다. 2장 ‘스크럼 준비 – 스크럼은 다르다’ 중 프로세스 제어 모델에 대한 블록으로, 저자가 왜 전통적인 프로세스들이 계속 실패하는지에 대한 통찰을 얻게된 계기를 이야기한 부분이다.
나는 1990년대 초반에 MATE라고 불리는 프로세스 관리 제품을 개발하고 라이선스하던 소프트웨어 업체를 운영했다. 우리의 최대 고객은 쿠퍼스 & 라이브랜드와 IBM 이었는데, 그들은 우리가 그들의 방법론을 사용해서 MATE를 개발하기를 원했다. 몇 차례 시도하긴 했으나 그 결과는 전적으로 불만족스러웠다. 당시, 우리 회사의 요구사항은 끊임없이 변하고 있었고 우리는 계속 신기술들을 도입하로 있었는데, 그 방법론은 우리를 도와주기는커녕 오히려 장애물을 만들고 유연성을 떨어뜨리는 등 마치 우리의 발목을 잡는 것과 같았다. 나는 왜 우리 고객들의 방법론이 우리 회사에는 효과가 없는지를 알고 싶었다. 그래서 1995년, 듀폰 연구소의 공정 제어 이론 전문가에게 시스템 개발 방법론에 대한 자문을 구했다. 바바툰데 ‘툰데’ 오거나이케(Babatunde ‘Tunde’ Ogannaike) 박사가 이끄는 전문가들은 산업 공정 제어 분야(industrial process control)에서 가장 존경 받는 이론가들이었다. 그들은 공정 제어에 대해 속속들이 알고 있었다. 심지어 연구자들의 일부는 유명 대학들에서 해당 주제에 대한 강연을 하기도 했다. 그들 모두가 시장 예측에서부터 제품 주문과 배달에 이르기까지 듀폰의 제품 생산 전 공정을 자동화하는데 관여하고 있었다. 듀폰의 연구자들에게 우리의 시스템 개발 프로세들을 살펴보도록 한 것은 듀폰의 연구자들에게 엄청난 우스갯거리를 선사한 거나 마찬가지였다. 그들은 우리 시스템 개발 산업이 전적으로 부적절한 공정 제어 모델에 따라 개발을 하고 있다는 사실에 깜짝 놀랐고 매우 의아해 했다. 듀폰의 연구자들은 시스템 개발이 너무 복잡하고 예측하기 힘들기 때문에, ‘경험주의적’이라고 부르는 다른 공정 제어 모델을 사용해야 한다고 말했다. 그들은 내가 왜 올바르지 못한 길로 가고 있는지를 이해시키기 위해서, “프로세스 역학, 모델링과 제어(Process Dynamics, Modeling and Control)” 라는 산업 공정 제어 이론의 필독서를 권했다. 간단히 말하자면 공정 제어에는 두 가지 주요 접근법이 있다. 하나는 ‘명시적인(defined)’ 공정 제어 모델로서 작업자들이 작업의 모든 부분을 완전히 이해해야 하는 것이다. 사전에 잘 정의된 일련의 입력들이 주어지면 매번 동일한 결과물이 산출된다. 명시적인 프로세는 완료 시점마다 매번 동일한 결과물을 내놓는 경우에 적용 가능하다. 툰데 박사는 내가 그에게 보여준 방법론들이 앞서 설명한 명시적인 프로세스를 사용하려고 했지만, 어느 프로세스나 태스크도 반복 가능하며 예측 가능할 정도로 충분히 명시되어 있지 않다고 말했다. 또한 그는 우리 산업이 명시적인 접근법을 쓰기에는 너무 많은 사고와 창조성을 요구하는 지식 집약적인 사업이라고 했다 툰데 박사는 우리 산업이 명시적인 방법론을 사용할 경우, 통제력 상실과 불완전한(혹은 잘못된) 제품 생산을 초래할 것이라는 사실을 이론적으로 증명해 보였다. 그럼에도 우리 분야의 여러 태스크들이 마치 시작과 종료가 예측 가능하기라도 한 듯이 명시적인 공법 프로세스처럼 서로 종속적으로 연결되어 있다는 점을 놀라워했다. 한편, 툰데 박사는 불확실성을 기반으로 하는 경험주의적인 공정 제어 모델에 대해서도 설명해 주었다. 경험주의 모델은 불완전하게 정의되어 예상 못한 결과를 만들어내는 프로세스를 빈번하게 검사하고 적응하는 방식을 통해 프로젝트를 제어하는 방법을 제공한다. 그는 내게 이 모델을 연구해서 시스템 개발 프로세스에 적용해볼 것을 권유했다. 듀폰 연구소 방문 기간 동안 나는 이 문제에 대한 진정한 통찰을 얻었다. 갑자기 내 안의 무엇인가가 번뜩이더니, 왜 우리 산업의 모든 사람이 시스템을 구축하는 데 그런 문제를 겪는지를 알게 되었다. 즉, 왜 우리 산업이 그런 곤경에 처했고, 형편없는 명성을 갖게 되었는지를 깨달은 것이다. 우리에게 필요한 것은 빈번하고 직접적인 테스트와 그에 뒤이은 즉각적인 수정임에도 불구하고 우리는 마치 조립 라인에서 일하는 것처럼 업무를 처리하는데 시간을 낭비하고 있었던 것이다.
나는 1990년대 초반에 MATE라고 불리는 프로세스 관리 제품을 개발하고 라이선스하던 소프트웨어 업체를 운영했다. 우리의 최대 고객은 쿠퍼스 & 라이브랜드와 IBM 이었는데, 그들은 우리가 그들의 방법론을 사용해서 MATE를 개발하기를 원했다. 몇 차례 시도하긴 했으나 그 결과는 전적으로 불만족스러웠다. 당시, 우리 회사의 요구사항은 끊임없이 변하고 있었고 우리는 계속 신기술들을 도입하로 있었는데, 그 방법론은 우리를 도와주기는커녕 오히려 장애물을 만들고 유연성을 떨어뜨리는 등 마치 우리의 발목을 잡는 것과 같았다.
나는 왜 우리 고객들의 방법론이 우리 회사에는 효과가 없는지를 알고 싶었다. 그래서 1995년, 듀폰 연구소의 공정 제어 이론 전문가에게 시스템 개발 방법론에 대한 자문을 구했다. 바바툰데 ‘툰데’ 오거나이케(Babatunde ‘Tunde’ Ogannaike) 박사가 이끄는 전문가들은 산업 공정 제어 분야(industrial process control)에서 가장 존경 받는 이론가들이었다. 그들은 공정 제어에 대해 속속들이 알고 있었다. 심지어 연구자들의 일부는 유명 대학들에서 해당 주제에 대한 강연을 하기도 했다. 그들 모두가 시장 예측에서부터 제품 주문과 배달에 이르기까지 듀폰의 제품 생산 전 공정을 자동화하는데 관여하고 있었다.
듀폰의 연구자들에게 우리의 시스템 개발 프로세들을 살펴보도록 한 것은 듀폰의 연구자들에게 엄청난 우스갯거리를 선사한 거나 마찬가지였다. 그들은 우리 시스템 개발 산업이 전적으로 부적절한 공정 제어 모델에 따라 개발을 하고 있다는 사실에 깜짝 놀랐고 매우 의아해 했다. 듀폰의 연구자들은 시스템 개발이 너무 복잡하고 예측하기 힘들기 때문에, ‘경험주의적’이라고 부르는 다른 공정 제어 모델을 사용해야 한다고 말했다. 그들은 내가 왜 올바르지 못한 길로 가고 있는지를 이해시키기 위해서, “프로세스 역학, 모델링과 제어(Process Dynamics, Modeling and Control)” 라는 산업 공정 제어 이론의 필독서를 권했다.
간단히 말하자면 공정 제어에는 두 가지 주요 접근법이 있다. 하나는 ‘명시적인(defined)’ 공정 제어 모델로서 작업자들이 작업의 모든 부분을 완전히 이해해야 하는 것이다. 사전에 잘 정의된 일련의 입력들이 주어지면 매번 동일한 결과물이 산출된다. 명시적인 프로세는 완료 시점마다 매번 동일한 결과물을 내놓는 경우에 적용 가능하다. 툰데 박사는 내가 그에게 보여준 방법론들이 앞서 설명한 명시적인 프로세스를 사용하려고 했지만, 어느 프로세스나 태스크도 반복 가능하며 예측 가능할 정도로 충분히 명시되어 있지 않다고 말했다. 또한 그는 우리 산업이 명시적인 접근법을 쓰기에는 너무 많은 사고와 창조성을 요구하는 지식 집약적인 사업이라고 했다 툰데 박사는 우리 산업이 명시적인 방법론을 사용할 경우, 통제력 상실과 불완전한(혹은 잘못된) 제품 생산을 초래할 것이라는 사실을 이론적으로 증명해 보였다. 그럼에도 우리 분야의 여러 태스크들이 마치 시작과 종료가 예측 가능하기라도 한 듯이 명시적인 공법 프로세스처럼 서로 종속적으로 연결되어 있다는 점을 놀라워했다.
한편, 툰데 박사는 불확실성을 기반으로 하는 경험주의적인 공정 제어 모델에 대해서도 설명해 주었다. 경험주의 모델은 불완전하게 정의되어 예상 못한 결과를 만들어내는 프로세스를 빈번하게 검사하고 적응하는 방식을 통해 프로젝트를 제어하는 방법을 제공한다. 그는 내게 이 모델을 연구해서 시스템 개발 프로세스에 적용해볼 것을 권유했다.
듀폰 연구소 방문 기간 동안 나는 이 문제에 대한 진정한 통찰을 얻었다. 갑자기 내 안의 무엇인가가 번뜩이더니, 왜 우리 산업의 모든 사람이 시스템을 구축하는 데 그런 문제를 겪는지를 알게 되었다. 즉, 왜 우리 산업이 그런 곤경에 처했고, 형편없는 명성을 갖게 되었는지를 깨달은 것이다. 우리에게 필요한 것은 빈번하고 직접적인 테스트와 그에 뒤이은 즉각적인 수정임에도 불구하고 우리는 마치 조립 라인에서 일하는 것처럼 업무를 처리하는데 시간을 낭비하고 있었던 것이다.
경험주의적 공정 제어 모델은 애자일 측에서 목에 핏대가 서도록 강조하는 것들이다. 빈번한 검사와 즉각적인 적응 과정. 이를 위해 항시 동작 가능한 제품을 만들고 고객과 직접 ‘이것이 원하는 것이 맞는가?’를 확인하고 조정하는 것이다.
전통적인 프로세스에서도 이를 간과하고 있지는 않다. 다만 그 중요성을 제대로 인지하지 못하고 충분히 강조하지 못하고 있었다고 말할 수 있겠다. 그리고 안타깝게도 내가 만나본 SE 전공자들 대부분은 스스로도 깨닫지 못하고 있어 잘못된 사상과 프로세스를 전파하고 강요하고 있었다.
Edge of Chaos | Agile Development Blog 에 Kanban 의 Cumulative Flow Chart 활용 예[1]가 실려서 옮겨본다.
(Kanban 에 대한 배경 지식이 전혀 없다면 One day in Kanban land [2] 를 먼저 읽어보고 오자. 흥미가 생긴다면 Lean and Kanban[3]의 글들을 시간을 두고 찬찬히 읽어보길 권한다.)
차트를 보면 우리가 12월 초에 병목을 겪었음을 볼 수 있다. 꾀 복잡한 유저 스토리 하나가 원인이었다. 이론적으론 유저 스토리 하나가 개발 주기에 심각한 영향을 미치거나 병목을 발생시키면 안되지만, 규칙을 조금 어기면 실제 그런 일이 일어날 수도 있다.
문제의 유저 스토리는 jQuery 자바스크립트 프레임워크를 ExtJS 프레임워크[6] 로 교체하는 것이었다. 이 작업은 개발자 한 명이 별도의 브랜치에서 1개월에 걸쳐 구현하였다. 그 한 달 동안 나머지 멤버들은 몇 차례의 릴리스를 성공적으로 마쳤다. 테스터들은 그 유저 스토리에서 별 문제점을 발견하지 못했고, 인수 테스트(acceptance test) 역시 모두 통과하였다. 이 코드를 메인 코드 브랜치에 반영하는 것은 당연한 수순이었고, 그렇게 했다.
불행히도, 코드 반영 후 스모크 테스트 중 꾀 많은 빌드 에러들이 발생하였다. 버그를 다 잡는데는 1주일 이상이 소요되었고, 그 동안 우리는 아무것도 릴리스하지 못했다. 이미 반영된 코드를 다시 롤백하는 것 역시 만만치 않았기 때문에 뾰족한 수가 없었다.
여기서 얻은 교훈은 근본적으로 보다 복잡한 유저 스토리에는 테스트에 더 많은 노력을 들이라는 것이다. 이런류의 스토리는 어플리케이션에 다방면에 걸쳐 영항을 미치고, 보통의 스모크 테스트만으론 충분치 않다. 그래서 우리는 병합 전에 더 세심한 테스팅과 검증이 필요함을 의미하는 새로운 부류의 서비스를 제공할 것이다. 일단 “기술적으로 복잡한 스토리”라고 불러보자.
일반적으로, Cumulative Flow 차트는 과거 데이터를 분석하는데 훌륭한 툴이긴 하지만, 긴급한 병목을 식별해 내는데는 Kanban Board 가 훨씬 효과적이다. Kanban Board 에서 최대 허용 작업 수(limit)에 도달함은 곧 무엇가 문제가 있음을 뜻한다.
쉬어가기[1]는 창의력을 끌어내는데 주안점을 두고 있고, 직접보기[2]는 생각을 현실화시켜 진정 원하는 것을 찾아가는데 초점을 맞추고 있다.
그리고 이제부터 살펴볼 수용하기는 변화를 권하고 받아들임으로써 개발자들에게 능동적 에너지를 불어 넣으려는 자세이다. 따라서 조직에서 권한을 쥐고 있는 윗사람들에게 크게 요구되는 자세이다.
조직에 변화를 불러 일으키려 할 때, 윗사람이 주도하는 하향식(top-down) 시도는 좋은 결과를 낳기 어렵다[3][4]. 특히나 한국처럼 수직적 위계질서가 철저한 문화에서는 윗사람의 지나가는 말 한 마디가 수십, 수백명을 고생하게 만들 만큼 파급이 크다. 심지어 조직 운명이 뒤바뀌기도 한다. 때문에 설사 올바른 말을 하더라도 확대 해석되고 준비도 없이 무조건적으로 즉시 수행하려해서 한 바탕 소동이 벌어지곤 한다.
효과적이고 지속적인 변화를 위해 윗사람에게 필요한 자세는, 변화를 겸허히 수용하고, 그런 분위기를 조성하고 문화를 만들어가는 것이다.
잠시 아쉬운 경험담을 하나 떠올려보겠다. 얼마전 수백명에 달하는 조직 구성원 전체가 모여 이것 저것을 공유하는 자리가 있었다. 그 중 임원들에게 궁금한 것을 여쭐 수 있는 시간이 주어졌고, 이런저런 이야기를 하다가 한 임원께서 조직의 변화에 대해 잠시 언급하셨다.
“조직은 쉽게 변하지 않는다. 조직이 변하길 기대하기보단 각자의 위치에서 스스로 변화시킬 수 있는 것을 찾아보아라.”
다소 차이가 있을 수 있으나 내가 이해한 의미는 이렇다. 현실의 모습을 있는 그대로 솔직히 이야기한 것이고, 남에게 바라기 앞서 스스로 변화를 시도하라는 좋은 이야기였다.
하지만 난 이 말에 적잖이 실망할 수 밖에 없었다. 왜일까? 만약 이렇게 이야기했다면 어땠을까?
“조직은 쉽게 변하지 않는다. 하지만 좋은 의견을 주면 내가 힘이 닿는데까지 그렇게 변화시킬 수 있도록 도와주겠다. 중간층에 있는 분들도 팀원들이 좋은 아이디어를 주면 최대한 반영할 수 있도록 힘써달라. 만약 내 힘이 필요하다면 누구든 도움을 요청하라. 다함께 힘이 닿는데까지 일할 맛 나는 팀을 만들어보자.”
조직은 쉽게 변하지 않는다는 사실엔 변함이 없다. 하지만 전자는 개인의 변화 의지를 크게 억누르는데 반해, 후자는 의욕을 한층 불살라줄 것이다.
중요한 것은.. 말과 격려에서 끝나면 안된다는 것이다. 불편사항을 누구든 편하게 개진할 수 있고, 개선 방법을 논의할 수 있는 장을 마련해 주어야 한다. 사람들이 쉽게 나서지 못한다면, 익명이 보장되는 토론장을 만들어주는 것이 큰 도움이 될 것이다. 애자일 회고(Retrospective) 제도[5]를 도입해 보는 것도 적극 권장한다. 그리고 이렇게해서 나온 좋은 아이디어들을 작은 것부터라도 하나씩 수용해가며 차근차근 개선되는 모습을 보여줘야 한다.
‘이봐들! 개선 아이디어를 가져와봐!’ 라고 강압하는 것은 좋지 않다. 이런 명령은 실무자들이 스스로 불편사항을 찾고 자율적으로 개선해나가는 분위기에 찬물을 끼얻을 우려가 있다. 단, 익명 보장 등 조치를 취해 주었는데도 아무도 의견 개진 없이 시간만 흐른다면 한 번쯤 발동을 걸어주는 것은 필요할 수 있다.
‘얼마나 개선되었는지 보고해봐!’ 와 같은 요청은 더 큰 위험을 안고 있다. CMMI 나 SPICE 등 개발 역량 평가 모델의 더 높은 등급을 받기 위해 벌어지는 상황이 재현될 가능성이 높다. 다시 말해 수치적으로 측정 가능하고, 형식적인 변화에 치중될 우려가 생긴다. 심할 경우, 개발자들은 변화에 회의를 느끼고 더 이상 적극적으로 참여하지 않게 될 것이다.
가만히 놓아 두어도 개발자들은 알아서 쓸데 없는 일과 꼭 필요하지만 귀찮은 일 그리고 수작업 등을 줄이고 생산성을 높이는 방향으로 변화시킨다. 더 효율적인 솔루션을 찾아 시도해보고 적용한다. 물론 시행착오를 거친다. 그래서 더 안좋아지는 부분이 생기면 되돌아가거나 다른 안을 시도해보며 결국 생각할 수 있는 최선의 방식으로 수렴해간다. 제도와 권위로 가둬놓지만 않으면 팀은 좋은 방향으로 진화해 나갈 수 있다.
STEN [1] 에서 재미난 설문을 하고 있다. 아직 진행중이지만 상황을 대략 파악할 정도는 나온 듯 싶다.
“국내 프로젝트에서 애자일을 도입했다가 실패했다면 그 이유는 무엇인가?” 1. 국내의 전반적인 소프트웨어 개발 프로세스 성숙도가 낮기 때문 (19.0%) 2. 과도한 애자일 프랙티스를 경험이 부족한 상태에서 여러가지를 동시에 적용하려 하기 때문 (25.4%) 3. 애자일한 개바 프로젝트에서 테스팅을 어떻게 해야할지 잘 모르기 때문 (9.5%) 4. 애자일 개발의 사상이나 이의 도입에 따른 개발 문화의 변화에 대한 고려없이 테크닉만으로 접근하기 때문 (44.4%) 5. 기타 (1.6%)
“국내 프로젝트에서 애자일을 도입했다가 실패했다면 그 이유는 무엇인가?”
1. 국내의 전반적인 소프트웨어 개발 프로세스 성숙도가 낮기 때문 (19.0%) 2. 과도한 애자일 프랙티스를 경험이 부족한 상태에서 여러가지를 동시에 적용하려 하기 때문 (25.4%) 3. 애자일한 개바 프로젝트에서 테스팅을 어떻게 해야할지 잘 모르기 때문 (9.5%) 4. 애자일 개발의 사상이나 이의 도입에 따른 개발 문화의 변화에 대한 고려없이 테크닉만으로 접근하기 때문 (44.4%) 5. 기타 (1.6%)
나는 4번을 찍었다. 물론 다른 이유들도 많다. 예를 들어 팀원 & 조직 전체가 변화의 필요성에 대해 공감한 상태에서 진행하느냐도 포함될 수 있다. 그리고 어느 하나의 이유보다는 여러 가지가 복합적이다.
나도 애자일 도입을 외치지만, 수많은 경험을 통해 아주 신중하게 접근해야 함은 뼈저리게 느끼고 있다. 어설프게 접근했다가는 ‘해봤는데.. 별 효과 없더라.’라는 부정적 인식만 남기기 쉽기 때문이다. 그리고 이는 소위 heavyweight 개발 프로세스 등 SE 가 지금껏 저질러왔던 과오이다. 애자일에서도 똑같은 일이 반복된다면 개발 문화를 개선할 수 있는 기회가 언제 다시 올 지 예측하기 어렵다.
‘쉬어가기.. 혁신을 이끌어내는 방법 [1]‘ 에서는 개발자들에게 쉬어갈 수 있는 시간을 제공함으로써 창의와 혁신을 이끌어는내는 이야기를 해보았다. 이번에는 ‘직접보기’라는 주제로 비슷한 이야기를 해보려 한다.
‘직접보기’ 가 필요한 이유는 아래의 그림을 보고 생각해보자. 이 그림이 말하고자 하는 원목적은 완전히 동일하진 않지만, 실물을 보지 않고 커뮤니케이션 했을 때의 문제를 효과적으로 말해주고 있다.
정리하면 고객이 원하는 것을 각 사람/조직마다 다르게 이해하고 있으며 심지어 고객 스스로도 자신이 무엇을 필요로 하는지 알지 못한다 것이다.
시장 조사를 토대로 고객의 needs 를 모두 만족시킨 제품의 출시 후 반응이 그리 좋지 않은 수많은 사례들을 잘 설명할 수 있는 논리이기도 하다.
혁신적인 제품을 잘 만들어내기로 유명한 애플(Apple)사의 경우, 신제품을 만들 때 시장 조사를 아얘 하지 않는 것으로도 유명하다(You Can’t Innovate Like Apple [2]). 시장에 존재하지 않는 제품에 대해 물어봐야 가치 있는 대답을 구하기 어렵기 때문이다. 대신 스스로 계속해서 실제품 수준의 프로토타입을 수없이 만들어보면서 직접 만져보고 써보며 자신들이 정말 이 제품을 원하는가를 판단한다. 그 결과 애플의 제품들은 종종 시장에서 당연히 필요하다고 생각하는 기능이 빠지기도 하고 이미 더 나은 제품들이 수두룩한데~ 라고 평가절하되곤 한다.
이미 만들어진 제품에 대해서는 다르다. 직접 사용해본 사용자들의 피드백은 소중하다. 애플 리테일 스토어가 중요한 역할을 수행하는데, 리테일 스토어의 직원들은 고객이 와서 들려준 이야기들을 놓치지 않고 본사로 보고하게 되어 있다. 그래서 스티브 잡스는 아이디어 도둑(유명 마케터 이해선 대표의 메시지 [3])이라는 말이 나오기까지 했다.
고객의 소리를 듣는 방식에 있어 두 경우가 다르다고 이야기했지만, 사실 그 원리는 동일하다. 바로 제품을 직접 만져보고 사용해본 사람들의 소리를 듣는다는 것이다.
이는 사실 애자일, 전통 할 것 없이 거의 모든 소프트웨어 개발 방법론에 중요하게 다루는 주제이고, 결론 또한 항시 동일하다. 짧은 반복 주기로 매 주기마다 동작 가능한 제품을 내놓고, 이를 고객에게 보여주고 피드백을 받는다. ‘당신이 말한 것을 우리는 이렇게 이해했는데, 이것이 정말 당신이 원했던 것이오?’ 를 확인하는 가장 중요한 절차인 것이다. 진정 공존을 원한다면 이 과정에서 쓸데없는 과장과 화려한 프리젠테이션은 없어져야 한다. 그리고 프로젝트 진행에 관련된 주요 인력들이 다 참석하는 것이 좋다. 고객, 프로젝트 리더, 영업 담당자, 주요 개발자들 등이 포함된다. 이들이 자주 모여 현실을 냉정하게 보고 허물없는 이야기를 하다보면 다음과 같은 반응들을 심심치 않게 목격할 수 있을 것이다.
직접 보기는 서로의 생각을 확인하고 공유할 수 있는 가장 좋은 방법이며, 다음 방향을 결정짓기 위한 논의를 시작하기 위한 믿음직한 베이스가 되어준다.
또한 개발자들에게는 자신들의 창의력과 열정을 어필할 수 있는 절호의 기회가 되기도 한다. 직접 구현하면서 가장 먼저 써보게 되는 개발자들은 가장 빠르게 피드백을 줄 수 있는 훌륭한 고객인 셈이다. 이해한 요구사항대로 구현했을 시 불편한 부분이 있거나 더 나은 안이 떠오르면 릴리즈 전에 그 아이디어를 정리해두자. 가능하다면 직접 구현해서 보여주는 것이 가장 좋다. 직접 사용해본 고객과 말이나 문서 정도로만 본 고객은 확연히 다른 반응을 보인다.
이런식으로 개발자들의 능력을 인정받고 발언권을 강화해두는 것이 조직 전체의 커뮤니케이션과 생산성 향상, 제품 혁신에 긍정적인 영향을 줄 것이다. 개발자들은 기본적으로 창의적인 인력들이며, 이에 더해 현실적이다. Sci-fi 영화에나 나올 법한 허무 맹랑한 꿈을 꾸지도 않고, 일부러 과장하려는 경향도 적다. 먼 과거와 달리 골방의 괴짜들이 모여 있는 집단도 아니다. 윗사람들보다 신세대이며 소비의 주체라는 장점도 있다.
결론?
조직은 제품을 직접 보고 함께 이야기하는 문화를 정착시킴으로써 많은 것을 얻을 수 있다. 단, 어설프게 릴리즈 압박용으로만 오용하지 않도록 주의하자. 상향식 변화는 실패할 것이며, 하향식 변화는 성공한 것 처럼 보일 것이다. ^^ [4]
[updated]
사례를 몇 가지 추가해보기로 하였다.
