1. 컨설팅 개요

SW 유지 보수조직(7명)을 대상으로 SW 개발 진행현황의 투명성과 생산성을 높이고 테스트 및 릴리즈 단계에서 발견되는 결함 감소를 목표로 진행하고자 한 사례이며 컨설팅 목표는 아래와 같다. 

• SW개발 진행 현황의 투명성

• 유지보수의 효율성 및 생산성 향상

• 통합테스트 및 릴리즈 단계에서의 결함 감소

2. 적용 전 상황

- 해당 팀의 유지보수 관리 시스템에서는 서비스 요청(Service Request)의 등록 및 완료 여부만 관리되고 실제 진행상황은 관리되지 않고 있어 개발자들이 무슨 일에 보틀넥이 걸려있으며 어떤 애로사항이 있는지 알기 어려워 팀장 입장에서 업무진행 현황파악에 어려움이 존재하였음(팀원들에게 진행상황을 물어보면 간섭하는 것으로 오해받기 쉬워 이러지도 저러지도 못하는 상황이었음)

- 개발자들이 Service Request를 완료한 후에 QA팀에서 주관하는 통합테스트 단계에서 사이드 이펙트에 의한 결함이 자주 발생하고 있었으며 이를 수정하는 데 또 다른 노력이 소요되고 있었음

- 유지보수 환경에서 1~2개월짜리 소규모 프로젝트를 수행하기 위한 개발방법론이 존재하지 않고 개발리더의 경험에 의존해서 프로젝트를 수행하고 있어 개발진행의 투명성이 부족함 (상세 WBS가 미흡하며 진행상황이 투명하게 관리되지 못함)

3. 수행내용

해당조직은 팀의 파트리더(Part Leader)가 중심이 돼서 개발자에게 업무를 할당하고 개발자들은 할당된 업무만 수행하는 전형적인 개발조직으로 초기에 해당 팀을 대상으로 Agile 방법론 워크숍을 1일 정도 수행하였으며 이후에도 프로젝트 코칭을 통하여 팀장과 팀원들의 마인드셋 변화를 지속적으로 이행하였다. 

유지보수 업무는 단발성의 서비스 요청을 처리하는 기본 업무와 1~2개월 정도되는 소규모 프로젝트성 업무 2가지로 구별될 수 있는데 해당팀은 2가지 성격의 업무가 동시에 발생하는 상황이라 Agile 방법론중에서 가장 많이 활용되고 있는 칸반(Kanban)과 스크럼(Scrum)을 모두 적용함. 워크숍이 끝나고 제일 먼저 시작한 것은 서비스 요청(SR) 건에 대한 업무 처리방식을 변화시키는 것이었다. 기존 방식은 팀의 파트리더(Part Leader)가 먼저 SR을 분석한 후에 개발자에게 할당하고 개발자들은 할당된 업무만 수행하였는 데 새로운 방식에서는 팀원들이 모두 참여하여 SR들을 분석하고 Planning Poker 기법을 사용하여 최적의 수행방법과 예상공수를 추정하였다. 그리고 업무에 대한 할당도 파트리더가 하는 것이 아니라 팀원들이 스스로 선택해서 업무를 수행하는 자율적 방식을 도입하였다. 

팀에서 수행했던 2개월짜리 소규모 프로젝트도 스크럼을 도입하여 전체 릴리즈 계획 및 2주 단위의 스프린트 수행, 데일리 스크럼 등을 통하여 팀원들의 자발성을 이끌어내었고 서로 협력하여 개발하는 문화를 촉진시키었다.  또한 통합테스트 및 릴리즈 단계에서의 결함을 감소시키기 위하여 팀원 공동으로 코드를 리뷰하고 점검함으로써 사이드 이팩트에 의한 결함을 줄이려고 노력하였다.

                                      [데일리 스크럼 진행 모습]

해당조직은 명령과 통제중심의 관리방식과 개인 중심의 업무 수행이 팽배해 있는 관계로 모두 각자의 역할만 충실히 수행하고 있었으며 서로간에 커뮤니케이션이 활발하지 않았으나 애자일 방법론을 도입하면서 업무 목표를 달성하기 위하여 각자의 역할에 국한되지 않고 서로 협력하는 문화를 확산하게 되었다. 처음에는 아침에 서서 하는 데일리 스크럼과 스프린트 계획 등 협력하고 소통하는 애자일 개발 문화가 익숙하지 않아 약 2달간 거부감과 반발이 있었으나 실제로 개발의 효율성과 품질이 높아지는 것을 경험하고 나서부터는 팀원들이 자발적으로 애자일 프랙티스를 적용하게 되었다.

                      [Planning Poker를 이용한 진행 모습]

4. 정성적 성과 (3개월 적용 후)

- 업무 진행상황의 가시성이 좋아졌다.

적용전에는 개발자들이 무슨 일에 보틀넥이 걸려있으며 어떤 애로사항이 있는지 알기 어려워 팀장 입장에서 업무진행 현황을 일일이 물어보아야 파악 할 수 있었는데 지금은 칸반 보드와 데일리 스크럼을 통하여 일일이 물어보지 않아도 팀원들이 어떤 문제에 애로사항이 있으며 어떤 업무에 버틀넥이 있는지 쉽게 알게 되었고 당면한 문제점들을 바로 해결할 수 있게 되었다.

- 통합테스트 및 릴리즈 단계에서 발생하는 결함이 많이 줄어듬

개발자들이 서비스 요청을 완료한 후에 QA팀에서 주관하는 통합테스트 단계나 릴리즈 후에 사이드 이펙트에 의한 결함이 자주 발생하고 있었으나 지금은 팀원들이 공동으로 협력하여 개발단계에서 사이드 이팩트를 찾아내고 수정함으로써 품질을 획기적으로 향상할 수 있게 되었다.

- 개발과정의 효율성이 높아지고 아울러 생산성도 향상됨

적용전에는 각자가 맡은 일을 혼자서 고민하고 해결하였지만 지금은 데일리 스크럼과 상호 협력을 통하여 최적의 개발방법을 찾을 수 있어서 서비스 요청 건들을 훨씬 빨리 해결할 수 있게 되었다. 

- 팀장 및 팀원들의 사기와 업무만족도 매우 높아짐

적용 전에는 파트리더가 중심이 돼서 개발자에게 업무를 할당하고 개발자들은 할당된 업무만 수행하는 형태라서 팀원들이 수동적이고 업무에 적극성이 부족했다.  또한 팀원간에 소통이 거의 없다보니 서로간에 신뢰도 부족하고 업무 만족도도 높지 않았으나 애자일을 적용하고 나서는 서로간에 신뢰도 높아지고 업무 만족도도 매우 향상되었다.

5. 정량적 성과

- 평균적으로 QA팀에서 개발팀으로 매달 8~9여건 정도의 크고 작은 재작업 요청이 있었으나 애자일을 적용하고 나서부터는 1~2건 정도로 줄어든 상태이며 그나마도 마이너한 작업이 되어 품질이 많이 향상되었다. (70% 이상 결함 감소)

- 전체 팀원 6명 중에서 신규 개발 건으로 3명이 7,8,9 3개월간 유지보수 업무를 수행하지 못하는 상황이 되었음에도 불구하고 애자일 적용을 통한 업무의 생산성이 높아져서 남아있는 3명으로도 기존의 유지보수 업무를 수행할 수 있을 정도가 되었으며 현재는 늘어난 생산성으로 인하여 기존 유지보수팀원 중의 일부를 빼내어 다른 업무를 맡기려 하고 있는 상황이 되었음 (1.5배 이상 생산성 향상)

- 처음에 애자일 방법론에 대하여 반신반의 했던 해당기업의 팀장은 품질과 생산성을 향상시키는 애자일 방법론에 확신을 갖고 조직 차원에서 다른 팀으로 확산시키려는 노력을 하고 있으며 컨설팅 결과에 대하여 매우 만족해하고 있음

6. 적용 소감

- 애자일을 통해 팀정신에 입각한 업무 협력 및 노력이 보이기 시작한 것 같다. 개인주의가 팽배한 우리 조직에 필요한 것은 팀 중심의 문화이기 때문에 애자일 사상이 잘 맞는 것 같습니다.

- 이것을 방법론으로 접근하기 보다는 어떻게 하면 우리가 일을 즐겁고 보람있게 할 수 있을까 라는 생각으로 접근하였더니 결과가 훨씬 좋아진 것 같다.

- 애자일 방법론은 개발자들이 어려워 하는 의사소통의 장을 마련하였다는 점에서 좋기도 하지만 한편으로는 한국 기업문화와 잘 맞지 않는 면도 있다고 생각한다.

7. 적용 후기

이 조직에 처음 애자일 방법론을 적용할 때만 하더라도 예전에 나름대로 해봤던 스크럼 방법론에 대한 안좋은 기억들로 인하여 팀원들에게 부정적인 인식이 많았습니다. 다행히 팀장의 확고한 지원으로 팀원들이 일차적으로 따라 오게 되었으며 1~2달 애자일 프랙티스를 적용해보면서 효과를 느끼게 되자 팀원들이 적극적으로 참여하게 되었던 것 같습니다. 처음에는 팀원들이 본인의 방법을 고집하는 경향이 있어 애를 먹었는데 스크럼을 제대로 한번 적용해보면서 이제는 이 방식에 대하여 신뢰를 가지게 된 것 또한 좋은 성과인 것 같습니다. 아직도 보완 해야할 점은 많이 있지만 팀장을 비롯해서 팀원들이 업무에 대한 만족도나 서로에 대한 신뢰가 높아지게 되었고 아울러 야근도 안 하면서 품질과 생산성이 획기적으로 높아지게 되어 컨설팅을 수행한 저도 매우 보람있게 생각합니다.

이재왕

PMP, Certified Scrum Master, Certified Scrum Professional