반응형

안녕하세요 오랜만에 개발 관련 글을 적게 됩니다. 몇 안되지만, 그동안 애자일 개발 프로세스를 사용했던 프로젝트 참여 경험과 호주 유학 시절 접했던 소프트웨어 개발 교육 내용을 토대로 적어 내려가며 최근 자료로 업데이트도 하고, 정리도 하며 공유 해 보려고 합니다. 

2018년 현재, 국내에서 Agile (이하 애자일) 개발 프로세스 를 처음 듣는 개발자나 관리자는 거의 없을 것이라 생각됩니다. (경험하지않은 분들은 당연히 있을것입니다.) 꽤 오랬동안 Hot 한 방법론(프로세스) 이였고, 여러 방법으로 이 프로세스를 개발 문화로 안착 시키려고 상당히 많은 분들이 노력 해 오셨습니다. 그래서 많은, 성공설도, 실패설도 있습니다. 

개발 방법은 전통적인 방법인 워터폴도 있고, 스파이럴 혹은 프로토타이핑 방법 등이 있는데 왜 애자일 개발 방법론을 선택하여 개발 해야 할까요? 10년전 필드에서는 벌써 전통적인 워터폴의 문제점들을 보안하고 변형시킨, 애자일 혹은 DevOps (이하 데브옵스) 등의 단어들을 사용하지 않더라도, 오랜 경험을 바탕으로 필요에 의해 내부적으로 개발 프로세스를 애자일 식으로 자연스레 변경한 팀 (Team) 들이 있었습니다. 하지만 대부분 워터폴 방법으로 개발 했고, 윗단계에서 발생한 문제점들은, 폭포수가 단계적으로 내려오며 마지막에 엄청난 량의 물이 떨어지듯, 엄청난 량의 문제점들과 이를 수습하기 위한 엄청난 비용, 노력, 밤샘 등의 반복이 있었습니다. 

때문에, [12 Annual State of Agile Report] 조사에 의하면 2017년엔 조사한 대상 회사 중, 97% 나 되는 회사에서 애자일 개발 방법론을 채택 했을 정도로 많이 확산되어 있습니다. 참고로 조사 대상 중 80% 이상이 미국과 유럽내 있는 회사들입니다. 그리고 이 방법론이 더욱 효과적으로 사용 하기 위해 지속적인 변형이 일어나고 있습니다. Scrum [56%] 방법이 가장 많이 선택되고 실행 되고 있지만, 필요에 따라 Scrum/XP 하이브리드 [6%], 나 ScrumBan [8%], 등 현재 소개된 애자일 개발 방법론들의 하이브리드 형태로 받아들여지고 있습니다. 

그 어떤 형태로든 애자일 개발 방법을 선택하여 진행된 프로젝트 중 성공 비율은 [12 Annual State of Agile Report] 조사 대상 중 98% 회사에서 애자일 개발 방법을 선택한 프로젝트의 성공 경험이 있다고 답변을 했습니다. 그리고 이 중 74% 는 반 이상의 애자일 프로젝트가 성공적으로 끝났다고 합니다. 

프로젝트 성공의 잣대는 역시나 주어진 시간 내, 계획을 잘 세워, 예상한 비용 만큼만 사용하여 모든 Scope 을 완료 하였다 일까요? 애자일에서는 이터레이션 번다운이 이를 설명하는 가장 근사치의 요소일 텐데요. 2016년만 하더라고 51%의 답변으로 가장 중요한 요소를 차지 했었습니다.  하지만, 올해엔 27%로 중요도가 떨어졌습니다. 

그 이유는 애자일 프로젝트가 성공적이라고 결정하는 가장 큰 요소가 2017년엔, 첫번째는 고객 만족도 이고, 비지니스의 가치 전달, 그리고 개발 후 마켓으로의 속도 순으로 바뀌었기 때문입니다. 여기서 고객 만족도는 2016년만 해도 28% 정도의 순위였는데 2017년에는 46%로 가장 중요한 요소가 되었습니다.

경험상, 어떤 고객(사용자)이든, 작게 나마 완성되어 돌아가는 프로그램을 지속적으로 보여주면서, 피드백을 받아주는 개발팀을 싫어하는 고객은 없었습니다. 결과물들을 더 자주 보기 위해 1 week Sprint (스프린트) 를 돌렸던 프로젝트도 있었던 것처럼 고객은 결과물을 자주 보고 피드백을 주며 그 피드백들이 대부분 적용되었으면 합니다. 여기서 개발팀은 Scope 이 늘어나기 때문에 초기 요청사항에서 동떨어진 피드백을 받기를 당연히 원하지 않습니다. 하지만 이를 위해 스프린트 (이터레이션) 마다 Story Card 의 우선순위를 바꾸는 회의가 진행됩니다. 고객(사용자)은 비지니스와 불필요한 Needs 에 대해 고집을 부리지 않습니다. 물론 같은 비용으로 더 많은 부분이 완료 되었으면 하지만, 불필요한 부분으로 인하여 정말 주요기능들이 빠지는 것을 원하지 않습니다. 우선순위 회의의 결과를 공유하여 문제 파악과 해결점을 함께 찾아야 합니다. 

여하튼, 요구사항이 바뀌는 것을 최소화 하기 위해 애자일에서는 Product Owner (PO) 가 늘 함께 해야 한다..는 실제로 불가능한 이론을 이야기 합니다. 분명 PO 의 참여도가 떨어진다라는 요소가 2016년 까지는 큰 장벽 요소 중 하나였지만, 2017년엔 31%로 큰 장벽의 요소에서는 제외 되었습니다. 아마도, 스프린트 끝의 회의 때마다 PO 에게 사용해 보게 한 뒤, 피드백을 받아, 점진적으로 고객의 Needs 에 대등한 완성도 높은 제품으로 변해가는 과정을 함께 경험/공유 하다 보면, PO 는 매 회의 때를 고대하게 되지 않을까 싶네요.

이렇게 많은 회사에서 사용중이라고 발표도 하고, 고객의 만족도가 높은 결과물을 낼 수 있는, 그리고 또 꽤 높은 성공률을 자랑하는 애자일 개발 방법론..

과연, 개발 팀원들은 (PO/개발/UI/BA/테스터) 한번 애자일을 경험한 후에 이 프로세스에 만족하며 이후에도 프로젝트를 위해 또 애자일 프로세스를 선택하게 될지 궁금합니다. 개인적으로는 무척 좋아했습니다. 짧은 스토리 카드 하나하나 완료 시키는 재미도 있고, 고객의 피드백이 늘 추가 요구사항이나 변경으로 이어지는것이 아니라, 후반으로 갈 수록 높은 만족도로 이어지는 경우가 대부분이라서 일을 하면서도 뿌듯했습니다.  

그렇다면 애자일 경험이 없는, 현재 개발 프로세스의 체계가 잘 잡혀 있지 않은 상태에서는 어떤 선택이 가장 좋을까요?

============

4년전, 2014년, 호주에서는 애자일 개발 프로세스를 소프트웨어 개발 방법론으로 채택한, 많은 프로젝트 들이 진행 되고 있었는데요. 당시 런칭 했던 많은 서비스들 중 Pizza Mogul 이라는 재미난 서비스가 있었습니다. Domino Pizza 를 통해, 소비자들이 피자를 디자인(도우,토핑 등) 할 수 있으며, 디자인된 피자가 다른 소비자들에게 판매가 되면, 그 이익금의 일부를 피자를 만든 소비자가 가지고 가는 서비스 입니다. 

Project Management 수업을 들을 때, Pizza Mogul 의 개발 아웃소싱 시 프로젝트 메니저가 선택한 개발 방법론은 Agile 개발 방법론이였으며 관련하여 수업에서 Agile 개발 경험을 공유해 주었습니다. 유학을 위해 호주 가기 전에 참여했던 Agile 개발 방법론을 채택했던 프로젝트들과 그리 다르진 않아서 조금 다행스럽기도 했습니다. 

흥미로웠던 점은 프레젠테이션이 끝나고, 질문 시간에, 제가 "워터폴이나 다른 여러 개발 방법론이 있는데 구지 Agile 을 택한 이유가 있나요?" 라는 질문에 "회사를 들어갔을 때 부터 개발 문화가 Agile 이여서 채택? 했을 뿐이다. 다른 개발 방법론은 경험해 보지 않아서 모르겠다." 라고 답변을 들었습니다. 실은 제가 초기에 개발 방법론을 이해 하며 개발 했던것이 아니였기 때문에 좋고 나쁘다를 판단 할 수 있는 데이터가 모자라 물어본 질문이였는데 의외로 그냥 사내 개발 문화로 자연스럽게 받아들였다는 대답을 들어 "당연한 것을" 물어봤나 하는 생각도 들었네요.

또한 "요구사항이 바뀌거나 늘어났을 텐데, 그에 대해서 고객과 어떤 조율이 이루어 졌나요?" 라는 질문에 대해서는 "매번 우선순위를 정했고, 고객과 공유하여 서비스를 위해 꼭 필요한 기능들에 우선순위를 정하였고, 변경을 수용했다. Scope 이 늘어나면 시간과 비용이 추가적으로 발생하는 점에 대해서 먼저 고객과 상호 이해가 되어야 한다... (생략)" 

============



<to be Continued...>


반응형

+ Recent posts