테스팅 히치하이커를 위한 안내서

생산성 혁신의 순서로 5S 3I 를 소개한 적이 있습니다. 5S와 3I란 경영 혁신 절차 8단계의 머리 글자를 딴것으로 분업화, 전문화, 표준화, 과학화, 시스템화, 집적화, 지능화, 비상식화를 말합니다. 관련된 내용은 http://murian.textcube.com/351 나 검색을 통해 알아보시면 좋을 것 같습니다. 이 5S 3I를 기반으로 Agile 과 Waterfall 의 관계에 대하여 나름대로 각색을 해보았습니다. 결론적으로 말한다면 저는 Agile 은 절대 은총알이 될 수 없다는 것과 Waterfall 조차 제대로 수행할 능력이 없는 조직은 Agile 을 도입하지 않는 것이 좋다고 생각합니다. 저는 5S 3I가 아래와 같은 관계를 가지면서 발전한다고 생각합니다. 하나씩 설명을 하자면 전문화와 표준화는 거의 동시적으로 발생하는 가장 초기 단계의 활동이라고 생각합니다. 그리고 전문화와 표준화를 묶어주는 아교와 같은 역할을 하는 것이 과학화라고 생각합니다. 단순화는 부분적으로 발생할 수도 있고 그렇지 못할 수도 있다고 생각합니다. 개인적으로는 잘 발생하지 않는 활동이라고 생각됩니다. 특히나 표준이나 인증을 도입하는 경우에는 거의 발생하지 않는 활동이라고 생각합니다. 결론적으로 전문화, 표준화, 단순화 즉, 생산성 혁신의 기본 3S 는 순차적이라기보다는 병렬적으로 발생하는 활동이라고 생각합니다. 그리고 이 3가지 활동을 유기적으로 묶어주는 것이 과학화라고 생각합니다. 이렇게 4가지 활동이 묶이면 하나의 시스템 즉, 프로세스가 된다고 생각합니다. Waterfall 은 이 4가지 활동으로 묶여진 하나의 프로세스 즉, 방법론인 것입니다. Waterfall 안에는 전문적인 분업조직과 R&R이 있고, 그러한 활동들에 대한 표준적인 사항들이 있으며 그러한 사항들을 측정하는 측정 지표가 모두 포함되어 있습니다. 기존에는 이 Waterfall 로도 충분한 환경이었다면 이 환경에 충격을 가한 것이 1I 즉, 집적화라고 생각합니다. 시간은 흘러 고객은 변했고 고객은...

xper 모임을 나가보거나 주변에서 얘기되는 Agile 얘기를 나눠본지도 벌써 2년이 다되어 가는 것 같습니다. STA Consulting Inc. 에서는 얼마전 2010년 테스팅 트렌드의 하나로 Agile Testing 을 이야기했고, 4월 21일에는 애자일(Agile) 소프트웨어 개발 및 테스팅 세미나 가 열리기도 합니다. 그런데, 여기저기 이야기를 나누고 다니다 보면 Waterfall 개발방법론과 Agile 개발방법론을 대척점으로 놓고 이해하고 있는 사람들이 은근히 많습니다. 마치 흑백의 논리 처럼 명확하게 둘을 구분짓고 대척점에 놓는 사람들 말입니다. 과연 그런것일까요? Agile 과 Waterfall 은 흑백처럼 서로 절대 만날 수 없는 견우와 직녀와 같은 그런 관계일까요? 저는 아니라고 생각합니다. 제약이론의 사고 프로세스에 의하면 Agile 개발 방법론은 궁극적으로 발전된 형태의 Waterfall 로 규정할 수 있습니다. 팀의 진화에 따라 많은 조직은 Waterfall 에서 Agile 로 자연스럽게 이동하게 되어 있다라는 결론에 도달합니다. 또한 Agile 그 너머를 생각해 볼 수도 있습니다. 많은 조직에서 Waterfall 을 통해 실패와 한계를 경험하고 그것을 극복하기 위한 방법의 하나로 Agile 을 도입하려고 합니다. 하지만 생각보다 Agile 로 성공적으로 이행하는 조직은 많지 않습니다. 분명 많은 성공사례가 보고되고 있지만 실제 현실에서는 여러 이유로 실패하는 경우가 많습니다. 왜 그런것일까요? 전 이것을 '모 아니면 도'와 같은 생각으로 Agile 을 도입하였기 때문이라고 생각합니다. 사람들은 Waterfall 반대편에 있는 것을 Agile 로 규정하고 Agile 을 도입하면 Waterfall 에서 발생한 모든 문제가 모두 해결될 것처럼 생각하기 때문에 실패한다고 생각합니다. 그리고 그러한 가정은 틀렸다라는 것이 제 생각입니다. Waterfall 에서도 제대로 된 성공경험이 없는 조직은 Agile 을 도입한다고 해도 ...

프로젝트는 예산, 일정, 품질 3가지 요소로 이루어진다고 볼 수 있다. 물론 위 3가지 요소 외에도 개발 범위, 팀워크, 자원 조달 등 여러가지 요소들도 고려해 볼 수 있지만, 가장 중요한 요소를 꼽는다면 예산, 일정, 품질일 것이다. 위에서 말한 여러가지 요소들은 프로젝트를 계획하여 완료하는 순간까지 복합적으로 작용해서 프로젝트의 성과를 제한하게 된다. 위의 요소들을 잘 통제한다면 성공적인 프로젝트가 되는 것이고 그렇지 못한다면 실패하거나 사라지게 될 것이다. 프로젝트 관리란 그런 면에서 제한된 자원을 가지고 목적한 바를 제한된 기간내에 최소의 비용으로 완수할 수 있도록 하는 것으로 정의할 수 있을 것이다. 이것을 도식화 한다면 아래와 같은 그림으로 표현할 수 있을 것이다. 위의 그림에 보는 것처럼 일정과 품질, 예산은 우리의 프로젝트가 목적하는 바를 달성하도록 하기 위해 상호 연관되어 작용하게 된다. 우리가 접하게 되는 많은 방법론들의 가정에는 위의 요소들을 어떻게 관리할 것인가에 대한 기본적인 가정들이 설정되어 있다. 조직에서 어떤 특정한 방법론을 도입한다는 것은 그런 가정에 동의하는 것이고 그러한 철학을 받아들인다는 것이기 때문에, 방법론을 채택하기 전에 조직의 근본 문제와 문화에 대해 점검해 볼 필요가 있다. 그리고 위의 요소들 외에 고려해 볼 사항은 위의 요소들은 변동성과 불확실성을 내포하고 있다는 것이다. 특히 비용과 예산, 목적은 프로젝트를 진행하면서 가변할 가능성이 매우 큰 요소들이다. 대부분의 방법론은 이러한 변동성에 대한 안전장치들을 가정해서 세워져 있다. 변동성의 측면에서 위의 요소들을 다시 살펴본다면 아래와 같이 가정할 수 있다. 위의 그림을 일부 해석해 본다면 일정이 늘어난다면 비용은 늘어나게 된다. 범위가 변경되어도 비용은 늘어나게 된다. 범위와 일정은 상호 의존적이 된다. 만약 위 3가지 요소의 변동성을 통제하지 못하게 된다면 프로젝트는...

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