Q: 지금 사용자 스토리를 읽고 있습니다. 전에 XP 읽고 느꼈던 감동이 다시 오더군요. 그때도 지금도 고민되는 문제점이 있습니다. 제가 XP 처음 접할 저는 벤처기업에 있었고 개발이 상당히 어렵게 진행되고 있었습니다. 대표적으로 회사가 상하로 나누어져 위에서는 개발자를 재촉하고 개발자는 수동적으로 따라가는 구조였습니다. 저는 그때 개발팀을 이끌고 있었고, 그래서 그런 현실이 안타까웠습니다. XP 읽고 한번에는 안되겠지만 점차 적용을 해야겠다고 생각하고 개발자들과 회의 시간에 XP 알렸습니다. 그런데 그때의 개발팀의 멤버는 아주 비관적인 말을 했지만 저도 답변을 수가 없었고, 지금도 마찬가지 입니다.

"스토리를 만드는 것이 일을 크게 하는 것이 아닌가?. 주어진 데로 하는 것도 쉽지 않은데 스토리를 작성해서 일이 커질 경우 개발 비용을 고스란히 개발팀이 안아야 한다."

이렇게 요약을 있는데요. 부분에 대해서 어떻게 생각하시는 지요? 예를 들면 지금 제가 개발 업체를 다니고 있고, 이번에 우리 회사가 카드회사의 새로운 프로젝트를 맡았다고 경우에, 이미 제안서와 요구사항에 의한 비용산출이 끝난 이후 개발팀이 투입이 것입니다. 개발팀의 팀장은 XP 이용하고자 했습니다. 카드회사의 새로운 프로젝트를 사용하는 사용자를 만나 미팅을 해서 프로젝트를 좀더 효과적으로 성공시킬 있는 아이디어를 도출할 있었습니다. 새롭게 도출된 결과는 카드 회사입장에서 상당히 장점이 있는 것으로 카드 회사는 제가 다니는 회사와 협의를 하게 것입니다.

이때 제가 다니는 회사에서 " 긁어 부스럼을 만들 어냐?"라는 말이 나올 있습니다. 많은 경우 아이디어는 일을 크게 하는 경우를 많이 봤습니다. 이런 경우에, 반복 주기에 고객의 의견을 반영함으로써 프로젝트의 완성도는 좋아지지만 점차 발생하게 되는 비용의 문제는 어떻게 해결해야 하는지요? 외국의 경우, 반복 주기마다 계약된 금액이 변경될 있나요?. 또는 국내 프로젝트에서는 어떤가요? 계약사항이 있는데도 ""이라는 이유로 요구사항을 변경하는 경우도 비일비재한데, 개발팀이 스토리 확장 변경에 관한 비용 문제를 어떻게 이겨내야 할까요?


A : 제 경험과 생각으로는 어차피 XP 나 기타 다른 Agile Process 가 아닌 전통 적인 개발 방법론을 사용하더라도 사용자의 기대 수준과 기획 시 계획의 차이는 해결해야 할 문제 인 것 같습니다. 프로젝트의 계약 시 보통 아주 세부적인 사항까지 계약하지는 않습니다. 개발 되는 시스템의 목적과 용도 에 입각해서 세부 사항은 숨기고 고객의 필요한 요구사항을 충족 시킬 것이라는 계약만 이루어 질 뿐입니다. 가령 계약이 기존의 이미 존재하는 시스템을 도입하여 프로그램의 세부 적인 구성을 고려하여 계약 되게 되더라도 실제 개발에서의 고객 요구 사항은 계약 내용과 상이한 점이 존재 할 수 밖에 없습니다. 그렇다고 고객의 요구를 무시하고 계약 되로 개발 할 수는 없죠? 그래서 소프트웨어 프로젝트의 개발 동안 PM 들은 계속 고객과 회사 등 프로젝트 전반에 걸쳐 이해관계가 있는 곳과 조율과 이해를 구하게 되는데 전통적인 개발 방식에서는 이 능력은 전적으로 PM의 역량에 의존하는 경향이 입니다(술로 해결하는 사람들도 많죠ㅡㅡ;;).

하지만 XP 프로세스에서는 계약과 현실의 차이를 고객이 조율하게 함으로 그 과정에 발생 할 수 있는 오해와 갈등을 이해와 화해의 수준으로 해결 하고 있습니다.
고객은 프로젝트 자원을 더 널리지 않고 범위를 가지고 변경된 요구사항을 조정하게 되며, 고객의 요구사항이 변화게 되더라도 결국 개발사의 전체적 비용은 초과 되지 않습니다. 즉 다시 계약 할 필요가 없죠(정말 이거 행복 합니다. 고객에게 추가 계약 이야기 하기는 정말 싫습니다.ㅜㅜ)
여기서 가장 중요한 것은 XP의 프로세스에서는 고객에게 가장 가치가 있는 스토리가 먼저 구현되고 프로젝트 전반에 걸쳐 다듬어 지며, 프로젝트가 완료되기 전 빠른 시간에 고객의 손에 넘어 간다는 것 입니다. 범위의 조정으로 계약 예산의 뒤쪽에 있는 즉 지정된 예산안에 처리가 되지 못하는 스토리들은 고객에게 상대적으로 먼저 수행되고 개발된 스토리보다 덜 중요한 스토리 이며, 개발사가 전체 스토리를 모두 구현하지 못하더라도 최소한의 계약 사항에 명시된 고객에게 제공해야 할 가치는 성공할 수 있는 것입니다.
전체를 망치겠습니까? 우리가 할 수 있는 중요한 몇 개라도 잘 하시겠습니까?ㅎㅎ
행복한 하루 되세요!

'Requirement' 카테고리의 다른 글

사용자 스토리 브레인스토밍(사용자 찾기)  (1) 2008.10.27
요구사항의 정의  (0) 2008.09.25
|
blog comments powered by Disqus

matrim's Blog is powered by Daum & tistory