흥미로운 포스트가 올라왔다. 설계가 완벽하지 않아야 하는 이유. 설계가 완벽할 수 없는 이유에 덧붙이는 주장이고, 프로젝트 시작부터 개발자가 바글바글이란 글에 대한 반박이 있다.
설계가 완벽하지 않아야 하는 이유는 도표와 함께 self-funding point라는 다소 어려운 용어로 읽는데 다소 장벽이 있었지만, 자세히 살펴볼수록 공감하고 동의했다. 두 가지 사항을 이야기하고 싶다. 하나는, 프로젝트 시작부터 개발자가 바글바글에 대해 동의하지 않았던 부분이고, 다른 하나는 강규영님이 그래프를 이용해 과학적으로 표현한 내용을 더 많은 사람이 공유하려고 현실에서 드러나는 사례를 하나 말하고 싶다.
프로젝트 시작부터 개발자가 바글바글에 대해 반은 동의하고, 반은 반대한다. 여러 사업 수행조직과 일하다 보면 인력 투입의 효용성은 분명히 사업 수행 역량의 중요한 지표이다. 대형 프로젝트의는 가변성이 높지만, 계약은 프로젝트 착수에 선행한다. 그래서, 인력 투입 문제도 사업 수행 관점에서는 예산 범위에서 돈을 쓰는 문제이다. 사업 수행 측면에서 프로젝트 시작부터 개발자가 바글바글에서 지적한 내용은 아주 기본적인 상식이다. 동감하는 바지만, 강규영님이 제시한 것처럼 인력 교체를 효율적으로 하는 방법 외에 다른 해결책이 있고, 더욱 효과적이란 점에 절대적으로 동의한다.
공정 분리와 분업은 먼저 명확한 역할 분리와 역할 사이의 계약에 기초하고 있다. 계약이란 말은 적절한 단어가 없어서 어렵게 썼는데, 선행 작업자의 산출물을 다음 사람이 받아서 과업을 진행하는데 무리가 없어야 한다. 그런데 대부분은 설계자 철수 후 개발자를 투입하는 경우 소프트웨어 설계 산출물이 구현으로 이어지는 데는 병목을 관찰할 수 있다. 설계 산출물을 통해 개발자가 분석, 설계 사항을 그대로 전수받는 일은 아직 어렵다. 화면 설계와 ERD만으로 시스템 개발이 가능한가? UML 다이어그램? UML은 중요한 업무 규칙을 표현하기엔 여전히 범용성이 떨어진다.1 얼마 전 언급한 칼럼의 주장처럼 조기 인스펙션 강조 역시 같은 맥락이라고 본다.
언젠가는 우리 업종에서도 완벽한 설계서가 구현으로 이루어져 명확한 분업이 가능한 날이 올 수도 있겠지만, 아직은 그러한 분업을 효과적으로 실행하기에 성숙도가 낮다고 생각한다. 전통적인 방식 안에서 문제 해결을 꾀하는 것이 현실적이라 할 수 있다. 그러나 반복해서 실패(?)한 경험2이 있다면 분업을 위해서는 산업 성숙도가 낮음을 인정(혹은 SW 업종의 특성 탓이라고 하던)하고, 애자일 도입을 조직차원의 학습 능력과 변화 수용 능력 안에서 수용하는 것도 현실적으로 심각하게 고려해볼 옵션이다.
어제 오랜만에 연락한 어느 분이 대형 SI 업체의 프로젝트에서 겪은 안타까움에 대해 하소연했다. 그 중 하나는 설계가 끝나고 참여했을 때, 설계 문서만으로는 개발할 수 없어 발생한 문제의 책임을 고스란히 개발자가 물었다는 내용이다. 예전에 일을 여러 차례 경험한 바 있었기에 남의 일인데 너무 쉽게 공감할 수 있다는 사실이 씁쓸했다.
설계가 완벽하지 않아야 하는 이유에서 도표를 보면 애자일은 조기에 이익이 드러난다. 불공평한 그림이라 주장할 수도 있다. 왜냐하면, 분석, 설계는 이익 실현이 아니냐고 주장할 수도 있기 때문이다. 하지만, 실제 현장에서 고객이 그렇게 생각할까?
최근 프로젝트에서 애자일 적용을 하고 있다. 초기에는 고객이 거부감을 나타냈다. 미래의 일에 대해 구체적인 작업까지 나누지 않았기 때문이다. 하지만, 조기 릴리즈를 반복하면서 안심하기 시작했고, 공공연히 '애자일로 할 수밖에 없는 프로젝트'라고 하거나 '매주 구체적인 결과를 보지 못하면 답답해' 하기 시작했다. 프로젝트 관리자나 개발자 관점에서는 팀 혹은 자신의 작업이 고객 생각과 다르지 않음을 1~2주 단위로 확인할 수 있다.
분석, 설계를 이익이라고 쳐도 잠재적 이익에 가깝다. 릴리즈 시점에서 고객이 '그게 아니었다.'라고 한다면 부도 수표로 바뀔 위험이 있으니까.
공교롭게 포스팅 후 얼마 지나지 않아, 설계자의 가정에 근거한 선행 개발에 따르는 비용과 위험에 대해 이야기하고, Kent Beck의 점진적인 설계 방식을 소개하는 InfoQ 기사가 올라왔다. 내 글의 제목과 어울리지 않지만, 유사한 내용을 다른 시각으로 다루고 있다.
설계가 완벽하지 않아야 하는 이유는 도표와 함께 self-funding point라는 다소 어려운 용어로 읽는데 다소 장벽이 있었지만, 자세히 살펴볼수록 공감하고 동의했다. 두 가지 사항을 이야기하고 싶다. 하나는, 프로젝트 시작부터 개발자가 바글바글에 대해 동의하지 않았던 부분이고, 다른 하나는 강규영님이 그래프를 이용해 과학적으로 표현한 내용을 더 많은 사람이 공유하려고 현실에서 드러나는 사례를 하나 말하고 싶다.
프로젝트 시작부터 개발자가 바글바글에 대해 반은 동의하고, 반은 반대한다. 여러 사업 수행조직과 일하다 보면 인력 투입의 효용성은 분명히 사업 수행 역량의 중요한 지표이다. 대형 프로젝트의는 가변성이 높지만, 계약은 프로젝트 착수에 선행한다. 그래서, 인력 투입 문제도 사업 수행 관점에서는 예산 범위에서 돈을 쓰는 문제이다. 사업 수행 측면에서 프로젝트 시작부터 개발자가 바글바글에서 지적한 내용은 아주 기본적인 상식이다. 동감하는 바지만, 강규영님이 제시한 것처럼 인력 교체를 효율적으로 하는 방법 외에 다른 해결책이 있고, 더욱 효과적이란 점에 절대적으로 동의한다.
공정 분리와 분업은 먼저 명확한 역할 분리와 역할 사이의 계약에 기초하고 있다. 계약이란 말은 적절한 단어가 없어서 어렵게 썼는데, 선행 작업자의 산출물을 다음 사람이 받아서 과업을 진행하는데 무리가 없어야 한다. 그런데 대부분은 설계자 철수 후 개발자를 투입하는 경우 소프트웨어 설계 산출물이 구현으로 이어지는 데는 병목을 관찰할 수 있다. 설계 산출물을 통해 개발자가 분석, 설계 사항을 그대로 전수받는 일은 아직 어렵다. 화면 설계와 ERD만으로 시스템 개발이 가능한가? UML 다이어그램? UML은 중요한 업무 규칙을 표현하기엔 여전히 범용성이 떨어진다.1 얼마 전 언급한 칼럼의 주장처럼 조기 인스펙션 강조 역시 같은 맥락이라고 본다.
언젠가는 우리 업종에서도 완벽한 설계서가 구현으로 이루어져 명확한 분업이 가능한 날이 올 수도 있겠지만, 아직은 그러한 분업을 효과적으로 실행하기에 성숙도가 낮다고 생각한다. 전통적인 방식 안에서 문제 해결을 꾀하는 것이 현실적이라 할 수 있다. 그러나 반복해서 실패(?)한 경험2이 있다면 분업을 위해서는 산업 성숙도가 낮음을 인정(혹은 SW 업종의 특성 탓이라고 하던)하고, 애자일 도입을 조직차원의 학습 능력과 변화 수용 능력 안에서 수용하는 것도 현실적으로 심각하게 고려해볼 옵션이다.
어제 오랜만에 연락한 어느 분이 대형 SI 업체의 프로젝트에서 겪은 안타까움에 대해 하소연했다. 그 중 하나는 설계가 끝나고 참여했을 때, 설계 문서만으로는 개발할 수 없어 발생한 문제의 책임을 고스란히 개발자가 물었다는 내용이다. 예전에 일을 여러 차례 경험한 바 있었기에 남의 일인데 너무 쉽게 공감할 수 있다는 사실이 씁쓸했다.
설계가 완벽하지 않아야 하는 이유에서 도표를 보면 애자일은 조기에 이익이 드러난다. 불공평한 그림이라 주장할 수도 있다. 왜냐하면, 분석, 설계는 이익 실현이 아니냐고 주장할 수도 있기 때문이다. 하지만, 실제 현장에서 고객이 그렇게 생각할까?
최근 프로젝트에서 애자일 적용을 하고 있다. 초기에는 고객이 거부감을 나타냈다. 미래의 일에 대해 구체적인 작업까지 나누지 않았기 때문이다. 하지만, 조기 릴리즈를 반복하면서 안심하기 시작했고, 공공연히 '애자일로 할 수밖에 없는 프로젝트'라고 하거나 '매주 구체적인 결과를 보지 못하면 답답해' 하기 시작했다. 프로젝트 관리자나 개발자 관점에서는 팀 혹은 자신의 작업이 고객 생각과 다르지 않음을 1~2주 단위로 확인할 수 있다.
분석, 설계를 이익이라고 쳐도 잠재적 이익에 가깝다. 릴리즈 시점에서 고객이 '그게 아니었다.'라고 한다면 부도 수표로 바뀔 위험이 있으니까.
공교롭게 포스팅 후 얼마 지나지 않아, 설계자의 가정에 근거한 선행 개발에 따르는 비용과 위험에 대해 이야기하고, Kent Beck의 점진적인 설계 방식을 소개하는 InfoQ 기사가 올라왔다. 내 글의 제목과 어울리지 않지만, 유사한 내용을 다른 시각으로 다루고 있다.
이올린에 북마크하기
이올린에 추천하기