번호표 발급기를 설치하고 싶습니다.

저는 1번의 가정이 틀렸기 때문에 그 나머지도 잘 되지 않는것이 아닌가 하는 상상을 해봤습니다. 물론 불가능하다는 이야기는 아닙니다만.

빌딩을 짓는 것과 같이 만들고 나서 수정할 수 없다면 만반의 준비와 분석 설계를 요구하게 됩니다. 사용자들도 이것은 한번 짓고 나면 고칠 수 없다는 것을 잘 알고 있기 때문에 계획 단계에서 모든 요구를 끄집어 내려고 자발적인 노력을 합니다.

소프트웨어 공학의 결과물 자체는 언제든 변형, 수정이 가능합니다. 그리고 사용자들도 이를 잘 알고 있습니다. 모든 소프트웨어에 버전 번호가 붙여지게 되는 의미에는 분명 변화에 대한 가능성을 염두에 두었을 것입니다.

1을 완벽히 끝내고 2, 3을 진행하기 보다는 적당한 1의 과정을 거쳐 2, 3을 진행하고 1로 다시 되돌아가는 반복 작업이 가장 소프트웨어 개발에 자연스러운 방법이지 않을까 생각이 됩니다.

강 한가운데 3백 미터 높이의 기둥 박는 작업을 끝마치고 '아 잘못 박았네' 이런 대사를 내뱉기는 정말 힘들죠. 그래서 그만큼 계획 준비 단계에 더 노력을 쏟는것 같습니다.

'기둥 잘 박혔는지 보시고 맘에 드시면 다음 기둥 박읍시다' 이런게 소프트웨어(디지털)의 장점이 아닌가 생각됩니다.

전 비록 현업은 아니지만 애자일 선언, 익스트림 프로그래밍에서 말하는 내용들이 소프트웨어를 만들어 나가는데 보다 보다 자연스러운 방법이 아닌가 생각합니다.

완벽한 설계 -> 변할수 없는 결과물

적당한 설계(요구) -> 구현 -> 의견 수렴 -> 반복 ...

--
마잇

많은 경우 요구사항이 잘 나와있지만 SI쪽, 특히나 공무원들과 일하는 경우에는 0번이 잘 안된다고 들었습니다.
제 경험은 아닙니다.

들은 대로 생각해 보면 여러 부서(혹은 사람)에서 여러가지를 요구하는데 가장 중요한 것이 무엇인지 알 수 없는 경우가 많아서 더욱 그런것 같습니다.

소프트웨어는 도구라고 봅니다.

이걸 쓰려는 사람이 자신의 사용 용도를 명확히 하고 이걸 기준으로 만들어 달라고 해서 만들면 그런대로 괜찮은 도구가 나올꺼라고 예상합니다.

하지만 다른 방식으로 만들어지는 소프트웨어도 있죠.

자신이 쓰려고 개발을 의뢰하는게 아니라 불특정 다수가 쓰게(많이)하려고 개발을 의뢰하는 경우는 개발에 따른 스펙 변경이 생길수도 있습니다. 이런데서는 XP같은 방법론이 꼭 필요할 것 같습니다. 우선 만들어 놓고 여러가지 추이를 봐가면서 변경할 수 있는 상황입니다.

마지막으로 제일 난감하고 제 경험상 많이 발생하는 상황은..
자신도 쓸 생각이 없고 어떤걸 원하는지도 모르며 불특정 다수가 어떻게 생각하는지에도 관심이 없습니다.
단지 위에서 압력만 들어오지 않고 조용히 지나가기만 하면 됩니다. 대화같은것도 별로 원하지 않습니다.
자신도 잘 모르고 관심없는 어떤걸 잘(가장 중요) 만들어 달라고 합니다.
이건 개발에서만이 아니라 다른 곳에서도 발생할 수 있는 상황이죠.
심지어 같이 일하는 개발자들 중에도 이런 사람들이 종종 있습니다.

아마도 budle77님께서 말씀하시고자 하는게 이 마지막 상황이 아닌가 생각됩니다.
이 경우에는 어떤 도구를 쓰더라고 소용 없다고 생각합니다.
그냥 접고 나오시거나, 포기하시고 하는데 까지 해보시는 방법 밖에는...

왠지 제가 더 흥분해 버린것 같네요.. ㅡ,.ㅡ