스크럼(Scrum)과 애자일(Agile)

예전에는 프로젝트가 시작하기 전에 요구사항을 모두 "수집"하고 "분석"하여 "정리"한 후 "확정"하는 것을 당연한 일로 받아들였다. 물론 real world에서는 그렇게 되는 프로젝트는 내가 수행하는 프로젝트는 물론 주위에서도, 아니면 내가 아는 모든 소프트웨어 개발 프로젝트에서도 거의 찾아보기 어렵다는 사실을 깨달게 되었다. CMMI적으로는 일단 "확정"하고 "변경관리"를 하면 되지 않느냐라고 할 수 있으나 고객이나 개발자입장에서 "변경관리"를 수행하는 것은 상당한 고통이 따르기 마련이다(개인적으로 GM과 일년 넘게 변경관리에 목을 매고 수행해본 결과이다)

결국 고객은 완성된 제품을 보고 써본 후에나 이제 제대로된 요구사항을 내놓수 있다는 사실을 인정해야 했다. 만약 그것이 fact라면 우리가 해야 할 행동은 우직하게 계속 요구사항을 프로젝트 시작단계에서 최대한 많이 확정지으려할 것이 아니라 최대한 빠른 주기로 고객에게 보여주면서 요구사항이 자연스럽게 흘러나오고 stable해질 수 있도록 돕는 것이 더 자연스러운 선택이라고 할 수 있을 것이다.

아래는 현재 번역하고 있는 스크럼 책에서 슈와버가 자신의 경험을 들어서 이 부분에 대해 설명하고 있는 부분을 인용해보았다:

내가소프트웨어 개발을 시작했을 당시에는 고객 참여와 협업은 전혀 문제가 되지 않았었다. 60년대에는 컴퓨터가그다지 강력하지 못해서 사용자도 적었고 응용프로그램도 단순했으며 단계별로 마일스톤을 가져간다는 개념도 아직 알려지지 않을 때였다. 나는 하루나 이틀짜리 짧은 반복주기를 사용하고 있었다. 나는 고객과만나서 함께 고객이 원하는 바를 종이에 스케치하곤 했다. 우리는 내가 완전히 이해할 수 있을 때까지의견을 서로 주고받았다. 그리고 난 뒤 나는 내 책상으로 돌아가 솔루션을 설계하고 코딩한 후 펀치카드에천공을 하고 천공한 카드로 컴파일을 했다. 컴파일과 링크가 성공적으로 끝나면 나는 시험용 데이터를 입력해서동작시켜보았다. 그런 다음 나는 고객에게 돌아가 “이것이당신이 원하던 것입니까?”하고 물었다. 우리는 그때 미처이렇게 할 수 있는 것이 천국이라는 사실을 깨닫지 못했다.

 

응용프로그램과기술이 점점 복잡해짐에 따라 프로젝트에 관여하는 이해관계자도 늘어났으며 이렇게 증가된 참여자들간의 의사소통을 조정하기 위해 여러 실천 방법이 도입되었다. 예를 들어, 많은 이해관계자들이 참여하고 있으므로 우리는 개발을시작하기 전에 그들의 요구사항을 모두 수집하기 시작했다. 우리는 시스템은 그들 각각의 요구사항 모두를반영하여 구축되어야 한다고 느꼈다. 문서는 의사소통을 위한 매체로는 적당치 못했으므로 우리는 서로 의사소통하기위해 그림을 사용하기 시작했으며 이 그림들을 글로써 보완했다. 하지만 그림은 부정확했으므로 우리는 그림을형식화시켜 표현할 수 있는 모델링 기술을 개발했다. 각각의 단계는 이해관계자와 개발자 사이에 쐐기를박는 셈이었다. 우리는 얼굴을 맞대고 하는 의사소통에서 문서기반의 의사소통으로 가버렸다. 우리는 신속한 왕복에서 길고 지루한 요구사항 수집 단계로 가버렸다. 우리는단순한 언어에서 애매하면서도 고도로 상세화된 산출물로 가버렸다.

 

되돌아보면, 우리가 소프트웨어 엔지니어링의 실천 방법을 개선시킬수록 우리는 관련자와 개발자간의 거리를 점점 넓히고 있는셈이었다. 이렇게 소원해지고 있던 관계에 마지막으로 종지부를 찍은 것이 바로 순차적 개발의 모든 단점을담고 있었던 폭포수 방법론(waterfallmethodology)의 도입이었다. 폭포수 방법론에서는 모든 요구사항을 모은 뒤설계를 만들어 내며, 그 다음에 코드를 작성한다. 그 뒤테스트를 개발하고 실행한 뒤 마지막으로 시스템을 설치하게 된다. 이러한 각 단계 사이에는 검토 회의가존재한다. 관련자들은 이 검토 회의에 초청받아 그때까지의 진척사항에 대해 검토하게 된다. 이 회의에서 관리자와 개발자들은 고객에게 다음과 같이 물어보게 된다. “우리가수집한 요구사항과 이를 기반으로 구축한 모델이 당신이 원하는 것을 정확하게 모두 나타내고 있습니까? 만약당신이 그렇다고 대답한다면 그 뒤부터는 이에 대해 변경하는 것은 비용이 증가하게 될 것입니다!” 대화에서알 수 있듯이 이것은 고객과 개발자간의 계약을 나타낸다. 이 시점까지 서로간의 협업은 거의 없었는데다짜고짜 계약하는 자리에서 “만약 내가 당신에게 보여준 것이 당신이 원하는 것에 대한 완전한 설명이라면일을 진행하도록 합시다. 하지만 만약 당신이 동의할 수 없다면 당신이 포기할 때까지 요구사항을 개발하는일을 계속할 겁니다!”라고 말하는 셈이었다.

(중략)