애자일 적용사례
개요
해당 PL의 도입 의지를 통해 프로젝트에 애자일을 도입
애자일 적인 요소를 현장상황에 맞게 변경
삼성코닝정밀소재 구매 SRM 시스템 구축 프로젝트 시 애자일의 프렉티스 몇 가지를 도입하여 프로젝트를 수행하는 과정에 있어 나타난 여러 지표들을 다루고자 한다. 해당 프로젝트는 삼성코닝정밀소재 사의 ERP 고도화 프로젝트의 일부였으며 전체적인 틀에 있어서는 프로젝트 공통적인 형태를 따라야 했으므로 일부 적용가능한 부분을 찾아 애자일 프렉티스를 진행하는 형태로 병행 하기로 하였다. 따라서, 애자일한 방법이 현재 시점에 어느정도 영향을 미칠 수 있고, 또, 적용하는 과정에 해결해 나가야 할 부분은 어떤 부분인지 정리하고자 한다.
SRM 시스템 구축 프로젝트는 OPEN PMS를 통하여 진척 관리를 진행하였고, 팀 내 방법론과는 별개로 주간 보고와 월간 보고를 진행해야 했다. 실질적으로 팀 내에서 통용하는 산출물은 코딩 리스트와 테이블 정의서, 인터페이스 정의서 만을 유지 하였지만 ERP 고도화 프로젝트의 기준에 맞춰 화면정의서, 프로그램 사양서, 단위테스트 시나리오, 통합테스트 시나리오 등을 추가적으로 작성하였다.
이번 프로젝트는 현행 시스템을 새로운 ERP에 맞게 재 개발 하면서 그동안 적재 되었던 요구사항들을 새로운 시스템에 반영하는 것을 과제로 하고 있다. 그에 따라 현행 시스템을 분석하고 필요한 요구사항들을 도출하여 정리하는 기간이 필요하였지만 당시 상황 상 이 부분에 많은 어려움을 겪고 준비가 부족한 상태에서 출발하게 되었다.
이로써 애자일적인 요소들이 도움이 된 부분도 있고 또 문제점을 드러낸 부분도 있다. 이 점을 한 부분씩 짚어보고자 한다.
애자일 요소
Daily Scrum, Sprint, Weekly Testing, Time Boxing
이번 프로젝트에 적용된 애자일 프렉티스는 다음과 같다.
Daily Scrum
Opening Meeting 이라는 이름으로 Iteration 진행 현황을 공유하기 위해 매일 아침 진행하였다. 별도의 스크럼 팀을 유지하지 않고 전체 팀 단위로 편성되었기 때문에 팀 전원이 참석하여 어제 한 일, 오늘 할 일을 얘기 하고 이슈 및 장애 사항을 공유하였다.
Opening Meeting 은 초반에 많은 도움이 되었다. 프로젝트 경험이 미숙한 외주 PL이 설계/개발 단계 이전에 요구되어지는 요구분석 및 아키텍쳐 정의가 제대로 이뤄지지 않아 개발 초기 많은 이슈와 장애 사항이 속출하였다. 이러한 이슈나 장애 사항을 모든 팀원들이 매일 아침 나누는 회의를 통해 도출되어지고 이를 해결할 전임자가 결정되는 과정이 반복되어 약 한달여 뒤에는 개발과 동시에 아키텍쳐가 상당히 안정화 되고 고객에게 대응하는 범위가 정해지는데 많은 도움이 되었다.
하지만 이 과정이 어느정도 마무리 되고 난 후에는 모두가 공통된 이슈 사항이 많지 않아 별반 관련 없는 이슈를 듣기위해 모두가 모여 시간을 보내는 모습으로 변질되었다. 그리고 스크럼 마스터 역의 PL이 이 미팅을 개인적인 업무 정리의 시간으로 오용하는 모습이 있어 팀원 모두가 이 부분에 대해 불만이 커지고 회의에 대해서 부정적인 견해를 갖게 되어 잘못된 결과를 핑계로 변호하거나 이슈 자체를 언급하기 꺼려하는 부작용까지 나타나게 되었다.
결과적으로 Opening Meeting은 개발 중반에 폐지 되었다.
좋은 부분은 모든 팀이 공유하고 해결해야 할 부분들이 초반에 빠르게 도출되고 해결되었다는 점이다. 반면, 스크럼 팀을 구분하지 않아 현재 개인과 크게 관련 없는 부분까지 그 내용을 듣는 것에 너무 많은 시간이 허비되어 보통 15분 내외라는 기준에 어긋난 모습이 원래 취지와는 다른 부작용을 낳았다. 이로써, Daily Scrum은 스크럼 단위를 잘 조절하여 업무 유관하게 회의를 진행하는 것이 훨씬 효율적일 것 이다. 물론 장점을 무시할 수 없기 때문에 팀 단위의 스크럼에서 도출된 이슈를 모두 공유할 수 있는 형태로 Scrum Of Scrum을 시행하거나 1주일에 한 번정도 Whole Team Scrum을 진행하도록 하는 방안을 고려해 보았다.
Sprint
Iteration 이라는 이름으로 업무설계 > 개발 > 코드 인스펙션 > 고객 테스트 > 이슈관리 까지 1주 내지 3주 길이로 유동적으로 진행하는 Sprint를 사용하였다.
Iteration은 해당 Iteration에서 주어진 부분에 대한 업무 설계부터 고객 테스트 까지를 한번에 담고 있어서 Iteration이 한번 끝나려면 고객의 확인이 있어야 하고 이를 통해 자연스럽게 매 Iteration 마다 고객 참여가 이뤄졌다. 고객 테스트는 Iteration 내에 한번에 끝나는 것이 아니고 Iteration 안에서도 에러나 요구사항 변경이 발생할 때 마다 설계부터 테스트 까지 과정을 지속적으로 반복함으로써 잦은 고객의 요구를 수용할 수 있도록 진행되었다.
이는 분명 좋은 사항이나, 개발에 많은 변경사항이 발생한다는 것은 그리 건강한 부분은 아니었다. 먼저 고객들이요구사항이 변경되도 비교적 쉽게 받아들여질 수 있다 여겨 필수적이지 않은 요구사항까지 등장하여 시스템을 오염시키는 경우가 많았다. 심하게는 설계조차 빈번히 변경되어 그에 따른 추가공수가 많이 발생했음에도 불구하고 이 부분에 대한 정당한 댓가를 요구할 수 없었다. 또한, 개발이 완료될 것으로 기대한 부분에 대해서 오류가 아닌 빈번한 요구변경으로 수정이 일어나는 것은 정성적으로 팀원에게 좋은 일은 아니었다.
변경이 수월할 수 있도록 유연한 설계에서 시작하지 않은 것이 빈번한 변경 요청을 만나면서 프로젝트 말기에 좋지 않은 부분으로 작용했다. 이는 Sprint 형태에 목적 중에 하나인 지속적인 고객 참여와 유연한 요구사항 변경을 제대로 성립시키기 위한 전제조건으로 고객으로 부터의 일방적 참여가 아닌 상호 소통에 의한 팀 정신 공유와 변경을 충분히 수용할 수 있는 유연한 설계가 필요하다는 뜻이다.
Product Backlog
Coding List 라는 이름으로 앞으로 진행해야 할 요구사항 도출 목록을 유지하였다. 설계, 개발에 있어서는 거의 유일하게 유지 관리되던 문서이다. 매 Iteration 마다 PL이 중요도에 맞춰 업무 분배를 하였고 새로운 요구사항이 나오면 이 목록에 추가하여 관리하였다. 다른 문서는 크게 고려하지 않고 진행 되었으며 고객이 요구하거나 ERP 프로젝트에서 요구 되어지는 부분에 대해서는 변경가능한 산출물을 통해 정비되었다.
하지만 일정 상의 문제로 각 아이템에 스토리 포인트를 구하거나 중요도를 반영하는 부분은 생략되었고 이를 대체하기 위해 PL과 각 서브 PL 모임을 통해 산정되었다. 이 부분에 있어서 고객의 참여가 없었기 때문에 쉽게 일어날 수 있는 기능의 상이가 발생하였고 결과적으로 요구사항이 초기 결정에 비해 150% 로 증가하는 결과가 되었다.
그렇지만 앞서 언급한 대로 일정 상의 문제로 이미 예상할 수 있는 부분이었기 때문에 크게 팀원들 사이에 영향을 주진 않았다.
대신, 모두가 한 목록만을 주시하며 프로젝트를 진행할 수 있어서 혼선을 줄이는 데 많은 역할을 했다.
적응 요소
Openning Meeting
- Iteration 진행 현황을 공유하기 위한 미팅을 매일 아침 진행하였다. 팀 전원이 참석하여 어제 한 일, 오늘 할 일을 발표
+ Burn Down Chart나 진척관리 등 시각적인 요소가 함께 도입될 필요가 있었다.
+ 일일 스크럼이 잘못 진행되는 경우에 핑계를 대는 공간이 된다.
Iteration
- 분석단계는 선행
- 업무설계 > 개발 > 코드 인스팩션 > 고객 테스트 > 이슈관리 단계로 1주 내지 3주 길이의 유동적인 형태
+ 병행되어야 할 프로젝트 내에 한 부분으로 외부적인 이슈에 대응하기 쉽도록 Iteration의 길이를 유동적으로 결정
+ 개발 기간은 최소화 하고 고객 테스트를 통해 피드백을 Iteration 안에 적용, 요구사항 분석이 부족했던 프로젝트 사정을 많이 보완하는 방법이 되었다.
Scheduling
한계점
Product Backlog가 정확히 추출되지 못한 경우, 단순하게 일의 누락이 아니라 개발 공정이 건강하지 못할 수 있다.
- 애자일은 소규모로 개발 단위를 나누는 경향이 있다. 따라서, 소규모로 독립될 수 있도록 의존도를 낮추는 과정이 필요하다. 혹은, 의존도가 낮은 단위로 진행해야 한다.
+ 소규모로 개발이 지속 가능한 환경이 구축되어야 한다는 과제가 있다. 실제, 이번 적용사례에서는 환경 구축이 개발과 동시에 진행이 되는 일정이었기 때문에 이 부분에 많은 혼선이 발생했다.
+ 방법론과는 별개로 아키텍쳐 적인 사항이나 선행 프로세스, 공통 프로세스 등 개발 중요도가 높은 부분을 누락하지 말아야 한다.
애자일에 대한 지속적인 교육이 필요함
- 전체 프로젝트에서 요구하는 산출물 및 공정 단계에 얽매여 진행이 이중적이 됨
- Openning Meeting이 PL의 업무 보고 형태로 변질되면서 폐지되었다. 제대로 기능하지 않는 점을 적극 수용했다는 점은 긍정적
Due Date를 통한 관리에 대한 요구
- 일정에 대한 진척관리 측면에서는 관리자 입장에서 좋겠지만, 관리자가 Command & Control 스타일을 버리지 못하는 경우에는 기존의 관리 방법처럼 팀원들을 일정을 두고 푸쉬하는 스타일을 벗어나지 못하며 Agile을 적용한다고 함에도 불구하고 팀원들은 Agile을 체감하지 못하고 일정으로 관리자에게 쪼임을 당한다고 생각할 수 있어 확산에 마이너스 => Self Organizing이 어려워 짐