Agile Note 세 번째
[애자일 개발 : 문서와 산출물]
애자일 방법론으로 소프트웨어를 개발할 때 어느 정도의 문서화 작업 또는 산출물 작업이 필요할까요? 애자일이 보편화되지 않은 우리에게는 많은 논란거리가 아닐 수 없습니다. 물론 제품으로 개발되는 Off the Shelf SW의 경우 제품사양서, 사용설명서 등 여러 형태로 고객들에게 전달되어야 하는 문서들이 있습니다.
그러나 제품형태의 SW 일지라도 애자일 방식으로 개발을 진행할 당시에 개발자들간 합의되는 문서의 종류와 범위, 개발 스프린트가 진행되면서 문서가 어떻게 구체화될 것인지의 여부, 개발종료시점에 전달되어야 하는 최종적인 문서의 종류와 깊이는 여전히 어려운 논의사항입니다.
어떤 문서를 Delivery할 것인지에 대한 의사결정이 비교적 명확한 제품SW에서도 쉽지 않은 결정인데, 전형적인 SI개발에서 애자일 방법론을 적용하고 필요한 문서들을 정의하는 작업은 꽤 혼란을 초래합니다. 물론 가장 교과서적인 접근은 ‘애자일 문서화는 필요한 만큼’ 이라는 간단명료한 문구를 따르는 것이지만, 주어진 현실에서 교과서가 제시하는 간단하고 명쾌한 정의를 따라가는 작업은 매우 지난하고 쉽지 않은 시간인 것 같습니다.
저희가 시도하고, 경험하고, 개발 Practice에 체화 시키려고 했던 ‘애자일 문서화’에 대한 이해를 간략히 공유합니다.
개발했던 어플리케이션의 업무와 특징에 대한 설명이 포함되어야 이해가 쉽겠지만 대외비인 관계로 SW자체에 대한 상세한 설명은 생략하겠습니다. 작년 5월 이후 비교적 가벼운 비즈니스 기능을 가지는 3개의 다른 어플리케이션 개발을 시작했습니다. 국내의 Product Owner들이 Off-Shore 개발센터에 개발을 의뢰하는 형태로 작업이 진행되었고, 애자일 방법론 중 스크럼을 사용하여 개발했습니다.
스프린트는 2주(2 Weeks) 간격으로 진행되었습니다. 국내의 프로덕트 오너와 해당팀은 대부분 애자일을 처음 접해보는 분들이었습니다. Off-Shore 개발센터의 인력들은 애자일에 대한 경험을 보유하고 있었지만 충분해 보이지는 않았습니다.
초기에는 ‘최대한 상세하게 기술된 설계문서를 작업지시서 형태로 전달해야한다.’ 라는 의식이 강하게 지배했습니다. 그러나 국내 SI 개발처럼 분석/설계기간이 별도로 계획되어 있지 않고, 국내 설계인력들도 상세한 설계문서의 디자인에 익숙하지 않은 상황에서는 쉽지 않은 일이었고 초기 혼란이 있었습니다.
결국 가장 중요한 논의는 첫 번째 개발 스프린트를 시작하기 위해서 준비되어야 하는 문서는 어떤 것이고 어느 정도의 깊이를 가지고 있어야 하는가? 라는 물음에 대답하는 것이었습니다. 그리고 스프린트를 몇 번 정도 지나야 문서의 완성도가 100% 수준에 도달하느냐가 두 번째 논의사항 있었습니다. 마지막으로 공정진행 중, 개발 완료 후의 단계에서 만들어져야 할 (또는 필요한) 문서의 종류는 무엇이고 깊이는 어떻게 정리해야 하나? 라는 것이었고 여전히 여러 대안들을 좁혀가고 있는 중입니다.
첫 번째 개발 스프린트를 진행하기 위해서 Discovery Phase(약 2주)라는 준비기간을 두었습니다. (물론 애자일 교과서에도 이런 형태의 준비기간에 대한 언급이 있습니다). 저희는 Discovery 이전 Pre-Discovery에서부터 해당 프로젝트에 대한 이해수준을 높이는 활동들을 진행하였습니다.
Discovery 기간 동안 초기 개발스프린트를 위한 사용자스토리 구성과 상위수준의 아키텍처(High Level Architecture), 개발환경 구성, 개발표준(초안), DB표준(초안), UI/UX기획(초안) 등에 대한 작업을 진행합니다.
상위수준 아키텍처와 개발표준, DB표준, UI/UX 등은 2회의 스프린트(약 4주)에 걸쳐 구체화되는 작업을 진행합니다. 대형 어플리케이션의 경우에는 더 많은 횟수의 스프린트가 지나야 구체화되겠지요.
결국 Pre-Discovery, Discovery 라는 준비기간 동안에 할 수 있는 최대한의 개발준비를 완료하고, 스프린트가 반복되는 동안 정의되어야 할 문서가 구체화되어간다는 뻔한 주장은 피할 수가 없습니다.
문서화, 산출물 등은 업무담당자, 설계자, 개발자 등이 개발해야 할 대상에 대해 서로 간 동일한 아이디어와 방향을 공유하는데 필요한 커뮤니케이션 수단이 되겠지요. 해당 Stakeholder 들이 이해할 수 있는 수준이라면 문서화의 수준이 충분한 것으로 판단됩니다. 지난 포스팅에서 언급한 Homogeneous 한 팀구성을 가지고 있다면 문서화도 조금 더 유연하게 접근 가능하고, 문서의 종류나 깊이, 만드는 시기 등에 대해서도 의사결정 과정이 여유로울 수 있을 것 같습니다.
하지만 Off-Shore 개발의 경우, 이야기는 많이 달라집니다. 방법과 그 기저에 있는 철학은 애자일이지만 많은 부분이 정교하게 디자인되는 것이 생산성을 향상시키는 것으로 보입니다. 문서(작업지시서)가 상세하고, 다양한 관점의 설계문서가 있고, 이런 문서들을 바탕으로 JIRA(프로젝트 관리툴)의 사용자 스토리로 정리되는 것이 필요합니다. 사용자 스토리가 상세할수록 Verbal Communication 횟수와 이중, 삼중의 작업을 줄이게 됩니다.
결국 정교하게 Crafting 된 문서와 Activity는 작업의 근간이 되고 이를 기반으로 그 위에서의 유연함이 가능하게 됩니다.
드라이퍼스 모델(Dreyfus Model of Skill Acquisition)에서 주장하는 레시피 또는 매뉴얼로서의 문서화는 Off-Shore 개발에서는 여전히 중요한 일로 다루어야 합니다(비록 애자일이라도).
다른 개발문화, 일하는 방식의 차이와 언어의 불편함을 가지고 있는 집단간의 협업(Collaboration)은 숙련된 기술인력조차도 창의성과 유연성을 발휘하기위한 토대가 필요합니다. 그 토대가 바로 정교하게 고안된 일하는 방식과 필요한 문서 그리고 그 깊이에 대한 공유된 정의라고 생각합니다.
#애자일 #Agile #스크럼 #Scrum #Offshore_development #Agile_document
