기본 콘텐츠로 건너뛰기

9월, 2009의 게시물 표시

한계를 넘어서

한계를 넘어서 - 엘리 골드렛 지음, 이정숙 옮김, 함정근 감수/동양문고 이 책도 역시 TOC를 통해서 프로젝트 경영, 납기, 예산, 내용 준수에 대한 소개를 하고 있는 책이다. 이 책은 골드랫 시리즈 중 3번째 책이다. 우리는 프로젝트를 진행하면서 납기를 얼마나 잘 맞추고 있을까? 추정은 얼마나 잘 하고 있을까? 소프트웨어 개발 프로젝트를 진행하면서 출시일에 정확히 예산 초과없이 제품을 출시해 본 경험이 얼마나 있는지 가슴에 손을 얹고 생각해 보기 바랍니다. 이러한 문제를 풀기 위해 수도 없는 방법론이 나오고 있고 최근에 유행하는 Agile이나 Lean은 이것을 요구사항을 조절함으로써 달성하려고 하고 있다. 하지만 TOC의 CCPM은 과감하게 어떤 요구사항의 변동 없이 정해진 기간에 정해진 예산으로 소프트웨어 개발 프로젝트를 완수할 수 있다고 주장하고 있다. 믿어지는가? 믿을 수 없다면 지금 서점에서 이 책을 구입해서 꼭 읽어보는 것을 추천해 드린다. 만약 잘 이해가 되지 않는다면 미약하나마 도움을 줄 수도 있으니 연락을 주시기 바란다. 솔직히 CCPM을 배우고 알고 있는 나지만 그 효과가 진정으로 있는 것인지 확인해 보지 못한 것이 아쉬울 지경이다. 혹시 이 무모한 도전에 도전하고 싶으신 분은 기꺼이 연락을 주시면 고맙겠습니다. 어찌 됐든 이 책 역시 5점 만점에 4.5점을 허하는 바이다. 솔직히 이 책은 아직 공감이 잘 가지 않는다. 비 물리적인 부분을 개념적으로 다루는 것에 있어서 이해력이 떨어지는 필자의 무지함에 통탄을 금치 못할 뿐이다. ㅠㅠ

신기술 도입의 함정

신기술 도입의 함정 - 엘리 골드렛 지음, 이정숙.정남기 옮김/동양문고 이 책은 TOC를 기반으로 ERP/SCM/물류 그리고 정보기술의 활용방안을 소설 형태로 소개하고 있는 책이다. 골드랫 저서들의 특징은 소설 기반으로 매우 빠르게 몰입할 수 있도록 하는 것이 장점이다. 하지만 소설 형태를 취하다 보니 실무적이거나 이론적인 배경에 접근하는 것이 생각보다 어려운 경우가 많다. 이 책은 매우 얇다. 거기다 소설 형태이기 때문에 매우 빠르게 읽을 수 있다. 하지만 우리가 소설을 읽고 나면 머리가 아주 깨끗하게 아무것도 기억이 나지 않는것과 마찬가지로 매우 어려운 내용임에도 매우 빠르게 읽을 수는 있었지만 책을 덮고 나면 그래서 뭐가? 라는 의문만 남는다. TOC가 무엇인지? 이 책에서 무엇을 말하고 싶었던 건지? 핵심이 무엇인지? 때문에 처음에 가볍게 읽더라도 나중에는 꼭 부분 부분 꼭꼭 씹어서 읽어볼 것을 추천해 드린다. 이 책은 꼭꼭 씹을 수록 우리가 기존에 이해하고 있던 많은 부분에 있어서 상식적이고 당연하다고 여겼던 부분들을 논리적이고 차분하고 훌렁 뒤집어 준다. 이 책을 읽고 기억에 남는 것은.. 우리가 어떤 제품을 팔 때 우리가 과연 고객에게 실질적인 가치를 제공하며 팔았던 적이 있던가? 라는 의문이다. 예를 들어 우리는 어떤 제품을 팔 때 겁나 빨라요, 최신이에용, 뽕빨나요, 정보를 한 눈에 볼 수 있어요 등등 온갖 미사여구로 포장하지만 그것이 과연 정작 고객에게 어떤 이익을 가져오는지 잘 전달하지 못하거나 아예 알지 못하는 경우가 많다. 분명 책의 시작은 ERP 시스템이었지만 후반부에는 마케팅에 대한 고민도 같이 나온다. 자신의 제품이 고객에게 어떤 가치를 제공해야 하는지 그 방법은 어떻게 접근해야 하는지에 대한 의문이 있는 모든 사람들에게 이 책을 추천하는 바이다. 개인적으로 이 책에 5점 만점에 4.8을 허하는 바이다.

SOS 죽어가는 프로젝트 살리기

SOS! 죽어가는 프로젝트 살리기 - E.M. 베나탄 지음, 박재호 옮김/에이콘출판 드디어 다 읽었다.. 완변한 컨설팅 이후로 이처럼 읽기 힘든 책은 없었던 같다.. 머 앞으로도 분명 읽기 힘든 책이 무수히 많겠지만... 최근 들어 읽기 힘든 책을 2권이나 읽었더니 진이 다 빠지는 느낌이다.. 왜? 이 책이 읽기 힘든가? 어려운가? 어렵지 않다.. 매우 상식적인 이야기를 하고 있다. 문제는 이 책을 읽어야 할 대상이 내 개인적인 생각으로는 매우 애매모호할 수 있을 것 같다. 초보자에게는 이 책은 매우 갑갑한 책이 될 가능성이 있다. 왜냐하면, 실제적인 해결책을 제시하지는 않기 때문이다. 어떻게 해야 한다는 얘기만을 하고 있을 뿐, 구체적인 이야기는 쏙 빠져 있다. 내가 읽으면서 가장 싫었던 해결책은 '선도관리자에게 지원을 요청한다.' 였다. 누가 모르냐고.. 그걸 얻어내는것이 간단할까? 반면 고급자에게는 이 책은 너무 당연한 얘기이다. 어떤 사람들은 이미 몇번의 프로젝트 복구를 해본 경험도 있을 것이다. 그런 사람들에게도 이 책은 갑갑할 것 같다. 이 책은 가이드 북이지 실전서는 아니라고 결론을 내리고 싶다. 각 장 끝부분마다 생각해 볼 문제도 제시하고 있지만 혼자서 풀기 매우 어려운 문제들 뿐이다. 만약 이 책을 읽고자 하는 사람들이 있다면 꼭 여러 사람들과 스터디를 통해서 읽는 것을 추천해 주고 싶다. 그렇다고 이 책을 읽을 가치가 없는 것은 전혀 아니다. 이 책은 프로젝트가 재난에 빠지기 전에 가능하다면 프로젝트를 시작하기 전에 꼭 읽었으면 하는 책임에는 분명하다. 우리는 너무나 당연한 사실을 쉽게 잊어먹는다. 그러지 않기 위해 프로젝트를 시작하기 전 다시 한번 자신을 돌아보고 프로젝트 성공을 위한 체크리스트로서 이 책의 가치는 무척 소중하다고 생각한다. 이 책을 읽는 내내 처음에는 왜 이 순서에 따라 프로젝트를 복구해야 하는가? 라는 의문과 질문에 끊임없이 시달렸다. 하지만 마지막 책장을 넘기면서 전체를 바라보니 이 책은 매우 논리적이고

프로젝트 재난 평가 - 예산

SOS! 죽어가는 프로젝트 살리기 - 2장 생각해볼 문제를 통해 프로젝트 재난 평가에서 예산에 관한 부분을 생각해 보도록 하자.. 된장.. 난 일정과 예산 둘다 닭인데.. 이녀석은 이해하는데 더욱 더 오래 걸렸다... 문제는 내 맘대로 바꾸어서 생각해보도록 하겠다. 우선 표부터 보도록 하자. 단계  단계예산초과율(%)  누적예산초과율(%)  초과비율(%)  단계별할당예산 누적할당예산 단계별예산초과액  누적예산초과액  추가필요예산액  1  0  0    5  5        2  0  0    7  12        3  0  0    11  23        4  0  0    16  39        5  20  2    16  55  3.2  3.2  280  6  50  6 266  17  72  8.5  11.7  254.5  7  80  13 123  18  90  14.4  26.1  222.1  8  80  21 61  20  110  16  42.1  186.1  9  100  32 52  22  132  22  64.1  142.1  10  100  45 39  25  157  25  89.1  92.1  11  110  58  31  25  182  27.5  116.6  39.6  12  120  69 19  18  200  21.6  138.2   금액 단위는 천만원으로 가정하였다. 여기서 살펴볼 것은 두가지다.. 하나는 초과비율이고.. 다른 하나는 추가필요예산액이다. 이 예산의 경우도 기본적인 관점은 이전의 일정과 같다. 각 단계별로 예산 초과율을 살펴 본다면 대략 7에서 9단계정도까지라면 대부분의 조직에서는 프로젝트의 진행에 대해 심각하게 고민하게 될 것이다. 실제 들어갈 예산에 비해 9단계부터는 거의 2배의 비용이 들어가고 있다. 이런 경우 정말로 이 프로젝트는 재난에 직면한 것일까? 예산을 다시 산정하거나 프로젝트를 포기해야할 정도로 심각한 상황인것일까? 이 프로젝트는 4단계까지는 예산 초과가 없었다. 이후 예산 초과가 발생하였고

프로젝트 재난 평가 - 일정

우선 이 글을 읽기 전에 'SOS! 죽어가는 프로젝트 살리기' 도서를 먼저 구매해서 꼭 필독하기를 바라는 마음이다. 아래 글은 SOS! 죽어가는 프로젝트 살리기 - 2장 생각해볼 문제 1번(정답도 없다.. ㅡㅡ 곤란해.. 스터디 하자고 해볼까?)에 대한 내 개인적인 이해와 생각이 혼재된 글들이기 때문에 책에 대한 부정적인 이미지를 심어주어 원 저자와 번역자에게 누를 끼치고 싶지 않다. 하여.. 혹여 내 글을 읽고 책 자체를 폄하하고 싶으신 분들은 그 전에 꼭 책을 구매해서 읽어보기 바란다. 그래야 내 글에서 내가 왜 이런 생각을 하게 되었는지 이해할 수 있으리라고 여겨지는 바이다.. 사설은 여기까지고.. 자 문제를 까볼까나? 문제의 요점은 일정 지연에 대해 종합적으로 판단하여 프로젝트에 대하여 경보를 발령할 것인가를 묻는 문제이다.. 이런거에 워낙 약한지라.. 이 문제 풀기 위해 2장만 한 5번은 읽었다.. 머리가 닭인건지.. 그런데도 솔직히 이 해답에 대해 확신이 없다. 혹시 이 책을 읽고 이 문제가 너무 쉬웠던 분들은 꼭 트랙백으로 우매한 필자를 영면의 세계로 인도해주길 바라는 바이다. 어쨌든.. 총 12단계중 현재 상태는 7단계이고 그 상태를 다시 정리한 표는 아래와 같다..  단계 누적 초과율(단계별 %) 경과된 일정 대비  전반적인 프로젝트 초과  1 0% 0% 0%  2 -30% -15% -18%  3 0% 0% 0%  4 40% 10% 3%  5 60% 12% 5%  6 100% 16.7% 8.3%  7 200% 28.6% 16.7%  8        9        10        11        12       자.. 하나씩 살펴보도록 하자. 일정 지연은 우리가 프로젝트에서 아침밥보다 더 자주 겪는 일이다. 이유가 여러가지겠지만.. 일정대로 개발하는 경우는 정말 손에 꼽는다. 머리가 단순한 관계로 책에서는 18개월 일정이었지만 12개월짜리 추정을 한 프로젝트로 가정을 바꾸어 생각해 보도록 하겠다. 그렇다면 각 단계는 1달짜리

완벽한 컨설팅

완벽한 컨설팅 - 피터 블록 지음, LGCNS 엔트루 컨설팅 외 옮김/인사이트 완벽한 컨설팅이라니.. 책 이름이 너무 건방지다.. 그런데 책 서문에도 그러한 글이 실려 있다. 이 책은 정말 두껍다.. 라면 받침 뿐만 아니라 베개로도 쓸 수 있을 정도로 두껍다.. 읽는 것 또한 고역이다. 이해하기 힘든 부분도 있고.. 이게 정말 가능한것인가? 라는 부분도 있고 너무 원론적인 부분이나 당연한 부분들도 있다. 하지만 인내의 시간을 갖고 책의 마지막을 덮으면서 느끼는 것은.. 그냥 막연하게 컨설팅이라는 것에 대한 느낌만 갖고 있던 과거에서 높은 산 정상에 올라 산 전체를 바라보는 그런 상쾌함이었다. 컨설팅의 모든 과정에 대해 다시 한번 전체적인 시각을 가질 수가 있었다. 이 책은 한번 읽어서는 그 뜻을 파악하기 힘들다. 어느 정도 컨설팅의 경험(실패한 경험이 많으면 더 좋을 듯..)이 있는 사람이 자신의 컨설팅을 돌아보고 새로운 방향을 찾고자 할 때 꼭 추천해 주고 싶은 책이다. 처음 읽을 때는 정말 고통스럽다. 하지만 몸에 좋은 약은 입에 쓰듯이. 천천히 곱씹고 곱씹어서 마지막 챕터에 도달하면 책 전체를 다시 한번 정리해 준다. 이 부분에서 그동안 힘들게 왔던 그 여정을 다시 한번 돌아보면 자신의 시야가 한층 더 넓어진 것을 느낄 수 있을 것이다. 그리고 다시 한번 더 읽는다면 또 다른 느낌으로 읽을 수 있다. 꼭 컨설팅 회사에서 일해야만 컨설턴트는 아니다. 우리는 일상 생활에서 알게 모르게 컨설팅을 수행하고 있다. 때문에 이 책은 꼭 컨설턴트가 아니더라도 누구나 읽을 수 있다고 생각한다. 특히 관리자나 컨설턴트로 이직을 꿈꾸는 사람에게 추천하고 싶다. 개인적으로 별 5개 중 4개 반을 수여하는 바이다.

xper 9월 정기 모임에 다녀와서..

7월부터 매달 한번씩 진행되고 있는 xper 9월 정기 모임에 다녀왔습니다. 이번 모임은 Agile Conference 에 다녀온 3분의 생생한 후기담을 공유하는 자리가 되었습니다. 후기를 들으면서 드는 생각은.. 아~~ 나도 한번 가보고 싶다는 것이었습니다. 특히 Agile 2008에 몰려온 일본인들 얘기를 들으면서 우리도 저래야 할텐데.. 하는 생각과 함께.. 제안해 주신 한중일 연한 컨퍼런스도 못할 것 없지 않은가? 라는 생각이 들었습니다. 마지막에 Kanban Game을 했습니다. 전 Scrum에서 사용하고 있는 Daily Board나 Scrum-ban과 Kanban을 잘 구별하지 못했었는데.. 이 게임을 통해 Kanaban을 조금이나마 이해하게 되었습니다. 이 게임을 하면서 느낀건 이 칸반이 TOC의 개념과 매우 흡사하다는 것이었습니다. 다만 칸반에서 아쉬운 것은 역시 각 팀의 작업 효율이 다를 경우 작업 효율이 우수한 팀은 해당 팀의 작업 효율이 높지 않을 수 있다는 것이었습니다. TOC는 이런 경우 Pull과 Push를 적절히 섞어서 해결을 하는데.. 칸반도 그러한지 다시 한번 더 관련 자료를 살펴봐야겠습니다. Pull과 Push는 어설프지만 제가 이전 포스트 에서 정리를 한번 했었는데.. 나중에 한번 더 정리를 해야할 것 같습니다. Lean과 TOC는 서로 특성이 비슷해서 혼합하려는 시도가 여럿 있었는데. 이번에 저도 그런 느낌을 강하게 받았습니다. 이것 역시 언제 한번 정리를 해봐야 할 것 같습니다. Kanban Game 에 대한 자료는 아래 링크에 있습니다. http://yattom.jp/trac/public/wiki/ProjectGames/TheKanbanGameEn 이 게임을 하면서 내가 속했던 조의 중간 회고는 아래와 같이 나왔습니다. 좋았던 점으로는 병목현상을 알 수 있었다. 프랙틱스를 쉽게 익힐 수 있었다. 재미있었다. 안좋았던 점으로는 게임처럼 팀안에서 Role을 쉽게 바꿀 수 있을까? 스토리카드의 속도보다 주사위의 숫자가 매번 크

국내 유일의 테스팅 잡지 testers insight vol 4

국내에 테스팅 잡지로는 내가 알기로는 유일하게 나오는 잡지가 하나 있다. 이름하여 testers insight 이 잡지는 계간지로 1년에 4번 나온다. 즉 3개월에 한권씩.. 두께도 제법 얇다.. 하지만 내용은 국내에서 구하기 힘든 테스팅 관련 자료들이 가득하다. 만약 당신이 QA나 테스터라면 필독해야할 잡지 중 하나이며, 소프트웨어를 개발하고 있는 관련자라면 필독해야할 잡지 중 하나인 것이다. 그러고 보니 이번호가 1주년 기념 아니었나? 확인해 봐야겠넹.. 이벤트도 없어.. 커헐.. 이번호의 주제는 아시아의 테스팅.. 즉, 아시아 주요 국가들의 테스팅에 관해 소개하고 있다. 그 외에도 여러 기사들이 들어있다. 특히 올해에는 외국의 여러 유명한 테스터들이 국내를 방문했고 국내에서도 외국의 많은 컨퍼런스에 참여했던 한해였는데 관련된 기사들이 그득 담겨있다. 내가 가장 기대하고 있는 세미나는 다음달에 있을 ISO/IEC 29119 의 워킹 그룹 WG26의 위원장을 맡고 있는 스튜어드 레이드의 ' 애자일 개발 프로젝트에서의 애자일 테스팅 '이 되겠다. 관련해서 스튜어드가 직접 쓴 글도 이번 잡지에 실려 있다. 이러한 알찬 잡지의 내용이 궁금하신 분은 지금 구독해 보시기 바란다. 가격도 단돈 9900원으로 매우 착한 가격이다. Just click!!!

Agile과 Waterfall

현재 소프트웨어 개발 모델을 대표하는 모델을 선택한다면 Waterfall과 Agile을 들 수 있습니다. Agile은 일부에서는 점진적-반복적 개발모델이라고도 하죠. 저는 이 두 모델을 조금은 다른 시각에서 바라보도록 하겠습니다. Push 개발 방식과 Pull 개방 방식입니다. Push 개발 방식은 일방적인 전달을 특징으로 합니다. Waterfall 이 대표적인 Push 개발방식이라고 볼 수 있습니다. Push는 미국의 포드에서 시작된 경영방식입니다. 그래서 미국식이라고 불립니다. Push 방식에서 추구하는 것은 효율입니다. 각 부분의 효율을 얼마나 끌어올리는가에 초점을 맞춰서 최적화를 진행합니다. 이 방식은 각 부분 부분이 비슷한 능력치를 가질 때 최대한의 성과를 낼 수 있습니다. 만약 전체 중 특정 부분의 능력이 떨어진다면 그 부분에서 지연이 발생하고 이것은 많은 손실을 내게 됩니다. 아래 그림에서 보면 A의 경우에는 Push 방식으로 작업을 진행해도 아무런 문제가 되지 않습니다. 하지만 두번째 단계의 효율은 50%이기 때문에 두번째 단계의 효율을 100%로 끌어올리게 됩니다. 그렇게 되면 그림 B와 같이 마지막 공정에서 전 공정에서 밀려온 일을 모두 처리할 수 없기 때문에 재고가 쌓이게 되고 이것은 일정의 지연이나 금액의 손해 등을 불러 일으키게 됩니다. 각 부분의 효율은 100%가 되었지만 생산 효율의 불균형으로 인해 열심히 일은 하고 있지만 계속해서 손해가 발생하는 상황이 되었습니다. 전체를 바라보지 못한 부분 최적화의 폐혜입니다. 위의 경우를 소프트웨어 개발로 생각해 보면 마지막이 테스팅 팀이 될 것입니다. 일반적으로 테스팅 팀은 요구사항 단계에서 배제되는 경우가 많습니다. 이러다 보니 요구사항에 대응하기 위한 자원 등의 배정등에서 우선순위가 밀리게 됩니다. 때문에 나중에 문제가 발생하여도 대처하기가 힘듭니다. Pull 개발 방식은 후공정에서 필요한 만큼 전공정에서 요구하는 방식으로 낭비(재고)를 줄이는 것을 목적으로 합니다. 대표적인 곳이 도요타로

생산성 지표 - 효과와 효율

생산성에 대한 패러다임에 대해 생각해 보도록 하자. 아래 그림을 보도록 하자. 앞부분의 화살표는 요구사항, 중간의 녹색 원통은 개발팀, 마지막 파란 원통은 테스팅 팀이라고 가정해 보자. A의 경우에 개발팀은 10의 요구사항을 개발할 수 있는 능력이 있지만 요구사항은 5만 들어오고 있다. 개발팀만을 생각한다면 현재 개발팀의 생산성은 50%이다. 반면에 테스팅 팀은 5만큼의 개발 결과물을 테스팅 할 수 있고 개발팀으로부터는 5만큼의 개발 결과물이 만들어지고 있기 때문에 테스팅 팀의 생산성은 100%이다. 따라서 전체 프로젝트의 생산성은 75%이다. B의 경우에는 개발팀은 100%의 생산성을 테스팅 팀 역시 100%의 생산성을 보인다. 반면에 테스팅 팀은 5의 능력뿐이지만 개발팀에서는 10만큼이 오고 있기 때문에 언제나 5의 재고가 쌓여있게 된다. 하지만 전체 프로젝트의 생산성은 100%이다. 당신은 어떤 팀이 더 훌륭한 팀이라고 생각되는가? A팀은 효과적인 팀이라고 한다. 여기서 효과라는 것은 목표 달성율을 말한다. A팀의 경우에는 모든 요구사항과 모든 개발 결과물을 처리하고 있기 때문에 할당된 모든 목표를 달성하고 있다. B팀은 효율적인 팀이라고 한다. 효율이라는 것은 자원 활용 능력을 말한다. A팀의 개발팀의 경우는 자원 활용율은 겨우 50%이다. 반면 B 팀은 모든 팀의 자원 활용율이 100%이다. 우리는 일반적으로 효과보다는 효율적인 팀에 집중한다. B팀은 개발팀의 결과물을 테스팅 팀에서 모두 소화하지 못하고 만성적인 지연에 시달리고 있다. 이럴 때 많은 경우 테스팅 팀은 계속되는 야근과 철야 등으로 자원 활용율을 200%로 올리는 방식으로 최적화를 하게 된다. 이게 정말 좋은 방식일까? 여기서 생각해 볼 개념은 TOC의 Throughput, 투자, 운영비용 이다. 쓰루풋은 Input 대비 Output의 비율이다. TOC에서는 개선을 할 때 투자와 운영비용의 추가 지출을 지양한다. 추가 지출을 하더라도 투자와 운영비용의 합이 쓰루풋보다 반드시 작아야 한다.

TMMi 심사 및 Test Process Improvement 제안 세미나 후기

얼마 전 국내에서 처음으로 공식 TMMi 심사가 있었다. Rob Hendriks 이라는 선임 심사원이 직접 한국에 와서 1주일간 심사를 진행하였다. 이번 심사를 보면서 가장 맘에 드는 것은... 인증을 받는 업체를 미리 준비시키지 않았다는 것이다. 국내에서는 인증을 받기 위해서 프로젝트 팀을 꾸리고 문서를 후다닥 만들어서 인증을 받고 나면 그 인증이 전사차원에서 받은 인증인 것처럼 떠벌리고 다니면서 인증에 대한 신뢰도를 바닥으로 만드는 횡포가 심했던 것이 누구나 알고 있는 사실이다. 난 그래서 CMMI같은 걸 믿지 않는다. 적어도 국내에서는.. 더 재미있는 것은 대형 SI와 같은 업체에서는 모기업이나 자회사를 통해 심사 기관을 지정 받은 뒤 저희들끼리 짜고 치는 고스톱 마냥 인증을 찍어내는 경우도 있었다. 이번 심사에서도 인증 업체에서 무엇을 준비해도 되는지 Rob에게 무척이나 많이 물어봤던 모양이다. 그리고 아무런 코멘트도 해주지 않는 것에 대해서 은근히 불만이 많았던 모양이다. 덕분에 결론은 어떻게 나올지 모르겠지만 인증업체는 무척 고생한 듯 하다. Rob의 얘기로는 실제로 테스팅 프로세스를 적어도 6개월 이상 수행해야만 인증을 받을 수 있을 것이라고 했다. 그말인즉, 꾸미지 말고 위조하지 말고 있는 그대로를 평가 받고 인증을 받으라는 얘기일 것이다. 그것은 곧 인증을 준비하는 업체는 그만큼 테스팅과 TMMi에 대해 정말 많이 알고 이해를 깊게 하고 있지 못하다면 인증을 받기 힘들다는 얘기가 될 것이다. 덕분에 몇몇 단점에도 불구하고 TMMi에 대한 신뢰도가 쑥쑥 커졌다. 그리고 앞으로 혹시라도 TMMi 인증을 생각하고 있는 업체가 있다면 테스팅 프로세스 구축에 대해 정말 많이 배우고 이해를 깊이 있게 해야할 듯 하다. Rob은 아래 3가지를 강조했었다. 왜 하느냐? 어떻게 하느냐? 그러한 프로세스들의 관계는 어떠한가? (추적성 같은 개념인듯 하다.) 우리가 실제로 프로세스를 구축하면서 쉽게 생각하지 않던 부분들에 대해 많은 고민을 해야 할 듯 하다.

누적 결함 S 커브

'SOS! 죽어가는 프로젝트 살리기'에서 프로젝트 재난 여부 평가는 일정, 예산 그리고 마지막으로 품질이다. 그런데 테스팅 에반젤리스트로서 이 책의 품질에 대한 측정보다는 아래에서 소개하고자 하는 '누적 결함 S 커브'가 더욱 더 효과적일 듯 하다. 머 판단은 책을 읽고 이 글을 읽는 여러분이 판단할 문제이긴 하다. 우선 책에 있는 문제를 내 맘대로 수정해 보았다. 아래 표를 보도록 하자. 단계  사소한 문제      심각한 문제     치명적 문제     신규 수정 잔존 신규 수정 잔존 신규 수정 잔존 1       2 12   12 2    2   3 18 10 20 3 1  4 2    2 4 13 15 18 4 2  6 2    4 5 15 13 20 1 3  4 3 1  6 6 15 20 15 8 4  8 4 1  9 7 31 18 29 10 6  12 1 2  8 8 42 25 46 16 8  20 9 3  14 9                   10                   11                   12                   위 그래프를 각각의 심각도 별로 그래프를 그리면 아래와 같다. 그래프를 읽는 법은 특정 심각도의 신규 결함과 수정된 결함을 누적하여 그린 후 두 곡선 사이의 가로 간격이 결함을 수정하는 데 걸린 시간이고 세로 축이 특정 시점에서의 잔존 결함이다. 위 그래프를 보면 현재 이 프로젝트는 심각하다. 지금 당장 경보를 울려야 할 상황이다. 이유인즉 모든 심각도에서 결함이 계속해서 발견되고 있다. 문제는 발견된 결함의 수정 활동이 사소한 문제에 집중되어 있지만 신규로 발견되는 결함을 모두 처리하지 못하고 있다. 더 심각한 것은 치명적 결함이다. 결함이 수정되는데 적어도 3단계의 기간이 필요하다. 그리고 잔존 결함이 전혀 줄어들지 않고 있다. 책에서도 결함이 수정된 것은 문제 목록에서 제거해야 한다고 적혀 있긴 하다. 하지만 단순한 표만으로 현재 결함의 증가 추세와 결함을 해결

오픈웹 논란에 대한 단상..

한국 웹의 불편한 진실 - 김기창 지음/디지털미디어리서치 이 글은 김기창 교수님의 '한국 웹의 불편한 진실'을 읽은 후 개인적인 생각에 관한 글입니다. 오픈 웹 운동이 있습니다. 김기창 교수님은 법정까지 가셨죠.. 이 사건에 대한 반대 여론도 만만치 않습니다. 논란의 진실은 혼미하기 이를데가 없습니다. 누가 진실을 말하는 것인지, 어디까지가 거짓인지 일반인은 판단하기 무척 어려운 실정입니다. 어떤 분에게는 왜 이런 것이 논란이 되는지조차 이해가 가지 않기도 합니다. 많은 부분의 논란의 가운데에는 액티브 엑스와 금융기관의 보안이 있습니다. 하지만 제 개인적인 의견으로는 이런 지엽적인 문제를 넘어서 우리의 IT 생활 자체를 돌아보아야 하지 않을까? 합니다. 솔직히 저로서도 무엇이 옳다라고 판단을 내리기 힘들 지경입니다. 우선은.. 1. 표준이 현재 변화 속도를 따라가지 못한다라는 의견이 있습니다. 당연합니다. 표준은 무수히 많은 이해 관계자의 협의에 의해서 탄생합니다. IEEE가 802.11n을 표준으로 인증하는데만 7년이 걸렸습니다. 하지만 기술에 관한 표준이라면 전 따라야 한다는 것이 제 생각입니다. 표준이 없었을 때 임시방편으로 구현한 경우라도 표준이 생겼다면 표준을 따라 재구축해야한다고 생각합니다. 물론 비용이 듭니다. 그렇기 때문에 임시방편으로 구현할 때는 추후 재구축할 비용을 반드시 염두에 두어야 한다고 생각합니다. 2. 금융 서비스를 이용할 때 익스플로러를 사용하면 된다고 합니다. 어떤 사람들은 리눅스나 맥 같은 운영체제를 사용하는 사람들에게 윈도우 한카피씩 사주면 된다고 주장합니다. 이들의 주장의 밑바닥에는 운영체제는 윈도우 브라우저는 익스플로러를 사용하면 되지. 왜? 다른 것을 사용하느냐? 라는 말입니다. 이것이 과연 옳은 것일까요? 전 이루어질 수 없는 꿈을 생각합니다. 모든 어플리케이션의 운영체제의 종속성에서 벗어나는 세상을 생각합니다. 만약 제가 포토샵을 산다면 윈도우나 맥이나 리눅스를 고민하지 않고 어디서나 설치해서 사용할

저항의 극복, 갈등의 해소

우리는 많은 경우 변화를 겪습니다. 그리고 변화에는 항상 저항을 하는 사람이 생깁니다. 그리고 저항을 하는 사람과 변화를 추진하는 사람 사이에는 항상 갈등이 생깁니다. 우리는 일반적으로 갈등을 해소하는 방법으로 아래와 같은 방법들을 사용합니다. 줄다리기, 강요, 포기, 회피, 타협 이러한 방법들의 공통점은 누군가는 좌절감과 분노를 느낀다는 것입니다. 이러한 방법들을 사용하게 되면 갈등은 해소되지 못하고 임시방편으로 봉합되었다가 훗날 알 수 없는 곳에서 폭발하게 됩니다. 결과적으로 누군가는 회사를 떠날 수도 있고 프로젝트가 실패할 수도 있고 회사가 경제적인 피해를 입을 수도 있습니다. 이러한 저항을 극복하고 갈등을 극복하는 방법은 기존에 정말 많은 방법들이 있습니다. 그러한 방법 중 하나가 TOC 이론의 TP(사고 프로세스) 중 증발구름이라는 것이 있습니다. 예를 하나 들어보도록 하죠. 여기 어떤 조직이 있습니다. 이 조직은 새로운 프로세스를 도입하고자 합니다. 애자일 프로세스가 될 수도 있고, 테스팅 프로세스가 될 수도 있습니다. 하지만 기존 관리자들의 반발이 만만치가 않습니다. 어떤 분들은 그냥 위에서 까라면 까는거지.. 라는 분들도 계시겠지만 앞에서 말했듯이 그렇게 해서 새로운 프로세스를 도입한다고 해도 그 프로세스가 정착할 리 없습니다. 이러한 경우를 증발 구름으로 만들어 보면 이러한 모양으로 만들 수 있습니다. 그림이 크다 보니 잘 안보이네요. 클릭하시면 잘 보입니다. 이 증발 구름을 읽는 법이 있습니다. 우선은 D와 D`입니다. D는 내가 바라는 상황입니다. 지금의 상황에서는 '체계적인 프로세스를 구축한다.'가 되겠죠. D`는 상대방이 바라는 상황입니다. '기존의 업무방식을 고수한다.'가 될것입니다. 지금 상항은 이 두 주장이 대립하여 갈등을 일으키고 있는 것입니다. 그렇다면 이 두 주장이 왜 갈등을 일으키고 있는 것일까요? 왜 둘 중 하나를 선택하지 못하고 갈등을 일으키는 것일까요? 저는 이렇게 생각해 보았습니다. 기존의

성과 측정과 생산성

조직에서 테스터의 자질은 무엇으로 평가되어야 할까요? 품질은 어떤 지표로 측정해야 하는 걸까요? 테스트의 결과는 무엇을 측정해서 제출해야 하는 걸까요? 개인적으로 테스터 개개인을 측정하는 것에는 반대하는 입장이다. 도데체 테스터의 가치를 단순한 숫자로 정의 내릴 수 있다는 생각은 누가 한 것일까? 개개인을 단순한 숫자로 측정하는 것은 관리자의 편의성을 생각해 볼때 이만한 해결책 이상은 있을 수가 없다. 하지만 내가 테스터 개개인의 측정을 반대하는 것은 측정 자체가 아니라 어떤 기준에 맞춰 모든 테스터가 그 기준을 상회해야한다는 그 어이없는 믿음에 반대하는 것이다. 예를 들면, 테스트 케이스의 갯수, 결함 발견 갯수 등등으로 테스터의 능력치를 측정합니다. 그런 이면에는 모든 사람이 슈퍼맨이길 바라는 관리자의 헛된 야망이 숨어있습니다. 하지만 모든 사람이 다 슈펴맨이 가능한 걸까요? 슈퍼맨이 된다고 해도 그런 슈퍼맨들만 모인 팀의 생산성이 과연 높은 것일까요? 예전에 히딩크 감독이 멀티 플레이를 주장했다 하지만 그렇다고 해서 축구에서 진영이나 포지션이 없어진 것은 아니다. 그리고 날고 긴다는 사람들만 모아놓은 대표팀이라고 해서 언제나 어디서나 승리하는 것은 아니라는 것을 알고 있다. 테스터 개개인의 능력을 측정하는 것은 필요로 하는 일이다. 하지만 테스터가 모든 분야에서 특정 기준 이상이어야 한다는 믿음에는 동의할 수 없다. 조직원의 특성을 파악하고 그 특성을 조화롭게 이끌어 내어 팀의 생산성을 높일 수 있는 관리자가 필요하다. 다양한 척도를 이용해서 테스터의 생산성을 측정하겠다는 가장 큰 약점이라면 테스터가 측정값을 속이기 쉽다는 것이다. 테스트나 품질 그 자체보다는 성과와 인사고과만을 위해 일하는 바보같은 테스터가 양산되어 버린다. 예를 들어 테스트 케이스 갯수를 가지고 생산성을 측정한다면 테스터는 의도적으로 의미없는 테스트 케이스 갯수를 늘릴 가능성이 매우 높다. 단순히 결함의 갯수만으르 가지고 측정한다면 테스터는 오타와 같은 쓸모없는 결함만을 양산해 낼 가

품질이란 무엇일까요?

품질이란 무엇일까요? 위에서는 사장님부터 아래로는 사원들까지 밖에서도 안에서도 언제나 메아리 치는 소리.. 품질... 하지만 품질이 무엇인지 정확히 말할 수 있는 사람은 많지 않습니다. 어떤 사람은 ISO 25000 표준을 얘기하는 사람도 있고, 어떤 사람은 사용성 같은 것을 이야기 하기도 합니다. 왜 그런걸까요? 여러분은 사랑을 정의 내릴 수 있나요? 가치관이나 부성애 같은 것은 어떠신가요? 꿈은 어떻습니까? 품질도 위와 같은 개념과 매우 비슷합니다. 품질을 정의하기 위한 노력을 지금 그만두는 것이 자원을 절약하는 지름길입니다. 왜냐하면 품질이란 매우 상대적인 가치관에 가깝기 때문입니다. 때문에 여러분 회사 제품의 품질이 낮다고 여겨진다면 고객의 불만이 크다고 생각된다면 대부분의 원인은 대화 부족인 경우가 많습니다. 소프트웨어 개발과 관련된 수많은 사람들 고객을 포함해서 개발자, 테스터, 기획, 그래픽, 경영진 등 많은 이해관계자들의 품질에 대한 가치과 우선순위가 틀리기 때문입니다. 서로 대화를 하지 않으면서 서로 다른 꿈을 꾸게 된다면 그 목적지는 전혀 다르게 됩니다. 개발팀에서는 기능의 풍부함을 품질로 보고 테스터는 기능의 정확성을 품질로 보고 경영진은 돈을 많이 벌어다 줄 제품을 품질로 보고 고객은 사용이 편한 제품을 품질로 여긴다고 가정할 때 각각의 이해 관계자의 의사소통이 없이 제품의 개발이 달려가게 된다면 그 끝은 자명한 일입니다. 품질의 정의와 가치에 대한 얘기는 탁상공론일 뿐입니다. ISTQB에서는 이러한 개념을 '오류-부재의 궤변'으로 설명합니다. 품질은 매우 중요합니다. 하지만 무엇을 품질의 가치로 삼을 것이고 그 가치의 기준을 제공할 당사자가 누구인지에 대해 명확하게 정의할 필요가 있습니다. 그런 선행과정이 있어야 품질이 무엇이고 품질을 어떻게 측정할 것인지에 대한 논의를 시작할 수 있을 것입니다. 세상에는 결함은 별로 없지만 잘 팔리지 않는 제품이 있는가 하면 끊임없이 결함이 생겨나고 문제가 있다고 해도 불티나게 팔리는 아

테스트 추정 - 지킬 수 없는 약속, 언제 끝내야 하나?

여러분은 테스트 추정을 하시나요? 많은 조직에서 테스트 수행을 위한 일자를 계산하고 일정을 세우지만... 과연 그 일정대로 테스트를 수행하고 종결하신 적이 얼마나 있으신가요? 우리는 항상 테스트를 언제 끝내야 할지에 대해서 고민합니다. 테스트를 끝낼 때쯤 되면 항상 들려오는 잔소리.. 결함 없져? 아무 문제 없져? 그런 질문에 확신할 수 없는 대답이나 거짓말 일정을 초과해서 테스트를 수행할 때 흔히 하는 거짓말.. 개발팀이 제 때에 결함 수정을 하지 않았습니다. 책임 회피, 불신, 반목 그렇지 않은 곳도 있겠지만 많은 조직에서 겉으로 꺼내놓고 말하지 못한 공공연한 비밀 중 하나입니다. 예를 들면 출시까지는 앞으로 한달.. 출시일은 바꿀 수 없습니다. 개발 예정은 앞으로 2주 그렇다면 테스트는? 선택권도 없이 당연히 2주.. 하지만 개발은 자꾸 지연되고 출시일이 코앞으로 닥친 1주일 전 최종 빌드가 넘어옵니다. 하지만 최종 빌드의 3분의 1은 결함이 줄줄줄 쏟아지고 나머지 절반은 아예 구동도 안됩니다. 이 미칠듯한 상황에 철야로 주구장창 달리면서 개발팀과 미칠듯한 설전을 펼쳐 누덕 누덕 기운 제품이 결국에 출시일에 맞춰 고객에게 인도됩니다. 그리고 하루가 지나기도 전에 CS팀의 게시판과 전화기는 불이 납니다. 쉬는 시간도 없이 다시 패치를 위한 일정과 계획에 돌입합니다. 이 미칠듯한 행진이 언제 끝날지는 아무도 모릅니다. 여러분은 위와 같은 상황에서 만약 테스트 팀장이라면 어떻게 하시겠습니까? 왜 이런 일이 생기는 걸까요? 저는 이 모든 1차 책임이 관리자에 있다고 봅니다. 먼저.. 관리자가 단무지이기 때문입니다. 단무지가 무엇인지는 아시죠.. 단순, 무식, 지랄... 즉, 테스트를 수행할 수 있는 기간이 2주에서 1주로 단축되었습니다. 단무지 팀장님은 생각합니다. 기간이 절반으로 줄었으니 두배 열심히 일하면 되겠군.. 하루에 8시간 근무를 철야를 해서 16시간씩 작업해도 하루

경로 의존성

경로 의존성이라는 것이 있다. 이와 관련된 기사를 우선 읽어 보도록 하자. [DT 시론] 경로 의존성과 전환 비용 - 디지털산업 경제신문 디지털타임스 www.dt.co.kr 2007년 8월 17일 ... 경로 의존성 이란 어떤 기술이나 제품의 발전이 그 결과 이상으로 발전되어온 과정의 구체적인 내용과 형식에 영향을 받는다는 것이다. ... 내가 이 경로 의존성에 대해 처음 접하게 된 것은 EBS의 '지식채널 e'를 통해서였다. 그 뒤로 난 테스트를 할 때 경로 의존성에 대해 한번 더 생각해 보게 되었다. 경로 의존성은 테스트를 수행할 때 뿐만 아니라 컨설팅을 할 때도 가장 큰 제약 중의 하나로 작용된다. 그리고 나 자신도 알게 모르게 수용해 버리고 마는 많은 것들이 있다. '한국 웹의 불편한 진실'과 '소프트웨어 누가 이렇게 개떡같이 만든 거야'라는 책을 읽으면서 나는 다시 한번 경로 의존성에 대해 생각해 보게 되었다. 일전에 썼던 '표준에 대한 단상'이나 'YES!!! Man을 거부해라'도 같은 맥락의 글이었다. 기술적인 표준에 관련된 경로 의존성을 깨뜨리기는 거의 불가능에 가깝다. 하지만 우리가 매너리즘에 빠지게 되는 많은 부분에서 경로 의존성의 극복은 의지의 문제이다. 많은 테스터들이 매너리즘에 빠진다. 항상 똑같은 테스트만 반복하다 보니 신선미나 독창성을 잃어버린다. 이것은 외국이나 국내나 사정이 별반 다르지 않다. 3년 이상 제대로 된 테스터 경력자를 구하기란 하늘의 별따기와 같다. 극소수의 테스터들도 관리자로 전향하면서 더 이상 경험이나 전문성과는 거리가 멀어져 버린다. 이것은 회사나 조직이 테스터에게 제대로 된 커리어 패스 하나 제시해 주지 못하기 때문이기도 하다. 하지만 매일 매일 똑같은 제품, 똑같은 테스트 케이스 수행을 하는 것에 대해서 "그거 원래 그런거야!! 바꿀 필요 없어!!"라는 주문에 과감히 "No"라고 외쳐보자