“애자일은 대형 프로젝트에서 안돼”

<SAFe(Scaled Agile Framework):150명 이상의 Portfolio 관리가 필요한 대형 애자일 방식>

<LESS(Large Scaled Scrum): MAX 80명 애자일 조직을 대상으로 수행하는 대형 스크럼방식>

이러한 프로세스는 기존의 도그마(Dogma: 독단적인 학설, 이성적으로 증명되지 않은 가설)라고 이야기 되던 순수 애자일 추구에서 벗어나 현실속에서 기존 문화와 다양한 프랙티스들을 섞는 것을 시도하는 내용들이 담겨 있었다. 시장 상황, 이해관계자들의 일해오던 방식 등을 일부 존중하면서, 애자일 방식을 통해 가치를 얻을 수 있는 중간 단계의 무엇인가를 찾는 노력들이 있었다.

이에, 디지안 씽킹으로 대표되는 디자인 방식의 변화, 린스타트업으로 대표되는 스타트업 바람이 더해져 바탕으로 이제는 소프트웨어 회사의 94%이상이 본인들은 애자일을 하는 회사라 말하고 있다.

<버젼원의 리포트2016: 애자일을 수행하는 회사가 94%라는 설문 결과>

전체적으로 스펙트럼이 소/중/대형을 넘나드는 애자일 방식들이 생겨나게 된 내용은 지금까지 설명한 바와 같다.

그렇다면 과거의 소규모를 향한 애자일과 중/대형 사업의 애자일과의 구체적인 차이는 무엇일까? 현실과 맞물린 일하는 방법이란 과연 무엇일까?

이를 효과적으로 설명하려면 2001년의 애자일 선언을 가지고 이야기 하면 좋다.

과거 작은 팀을 중심으로 진행하는 애자일 방식은 오른쪽 노란색 부분은 마치 금기처럼 무시하려는 분위기가 강했다. 그래서 조금이라도 오른쪽에 접근하는 것을 경계했다.

하지만 현실과 맞물리며 대형 프로젝트 같은 경우, 왼쪽보다는 확실히 덜 중요하나 오른쪽 부분 또한 중요하다는 인식으로 발전되어 갔다.

이를 설명하면 다음과 같다.

1. 대규모 프로젝트(50명 이상)에서 개인과 상호작용만 강조하면, 두 개이상의 팀이 되었을 때 효과적인 커뮤니케이션을 하기 힘들다 때문에 툴을 사용하는 것이 좋다

2. 동작하는 소프트웨어에만 집중하면 팀 내에서는 진행상황에 대해 잘 이해할 수 있으나 두 개이상의 팀이 되었을 때 서로의 진행사항을 확인하기 어렵다. 애자일팀들이 아주 쉽게 말하는 “우리팀에 와서 언제든 제품을 보세요” 라는 말은 2팀 이상을 봐야 하는 관리자에게는 눈살을 찌푸리게 만드는 대화가 될 수도 있다. 때문에 적당한 문서화는 커뮤니케이션에 도움이 될 수 있다.

3. 고객과의 협업만 강조하면 다양한 이해관계자를 모두 포용하지 못할 수 있다. 때문에 계약과 협상 을 통해 전체 이해관계자와 동일한 비전/생각을 갖으며 일을 해야 한다.

4. 상황에 따라 변화를 하는 것은 중요하지만, 주변 팀에 이야기 하지 않으면 두 팀 이상이 될 경우 의존관계를 무시하게 되여 고객의 비즈니스 가치를 늦게 딜리버리하는 상황을 만날 수 있다.

혹시나 대형 프로젝트, 대규모 조직에서 애자일을 적용하다 현실의 벽에 부딪혀 고민하고 있는 독자가 있었다면 위 이야기를 듣고 반가운 생각이 들 수 있다.

하지만, 다시한번 강조하여 이야기 하고 싶다. 개인과 상호작용, 동작하는 소프트웨어, 고객과의 협업, 상황의 따른 변화가 여전히 더 중요하다. 그래야 애자일 방식이다.

...

http://techit.co.kr/8757 - 옛날에는 개발을 더 잘했는데… 

http://allofsoftware.net/entry/%EC%98%9B%EB%82%A0%EC%97%90%EB%8A%94-%EA%B0%9C%EB%B0%9C-%EC%9E%98%ED%96%88%EB%8A%94%EB%8D%B0

우리나라 많은 회사들은 소규모일 때 상당히 개발을 잘 하는 것처럼 보인다. 짧은 기간에 꽤 멋진 Software를 뚝딱 뚝딱 잘 만들어 낸다. 이러한 제품이 시장에서 통해서 회사가 성장을 하게 되면 그 이후로 이상하게 개발이 점점 더 어려워지게 된다.

옛날에는 고참 두 명이 이정도의 Software를 6개월만에 이렇게 잘 만들어 냈는데, 지금은 팀원이 10명이나 되고 프로젝트 기간도 과거보다 더 줬는데, 제품의 버그는 더 많고, 제품도 옛날보다 형편 없어 보인다고 한다. 점점 개발이 더 어려워지는 이유는 무엇일까?

두번째 시스템을 만드는 것은 첫번째 시스템을 만드는 것보다 훨씬 힘들다. 두번째 시스템은 첫번째 시스템을 유지보수 하면서 만들어야 한다. 첫번째 시스템에 버그가 많거나 커스티마이징 요구가 많아서 소스코드 브랜치라도 몇 개 존재하면 유지보수에 많은 노력이 들어가서 두번째 시스템에 많은 노력을 들이기 어려워 진다.

또한 두번째 시스템은 첫번째 시스템과 호환성을 고려해야 한다. 두번째 시스템은 첫번째 시스템을 사용하던 고객들의 수많은 요구를 수용해야 한다. 첫번째 시스템은 간단 명료한 기능의 매력으로 인해서 많은 사용자들이 사용을 했지만, 이를 사용하던 사용자들은 계속 요구사항을 요구하게 되고 이러한 요구사항을 적절히 조절하여 수용하는 것이 쉬운 일이 아니다.

두번째 시스템 개발에는 많은 개발자가 투입되고 특히 초급 개발자가 많이 투입되곤 한다. 소수의 개발자끼리 개발을 할 때는 커뮤니케이션 문제가 별로 발생하지 않았는데, 개발자 인원이 많아지면 기존의 주먹구구 방식으로 똑같이 개발을 하면 문제가 발생하지 않을 수 없다. 초급 개발자들은 자기 역할을 제대로 못하는 것 같고, 일이 효과적으로 분배가 되지 않아서 결국 소수의 고참 개발자들이 대부분의 개발을 하는 결과를 초래하기도 한다.

두번째 시스템은 아키텍쳐를 전면 개편하기도 한다. 첫번째 시스템을 개발해 놓고 계속 유지보수를 하면서 사용자의 요구사항을 하나씩 추가해 나가기 시작하면 기존의 아키텍쳐로는 한계라고 불평을 자주 하게 된다. 특히, 첫번째 시스템을 개발했던 개발자들이 퇴사한 상태라면 더욱 더 첫번째 시스템을 비난한다.

그러면서 두번째 시스템에는 완전히 새로운 아키텍쳐를 적용하곤 하는데, 그동안 엄청나게 많은 노력을 들인 첫번째 시스템을 버리고 기능도 몇 배로 많아진 두번째 시스템에 완전히 새로운 아키텍쳐를 적용하면 첫번째 시스템이 시장에서 안정화되면서 겪었던 시간과 노력의 몇 배를 다시 투입해야 한다. 이런 경우 프로젝트가 지연되기 일쑤이고, 출시 후에도 많은 버그와 고객의 불평으로 상당기간 고생을 하게 된다.

그럼, 어떻게 해야 과거처럼 개발을 착착 해낼 수 있을까?

조직이 커졌다면 당연히 시스템과 프로세스가 바뀌어야 한다.

과거에 소수 인원이 개발할 때는 주먹구구식으로 개발을 했어도 문제가 없는 것처럼 보이지만, 사실은 문제가 똑같이 있었는데, 워낙 인원이 적으니 서로 의견을 활발하게 주고 받으면서 문제를 해결해 온 것이다. 인원이 조금만 늘어도 이런 행운은 기대할 수 없다. 조직에 걸맞는 시스템, 프로세스를 적용해서 체계적으로 개발을 해야 한다.

첫번째 시스템도 이런 과정을 거쳐서 체계적으로 개발이 되었다면, 두번째 시스템 개발자들에게 비난을 덜 들을 수 있었을 것이다. 두번째 시스템 개발자들이 완전 새로 개발하려는 이유 중 하나가 첫번째 시스템에 대한 문서가 쓸만한 것이 없고, 아키텍처가 뒤죽박죽이라서 개선을 못하고 버리려고 하는 것이다.

회사가 켜졌을 때 문제 해결 차원에서 시스템과 프로세스를 갖출 것이 아니라, 1,2명이 회사를 시작하더라도 체계적으로 개발하는 것이 가장 좋은 방법이다. 이미 첫번째 시스템은 점점 뒤죽박죽이 되어가고 조직은 엉망이라면 시스템과 프로세스를 갖추는 일이 먼저 필요하다.