아래 내용은 KLDP 에서 몇 해 전 사용자 스토리에 대한 개발자 분께서 남겼던 질문에 대한 대답을 한번 해 본 것 입니다.
Q: 지금 사용자 스토리를 읽고 있습니다. 몇 년 전에 XP를 읽고 느꼈던 감동이 다시 오더군요. 그때도 지금도 고민되는 문제점이 있습니다. 제가 XP를 처음 접할 때 저는 벤처기업에 있었고 개발이 상당히 어렵게 진행되고 있었습니다. 대표적으로 회사가 상하로 나누어져 위에서는 개발자를 재촉하고 개발자는 수동적으로 따라가는 구조였습니다. 저는 그때 개발팀을 이끌고 있었고, 그래서 그런 현실이 안타까웠습니다. XP를 읽고 한번에는 안되겠지만 점차 적용을 해야겠다고 생각하고 개발자들과 회의 시간에 XP를 알렸습니다. 그런데 그때의 개발팀의 멤버는 아주 비관적인 말을 했지만 저도 답변을 할 수가 없었고, 지금도 마찬가지 입니다.
"스토리를 만드는 것이 일을 크게 하는 것이 아닌가?. 주어진 데로 하는 것도 쉽지 않은데 스토리를 작성해서 일이 커질 경우 개발 비용을 고스란히 개발팀이 떠 안아야 한다."
이렇게 요약을 할 수 있는데요. 이 부분에 대해서 어떻게 생각하시는 지요? 예를 들면 지금 제가 개발 업체를 다니고 있고, 이번에 우리 회사가 카드회사의 새로운 프로젝트를 맡았다고 할 경우에, 이미 제안서와 요구사항에 의한 비용산출이 끝난 이후 개발팀이 투입이 될 것입니다. 개발팀의 팀장은 XP를 이용하고자 했습니다. 카드회사의 새로운 프로젝트를 사용하는 사용자를 만나 미팅을 해서 프로젝트를 좀더 효과적으로 성공시킬 수 있는 아이디어를 도출할 수 있었습니다. 새롭게 도출된 결과는 카드 회사입장에서 상당히 장점이 있는 것으로 카드 회사는 제가 다니는 회사와 협의를 하게 될 것입니다.
이때 제가 다니는 회사에서 "왜 긁어 부스럼을 만들 어냐?"라는 말이 나올 수 있습니다. 많은 경우 아이디어는 일을 크게 하는 경우를 많이 봤습니다. 이런 경우에, 반복 주기에 고객의 의견을 반영함으로써 프로젝트의 완성도는 좋아지지만 점차 발생하게 되는 비용의 문제는 어떻게 해결해야 하는지요? 외국의 경우, 반복 주기마다 계약된 금액이 변경될 수 있나요?. 또는 국내 프로젝트에서는 어떤가요? 계약사항이 있는데도 "갑"이라는 이유로 요구사항을 변경하는 경우도 비일비재한데, 개발팀이 스토리 확장 및 변경에 관한 비용 문제를 어떻게 이겨내야 할까요?
A : 제 경험과 생각으로는 어차피 XP 나 기타 다른 Agile Process 가 아닌 전통 적인 개발 방법론을 사용하더라도 사용자의 기대 수준과 기획 시 계획의 차이는 해결해야 할 문제 인 것 같습니다. 프로젝트의 계약 시 보통 아주 세부적인 사항까지 계약하지는 않습니다. 개발 되는 시스템의 목적과 용도 에 입각해서 세부 사항은 숨기고 고객의 필요한 요구사항을 충족 시킬 것이라는 계약만 이루어 질 뿐입니다. 가령 계약이 기존의 이미 존재하는 시스템을 도입하여 프로그램의 세부 적인 구성을 고려하여 계약 되게 되더라도 실제 개발에서의 고객 요구 사항은 계약 내용과 상이한 점이 존재 할 수 밖에 없습니다. 그렇다고 고객의 요구를 무시하고 계약 되로 개발 할 수는 없죠? 그래서 소프트웨어 프로젝트의 개발 동안 PM 들은 계속 고객과 회사 등 프로젝트 전반에 걸쳐 이해관계가 있는 곳과 조율과 이해를 구하게 되는데 전통적인 개발 방식에서는 이 능력은 전적으로 PM의 역량에 의존하는 경향이 입니다(술로 해결하는 사람들도 많죠ㅡㅡ;;).
하지만 XP 프로세스에서는 계약과 현실의 차이를 고객이 조율하게 함으로 그 과정에 발생 할 수 있는 오해와 갈등을 이해와 화해의 수준으로 해결 하고 있습니다.
고객은 프로젝트 자원을 더 널리지 않고 범위를 가지고 변경된 요구사항을 조정하게 되며, 고객의 요구사항이 변화게 되더라도 결국 개발사의 전체적 비용은 초과 되지 않습니다. 즉 다시 계약 할 필요가 없죠(정말 이거 행복 합니다. 고객에게 추가 계약 이야기 하기는 정말 싫습니다.ㅜㅜ)
여기서 가장 중요한 것은 XP의 프로세스에서는 고객에게 가장 가치가 있는 스토리가 먼저 구현되고 프로젝트 전반에 걸쳐 다듬어 지며, 프로젝트가 완료되기 전 빠른 시간에 고객의 손에 넘어 간다는 것 입니다. 범위의 조정으로 계약 예산의 뒤쪽에 있는 즉 지정된 예산안에 처리가 되지 못하는 스토리들은 고객에게 상대적으로 먼저 수행되고 개발된 스토리보다 덜 중요한 스토리 이며, 개발사가 전체 스토리를 모두 구현하지 못하더라도 최소한의 계약 사항에 명시된 고객에게 제공해야 할 가치는 성공할 수 있는 것입니다.
전체를 망치겠습니까? 우리가 할 수 있는 중요한 몇 개라도 잘 하시겠습니까?ㅎㅎ
sumer 왈 : 그런데 여기서 한가지 문제가 더있을 수 있습니다. 고객의 고집 입니다. 결국 사용자 스토리를 이용한 XP 개발 방법에서는 고객의 이해와 협조 를 요구 하게 되는데요 PM 또는 대고객 업무를 당담하고 있는 책임자가 고객과의 관계 또는 고객의 이해를 끌어 내지 못 했을 경우 아주 심각한 위기에 쳐 하게 됩니다.
실제 이번에 6개월 정도 진행한 이랜드 시스템즈의 소극장 예매 시스템의 경우 고객의 이해를 받지 못 했습니다.
고객은 모든 자신들의 요청이 반영되기를 원했고 시간도 엄수하기를 원했습니다. 그리고 비용 추가도 거부 했죠
결국 계획은 무산 되고 계약도 슬그머니 숨어 버렸으며, 개발자는 개발 중반에 계약기간 완료로 프로젝트에서 빠져버리는 무시무시 한 상항이 왔습니다.
솔직이 저 를 포함한 프로젝트 팀(고개도 포함 입니다.^^) 엄청난 마음의 고생을 했고 서로의 갈등이 많이 깊어 졌습니다.
왜 이런 일이 일어 났을까 ? 생각 해보면 이유는 단 하나 였습니다. 당시 PM은 고객 쪽에 끌려 다니고 있었습니다.
결국 개발쪽의 일정 위험 신호나 요구사항에 대한 타협 의견 등은 모두 무시 되었고, PM은 단 한마디로 그런 위험 사항을 정리 해벼렸죠! '밤새워서 라도 다 해주세요!'
그 한마디에 개발자들의 사기는 물론 개발 프로세스를 적용할 수 조차 없는 그냥 개발자들에게 늦은 퇴근 강요하고 달래고 주말 근무 요청하고 뭐 이런 씩으로 프로젝트 관리가 변질 되어 버렸습니다.
절대 PM 이나 프로젝트에 대한 관리를 책임 지시는 분은 저런 실 수를 하지 않기 바랍니다.
행복한 하루 되세요!