테스팅 프로젝트의 추정은 누가 하고 계신가요?
테스팅 팀장님이 하시나요?
음.. 그런곳도 있을 것 같습니다. 하지만 전 아직 들어보지 못했습니다.
제가 겪어 보고 일반적으로 들어서 알고 있는 테스팅 프로젝트의 일정은 아래와 같은 상황입니다.
몇몇의 경영자와 기획자 그리고 마케터들이 모여서 제품 출시일을 논합니다. 물론 개발자 분들도 있습니다.
잠시 열띤 토론 끝에 마케터 분들이나 경영자의 한마디로 회의가 끝납니다.
이 제품은 6개월 후에 출시합니다.
그 이후로는 전쟁입니다. Gantt 차트나 기타 여러가지 방법으로 척척 아름다운 추정들이 쏟아져 나와서 MS 프로젝트나 엑셀로 멋지게 그려집니다.
그리고 그걸로 끝입니다. 해당 일정은 가끔 기획자나 경영자들이 들여다보면서 이러면 안돼~~ 라는 외마디 비명을 지를때 외에는 다른 사람들은 그다지 관심이 없습니다.
우선 한 2달간 열심히 기획을 하면서 개발이 시작됩니다. 그리고 출시 한달 전까지 죽어라 개발만 합니다. 그리고 출시 한달을 앞두고 어느 정도 모양이 잡힌 실행을 할 수 있을 만한 제품이 테스트 팀으로 넘어옵니다.
하지만 곧바로 테스트를 할 수가 없습니다. 제품이 정상적으로 구동되지 않거나 환경이 제대로 갖춰지지 않은 경우가 많습니다. 개발팀에서 테스트를 요청할 때는 그냥 언제까지 끝내달라고만 말합니다. 야근과 철야로 어떻게든 일정에 맞춰주면 그 뒤로 수정되었다는 소식은 함흥차사입니다.
출시일은 제꺽 제꺽 다가오고 한달 정도 전쟁과 같은 테스트와 수정을 하던 제품은 우선 출시일에 출시가 됩니다.
그리고 나서 또 몇달 간의 전쟁과 같은 수정과 테스팅이 반복이 됩니다.
위 상황에서 누구도 테스트 팀에게 테스트 일정을 물어보지 않습니다.
테스트 팀의 일정은 전체 개발 기간에서 남는 시간동안 진행하는 것이거나 개발팀이나 다른 부서에서 정해준 시간까지인 경우가 제가 듣고 겪어본 일정 추정 방법입니다.
여러분은 어떠신가요?
이게 과연 제대로 된 일정 추정인가요?
추정이라는 것이 현실적이라고 생각하는 사람은 많지 않습니다. 추정은 현실이라기보다는 차라리 희망사항에 가까운 것이 사실입니다.
하지만 그러한 희망사항도 당사자의 희망사항이 아닌 경우가 많습니다.
우리의 추정이 부정확한 이유는 여러가지가 있지만(계획이 잘못된 경우도 있지만 진행 자체의 불확실성도 큰 몫을 합니다.) 그 중 하나가 바로 해당 작업을 수행할 당사자들이 일정을 추정하는 경우가 많지 않다는 것입니다.
대부분의 경우 추정은 경영진이나 마케팅, 또는 갑이라 불리는 사용자에 의해 이루어집니다.
그렇다면 도데체 왜 당사자가 아닌 다른 이해관계자가 일정을 추정하는 것일까요?
이것은 어쩌면 신뢰의 문제일 수 있습니다.
제품의 개발 일정에 대해 개발팀이나 테스팀과 같은 당사자들은 경영진이나 마케터와 같은 이해관계자가 추정한 일정에 대하여 불가능한 이유를 먼저 생각하고 이해관계자들은 그러한 당사자에 대하여 불평과 불만이나 늘어놓는 투덜이 스머프쯤으로 생각한다는 것입니다.
그런데 더 큰문제는 프로젝트의 성공과 실패의 기준으로 가장 중요하게 다뤄지는 요소가 바로 일정이라는 것것입니다.
물론 인터뷰를 해보면 품질과 같은 그런 고급스러운 얘기를 하지만 실제적으로 프로젝트의 성공과 실패는 일정과 이익인 경우가 많습니다.
그것은 단단한 것이 부드러운 것을 몰아내기 때문입니다.
하지만 이것은 경영진이나 마케터와 같은 사람들의 생각이고, 실제로 개발자나 테스터와 같은 당사자들의 생각은 어떨까?
Jeffry와 Lawrence는 1985년에 한 잡지에 "추정을 전혀 하지 않은 프로젝트가 생산성 측면에서 가장 성공적이었다." 는 기사를 개제했다. 그 다음은 기술자들이 추정을 수행한 프로젝트가 차지했고, 관리자가 추정을 수행한 프로젝트는 최악이었다고 한다.
우리가 알고 있는 생각과는 전혀 다른 사실에 어안이 벙벙하다.
하지만 이 개념이 최근에는 그렇게 낯선 개념은 아니다. 이와 비슷한 개념을 우리는 Agile의 자기 조직화에서 찾아볼 수 있다.
그렇다면 일정이 아닌 무엇으로 우리는 프로젝트의 성공을 논하고 관리를 제대로 할 수 있을까?
여러가지 다른 것들을 생각해 볼 수 있지만 Agile 이라면 구동 가능한 제품을 생각해 볼 수 있다.
그런데 최근의 애자일은 구동 가능한 제품보다 이터레이션이 더 강조되는듯하여 씁쓸함을 감출 수 없다.
Scrum 이 보급된 조직과 회사가 많아지면서 대략 2주 정도의 이터레이션이 마치 성배처럼 얘기되는 느낌을 지울 수가 없다.
개인적으로 나는 저 2주라는 시간을 강제하는 것은 Agile 의 몰락의 단초가 될 것이라고 생각된다.
우리는 일정을 강조할 경우 일정을 맞추기 위해 품질을 희생하는 경우를 이미 수도 없이 보아왔다.
2주라는 시간은 초기에는 개발부터 테스트까지 가능한 시간일지는 모르겠지만 분명 통합과 시스템 구성의 단계로 넘어갈 수록 기하급수적으로 늘어나는 복잡성과 여러 품질 이슈를 모두 충족 가능한 시간으로는 턱없이 부족하다고 생각한다.
그렇다면 정말로 추정을 전혀 하지 않고 제품을 개발하는 것이 최선인 것일까? 난 그렇지는 않다고 말하고 싶다.
일정은 추정되어야 한다.
단, 지금까지의 권력의 구조를 바꾸어야 한다. 이해관계자들이 정책적으로 책정하는 엉터리 추정은 없어져야 한다. 즉, 데드라인은 없어져야 한다.
실제적인 당사자들에 의한 일정이 수립되어야 하며, 그 일정들은 일정한 한계값을 가지고 있어야 한다.
예를 들어 3개월 개발이라면 최소한 2달의 테스트 기간과 수정 기간은 확보되어야 하며, 그 기간동안 개발팀이 모든 결함을 수정하지 못한다면 그에 대한 책임을 져야 한다는 것이다.
단순히 시장에 의해서 누군가에 의해서 만들어지는 일정이 아니라 실제적으로 수행할 수 있는 일정이 수립되어야하고 그 일정이 바로 정책적인 일정이 될 수 있도록 서로간의 신뢰를 쌓아야 한다고 생각한다.
테스팅 팀장님이 하시나요?
음.. 그런곳도 있을 것 같습니다. 하지만 전 아직 들어보지 못했습니다.
제가 겪어 보고 일반적으로 들어서 알고 있는 테스팅 프로젝트의 일정은 아래와 같은 상황입니다.
몇몇의 경영자와 기획자 그리고 마케터들이 모여서 제품 출시일을 논합니다. 물론 개발자 분들도 있습니다.
잠시 열띤 토론 끝에 마케터 분들이나 경영자의 한마디로 회의가 끝납니다.
이 제품은 6개월 후에 출시합니다.
그 이후로는 전쟁입니다. Gantt 차트나 기타 여러가지 방법으로 척척 아름다운 추정들이 쏟아져 나와서 MS 프로젝트나 엑셀로 멋지게 그려집니다.
그리고 그걸로 끝입니다. 해당 일정은 가끔 기획자나 경영자들이 들여다보면서 이러면 안돼~~ 라는 외마디 비명을 지를때 외에는 다른 사람들은 그다지 관심이 없습니다.
우선 한 2달간 열심히 기획을 하면서 개발이 시작됩니다. 그리고 출시 한달 전까지 죽어라 개발만 합니다. 그리고 출시 한달을 앞두고 어느 정도 모양이 잡힌 실행을 할 수 있을 만한 제품이 테스트 팀으로 넘어옵니다.
하지만 곧바로 테스트를 할 수가 없습니다. 제품이 정상적으로 구동되지 않거나 환경이 제대로 갖춰지지 않은 경우가 많습니다. 개발팀에서 테스트를 요청할 때는 그냥 언제까지 끝내달라고만 말합니다. 야근과 철야로 어떻게든 일정에 맞춰주면 그 뒤로 수정되었다는 소식은 함흥차사입니다.
출시일은 제꺽 제꺽 다가오고 한달 정도 전쟁과 같은 테스트와 수정을 하던 제품은 우선 출시일에 출시가 됩니다.
그리고 나서 또 몇달 간의 전쟁과 같은 수정과 테스팅이 반복이 됩니다.
위 상황에서 누구도 테스트 팀에게 테스트 일정을 물어보지 않습니다.
테스트 팀의 일정은 전체 개발 기간에서 남는 시간동안 진행하는 것이거나 개발팀이나 다른 부서에서 정해준 시간까지인 경우가 제가 듣고 겪어본 일정 추정 방법입니다.
여러분은 어떠신가요?
이게 과연 제대로 된 일정 추정인가요?
추정이라는 것이 현실적이라고 생각하는 사람은 많지 않습니다. 추정은 현실이라기보다는 차라리 희망사항에 가까운 것이 사실입니다.
하지만 그러한 희망사항도 당사자의 희망사항이 아닌 경우가 많습니다.
우리의 추정이 부정확한 이유는 여러가지가 있지만(계획이 잘못된 경우도 있지만 진행 자체의 불확실성도 큰 몫을 합니다.) 그 중 하나가 바로 해당 작업을 수행할 당사자들이 일정을 추정하는 경우가 많지 않다는 것입니다.
대부분의 경우 추정은 경영진이나 마케팅, 또는 갑이라 불리는 사용자에 의해 이루어집니다.
그렇다면 도데체 왜 당사자가 아닌 다른 이해관계자가 일정을 추정하는 것일까요?
이것은 어쩌면 신뢰의 문제일 수 있습니다.
제품의 개발 일정에 대해 개발팀이나 테스팀과 같은 당사자들은 경영진이나 마케터와 같은 이해관계자가 추정한 일정에 대하여 불가능한 이유를 먼저 생각하고 이해관계자들은 그러한 당사자에 대하여 불평과 불만이나 늘어놓는 투덜이 스머프쯤으로 생각한다는 것입니다.
그런데 더 큰문제는 프로젝트의 성공과 실패의 기준으로 가장 중요하게 다뤄지는 요소가 바로 일정이라는 것것입니다.
물론 인터뷰를 해보면 품질과 같은 그런 고급스러운 얘기를 하지만 실제적으로 프로젝트의 성공과 실패는 일정과 이익인 경우가 많습니다.
그것은 단단한 것이 부드러운 것을 몰아내기 때문입니다.
하지만 이것은 경영진이나 마케터와 같은 사람들의 생각이고, 실제로 개발자나 테스터와 같은 당사자들의 생각은 어떨까?
Jeffry와 Lawrence는 1985년에 한 잡지에 "추정을 전혀 하지 않은 프로젝트가 생산성 측면에서 가장 성공적이었다." 는 기사를 개제했다. 그 다음은 기술자들이 추정을 수행한 프로젝트가 차지했고, 관리자가 추정을 수행한 프로젝트는 최악이었다고 한다.
우리가 알고 있는 생각과는 전혀 다른 사실에 어안이 벙벙하다.
하지만 이 개념이 최근에는 그렇게 낯선 개념은 아니다. 이와 비슷한 개념을 우리는 Agile의 자기 조직화에서 찾아볼 수 있다.
그렇다면 일정이 아닌 무엇으로 우리는 프로젝트의 성공을 논하고 관리를 제대로 할 수 있을까?
여러가지 다른 것들을 생각해 볼 수 있지만 Agile 이라면 구동 가능한 제품을 생각해 볼 수 있다.
그런데 최근의 애자일은 구동 가능한 제품보다 이터레이션이 더 강조되는듯하여 씁쓸함을 감출 수 없다.
Scrum 이 보급된 조직과 회사가 많아지면서 대략 2주 정도의 이터레이션이 마치 성배처럼 얘기되는 느낌을 지울 수가 없다.
개인적으로 나는 저 2주라는 시간을 강제하는 것은 Agile 의 몰락의 단초가 될 것이라고 생각된다.
우리는 일정을 강조할 경우 일정을 맞추기 위해 품질을 희생하는 경우를 이미 수도 없이 보아왔다.
2주라는 시간은 초기에는 개발부터 테스트까지 가능한 시간일지는 모르겠지만 분명 통합과 시스템 구성의 단계로 넘어갈 수록 기하급수적으로 늘어나는 복잡성과 여러 품질 이슈를 모두 충족 가능한 시간으로는 턱없이 부족하다고 생각한다.
그렇다면 정말로 추정을 전혀 하지 않고 제품을 개발하는 것이 최선인 것일까? 난 그렇지는 않다고 말하고 싶다.
일정은 추정되어야 한다.
단, 지금까지의 권력의 구조를 바꾸어야 한다. 이해관계자들이 정책적으로 책정하는 엉터리 추정은 없어져야 한다. 즉, 데드라인은 없어져야 한다.
실제적인 당사자들에 의한 일정이 수립되어야 하며, 그 일정들은 일정한 한계값을 가지고 있어야 한다.
예를 들어 3개월 개발이라면 최소한 2달의 테스트 기간과 수정 기간은 확보되어야 하며, 그 기간동안 개발팀이 모든 결함을 수정하지 못한다면 그에 대한 책임을 져야 한다는 것이다.
단순히 시장에 의해서 누군가에 의해서 만들어지는 일정이 아니라 실제적으로 수행할 수 있는 일정이 수립되어야하고 그 일정이 바로 정책적인 일정이 될 수 있도록 서로간의 신뢰를 쌓아야 한다고 생각한다.
댓글
댓글 쓰기