애자일 이야기2015.06.08 09:44

쏘트웍스(ThoughtWorks)는 미국에 본사를 둔 세계적인 IT 회사이다. 직원이 3000명 가까이 되고 각 세계의 주요 도시마다 사무실이 있을 만큼 큰 IT 조직이다. 이 회사는 애자일의 거장으로 손꼽히고 또 리팩토링으로 유며한 마틴 파울러가 CSO(Chief Scientist Officer)로 몸 담았던 회사이기도 하다. 그래서 그들은 애자일에 있어서 누구보다 빠르고 적극적으로 도입했다. 그 결과 애자일에 대한 지식과 경험이 월등히 뛰어난 기업이다. 하지만 그들은 원거리(사무실이 지역적으로 떨어진 복수팀에 의해 진행되는) 프로젝트를 진행하면서 새로운 도전을 맞게 되었다. 원거리에서 개발 프로젝트를 진행하게 될 경우 구성원 사이의 커뮤니케이션, 협업, 지식의 공유 등 많은 어려움이 존재하기 때문이다.

쏘트웍스는 각기 다른 기술을 가진 30여명의 구성원이 인도, 호주, 영국에 나눠져 프로젝트를 진행하는 상황을 직접 겪게 되었다. 그들은 기존과 다른 방식으로 일일 스탠드업 미팅과 서로 지식을 교류하고 활동들을 도입해야 했다. 예를 들어 원거리 커뮤니케이션을 위해서 메신저와 같은 도구들을 적극적으로 활용했다. 그럼 원거리 프로젝트에서 애자일을 어떻게 활용하였는지 그리고 그 프로젝트를 어떻게 성공 시킬 수 있었는지 살펴보도록 하자.



프로젝트 배경

애자일 팀은 구성원들 사이의 소틍을 가장 중시하고 있다. 그리고 많은 애자일 프로젝트에서 소통의 실패가 프로젝트 실패로 이어졌다. 지역적으로 떨어져 있고 거기에 시간대까지 다르다는 것은 분명 커뮤니케이션에 있어서 높은 장벽일 수 밖에 없다. 이번 장에서는 이러한 경험을 직접 체험한 쏘트웍스의 사례를 설명할 것인데 이들은 삼 개국(영국, 인도, 호주)으로 프로젝트 팀원들과 고객이 떨어져 있었다. 그러므로 그들은 어떻게 이 커뮤니케이션 문제를 해결할지 그리고 기존에 지켜오던 애자일 프랙티스들을 어떻게 상황에 맞게 고쳐야 할지 고민해야 했다.

최종 고객은 영국에 있었는데 재무관련 서비스를 만들어 제공하는 것이 목표였다. 그들의 프로젝트는 초기 두 달 동안 프로젝트 참여인원을 구성해야 했다. 이렇게 모인 프로젝트 구성원은 약 30명 정도로 인도의 방갈로, 호주의 시드니, 영국 이렇게 삼 개국으로 나눠 구성이 되었다. 이중에 주 개발센터는 시드니였다. 시드니에는 프로젝트 매니저, 비즈니스 분석가, 기술 리더, 여덟 명의 개발자가 있었다. 이 프로젝트가 재무관련 프로젝트인 만큼 재무지식을 갖춘 비즈니스 분석가가 필수적이었다. 그리고 방갈로팀은 프로젝트 매니저와 비즈니스 분석가 그리고 두 명의 테스터와 16명의 개발자들로 구성되었다.

앞서 이야기 했던대로 그들은 이렇게 팀원을 꾸린 다음 30명의 참여인원을 두 개 팀으로 나눴다. 그들은 재무적인 이익들을 고려하여 데드라인을 결정하게 되었다. 고객이 원격지의 팀을 선택하게 되었던 결정적인 이유는 짧은 기간 내에 많은 인원이 필요했는데 그만큼의 리소스를 투입하기 위해서였다. 그리고 고객이 제시한 데드라인을 지킬 수 있는 다른 조직을 찾지 못했기 때문이다.

그들은 주간 이터레이션를 이용하여 진행상황을 가능한 짧은 주기로 관찰하고 고객에게도 보고하기로 결정했다. 그들은 프로젝트 기간 중간 중간에 회고 일자를 정하고 매일 스탠드업 미팅을 진행하기로 하였다.


단절된 커뮤니케이션의 극복

그들은 프로젝트를 진행하면서 매일 진행되는 스탠드업 미팅을 포함하여 여러 가지 애자일 활동들을 도입했다. 그럼 그들이 원거리 환경을 극복하기 위해서 수행한 노력들을 살펴보도록 하자. 


스탠드업 미팅


지역적으로 떨어진 환경에서 처음으로 직면했던 문제가 바로 스탠드업 미팅을 비롯한 주기적인 소통을 부분이었다. 그들은 이전 프로젝트까지 줄곧 일일 스탠드업 미팅을 유지해 왔었는데 짧은 시간 동안 진행사항을 점검할 수 있고, 커뮤니케이션의 질을 높여 주기 때문이었다. 팀은 그 동안 사무실에 모여 하던 일일 스탠드업 미팅을 어쩔 수 없이 원격지 팀과 함께 할 수 있는 컨퍼런스 콜 형태로 진행했다.


두 나라의 시간대가 다르다 보니 일일 스탠드업 미팅 시간은 호주는 오전 10시였고, 인도는 오후 3시30분 이었다. 이 미팅은 대략 15-30분 정도가 소요됐다. 미팅에서 그들은 지난 24시간동안 진행한 일들과 다음 24시간동안 진행할 일에 대해서 이야기했다. 보통 3-6명의 시드니 팀원들과 8-10명의 방갈로 팀원들이 이러한 스탠드업 미팅에 참여했다.

그들은 사전에 이 원격 스탠드업 미팅이 어려울 것이라고 생각은 했지만 이 정도로 커뮤니케이션이 힘들게 진행될 줄은 예상치 못했다. 그들은 네트워크 문제로 굉장히 작은 목소리와 좋지 않은 전화 품질로 대화를 진행해야만 했다. 그러다 보니 듣고 이해하기가 굉장히 힘들었다. 즉, 여러 사람이 컨퍼런스 콜을 이용하는 것 자체가 쉬운 일이 아니었다. 그 뒤에 그들은 인터넷 기반의 컨퍼런스 소프트웨어를 이용했다. 일단, 음질에 있어서는 확실히 컨퍼런스 콜보다 뛰어났다. 그리고 처음에는 노트북에 장착되어있는 마이크와 스피커들을 이용했데 이 부분이 음질에 있어서 문제를 발생시킨다는 것을 알게 되었다. 

이렇게 그들은 초기 몇 달 동안 통화품질을 조정하고 또 서로의 영어 발음에 익숙해 지는데 소비하게 되었다. 그들은 이런 커뮤니케이션의 이슈로 인해 인내를 가지고 반복적으로 묻고 답하기를 해야만 했다. 당연히 기존의 스탠드업 미팅보다 더 많은 시간을 소비하게 됐다.

스탠드업 미팅 외의 커뮤니케이션은 주로 메신저를 이용하였다. 아무래도 익숙하지 않은 영어발음보다 텍스트 기반의 대화가 훨씬 이해하는데 유용했다. 그들은 또한 컨퍼런스 콜은 다수의 사람들이 참여하기에는 적합하지 않음을 깨달았다. 그래서 그들은 컨퍼런스 콜의 인원을 8명 이하로 제한하는 규칙을 만들었다. 그들이 생각할 때 이 스탠드업 미팅을 통해서는 팀 간의 신뢰관계를 쌓기 힘들다고 생각했다. 그래서 그들에게는 개인적인 관계를 만들 수 있는 다른 무언가가 필요했다.


관계에 다리놓기

그들이 가졌던 빡빡한 데드라인과 적지 않은 인원으로 구성된 개발 팀이라는 환경 때문에 1:1 관계를 만들어 가는데 무리가 있었다. 그렇다고 이 관계를 무시할 수 없었기 때문에 시드니와 방갈로 매니저들 사이에서만 1:1 관계를 가져 나가기로 했다.

각 매니저는 자신의 팀을 대표해서 이슈를 비롯해서 질문이나 필요한 도움을 수집하였다. 그리고는 둘이서 해당 내용을 이야기했다. 이렇게 중간 다리를 만들자 팀 사이에서 커뮤니케이션이 개선되는 것을 볼 수 있었다. 이런 활동을 통해서 매니저 사이에 두터운 신뢰가 쌓여가는 것을 볼 수 있었고 어떤 문제점이 발생하거나 특정 행동이 필요 할 때 적절히 진행할 수 있었다.

그들은 이러한 두 매니저 사이의 미팅을 매일 진행했다. 둘만의 대화를 통해서 스탠드업 미팅으로는 해결할 수 없는 복잡한 문제를 토론하는 것이 가능했다.



파견인사의 교환


처음에는 대면하지 않고 프로젝트를 진행한다는 것이 굉장히 어려운 일이었다. 무엇보다도 고객은 영국에서 시드니로 요구사항을 전달하기 때문에, 시드니팀에서 다시 방갈로팀에게 비즈니스 요청사항을 전달하는 것이 쉽지 않았다. 실제 얼굴을 보면서 이야기하는 것을 대체할 만한 도구나 마땅한 대안이 없었다. 

그래서 그들은 파견인사의 교환이라는 방법을 찾게 되었다. 이 방법은 실제 커뮤니케이션을 증진하는데 효과적이었다. 이 파견인사의 교환을 통해서 개인 간의 관계를 두텁게 만들어 갈 수 있었고 어떤 지식이나 신뢰를 쌓아가는데 있어도 도움이 되었다. 파견인사들은 원격지 팀을 방문함으로써 새로운 교훈들을 얻어갈 수 있었고 미래의 방향을 설정하는데 큰 도움을 받을 수 있었다.

먼저 시드니팀에서는 개발자와 매니저를 방갈로에 보내고, 그 다음에는 방갈로 개발자들이 시드니를 방문했다. 그들은 팀원들을 차례대로 돌아가면서 파견 갈 수 있도록 기획해서 진행했다. 가능한 많은 팀원들을 보내고 싶었지만 개인사정상 가지 못하는 사람들도 있었고 회사의 입장에서도 비자와 경비 측면에서 어려운 부분이 있었다. 

파견인사가 현지에 도착하게 되면 현지 팀은 기본적인 주거 공간을 제공하고 자신들이 하고 있는 일과 현지 팀의 프로세스를 설명했다. 그리고 그 파견인사와 함께 일할 공간을 보여주고 그들이 해줘야 하는 역할과 업무를 소개했다. 이렇게 파견된 팀원은 약 한달 정도 시간을 보내면서 네 번의 이터레이션에 참여했다. 그들은 해당 기간 동안 스탠드업 미팅에 참여 하였고 또한 회고 미팅에도 참여하였다. 파견인사의 출장 기간을 3주로 할 경우 경험을 축적하게는 너무 짧아 효과가 없을 것이고 그렇다고 너무 오래 머물게 하면 원래 팀에서 인수인계를 필요로 하기 때문에 이 역시 쉽지 않았다. 그래서 4주라는 기간을 정하게 된 것이다.

그 파견인사를 위해 일과 시간이 끝난 뒤에 친목을 다지는 이벤트를 진행했다. 시드니에서는 매주 금요일 오후에 BBQ파티가 있었고 방갈로에서는 팀원들이 함께 저녁을 먹는 이벤트가 있었다. 이런 친목 이벤트는 팀원들끼리의 단합과 신뢰를 다지는데 큰 역할을 하게 되었고 그 파견인사가 자신의 나라로 돌아갔을 때 그 효과를 톡톡히 볼 수 있었다.

파견인사들의 활발한 참여를 통해서 다른 팀의 환경을 이해하게 되었고, 더불어 원격으로만 진행하던 커뮤니케이션을 파견인사를 통해서 간단히 질의하는 것도 가능했다. 더 인상 깊었던 것은 파견을 온 직원일수록 더 열심히 일하면서 무언가 좋은 영향을 주려고 애쓰는 모습이었다. 파견인사들은 자신의 원래 근무지로 돌아가게 되었을 때 파견지에서 같이 일하던 동료들과 자주 연락을 주고 받으며 친하게 지내는 것을 볼 수 있었다. 이런 부분이 커뮤니케이션에 있어서 중요한 역할을 하게 되었다. 왜냐하면 그들의 관계와 각 팀이 갖고 있는 문화에 대한 지식이 어려운 결정을 할 때 아니면 복잡한 이해 관계가 얽혀 있을 때 해결해주는 열쇠가 되어주곤 했다.

파견인사는 출장이 끝나면 그들이 파견기간 동안 쌓은 지식을 원래 팀으로 가져가게 되면서 그들이 갖고 있던 사소한 오해 같은 것들을 해결해 주었다. 그들은 원격지에 머물면서 알게 모르게 중요한 지식들을 흡수하게 되고 또 자신이 배우고 느낀 것을 다른 팀원들에게 퍼뜨리면서 두 팀은 같이 성장할 수 있었다.

그 파견인사에게는 다녀 온 소감이나 배운 것들을 공식적으로 보고하는 절차가 없었다. 하지만 자연스럽게 비공식적으로 그들의 경험과 지식이 팀에 전해져 나갔다. 아마 이런 보고를 부담을 주지 않는 선에서 공식화 시켰어도 충분히 좋은 내용이 되었을 것이다.


걸러지지 않은 커뮤니케이션 

인도에서 온 파견인사는 흥미로운 사실을 발견했다. 시드니팀이 방갈로팀에게 복잡한 내용을 최대한 간단히 설명하려고 노력하는 것을 본 것인데 실제 이런 작업이 갈등의 원인이 되었다. 왜냐하면 방갈로팀은 프로젝트에서 특정 결정이 이루어지면 근본이 되는 내용을 잘 몰랐기에 이해하기 힘든 부분이 있었다. 운이 좋게도 그때 파견 온 팀원이 이 부분을 정확하게 잡아낼 수 있었고 생략된 내용을 인도 팀에게 전달할 수 있었다. 

시드니팀은 불필요한 정보를 걸러내고 커뮤니케이션을 하려고 했던 것인데 중요한 부분까지 놓쳤다는 것을 알게 되었다. 그들은 뒤늦게 이 점을 깨닫고 프로젝트를 처음 시작할 때부터 지금까지 있었던 배경과 목표에 대해서 다시 인도 팀과 대화를 하면서 오해를 풀기 위해 노력하였다. 이런 커뮤니케이션을 통해서 프로젝트에 대해 모든 정보를 전달하면서 팀 사이에서 신뢰를 회복할 수 있었다.


프로세스의 개선

첫 번째 계획한 분기가 끝나고 그들은 회고를 진행하기로 했다. 이 회고 미팅에서는 양쪽 팀과 파견인사들이 참여하여 서로 상대 팀의 결과물에 대한 대화를 나눴다. 이 회고 미팅에서 팀을 더 작게 만들어 스스로 진행할 수 있게 하면 좋겠다는 의견이 나왔다. 그럼 이 의견을 어떻게 적용해 나갔고 어떤 이익을 얻을 수 있었는지 살펴보도록 하자.


소규모 팀

그들은 기존에 대규모 팀으로 움직일 때, 몇 가지 어려움들이 있었다. 대규모 팀의 팀원들은 회의를 진행할 때 자기 때문에 회의가 길어지면 안 된다는 압박을 느낀다. 이런 압박은 커뮤니케이션이 효율적으로 진행되는 것을 방했다. 그로 인해 각 팀원들도 서로의 업무를 깊게 이해할 수 없었다. 

그들은 이러한 문제들을 인정하였고 30명으로 구성된 하나의 팀을 10개 팀으로 나누었다. 이렇게 소규모 팀들로 나눠지면서 팀원들끼리 더 많은 소통을 할 수 있었다. 그리고 그 결과 산출물도 향상되었다. 소규모 팀들은 소통의 문제를 해결함과 동시에 팀원들이 서로 더 가깝고 친밀하게 만들었다. 

뿐만 아니라 팀들이 조금 더 정돈 될 수 있었고 팀원끼리 동지애가 형성되면서 서로에 대한 신뢰를 더욱 두텁게 증진시킬 수 있었다. 특히 이런 원거리 프로젝트에서는 더 많은 커뮤니케이션을 필요로 하기 때문에 작은 팀의 효과를 다른 프로젝트보다 더 크게 얻을 수 있었다.


잘 분배된 팀들

첫 분기가 지났을 때, 대부분의 사용자 인터페이스는 방골라 팀에 의해서 개발되었고 백 엔드(Back-End) 개발은 시드니팀에 의해서 진행되었다. 고객이 관련된 업무를 직접 할당하면서 각 현지에서의 불필요한 커뮤니케이션을 줄일 수 있었다. 둘째 분기에서는 이 작업을 순차적으로 진행할 수 있는 구조로 바꾸었다. 즉, 기존에 각 팀 별로 원하는 기능을 모두 수평적인 상태에서 처리하는 형태였는데 이제는 순서대로 사용자 기능을 처리할 수 있게 바꾼 것이다. 즉, 그들은 우선순위를 부여한 순서대로 일을 할당하는 것이 커뮤니케이션에 있어서 큰 효과가 있었다.

이런 일을 통해서 고객과 불필요한 소통을 최소화하면서 높은 생산성과 작업효율을 얻을 수 있었다. 뿐만 아니라 각 팀은 프로젝트 매니저, 팀 리더, 비즈니스 분석가 그리고 개발자 등 다양한 역할을 지닌 사람들로 구성되어 있었기 때문에 스스로 일할 수 있는 환경이었다. 만약 역할 별로 팀을 구성했다면 지역에 따른 시간대 차이 때문에 원활한 소통이 어려웠을 것이다.


미러링

팀의 구성을 새롭게 바꾸면서 팀은 더 작은 단위가 되었고 각 분야 별로 3명의 개발자들만 있게 되었다. 이런 변화는 팀원 간의 관계를 친밀하게 만드는 효과를 가져왔다. 팀의 구조를 바꾸면서 그들은 “미러링”이라고 부르는 방법을 도입했다. 이것은 업무 별로 개발자, 테스트, 비즈니스 분석가 등으로 팀을 구성하는데 동일한 팀을 시드니와 방갈로에 두는 것이다. 그들은 각자 자신의 지역 시간대에 맞춰 개발을 진행하고 개발이 끝나면 다른 지역의 팀이 출근해서 그 일을 진행한 부분까지 인수인계 받아 진행하는 형태이다.

시드니 개발자들이 자신의 업무를 방갈로 개발자에게 인수인계 해주는 데는 2시간 정도가 소요 되었다. 이 때는 자신과 동일한 업무를 하는 사람에게 개별적으로 인수인계를 해주었다. 인수인계는 음성 메신저를 이용했으며 원격 데스크탑 서비스를 이용해서 코드를 보여주고 진행과정과 이슈들을 설명했다. 

이렇게 진행한 결과 팀이 자율적으로 업무를 관리해 나가는 것이 가능했고, 미러링은 풍부한 커뮤니케이션을 제공하기 때문에 기존 커뮤니케이션으로는 해결하지 못한 문제점들을 줄일 수 있었다. 


안정적인 인프라

프로젝트의 초기 2주 동안은 네트워크를 비롯한 내부 인프라에 문제가 많이 있었다. 이러한 인프라 문제들은 50여명의 팀원들의 생산성을 저하시켰다. 그들은 초기 2주 동안 진행한 스토리 포인트를 측정해 봤는데 인프라 문제가 심각하다라는 것을 알 수 있었다. 인프라 문제가 잦았던 첫 이터레이션에서는 스토리 포인트를 약 18포인트 밖에 올리지 못했다. 하지만 이 문제를 해결한 두 번째 이터레이션 이후부터는 평균 70포인트를 올릴 수 있었다.


[그림] 이터레이션별 진행률


인프라 문제는 일정 연기 뿐만 아니라 팀이 개발을 진행할 때 의욕 또한 저하시키기 때문에 생산성이 크게 감소하게 되었다. 그들이 프로젝트를 진행하는데 있어서 가장 중요한 인프라는 공동의 코드 저장 공간과 CI(Continuous Integration) 였다. 

그들은 두 번째 이터레이션에서 자신들의 개발 인프라를 보다 안정적으로 제공하려고 노력하였다. 무엇보다도 다음과 같은 네 가지 요소의 안정성이 개발 생산성을 개선에 있어 중요한 열쇠였다.


• 빠르고 안정적인 인터넷 환경

• VPNS 환경

• 코드 공유 컨트롤 서버

• 최신 DB 및 설정 서버


인프라 팀은 항상 네트워크를 비롯한 인프라 환경을 모니터링 하고 방갈로팀에 문제가 발생할 경우 늦은 밤까지 문제를 해결해 주려고 노력하였다. 


원격 개발 도구들의 소개


이 원격 프로젝트를 진행하는 동안 그들은 많은 커뮤니케이션 도구들을 사용했다. 그 중에 유용했던 도구들을 살펴보도록 하자. 


메신저

대부분의 원격 팀들은 모두 그룹 메신저를 통해서 수시로 소통을 했다. 커뮤니케이션의 제1순위가 바로 이 메신저를 이용하는 것이었던 것만큼 가장 중요한 도구였다. 그들은 야후! 메신저를 사용하였고 다음과 같은 룰을 통해서 더 많은 도움을 받을 수 있었다. 


• 고객, 테스터, 비즈니스 분석가, 개발자 모두 프로그램을 설치했고, 자신의 이름에 역활을 표시하게 하였다.

• 주소록을 만들어서 전체 팀을 추가하였고 자유롭게 연락할 수 있게 하였다.

• 연락처 부분에 현재 일하고 있는 위치를 표시하였다.


이러한 간단한 룰을 통해서 각 지역에서 쉽게 커뮤니케이션을 진행할 수 있었고 어떤 질문이 생길 경우 쉽게 물어볼 수 있었다. 각 팀은 그룹메시지를 지정하여 그룹 별로 쉽게 토론을 개설하고 참여할 수 있었다. 

이런 환경 설정은 하루 만에 끝낼 수 있었고, 실제 자리에 있는지 여부를 메신저 상태를 통해서 쉽게 알 수 있었다. 그리고 그들이 바쁘거나 방해 받고 싶지 않을 경우에 ‘바쁨’으로 메신저 상태를 표시하도록 하였다. 



스카이프


야후 메신저와 별도로 스카이프(Skype)를 이용하여 음성 대화를 진행했다. 초기에는 스카이프의 기본 음성 통화 기능을 이용해서 스탠드업 미팅을 진행했다. 그러나 시간이 흐를수록 다른 회의나 연락에도 전화보다는 스카이프를 즐겨 사용했다. 그리고 스카이프는 인터넷을 이용하여 현지의 일반 전화로 연결할 수 있는 기능이 있는데 한 쪽에서 인터넷이 사용이 불가능한 경우에는 상대방의 휴대폰 전화로 연결을 시도했다.

무엇보다도 스카이프에서 제공하는 연락처를 이용해서 급한 경우에 쉽게 연락할 수 있었다. 그리고 스카이프에서 제공하는 인터넷 기반의 전화 또한 좋은 통화품질을 갖고 있어 추가비용 없이 쉽게 이용할 수 있었다. 하나의 단점은 네트워크 속도에 따라서 통화품질에 제한이 있었다는 것이다. 


동영상 문서


원격 개발팀에서 한가지 더 중요한 것이 있는데 바로 동영상을 작성하는 것이다. 그들은 짧은 동영상을 활용하여 특정 기술을 전달하거나 교육이 필요할 경우 사용하였다. 그들은 개발에 있어 필요한 설정가이드나 고객에게 시스템 데모를 보여주기 위해서 동영상을 활용했다.

프로젝트 매니저 또한 시스템 아키텍처 또는 복잡한 도구의 사용법을 알기 쉽게 전달하기 위해서 동영상을 사용하기도 했다. 작성된 동영상은 네트워크 드라이브를 통해서 공유하였다.  그리고 파일 사이즈가 클 경우, 원격 드라이브를 사용하는데 문제가 있었기 때문에 카메라의 해상도와 화질을 적절히 조절해서 파일 사이즈가 너무 크지 않도록 하였다. 간혹 화이트 보드에 적은 내용을 문서화 할 시간이 없을 경우, 사진으로 찍고 그 사진들을 모아서 동영상으로 제공하기도 하였다. 


그들은 좋은 동영상 만드는 팁들을 다음과 같이 소개하고 있다. 


• 동영상은 최대한 짧게 만드는 것이 좋은 하나의 주제당 3-5분 정도가 적합하다. 녹화할 때 적절히 끊어서 작업을 진행하면 나중에 동영상을 편집하는 리소스를 줄일 수 있다.


• 카메라를 PC에 연결했을 때 자동으로 동영상을 변환하는 도구를 이용하는 것이 좋다. 그들은 캐논 드라이버를 이용하였고 윈도우에 있는 카메라 내에 동영상을 자동으로 감지하여 변환하는 도구를 이용하였다. 이런 자동화를 통해서 일의 번거로움을 줄이는 것이 좋다. 


• 파일명은 최대한 쉽고 이해가 가능하게 정하는 것이 좋다.


그들은 화면을 녹화할 때 해상도를 800x600으로 맞추어 작성하였다. PC화면을 촬영할 경우 음성 메시지도 적절히 같이 녹음하여 보다 쉽게 이해할 수 있게 진행하였다. 가끔은 말하는 사람의 얼굴과 PC화면을 적절히 번갈아 가면서 녹화를 진행하였다. 


원격 제어


시드니팀과 방갈로팀은 코드를 같이 보면서 이야기 해야 될 경우가 많았다. 그럴 때 리얼 VNC(Real VNC)라는 무료 소프트웨어를 이용했다. 이 도구와 함께 음성 채팅을 이용하여 대화를 진행했다. 원격제어 소프트웨어는 코드 기반 리뷰의 질을 높이는데 큰 역할을 했다. 

첫 이터레이션에서는 이 도구를 자주 사용하지 않았었다. 하지만, 두 번째 이터레이션부터 개발자들이 미러링이나 기술적인 인수인계가 필요할 경우 자주 사용하게 되면서 이 도구의 유용성을 깨닫게 되었다. 해당 도구를 이용하면 훨씬 쉽게 화면을 공유할 수 있다는 것을 인지하고 작은 코드리뷰에도 무조건 이 도구를 이용하기 시작했다. 


정리

지금까지 그들이 원격 프로젝트를 진행한 과정과 과정 도중에 발생한 어려움을 해결하기 위해서 수행했던 여러 방법들을 살펴보았다. 해결방법 중 일부는 굉장히 효과적이었고 다른 일부는 부분적 효과만 있었다. 예를 들어 그들이 초기에 컨퍼런스 콜을 이용한 스탠드업 미팅은 비효율적이었다. 원격 환경에서는 스탠드업 미팅과 더불어 화상 전화와 원격 제어 그리고 메신저와 같은 여러 커뮤니케이션 도구들이 추가로 제공되어야 한다. 

그들은 또한 원격팀과 이야기 할 때 최대한 간단히 이야기 하려고 많은 내용을 걸러서 진행했지만, 시간이 조금 더 소모되더라도 자세히 이야기 하는 것이 좋다고 했다. 왜냐하면 모두가 진행되고 있는 정책과 관계 그리고 각 기능이 도출되기까지의 상황을 설명해주어야 오해가 생기지 않기 때문이다. 

그리고 그들은 중간 소통자를 둬서 복잡한 이슈를 대신 의논하게 하고 지역 별로 각 분야 전문가를 둠으로써 많은 문제를 해결 할 수 있었다고 한다. 

그리고 두 번째 이터레이션에서 보다 팀을 작게 만들어 많은 효과를 얻었다. 비록 큰 팀들이 어떤 정보가 격리 된다거나 어떤 책임 의식이 나누어 진다라는 리스크를 가지고 있다고 하더라도 원격 팀에게 있어서 그런 책임감이 짐으로서 다가오게 된다. 소규모 팀을 통해서 이런 부담감을 적절하게 조절할 수 있고 팀 별로 원하는 만큼의 정보만 제공함으로써 과도한 커뮤니케이션 문제 또한 해결할 수 있었다.

그들이 활용했던 방법 중에 가장 효과적이었던 것은 파견인사 제도였다. 이 제도를 통해 자연스럽게 신뢰를 두텁게 하고 서로 오해한 부분과 잘못된 지식을 자연스럽게 고쳐갔다. 원격 프로젝트를 진행한다고 할 때 실제로 얼굴을 보면서 하는 커뮤니케이션을 과소평가하는 경우가 많이 있다. 하지만 결국에 그 간과했던 커뮤니케이션이 오해로 돌아오면서 더 큰 비용이 소모되는 경우가 많이 있다는 점을 볼 때 반드시 이뤄져야 하는 투자가 분명하다. 

원격 팀들은 안정적 시스템 인프라가 최우선 되어야 하고, 그 인프라를 바탕으로 최대한 많은 커뮤니케이션을 해야 한다. 그리고 중요한 것은 원격 프로젝트인 만큼 더 자주 진행과정을 점검해야 한다. 이번 장에서 소개한 쏘트웍스의 환경과 방법들을 잘 조합한다면 원격 프로젝트도 분명히 성공적으로 이끌 수 있는 자신감을 가질 수 있을 것이다.


저작자 표시
신고
Posted by 박경훈
애자일 이야기2015.02.04 10:58

아브락사스 애플리케이션(Abraxas Applications) 이라는 회사는 고객사에게 소프트웨어를 납품하는 미국의 중간 규모의 개발사이다. 세계적으로 널리 알려진 회사가 아님에도 세 번째 사례로 소개하게 된 이유는 그들이 겪었던 문제들은 처음 애자일을 도입하는 회사들에서 자주 볼 수 있는 패턴들이기 때문이다. 즉, 그들이 가졌던 애자일의 오해와 문제들을 통해서 애자일의 가치들을 다시 한번 되짚어 볼 수 있는 기회가 되기를 바란다.



이 회사의 사례는 2009년 미국에서 개최된 애자일 컨퍼런스에서 브라이언 빅터(Brian Victor)와 노아 제이콥슨(Noah Jacobson)에 의해서 소개되었다. 그들은 초기 애자일 프랙티스(Agile Practice)들을 회사에 소개하고 도입하기 시작했다. (애자일 프랙티스라는 용어가 국내에서는 애자일 실천법 정도로 사용되고 있다. 주로 TDD, CI, 매일 아침 미팅, 회고 등과 같은 작은 애자일의 방법들을 애자일 프랙티스라고 부른다) 이 두 개발자들은 처음 애자일을 도입할 때는 애자일이 소통 프로세스인 것을 모르고 있었다고 밝혔다.

흔히 남이 한다고 해서 따라 하는 경우 큰 효과를 얻기 힘들다. 애자일도 똑같다. 애자일 프로젝트를 성공 시키기 위해서는 무엇보다 애자일 개발 원칙 선언문이라고 불리는 애자일 선언(Agile Manifesto)을 중심으로 애자일 원칙에 대해 팀원 전체가 완벽히 이해하는 것이 중요하다. 이들의 사례에서도 애자일 원칙에 이해 없이 실천법부터 도입했던 것이 애자일을 도입하는데 실패한 이유일 것이다. 또한 개발자 출신으로 시작했던 것이 더 잘할 수 있었던 부분에 장애물이 되었다. 그럼 그들이 애자일을 처음 좌충우돌 도입하기 시작한 사례부터 지금의 성공적 애자일 정착까지 과정을 한번 살펴보도록 하자.


그들이 잘 알지 못했던 사실 “애자일은 소통의 과정”

처음 애자일을 접했을 때 그들에게는 간단해 보였다. 그들은 애자일 관련 정보를 책, 블로그, 문서, 뉴스그룹 등등 다양한 경로를 통해서 얻을 수 있었다. 그리고 이러한 정보는 애자일에 대한 지식이 없던 팀원들과 공유하였다. 그 당시에 그들이 애자일을 이해한 것으로는 TDD, CI, 짧은 반복주기의 릴리즈와 같은 여러 애자일 프랙티스들을 도입하는 거라고 생각했었다. 하지만 애자일에서 프랙티스는 애자일을 구성하는 작은 요소들일 뿐 절대 핵심이 아니다. 그래도 만약 그들이 도입했던 프랙티스(실천법)들이 성공적으로 잘 장착되었다면 그들은 아마 다른 프랙티스를 도입하는 것도 애자일의 옵션을 추가 하는 정도로 생각했었을지도 모른다.

어쨌든 TDD, CI, 짧은 반복주기 같은 개념들은 도입하기에는 쉬웠기에 그들 스스로 이 세 가지 프랙티스들을 도입하여 기존 방식을 대체했다. 하지만 해당 프랙티스들로부터 큰 효과를 얻을 수 있다고 했지만 귀찮고 번거로울 때가 많았다. 즉, 그들은 애자일의 큰 그림인 “애자일은 소통의 과정이다.” 라는 것을 모른 채 애자일을 시작했던 것이다. 


애자일의 도입과정

앞서 설명한 두 개발자는 아브락사스 애플리케이션에서 회사 설립 시부터 근무한 개발자들이었다. 그들은 처음에 CruiseControl과 NUnit 이라는 닷넷 시스템의 CI 도구와 TDD 도구를 설치했다. 그리고 주간 릴리즈 미팅을 계획하였다.

그들은 그들이 알고 있는 만큼의 애자일을 도입했다. 그것들이 새롭게 다가왔지만 1년후에 어떤 일들이 벌어질지 그들은 알지 못했다. 그들은 계속 해왔던 대로 고객들과 일주일에 한번씩 회의를 가졌다. 처음 애자일 도입 했을 때는 전체 회사가 한 방안에 앉아서 회의를 진행했기 때문에 피드백 자체가 굉장히 빠르게 이루어졌다.

몇 개월이 흐른 뒤에 그들은 넓은 새로운 사무실로 이사를 했고 새로운 개발자들을 고용했다. 이들 중에는 누구도 애자일 개발에 대한 경험이 없었다. 그 뿐만 아니라 팀 내에서 한번도 애자일 교육을 했던 적이 없었기 때문에 새로운 개발자들에게 개념을 이론적으로 설명을 하고, 현재 팀에서 해오던 방식에 대해서만 설명했다. 당연히 경험에서 나오는 어떤 노하우도 없었다. 관리자와 팀원들 사이에서도 미묘한 갈등이 시작됐다. 왜냐하면 왜 애자일을 해야 하는지 정확하게 설명할 수 없었기 때문이다.

이러한 좌충우돌 경험 속에서 그들은 마침내 애자일 개발경험이 풍부하고 기존 회사에서도 애자일 코치로 활동해오던 한 사람을 고용할 수 있었다. 그는 조직을 도와서 빠르게 잘못된 점들을 점검하고 고쳐나가기 시작했다. 그리고 그는 왜 그런 문제가 생기게 되었는지에 대한 원인까지 이야기 해줌으로써 팀원들에게 정확한 이해를 시켰다.



신뢰와 관리

XP 프랙티스 중에 한 주에 40시간만 일하라는 “지속적인 속도로 일하기(substainable Pace)” 라는 실천법이 존재한다. 즉, 일을 몰아서 야근까지 해가며 무리하게 하지 말라는 것이다. 근무 시간을 늘려 야근을 할 경우에는 팀원들의 사기를 떨어뜨릴 수 있고 결과물의 품질 또한 낮다는 것이 XP에서의 주장이다.

그들의 실수는 이 지속적인 속도로 일하라는 프랙티스의 경우 결과물을 보장하지 못한다고 생각한 점이다. 그리고 고객은 그들의 산출물을 신뢰하지 않을 것이라고 예상했다. 하지만 그들은 이터레이션 계획 미팅에서 어떤 약속을 하는 것이 어려웠다. 즉, 다양한 업무분야의 진행속도를 추정하는 것이 힘들었다. 어떤 때는 기능에 대한 정보가 부족하여 더욱 추정이 힘들었다. 최악의 상황은 4명의 개발자가 한 이터레이션 안에서 4명 모두 스토리를 완성하지 못했을 때였다. 결국 이터레이션이 끝났을 때 고객에게 어떤 결과물도 보여주지 못했다. 그 때는 개발팀이 마치 아무런 일도 하지 않는 것처럼 평가되었다.

아무튼 그들이 잘못 가고 있다는 것을 인지할 만한 몇 가지 것들이 있었다. 첫 번째는 그들 스스로 찾아낸 것이다. 그것은 바로 고객에게 아무런 산출물도 넘겨주지 못한다면 고객으로부터 어떤 신뢰도 얻을 수 없다는 것이다. 비록 개발자들은 내부적으로 코드를 볼 수 있기 때문에 계속 일하고 있다는 것을 증명할 수 있다. 하지만 고객에게는 그럴 수 없다. 그렇기 때문에 고객은 개발팀을 신뢰할 수 없었다. 이러한 악순환은 새로운 애자일 코치가 일정을 계획하고 사용자 스토리를 재작성 하고 나서야 상황이 호전될 수 있었다. 코치는 사용자 스토리들을 개발자들이 충분히 측정하고 완료할 수 있을 정도의 크기로 줄였다. 그는 매일 아침의 스탠드업 미팅에서는 각자 맡은 스토리들의 진행상항에 대해서 물어봤다. 그가 그렇게 한 이유는 만약 스토리의 완성이 늦어질 것 같으면 고객에게 일찍 알려주기 위해서였다.

그들은 애자일을 기술적인 관점에서만 적용하려 했기 때문에 사람 관점의 애자일을 보지 못했던 것이다. 



커뮤니케이션

그들은 한 장소에 모여 일했고, 손을 흔들며 서로에게 말을 건네는 것이 가능했다. 이전에는 이 정도의 커뮤니케이션도 진행하기 어려웠기 때문에 이 정도의 환경만으로도 충분하다고 생각했다. 하지만 일하는 동안 각자 자신의 음악을 듣는 것을 좋아했다. 자기가 일하는 환경에서 다른 사람의 불필요한 잡음을 듣기 싫어했다. 

회사가 커지면서 팀은 여러 방으로 분리 되었고, 각자 원하는 곳에 파티션을 치고 앉았다. 그들은 모두 다른 이들로부터 방해 받지 않는 자신만의 개발 환경을 원했기 때문에 이에 대해서 어떤 반대 의견도 없었다. 그들은 여전히 일일 스탠드업 미팅을 가졌고 주간 이터레이션 미팅도 가졌다. 그리고 질문이 있을 경우에 다른 방에 들어가서 질문을 하기가 많이 어렵지 않았다. 하지만 점차 그들은 개발 중에 누군가가 갑작스레 와서 질문을 하는 것을 원치 않게 되었다. 그래서 많은 대화가 이메일이나 사내 인트라넷 시스템을 통해 이뤄졌다.

이런 환경은 새로운 스크럼 코치가 오면서 모두 바뀌었다. 먼저 각자 사용하던 헤드폰 사용을 금지했고 떨어져서 일하던 팀원들을 모두 한 방에 모여서 일하도록 했다. 그리고 방에 모두가 듣을 수 있게 음악을 틀었다. 비록 명시적으로 커뮤니케이션의 양을 측정하지 않았지만, 쉽게 의견을 나누거나 질문을 할 수 있게 된 점은 명백했다. 이전에는 대화를 나누기 위해서는 다른 사람의 자리로 걸어가서 손을 흔들어야 했다. 새로운 환경으로 바꾸고 나니 이전 절차가 생각보다 길었었음을 느꼈다. 하지만 지금은 아주 쉽게 질문을 주고 받을 수 있다. 

그들은 커뮤니케이션 장벽이 잠재적으로는 문제를 가져올 수 있다는 것을 깨달았다. 팀원들이 서로 멀리 떨어져 있는 경우 대화가 이뤄지기까지 소요되는 시간 이상으로 생산성에 악영향을 미친다는 점을 깨달았다. 보다 원활한 소통 환경을 갖고 있다면 그만큼 개발 생산성을 올릴 수 있음을 기억해두자.


외부 협력사 QA

그들은 자신들이 구축한 자동화된 테스트 시스템이 정말 환상적이라고 생각했다. 코드가 자동화된 테스트 시스템을 통과할 때마다, 그들 스스로의 제품에 반영할 수 있는 자신감이 생겼다. 하지만 아직 테스트 되지 않은 코드가 있었다. 그리고 최종 테스트는 외부 협력업체를 통해서 수행하고 있었다. 외부 협력사에게 1주 단위로 테스트를 의뢰하였고, 테스트 결과도 1주 단위로 받을 수 있었다. 

스크럼 코치는 어떤 기능을 수정하면 버그와 같은 테스트 결과를 받는데 3주 정도가 소요되는 것을 알게 되고서는 조치가 필요함을 느꼈다. 그래서 애자일 코치는 외부 협력사의 테스터를 사내로 들어와 테스트 해주길 부탁했다. 그리고 웹 기반으로 사용하던 버그 관리 프로그램을 바로 화이트보드로 바꾸었다. 버그들은 한 시간 정도의 범위 내에서 발견되고 즉시 수정되어 다시 테스트 되었다. 

결론은, 가까이서 소통하는 것만큼 좋은 결과는 없었다. 테스터와 가까이 일하면서 그들은 테스트 결과 피드백 주기를 놀랍게 단축시킬 수 있었던 것이다.



애자일 프랙티스의 전도

그들이 새로운 개발자를 채용하게 되면, 새로운 팀원에게 사내의 애자일 프로세스를 설명했다. 그 중 애자일 경험이 없는 개발자는 많은 질문을 했다. 하지만 회사 자체적으로 애자일에 대한 경험이 많이 축적되지 않은 관계로 그들도 애자일 도입에 대한 확신이 없었다. 사내 일부 팀에서는 애자일 프랙티스 도입을 싫어했기 때문에 시늉만 낼 뿐 실제 내부적인 진행은 전과 다르지 않았다. 하지만 그들은 애자일 프랙티스를 한 사람씩 천천히 도입하기 시작했다. 그렇기 때문에 모든 코드가 테스트 가능한 것이 아니었고, 항상 빌드가 통과 되었다는 녹색불이 켜지지 않은 적도 많았다. 

이런 프랙티스를 팀 내에 전도시키는 것은 어려운 문제였다. 이를 선호하는 사람들과 반대하는 사람들 사이에 갈등이 발생하기 때문이었다. 결국 애자일 코치의 지시대로 애자일 프랙티스를 전면적으로 도입했다. 하지만 그들은 그들 중에 재능은 있지만 애자일에 반대하는 사람을 잃을 수 있다는 것을 감수해야 했다.



설계


애자일 적용 후 개발을 설계 하는 부분에 문제가 있었다. 무엇보다도 그들이 도입한 TDD의 경우는 테스트 코드를 먼저 작성하면서 설계를 진행한다는 철학이 있었기 때문에 별도의 설계 그룹이 존재하지 않았다. 그렇기 때문에 해당 업무를 맡은 사람에게 설계 권한이 주어졌다.

하지만 팀이 커지면서 이 부분에서 갈등이 발생하기 시작했다. 팀원들마다 선호하는 설계 방식이 있었고 코드를 합칠 때 서로의 설계 방식에 대해서 서로가 굉장히 비판적이 되었다. 그래서 이러한 갈등을 해소하기 위해 생각해낸 방식이 이터레이션을 시작하는 킥오프 미팅에서 각 스토리 별로 충분한 토의를 하기로 했다. 팀원들 모두가 모여 최대한 많은 의견을 나누었다.

지금은 뛰어난 일부 개발자들 주도로 설계가 진행되고, 또한 누구나 의견을 줄 수 있었기 때문에 서로의 설계에 대한 갈등이 없어졌다.



회의

그들은 회의를 가능한 짧게 하려고 노력했다. 매일 아침에 진행되는 스탠드업 미팅은 15분 미만으로 했고, 계획을 세우는 미팅과 결과를 확인하는 주간 이터레이션 미팅은 한 시간 정도였고, 분기별로 진행되는 회고는 두 시간 이내에서 진행했다. 그들은 주 단위 이터레이션 미팅의 경우 한 시간이라는 제한 속에서 커뮤니케이션을 진행해야 했기 때문에 우선 순위를 정하는 정도의 일만 처리할 수 있었다. 그래서 팀원들은 늘 제품에 대한 충분한 대화가 부족하다고 느꼈다. 

애자일 코치와 같이 일을 시작하면서 알게 된 것이 있다면 잘 짜인 계획과 미팅들의 중요성이었다. 그들은 이전보다 훨씬 많은 시간을 미팅에 부여했다. 결과는 증가된 시간보다 더 큰 효과를 가져올 수 있었다. 애자일 코치는 한 주마다 이루어지는 이터레이션 미팅을 다음과 같이 수정하였다. 

킥오프 미팅(2-3시간): 고객들과 기능과 스토리에 대해서 이야기하였고 요구사항을 분석하였고, 업무 리스트를 작성하였다.

- 회고(1시간): 이전 이터레이션을 점검하였고, 필요할 경우 프로세스를 개선했다.

- 릴리즈 계획(1시간, 혹은 필요한 만큼): 긴 제품 계획을 만들었다.

- 리뷰(1-2시간): 완성된 스토리를 고객들에게 전달하고 피드백을 받았다.



스토리의 크기


그들은 어떻게 스토리들을 작성해야 할지 감이 없었다. 처음에는 매우 작게 기술적인 이야기들로 스토리들을 작성했다. 이 때의 문제는 스토리를 통한 고객들과의 대화가 어려웠다는 점이었다. 반대로 고객이 작성한 제품의 기능은 광범위한 범위를 다뤘다. 그래서 그들은 그 요구사항을 듣고 굉장히 긴 스토리들을 작성했다. 이것 또한 문제가 되었다. 긴 스토리의 경우 업무 범위가 크기 때문에 너무 많은 세부 내용을 필요로 했기 때문이었다. 

그들은 이러한 경험을 통해서 스토리 크기가 고객과 대화함에 있어 중요한 영향을 준다는 것을 깨달았다. 그래서 지금은 고객과 대화하는데 어려움을 줄이기 위해서 적당한 크기로 만들려고 노력하고 있다. 그들이 찾은 최적의 크기는 이터레이션 별로 여섯 개에서 열두 개 정도의 스토리를 처리할 수 있을 정도이다. 그리고 기술적인 내용은 각 스토리의 서브 업무로 포함하여 진행하였다. 



애자일 원칙

그들이 놓치고 있던 부분들을 애자일 메니페스토에 선언된 애자일 원칙과 비교해서 무엇이 잘못되었는지 정리해보도록 하겠다.

알지 못했던 사실 #1
애자일은 계획 수립을 돕기 위한 메커니즘이지 패널티와 규정을 만들려고는 것이 아니다. 계획 수립을 위한 애자일 방법론을 해서 팀과 고객간의 신뢰를 증진 시킬 수 있다.

그들이 가지고 있었던 문제 
고객은 개발팀의 약속을 거의 믿지 않았다. 즉, 고객과 개발팀 사이에 신뢰가 거의 없었음에도 이 점을 인지하지 못하고 있었다. 대표적인 예로 고객은 미팅 때마다 피드백을 주기 보다는 개발팀이 일정 내에 끝내지 못한 것에 대해 비판만 했다.

해결전략

우선 서로에 대한 신뢰를 다시 쌓아야 한다는 점을 깨달았다. 그래서 매일 아침 고객과 팀이 짧은 미팅을 가졌고 이터레이션(XP의 개발주기) 내에 남은 스토리들에 대해 서로 의견을 나누었다. 만약 남아 있는 스토리(업무)들을 모두 완료하기 힘들 경우에는 고객이 다시 우선순위를 정하고 같이 그 문제에 대해서 상의하였다.


애자일 선언문의 원칙

“우리의 최우선 순위는 고객을 만족시키는 것이다.”


알지 못했던 사실 #2


그들은 좋은 커뮤니케이션 환경을 만드는 것이 중요하다라는 것을 전혀 알지 못했다.

그들이 가지고 있었던 문제

그들은 서로 분리된 방에 떨어져 앉아 있었다. 일하는 동안에는 각자 헤드폰으로 음악을 들었다. 그렇게 그들은 조용한 환경을 좋아했다.

해결전략

두 개의 팀이 충분히 보고 들을 수 있도록 한 테이블에 앉아 일했다. 그리고 이야기 주제와 상관없이 최대한 많은 대화를 나누었고 사무실에 흐르는 하나의 음악을 공유했다.

애자일 원칙

“정보전달에 있어 가장 효과적인 방법은 바로 직접 얼굴을 보면서 하는 대화이다.”


알지 못했던 사실 #3

테스트를 진행하기에는 한 주 단위는 너무 길다.


그들이 가지고 있었던 문제

기능구현이 끝나면 주로 외부에 있는 테스터가 테스트를 진행하였는데 매 반복주기(이터레이션)가 종료된 후에 테스트를 진행했다. 따라서 버그를 발견하고 수정하기까지 약 3주의 시간이 소비되었다.


해결전략

기존에 외부에 있던 테스터를 내부로 불러들여 기능구현 완료와 동시에 진행할 수 있는 환경을 만들었다. 그렇게 함으로써 반복주기 마지막에 테스트를 몰아서 하지 않았다. 

애자일 원칙

“소프트웨어를 가능한 자주 전달해야 한다.”


알지 못했던 사실 #4

애자일에 대한 팀 전체의 헌신이 없거나 애자일을 추진할 수 있는 핵심 인물이 없다면 팀 구성원들은 본능적으로 새로운 프랙티스에 대해서 거부감이 들기 마련이다.

그들이 가지고 있었던 문제

모든 것에 토론을 진행할 수 있게 하였고, 모든 다른 의견들을 수용했다. 더불어 모든 팀이 필요로 하지 않는 TDD와 CI와 같은 애자일 프랙티스들을 강제 하였는데 결국 이것은 융통성이 없는 집착이 되었다.


해결전략

팀 별로 원하는 것을 부분적으로 도입할 수 있도록 하였다.


애자일 원칙

“팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.”


알지 못했던 사실 #5

팀원들 모두가 프로그램 설계와 아키텍처에 대한 의사결정에 참여하고 의견을 전달할 수 있는 통로를 확보해야 한다. 그럼으로써 향후에 발생할 수 있는 민감한 불만들을 예방할 수 있다.

그들이 가지고 있었던 문제

특정 기능을 구현하기 전에 설계를 진행하는 그룹이 없었다. 그래서 그들은 스토리(업무)를 맡은 사람에 의존하여 시스템을 설계해 나갔다. 

해결전략

보통 하나의 사용자 스토리는 여러 업무들로 구성된다. 그래서 그들은 이터레이션이 시작하는 스프린트 계획 미팅에서 다같이 모여 스토리들마다 설계를 정의하였다.

애자일 원칙

“최고의 아키텍처와 요구사항 그리고 설계가 생겨나야 한다.”


알지 못했던 사실 #6

특정 대화나 미팅은 개발팀의 진행을 지원하기 위해서 반드시 수반되어야 한다. 만약 이런 정기적인 미팅들이 없다면 꼭 시간을 할애해서 미팅을 만들어야 한다.

그들이 가지고 있었던 문제

그들은 한번의 미팅으로 많은 일들을 계획하고 의사결정 했다. 그리고 그 때가 고객을 만나는 단 한번의 순간이었다.

해결전략

여러 번의 주기적인 미팅을 각각의 이터레이션에 적절히 배분했다.

애자일 원칙

“고객이나 비즈니스 관련 이해관계자와 개발자는 함께 일해야 한다.”


알지 못했던 사실 #7

사용자 스토리는 팀과 고객이 충분히 이해할 수 있는 크기로 만들어져야 한다. 

그들이 가지고 있었던 문제

그들이 작성한 스토리들은 굉장히 작았다. 그래서 스토리가 독립적이지 못하고 항상 다른 스토리와 의존적 관계를 맺었다. 또 다른 스토리는 너무 커서 한 이터레이션 내에 끝낼 수가 없었다.

해결전략

그들은 사용자 스토리들이 2주 주기의 이터레이션에서 6개에서 12개를 처리할 수 있는 크기로 재정의 하였다. 

애자일 원칙

“소프트웨어를 개발함에 있어 진행상황을 측정할 수 있음은 가장 중요한 요소 중 하나이다.” 



정리

설계부터 구현에 대한 버그 리포트를 만드는 것까지 전체 개발 절차에서는 굉장히 많은 커뮤니케이션을 필요로 한다. 올바른 커뮤니케이션이 수반되지 않는 경우 원하는 결과를 얻지 못할 가능성이 충분하다. 이 사례를 통해 강조하고 싶은 것은 소프트웨어 개발은 소통의 과정이라는 것이다. 즉, 모든 것이 대화로 시작해서 대화로 끝나야 가능하다는 것이다.

지금 아브락스 애플리케이션은 개발팀 간의 커뮤니케이션 능력을 키우는데 많은 역량을 집중하고 있다. 그리고 처음 도입했을 때는 하지 못했던 여러 애자일 프랙티스들을 실천하고 있다고 한다. 

더불어 애자일 개발을 위해서 반드시 애자일의 기본 원칙들을 이해하고 왜 애자일을 해야 하는지에 대한 이유를 먼저 정립하고 도입해야 한다는 교훈을 얻을 수 있었다. 다음 애자일 선언문에서 언급하고 있는 애자일의 원칙들을 공유하면서 이번 사례를 정리한다.

애자일 선언의 원칙들

우리는 다음 원칙을 따른다:
우리의 최우선 순위는, 가치 있는 소프트웨어를
일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

비록 개발의 후반부일지라도 요구사항 변경을 환영하라.
애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이
되게 한다.

작동하는 소프트웨어를 자주 전달하라. 두어 주에서
두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.

비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에
걸쳐 날마다 함께 일해야 한다.

동기가 부여된 개인들 중심으로 프로젝트를 구성하라.
그들이 필요로 하는 환경과 지원을 주고 그들이 일을
끝내리라고 신뢰하라.

개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장
효율적이고 효과적인 방법은 면대면 대화이다.

작동하는 소프트웨어가 진척의 주된 척도이다.

애자일 프로세스들은 지속 가능한 개발을 장려한다.
스폰서, 개발자, 사용자는 일정한 속도를 계속 유지
할 수 있어야 한다.

기술적 탁월성과 좋은 설계에 대한
지속적 관심이 기민함을 높인다.

단순성이 (안 하는 일의 양을 
최대화하는 기술이) 필수적이다.

최고의 아키텍처, 요구사항, 설계는
자기 조직적인 팀에서 창발한다.

팀은 정기적으로 어떻게 더 효과적이 될지
숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.


참조
Manifesto for Agile Software Development
http://agilemanifesto.org/

Agile Conference 2009
http://agile2009.agilealliance.org/index.html


저작자 표시
신고
Posted by 박경훈
애자일 이야기2015.01.06 14:57
내부 개발팀의 교육용으로 사용한 자료를 공유합니다.


  • 1. 박경훈 애자일 의 모든 것 http://blog.hoons.net
  • 2. 진행순서 - 애자일 선언문의 원칙들 - 애자일의 오해 - 스크럼(Scrum) - User Story - Estimation - XP(eXtreme Programming) - XP Practice #1 – TDD와 테스트 자동화 - XP Practice #2 – Refactoring, CI - 애자일 사례 소개 1일차 2일차 3일차 4일차 5일차
  • 3. 왜 프로젝트는 실패하는가? 올바른 커뮤니케이션의 부재
  • 4. 프로젝트 매니저 개발자 디자이너 코드의 양이 만만치 않은데 디자인 하기 어려운 기능인데 무조건 빨리 끝내야 하는데 새 요구사항 팀들의 잘못된 목표
  • 5. 애자일의 등장 배경 S/W 개발 환경의 변화 - 결과물의 배포시기가 중요해짐 - 개발 생산성 저하 기존 방법론의 한계 - 문서 및 절차 위주의 방법론 (변화에 대응이 어려움) - 개발자의 개발능력의 차이 불안정 Waterfall model의 문제점 - 불명확하고 변화하는 사용자의 요구사항 - 개발된 모듈들의 통합의 어려움 - S/W 품질의 하락(충분한 테스트가 어려움)
  • 6. Agile 방법론의 정의 더 나은 의사소통 지속적인 변화 관리 우선순위에 따라 중요한 것 먼저
  • 7. - 어떻게 누가 잔디를 깎을 것인지 계획서 - 섬세하면서 포괄적인 청소 계획서 - 청소 도구 리스트 잔디 청소업체의 사례
  • 8. 애자일 선언문의 원칙들
  • 9. 원칙 #1 우리의 최우선 순위는, 가치 있는 소프트웨어를 일 찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다. - 고객이라는 하나의 동일한 목표를 가지는 것 - 자주 보여주는 것이 피드백을 받고 반영할 수 있는 최고의 방법이다.
  • 10. 원칙 #2 작동하는 소프트웨어를 자주 전달하라. 2-4주 간격으로 하되 더 짧은 기간을 선호하라. - 일정 주기를 통해서 팀에 리듬감을 더할 수 있다. - 주기를 통해서 평가하고 다시 계획한다.
  • 11. 원칙 #3 작동하고 있는 소프트웨어를 보여주는 것이 진척을 확인할 수 있는 길이다. - 고객에게 신뢰를 전달할 수 있는 방법이다. - 결과물 없이 커뮤니케이션이 어렵다.
  • 12. 원칙 #4 비록 개발의 후반부일지라도 요구사항 변경을 환영 하라. 애자일 프로세스들은 변화를 활용해 고객이 경쟁력 에 도움이 되게 한다. - 프로젝트의 공통된 목표는 고객을 만족시키는 것이다. - 변화를 통해서 결과를 만들어 가는 것이 애자일 방법론이다.
  • 13. vs
  • 14. 원칙 #5 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체 에 걸쳐 날마다 함께 일해야 한다. - 커뮤니케이션의 퀄리티를 높여야 한다. - 잘못된 지시나 생각의 전달을 줄여야 한다. - 날마다가 아니여도 바로 피드백이 가능하면 좋다.
  • 15. 원칙 #6 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라. - 프로젝트들은 사람을 통해서만 성공할 수 있다. - 안좋은 환경과 빨리하는 개발의 강조는 협업과 소통을 저해한다.
  • 16. 원칙 #7 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가 장 효율적이고 효과적인 방법은 얼굴을 보며 할 수 있는 대화이다. - 이메일이나 문서로 충분한 내용을 다루기 어렵다. - 시간을 절약하는 길이다.
  • 17. 원칙 #8 최고의 아키텍처, 요구사항, 설계는 스스로 움직이 는 조직적인 팀에서 탄생한다. - 최고의 설계는 팀에 연결된 사람으로부터 나오는 것이지 특정한 역할 로부터 나오는 것이 아니다. - 일을 하면서 쌓인 작고 큰 지식들이 결국 구조를 만들기 마련이다.
  • 18. 원칙 #9 기술적 탁월성과 좋은 설계에 대한 지속적인 결과 물의 전달이 민첩함을 높인다. - 좋은 설계는 한번에 정의 내려질 수 없다. - 우리는 지속적인 결과물을 만드는 것과 동시에 기술적으로도 충분히 탁월함을 유지해야 한다. - 잘 캡슐화된 디자인이 민첩함을 높일 수 있다.
  • 19. 원칙 #10 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다. - 일에 지친 사람은 실수를 만들 확률이 높다. - 단기간 높은 성과보다 길게 꾸준한 성고가 좋다.
  • 20. 원칙 #11 단순함, 안 해도 되는 일은 최대한 안 하게 하는 기 교, 이것이 핵심이다. - 사용자와 개발자 그리고 모든 사람들 입장에서 일을 단순화 시킬 수 있어야 한다. - 아직 안 끝난 일들을 계속 돌아보며 필요없는 일들을 지워나가야 한 다.
  • 21. 원칙 #12 팀은 정기적으로 더 효과적으로 일할 수 있는 방법 을 숙고하고 그에 따라 자신의 행동을 조율하고 수 정한다. - 커뮤니케이션의 퀄리티를 높여야 한다. - 잘못된 지시나 생각의 전달을 줄여야 한다. - 날마다가 아니여도 바로 피드백이 가능하면 좋다.
  • 22. 애자일의 오해
  • 23. 애자일의 오해 애자일 개발 방법론은 새로운 개발 방법론이다. 애자일은 스크럼/XP/칸반 등 하나의 개발 방법론만 이용해야 한다. No, 가장 큰 차이는 가치와 철학 No, 대부분이 원하는 기술과 프로세스들을 연결하여 사용한다.
  • 24. 애자일의 오해 만약 애자일을 도입하면 100% 프로세스에 따라야 한다. 애자일 개발팀들은 시니어 개발자들로 구성되어야 한다. No, 작은 것부터 시작해야 한다. 어떤 변화를 주기 전에 충분한 동기가 필요하다. No, 슈퍼 개발자 집단보다는 능력이 고루 섞인 팀에서 더 큰 장점을 발휘한다.
  • 25. 애자일의 오해 작은 프로젝트에서만 가능하다. 새로운 프로젝트에서만 도입이 가능하다. No, 가장 큰 차이는 가치와 철학 No, 이미 존재하는 소프트웨어를 확장하고 개발하는 프로젝트에서도 도입이 가능하다.
  • 26. 애자일의 오해 애자일 개발 방법론으로 전환하면 많은 장점을 가 져다 준다. No, 전환만으로는 어렵다. 팀 전체가 애자일의 가치와 원칙을 공유해야 한다.
  • 27. 커뮤니케이션
  • 28. Exercise - Drawing Communication Game
  • 29. 스크럼(Scrum) Ken Schwaber & Mike Beedle
  • 30. 작은 목표를 주기적으로 전달하는 것(Baby Step) 진행을 모니터링 하고 결과에 따라 계획을 조 절하는 것 비즈니스 목표가 변경되는 것과 개발팀이 민 첩하게 대응하여 완료할 수 있는 것들의 밸런 스를 조정하는 것
  • 31. Values Commitment Focus Openness Respect Courage
  • 32. Scrum Team
  • 33. 스프린트(Sprint) “The team works for a fixed period of time called a Sprint” - 1~6주 범위 내에서 특정 기간을 선정 - 일반적으로 2주 or 4주를 가장 많이 사용함 - 스프린트 기간 동안에는 분석, 설계, 코딩 그리고 테스트와 배포까지의 모든 과정을 포함함 — Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 50)
  • 34. Sprint Planning Meeting “Customers, users, management, the Product Owner and the Scrum Team determine the next Sprint Goal and functionality at the Sprint Planning meeting. The team then devises the individual tasks that must be performed to build the product increment” — Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 47) Input: 백로그, 수용 가능한 시간, 과거의 퍼포먼스 Output: 스프린트 목표, 스프린트 백로그
  • 35. Output Example Sprint Goal: A non-developer can create a basic invoice on their machine Sprint Backlog: – Create basic invoice (no tax etc) – Generate VAT invoice – Deploy application to a non-developer Scrum team member’s PC – Set-up automated test environment
  • 36. Daily Scrum Meeting “Software development is a complex process that requires lots of communications. The Daily Scrum meeting is where the team comes to communicate” — Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 40) 매일 짧은 미팅(15분): - 내가 한 일 - 오늘 할 일 - 있었던 이슈들
  • 37. Sprint Review “The Sprint Review meeting is a four-hour informational meeting. During this meeting, the team presents to management, customers, users and the Product Owner the product increment that it has build during the Sprint” — Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 54) 만든 결과물이 제품 책임자가 원하는 기능인지 확인 진행된 프로그레스의 리뷰 (비즈니스 & 기술적 이슈 공유) 다음 스프린트의 효율을 높이기 위한 아이디어 공유
  • 38. Burndown Chart
  • 39. Scrum Board
  • 40. User Stories
  • 41. User Story? …understandable to customers and developers, testable, valuable to the customer and small enough so that the programmers can build half a dozen in an iteration. …A user story is nothing more than an agreement that the customer and developers will talk together about a feature. — Beck et al, 2001, p. 45-6 개발자와 제품 책임자와의 소통을 위한 요구사항 정의서
  • 42. 개발 문서에 의존하면? 변화를 받아 들이지 못한다. 고객이 원하는 것이 아닌 적혀있는 명세에 따라 개발한다. 실제 20%만 제대로 된 요구사항이다. 잘못된 추측과 가정이 난무한다. Ex) “나는 그가 설계서를 안 만들었다고 말하지 않았습니다."
  • 43. 사용자 스토리 규칙 1. 다른 스토리에 종속적이지 않아야 한다. 2. 너무 세세하게 적지 않아야 한다. 3. 추정 가능해야 한다. 4. 적당한 크기로 작성해야 한다. - 한 스프린트 안에서 개발이 가능한 5. 테스트 가능해야 한다.
  • 44. Template As a I … < role> … I want … <short description of feature> … So that … <value or why need functionality> … Example: As a regular traveler I want my cell-phone to wake me up at a set time so that I don’t need to pack an alarm clock. 스마트폰 이용자는 내가 있는 지역의 날씨를 알기 위해서 날씨 앱을 이용하고 싶다.
  • 45. Acceptance Criteria Given … <some initial context (the givens)> … When … <an event occurs> … Then … <ensure some outcomes> … Example: Given my cell-phone is switched off When the time for my alarm is reached Then turn the cell-phone on and sound the alarm 다른 나라를 여행하고 있는데 인터넷이 되는 환경에서 날씨 앱을 실행했더니 그 해당 지역의 날씨의 정보를 가져와 보여주었다. => 통합 테스트(IntegrationTest) 조건
  • 46. Example
  • 47. Example
  • 48. Example
  • 49. Example Snapshot As a user, I want to take a snapshot of any part of the book where I don’t understand so that the snapshot can be uploaded to the program. Criteria Verify that user is able to take a picture in the application. Estimation 8
  • 50. Exercise – User Story
  • 51. Estimation
  • 52. About Estimation 누가? 왜? 일과 관련된 모든 사람들 스프린트를 계획하고 일들의 우선순위를 정하기 위해서 측정 단위 : 시간 (날짜 or Hours) 복잡도 (포인트) 사이즈 (SS, S, M, L, XL)
  • 53. Planning Poker
  • 54. Exercise – Planning Poker
  • 55. XP(eXtreme Programming)
  • 56. About XP 1999년 켄트 백의 저서인 'Extreme Programming Explained - Embrace Change‘ 에서 처음 발표 10-12 개의 실천법(Practices)들로 구성
  • 57. Values Communication Feedback Simplicity Respect Courage
  • 58. XP Practices Small Release Simple Design Refactoring Testing (unit and acceptance) Pair Programming Collective Ownership Continuous Integration 40-hour week On-site customer Coding Standards
  • 59. XP Anti-practice
  • 60. AntiPatterns of XP Practices  Introduced by Yoshihito Kuranuki(TIS, Inc.) and Kenji Hiranabe(Eiwa System Management)  Japanese XP Community  Various XP AntiPracties
  • 61. Brownie's Works – “The boss refactored our code!”
  • 62. [story 1. Brownie's Works] WR WR a freshman, began to learn the fun of programming. CR CR also a freshman, had quite a good experience of programming in the university.
  • 63. [story 1. Brownie's Works] AF (Coach) This is the first “freshman pair”. Can you guys finish this task? Yes, sir
  • 64. [story 1. Brownie's Works] Late in the evening, they checked in their code to their code base. The "fanfare" sounded nicely (their auto- build/test batch played fanfare if it is successful). It worked! It was a hard one, thank you for your help. Thank you... let's go home.
  • 65. [story 1. Brownie's Works] RG -Senior Developer Late at the night, the senior programmer RG was working alone. What's this messy code!!!? This supposed to be like this... He refactored all the code the freshman pair had just checked in.
  • 66. [story 1. Brownie's Works] Our code is gone. Yes, I refactored the code. That’s collective ownership. The next morning…
  • 67. [story 1. Brownie's Works] The boss refactored our code! CR and WR were really depressed…
  • 68. Let’s discuss [story 1. Brownie's Works]
  • 69. What if they are not there? Mail to the list why and how you refactored. I think you should have pair programmed when you refactored their code. [story 1. Brownie's Works]
  • 70. This kind of thing would happen repeatedly, so it would be easier to teach them once. [story 1. Brownie's Works]
  • 71. [story 1. Brownie's Works] RG’s action made a new move in the team dynamics. CR andWR learned a lot from RG with pair programming.The team got back its normal or even better condition. [After]
  • 72. Anybody Syndrome - “I’m not necessary here”
  • 73. [story 2. Anybody Syndrome ] One morning, WR got a bad cold. He called in to the office and said to the coach. "I think I have a cold. May I take a day off?" Sure, it was a tough iteration. Don't worry about the team. Take a rest
  • 74. [story 2. Anybody Syndrome ] After four days' off, he came to the office and saw the team working just as well as the day he left. He was happy that everything was fine, but felt some loneliness. What is my value for the team? I’m not necessary here… After that, he began to stay away from his work quite often.
  • 75. Let’s discuss [story 2. Anybody Syndrome ]
  • 76. [story 2. Anybody Syndrome ] The coach had an interview withWR face to face You are frequently absent from the office these days, is anything the matter with you? when I took some days off and came back, I found that the team did not have any trouble at all.
  • 77. [story 2. Anybody Syndrome ] “Yes, that's a good thing! That means the team is fine without me.
  • 78. [story 2. Anybody Syndrome ] That’s not quite right. Everybody wants to work with you, and you have your own goal in the project. You participate in the project with that goal, don’t you? The coach and WR talked about his goal in the project and his career plan. WR was grateful to the coach for giving an opportunity to talk over these kinds of things in a big picture.
  • 79. The project members found that they had their own goals as well as the project goal and they were free to talk about them anytime. That became a grand rule set by the coach. They now talked about their dreams, plans, and families.They started acting more autonomously, and the fresh energy came back to the team. [story 2. Anybody Syndrome ] [After]
  • 80. Pairing Prison – “I'm always under observation!”
  • 81. [story 3. Pairing Prison ] CR was a senior programmer with three years of experience in waterfall type development environment. He had been interested in XP, and this was his first XP experience in a real project. He had wanted to try pair programming, so this was a wonderful opportunity for him.
  • 82. When he paired with juniors, he got serious so he become a good example. [story 3. Pairing Prison ]
  • 83. With seniors, he felt like he was taking an examination. Pair programming made him feel observed in a prison. [story 3. Pairing Prison ]
  • 84. He could not stand the situation anymore, and consulted the coach. He said [story 3. Pairing Prison ] I'm always under observation!
  • 85. Let’s discuss [story 3. Pairing Prison ]
  • 86. The next day, the coach told the team that he recommended to take breaks more often. The team adopted this as a ground rule. In addition, they doubled the lunch time for their personal time. [story 3. Pairing Prison ]
  • 87. 테스트 자동화와 TDD
  • 88. 소프트웨어의 소스는 복잡하게 연결되어 있다.
  • 89. 작은 한 부분이 수정된다면?
  • 90. 모든 기능을 다시 테스트 해야 한다.
  • 91. 소스코드는 시간이 흐르면 녹이 슨다.
  • 92. 끊임없이 OOD(Object Oriented Design)와 패턴 구문들을 적용해가며 리펙토링 해야 한다.
  • 93. 하지만 리펙토링이 어려운 이유
  • 94. 모든 기능을 다시 테스트 해야 한다.
  • 95. 자동화 된 테스트가 없다면?  자체 버그 검출 능력 저하 - 모든 기능을 테스트 하기 어려움  소스 코드의 품질 저하 - 어디서 버그가 생길지 모르기 때문에 잘못 된 코드도 고치지 않으려 하는 현상  자체 테스트 비용의 증가 - 작은 수정에도 모든 기능을 다시 테스트 해 야 되는 문제
  • 96. 자동화 된 테스트란?  모든 테스트 케이스를 코드 스크립트로 변환 한 집합체
  • 97. 3rd party testing tools  http://www.youtube.com/watch?v=qsh4zWa 6bE8  http://www.youtube.com/watch?v=4TGkGQo nmy4#t=64
  • 98. 누가 테스트 스크립트를 만드는가? Software Engineers QA Engineers Software Architect
  • 99. 개발 프로세스 요구사항 Software & QA Engineer 테스트 케이스 수립 - 공백입력 하면 오류 메시지 띄우기 - 사용자가 여러 개의 비디오를 옮길 수 있게 개발 Software EngineerQA Engineer 통합 테스트 코드 작성
  • 100. TDD란 무엇인가?  Test-Driven Development - 요구사항의 테스트 요건을 먼저 고려  Test-First Development - 개발 전 테스트 코드를 먼저 작성하여 개발  1999년 XP라는 애자일 기반의 개발 방법론과 함께 소개 됨
  • 101. TDD란 무엇인가? 기존 개발방식 TDD의 개발방식
  • 102. TDD의 장점  높은 소스코드 품질 - MS와 IBM사의 조사 결과 TDD 약 15~35% 정도의 개발시간 증가 결 함율(버그)은 약 40~90% 정도 줄어듬 - http://research.microsoft.com/en- us/groups/ese/nagappan_tdd.pdf  재설계 시간의 절감  손쉬운 테스트 근거 산출 및 문서화 (test coverage, performance)  디버깅 시간의 절감
  • 103. TDD의 단점  all about 개발 생산성!
  • 104. 1부터 10까지의 수를 출력하는 프로그램 만들기! - 단, 3의 배수에서는 숫자대신 “HOONS”를 출력 - 5의 배수에서는 “JAEDAM”을 출력
  • 105. 통합테스트와 유닛테스트 Dependency Injection = AOP
  • 106. 편의점 카운터에서 물건을 스캔한 뒤에 고객에게 최종 가격을 알려주는 프로그램이 필요합니다. 물건들의 가격은 데이터 베이스에 있으며, 한가지 특별한 것은 현재 모 든 물건을 2개 사면 하나 더 주는 이벤트를 하고 있기 때문에 이 로직을 반영해주세요.
  • 107. 데이터 레이어 => 가격정보 비지니스 레이어 => 할인점검 유닛테스트 유닛테스트 통합테스트
  • 108. Test Automation /TDD AOP Repository Pattern MVC, MVP, MVVM Dependency Injection SOLID, DRY, KISS ORM - Entity CI Pair programing Git – code review BDD/DDD Agile – XP/Scrum Daily Standup User Story & Estimation 패턴 문화
  • 109. 결과 중심적 개발 프로세스 Project Manager Software Engineer Tester 요구사항 결과물 개발
  • 110. 품질 중심적 개발 프로세스 Project Manager ① 요구사항 Architect / Lead developer Software Engineers ② 분석/설계 전달 개발 결과물 ③ 코드리뷰 요청 (pull request) Architect / Lead developer Tester 테스트 요청 결과물 피드백 코드 리뷰
  • 111. Continuous Integration
  • 112. Continuous Integration “팀원들이 작업한 결과를 자주 지속적으로 통합하 고 그것을 자동화 하는 것”
  • 113. Why CI? 구현 기능의 가시화 (작업물의 공유) 프로젝트의 결함 조기 발견
  • 114. CI를 넘어
  • 115. Developer vs Operator
  • 116. Devops tools
  • 117. 코드 리팩토링
  • 118. 소스코드는 시간이 흐르면 녹이 슨다.
  • 119. 그 이름은 스파게티,,
  • 120. 좋은 코드란? “기계가 아닌 사람이 이해 할 수 있게 작성된 코드”
  • 121. 리팩토링(Refactoring) 이란? “소프트웨어 디자인을 개선하고 코드를 쉽게 사용하 고 이해할 수 있게 만드는 작업”
  • 122. When to refactor? 새로운 함수를 추가할 때 버그를 수정해야 할 때 코드 리뷰를 수행할 때
  • 123. 리팩토링이 무의미한 경우 리팩토링을 실행해도 복구가 어려울 정도로 망가져 버린 코드들 데드라인이 너무 가깝고 리팩토링한 검증할 테스트 코드가 없을 때
  • 124. 나쁜 코드 스멜 복사된 코드 로직 너무 긴 메서드 굉장히 긴 클래스 너무 많은 파라미터 리스트
  • 125. Before Refactoring 테스트 코드의 작성
  • 126. 나의 규칙을 따르라!
  • 127. #1 메서드 추출 void PrintOwing(double amount) { PrintBanner(); //print details WriteLine("name:" + _name); WriteLine("amount" + amount); } void PrintOwing(double amount) { PrintBanner(); PrintDetails(amount); } void PrintDetails(double amount) { WriteLine("name:" + _name); WriteLine("amount" + amount); }
  • 128. #2 인라인 메서드 int GetRating() { return (MoreThanFive()) ? 2 : 1; } bool MoreThanFive() { return _number > 5; } int getRating() { return (_number > 5) ? 2 : 1; }
  • 129. #3 임시변수의 중복 사용 double temp = 2*(_height + _width); WriteLine(temp); temp = _height * _width; WriteLine(temp); double perimeter = 2*(_height + _width); WriteLine(perimeter); double area = _height * _width; WriteLine(area); 임시 변수는 한번만 할당
  • 130. #4 파라미터의 값 할당을 피해라 int Discount (int inputVal) { if (inputVal > 50) inputVal -= 2; … } int Discount (int inputVal) { int result = inputVal; if (inputVal > 50) result -= 2; … } 파라미터를 변경하려면 임시 변수를 이용하라
  • 131. #5 메서드를 객체로 class Order... double price() { double primaryBasePrice; double secondaryBasePrice; double tertiaryBasePrice; // long computation; ... } 한 메서드 안에서 진행되는 작업이 너무 많은 경우
  • 132. #6 복잡한 수식의 표현 if( ( platform.toUpperCase().indexOf("MAC") > -1 ) && ( browser.toUpperCase().indexOf("IE") > -1 ) && ( wasInitialized() && resized > 0 ) { // 작업... } bool isMasOS = platform.toUpperCase().indexOf("MAC") > -1; bool isIEBrowser = browser.toUpperCase().indexOf("IE") > -1; bool wasResized = 0; if( isMacOS && isIEBrowser && wasInitialized() && wasResized ) { // 작업... } 복잡한 수식을 이해하기 쉽게 변수를 적절히 이용
  • 133. #7 Single Responsibility class Customer { public void Add() { try { //DB 접근코드 } catch (Exception ex) { System.IO.File.WriteAllText( @"c:Error.txt", ex.ToString()); } } } class FileLogger{ public void Handle(string error){ System.IO.File.WriteAllText(@"c: } } class Customer { private FileLogger obj = new FileLogger(); public void Add() { try{ // DB 접근코드 } catch (Exception ex) { obj.Handle(ex.ToString()); } } } 하나의 클래스에서는 하나의 책임만 할당
  • 134. “나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전량에 의거해 철저히 처리한다.” — 이야네 스트룹스트룹(Bjarne Stroustup), C++창시자 의존성 줄이는 것 = 객체간의 강한 참조를 줄이는 것 = Loose coupling = 클래스 참조 대신 Interface를 이용
  • 135. class FileLogger{ public void Handle(string error){ System.IO.File.WriteAllText(@"c:Error.txt", error); } } class Customer { private FileLogger obj = new FileLogger(); public void Add() { try{ // DB 접근코드 } catch (Exception ex) { obj.Handle(ex.ToString()); } } } File Logger가 아닌 DBLogger도 구현해야 한다면? #8 의존성 제거
  • 136. interface ILogger { void Handle(string error); } class FileLogger :ILogger { public void Handle(string error) { System.IO.File.WriteAllText(@"c:Error.txt", error); } } class DBLogger : ILogger { public void Handle(string error) { //DB 저장 로직 } } 인터페이스의 도입
  • 137. class Customer { private readonly ILogger _obj; public Customer(ILogger obj) { _obj = obj; } public virtual void Add() { try { //Some codes } catch (Exception ex) { _obj.Handle(ex.ToString()); } } } var customerDB = new Customer(new DBLogger()); var customerFile = new Customer(new FileLogger())); Customer의 loose coupling
  • 138. 리팩토링 추천도서 리팩토링 : 코드 품질을 개선하는 객체지 향 사고법 - 저)마틴 파울러 xUnit 테스트 패턴 : 68가지 단위 테스트 패턴을 통한 테스트 코드 리팩토링 기법 – 저) 제라드 메스자로스
  • 139. 애자일 도입사례
  • 140. 세일즈포스 – 대규모 개발팀에서,, CRM 끝판왕 (클라우드 기 반, SaaS) 87,200여 회사에 이용 200만명 이상의 사용자 3개월 기간 동안의 30개의 대규모 개발 팀에 애자일 도입
  • 141. 도입 배경 - 정확하지 않은 전체 개발기간 (일찍 산정하고 평가하는 것은 결국 각 기능별 정학한 완 성일자와 완전한 테스팅 스케줄을 제공할 수 없었다.) - 실제 릴리즈의 모든 단계별로 눈에 보여지는 결과물의 부재 - 거의 릴리즈 끝에 이루어지는 기능들의 늦은 피드백 - 길고 예측이 어려운 릴리즈 스케줄 - 팀이 확장될수록 줄어드는 생산성
  • 142. 도입 결정 KISS(Keep it Simple Stupid)개발 원칙과 빠른 반복 주기, 고객들의 의견이 중요 -> 애자일 원칙과 유사 시범적 팀에 도입 vs 일부 팀에 도입 =>대부분의 팀 원들이 같은 시간에 같이 도입을 원 함
  • 143. 도입 과정 - 상당수의 개발자들에게 외부 스크럼 교육을 지원 - 스크럼 마스터/개발자 자격증 응시 지원 - 애자일 TF팀이 꾸려져 사내 팀에 Lean과 XP 교육
  • 144. 성공요인 #1 - 개인의 생산성 보다는 팀의 처리량에 초점을 맞추는 것 - 각 기술 별로 나뉘어진 팀들은 매일 만나서 진행하는 미팅 - 공통으로 사용하는 언어의 정의와 간단한 애자일 프로세스 - 모든 팀 별로 일들의 명확한 우선 순위 리스트 - 사용자 스토리와 새로운 업무 측정방법의 정의 - 빌드 속도와 유연성에 초점이 맞추어진 자동화 팀 - 제품과 릴리즈의 완성도를 하루 단위로 확인할 수 있는 도 표
  • 145. 성공요인 #2 - 스크럼을 이용한 제품 라인과 주별로 모든 팀이 볼 수 있는 어떤 결과물 - 넓은 분야의 스프린트 리뷰와 매달 진행하는 회고 - 제품 책임자(Product Owner)와 스크럼 마스터 (ScrumMaster)들의 주기적 미팅 - 큰 릴리즈를 앞두고 정확한 시간 단위로 정확하게 만들어지는 작은 릴리즈 - 약 1500개 이상의 버그의 감소 - 매달 진행되는 잠재적인 제품들의 릴리즈
  • 146. 일찍 알았으면 - 일찍 애자일 도입 피드백에 귀 기울이는 것 - 제품 책임자를 일찍 교육 시키는 것 - 외부의 코치들을 일찍 섭외하는 것 - 자동화 부분을 보다 일찍 시작하는 것 - 경영진들에게 애자일 도입에 대한 구체적인 업무 들을 요청하는 것 - 조금 더 클리어하게 애자일의 역할이 무엇인지를 전달하는 것
  • 147. 세일스포스 사례를 통한 교훈 - 애자일을 도입을 진행할 헌신적이고 모든 권한을 가지고 있는 팀을 만드는 것 - 전문가의 도움을 얻는 것 - P2P처럼 개개인이 서로 코치할 수 있게 하는 것 - 여러 개의 팀을 뛰어나게 만드는 것 - 회사 레벨의 스프린트를 만드는 것 - 일찍 필요한 도구를 만드는 것 - 진행사항을 눈에 볼 수 있게 하는 것과 최대한 많 은 커뮤니케이션을 만드는 것 - 실수를 인정하고 그것에 관대해지는 것
  • 148. BBC – 제품 책임자의 역할 영국 방송국 (British Broadcasting Corporation) iPlayer 프로젝트 진행 대규모 프로젝트에서 프 로젝트 진행
  • 149. iPlayer 프로젝트 목표 - 1. 홈페이지 개발 - 2. “다운로드”, “지금 보기” 와 같은 사용자 기능 제공 및 액션 의 처리 - 3. 내려 받은 미디어를 관리하기 위한 애플리케이션 - 4. 내려 받을 수 있는 컨텐츠를 검색하고 내려 받을 수 있는 환 경 제공 - 5. 웹 기반의 프로그램 스케줄과 사용자 가이드 - 6. 프로그램 제목, 방영날짜 등과 같은 메타데이터의 정보 관리 - 7. 기존의 인증 시스템과 연동하여 자동로그인 기능 (SSO:Sigle Sign On) 제공 - 8. IP 체크를 통한 위치 기반의 사용자가 맞춤 환경 분석 - 9. 사용자 경험과 인터렉션
  • 150. iPlayer 프로젝트 - TV 프로 다시보기/실시간시청 기능 제공 - 9개의 컴포넌트 팀 & 중앙 관리팀 (80여명) - 2개 팀은 이미 스크럼 경험 - 2주 간격의 스프린트 - 일일스크럼미팅 / “스크럼”의 스크 럼 미팅 진행 - 각 팀별로 스크럼 마스터, 제품 책 임자는 중앙팀에 배치
  • 151. 9개의 팀 = 각 팀병1명의 스크럼마스터 + 팀원들 중앙 관리 팀 제품 책임자
  • 152. 무엇이 잘못되었을까? - 진행 속도가 2주차 부터 현저히 감소 - 1명의 제품 책임자가 너무 바쁨 - 제품 책임자가 어떤 결정을 혼자서 내리기 어려움 - 백로그에 우선순위가 없어서 자신이 원하는 항목 부터 처리 - 제품 책임자가 결정을 내리지 못하여 미팅이 잦아 짐 - 스크럼으로는 성공할 수 없다는 목소리들
  • 153. Let’s discuss
  • 154. 처음 시도 중앙 팀을 2개로 나눠서 관리
  • 155. 하지만 이전과 비교해서는 좀 나아짐 하지만 여전히 각 팀들의 스크럼을 중앙에 동기화 하 는 것이 어려움 각 팀 별로 가지고 있는 의존성 때문에 잦은 미팅 두 책임자들의 잦은 충돌과 비효율적인 결정
  • 156. 자기 주도적으로 일하기 각 9개의 팀 별로 제품 책임자의 역할을 하는 제품 프로듀서를 다시 임명 9개의 팀 = 각 팀병1명의 스크럼마스터 + 팀원들
  • 157. 효과 • 각 팀들은 보다 분명한 제품의 책임 의식 고취 • 프로젝트 요구사항이 명시적으로 정의 가능 • 질문에 대한 빠른 답변 가능 • 각 팀들이 명확한 제품 백로그를 생성 & 스프린트 계획수립 가능 • 해야 할 업무의 배분이 적절이 이루어졌고 새로운 기능들을 매 스프린트마다 고객에게 전달 • 각 팀의 제품 책임자들은 각자 맡은 분야의 전문가 가 됨 • 일관성이 없었던 제품 백로그 항목들이 각 팀들에 의해서 완화됨
  • 158. BBC의 팀 • 프로젝트 안에서 각 팀을 구성할 때 제품 책임자와 함께 할 수 있는 시간을 고려해야 한다. • 한 명의 제품 책임자에 의존하다 보면 결국 일 진 행이 늦어지고 프로젝트의 올바른 방향을 설정하는 것이 어렵다. • 제품 책임자들의 역량은 팀이 크거나 여러 팀의 목 표를 동시에 고려하다 보면 줄어든다. • 조직적이지 못한 팀이 하나의 프로젝트에서 같이 일하면 비즈니스 목표와 다른 제품이 만들어 질 수 있다.
  • 159. 대규모 스크럼 프로젝트의 성공조건 • 스크럼의 스크럼 • 같은 공간에서 일하는 개발 팀들 • 팀 안에서 적절한 역할의 사람들 • 권한이 있는 스크럼 마스터



저작자 표시
신고
Posted by 박경훈
애자일 이야기2015.01.06 11:10

BBC (British Broadcasting Corporation) 방송국은 영국에서 가장 크고 오랜 전통을 지닌 방송국이다. 특히 세계적으로 BBC 뉴스의 위상은 대단하다. BBC의 라디오와 TV 프로그램들은 현재 많은 세계의 방송사들의 채널을 통해서 방영되고 있다. 최근에는 BBC의 웹사이트를 방문하여 모바일, 타블렛, PC에서 TV를 시청하는 경우가 급증하고 있는 상황이다. 이에 맞춰 BBC는 인터넷을 통해서 모든 방송 컨텐츠를 시청자의 수요에 맞추어 제공해야 하는 과제를 진행하게 되었는데 그 과제를 진행하면서 도입했던 애자일에 대한 이야기를 살펴 볼 것이다.



많은 사람들이 대규모 조직에서도 스크럼이 가능한지 여부에 대해 의문을 갖고 있다. 특별히 애자일 개발 방법론에 회의적인 사람이거나 변화자체를 싫어하는 사람일수록 의구심이 클 것이다. BBC에서 스크럼을 도입한 보고서에서는 스크럼이 대규모 조직에서도 활용 가능할 뿐만 아니라, 우려했던 손해나 위험이 없다고 밝혔다. BBC에서 스크럼을 도입하면서 그 팀 멤버들은 스크럼 마스터와 함께 자연스럽게 기존에 보기 어려웠던 리더십이 발휘될 수 있었다. 하지만 그들이 경험했던 문제는 제품 책임자(Product Owner)의 역할이었다. 이번 사례에서는 BBC라는 대규모 조직에서 애자일을 도입하면서 겪었던 크고 작은 시행 착오들을 살펴보도록 하겠다.


프로젝트의 소개

iPlayer 프로젝트는 영국의 많은 시청자들과 해외에서 BBC의 TV프로그램이나 라디오 프로그램들을 듣고 싶어하는 사람들을 위해 진행했던 프로젝트이다. 필자 또한 영국에 거주하면서 실시간 방송과 뉴스들을 보기 위해서 가장 많이 이용하던 서비스이기도 했다. 이 프로젝트는 지난 7일 동안 방송되었던 컨텐츠들을 검색하여 다시 보기를 제공하고자 했다. 이 때, Kontiki 라는 P2P 네트워크를 통해서 데스크탑에 다운 받기 기능도 제공하려 했다.


 


[그림3-1] iPlayer 화면


장기목표는 모든 BBC의 프로그램들을 다운받거나 스트리밍 서비스를 제공하는 하나의 플레이어를 구축하는 것이었다. 마이크로소프트의 윈도우 플랫폼에서 제공하는 것을 시작으로 모바일과  다른 OS까지 확장하는 것이 최종 목표였다.

iPlayer를 개발하기 위해서 BBC는 외부 협력업체 두 곳과 함께 프로젝트 팀을 구성하였다. 협력업체는 주로 인코딩 된 미디어, 메타데이터, 자막, 저장공간 등과 같은 영상을 전달하는 역할을 담당하고 있었다. BBC에서 협력업체들과 더불어 프로젝트를 진행할 사내 조직을 FM&T(Future Media and Technology)라고 작명했다. 이 팀은 주로 UI와 미디어를 검색 같은 핵심 기능들을 맡았다.

FM&T가 프로젝트를 진행하기 위해서 추가적인 팀을 구성할 수도 있었지만, 효율을 위해서 기존에 회사 내 팀들의 협조를 받기로 했다. 그래서 모두 아홉 개의 팀들이 iPlayer에 필요한 컴포넌트를 개발하기 위해서 참여하였고, 중앙의 한 팀이 프로젝트를 관리하였다. 각 팀들은 아래와 같은 기준으로 나누어지게 되었다.


1. 홈페이지 개발

2. “다운로드”,  “지금 보기” 와 같은 사용자 기능 제공 및 액션의 처리

3. 내려 받은 미디어를 관리하기 위한 애플리케이션

4. 내려 받을 수 있는 컨텐츠를 검색하고 내려 받을 수 있는 환경 제공

5. 웹 기반의 프로그램 스케줄과 사용자 가이드

6. 프로그램 제목, 방영날짜 등과 같은 메타데이터의 정보 관리

7. 기존의 인증 시스템과 연동하여 자동로그인 기능 (SSO:Sigle Sign On) 제공

8. IP 체크를 통한 위치 기반의 사용자가 맞춤 환경 분석

9. 사용자 경험과 인터렉션


그럼 이 아홉 개의 컴포넌트 팀들 사이에서 도입했던 애자일 경험과 이 프로젝트에서 제품 책임자의 좌충우돌 경험에 대해 살펴보도록 하겠다.


프로젝트 준비하기

2006년 4월에 총 아홉 개의 개발팀에 80명의 직원들로 구성된 iPlayer 프로젝트가 발족되었다. 각 팀에는 개발자, 테스터, 분석가, 디자이너, 프로젝트 매니저 등 다양한 역할의 팀원들로 구성되었다. FM&T에서는 기존의 프로젝트 매니저들을 모두 스크럼 마스터로 역할을 바꾸기로 했다. 

아홉 팀 중 이미 일곱 팀은 내부적으로 스크럼을 적용하고 있었고 남은 두 팀들은 이번 프로젝트를 통해서 스크럼을 도입하게 되었다. 참여한 모든 팀들이 서로 개발한 결과물을 전달하는데 문제가 없게 하기 위해서 2주 기반 스프린트를 동시에 설정하여 서로 같은 주기로 진행하도록 했다. 미디어 영역에서는 전송환경이 불규칙적이기 때문에 제품 백로그(Product Backlog)가 변경 될 가능성이 높았다. 때문에 2주 기반의 스프린트 기간은 적절한 주기였다.

그들은 의무적으로 일일 스크럼 미팅을 각 팀 별로 진행하기로 했다. 그리고 이와는 별도로 스크럼의 스크럼 즉, 모든 팀들의 스크럼 마스터들이 모여서 각 팀 별로 구현해야 하는 기능들을 공유하기 위한 미팅도 매일 진행하기로 했다. 스크럼 마스터들의 미팅에서는 각 팀끼리의 의존관계를 고려한 구현의 진행 순서 중심으로 논의를 하고 그와 더불어 어제 무엇을 했고 지금 무엇을 하고 있는지도 서로 공유하기로 하였다. 그들은 또한 매주 각 팀의 선임 개발자들이 모여 개발 표준과 개발 방법들에 대한 내용을 공유하기로 했다. 

그 다음 그들이 프로젝트를 위해서 할 일은 바로 제품 책임자를 임명하는 것이었다. 대규모 프로젝트이기 때문에 제품 책임자는 중앙 관리 팀에서 진행해야 된다고 생각했다. 왜냐하면 중앙 관리 팀이 제품 전체의 로드맵과 설계, 요구사항들을 정리하는 역할을 맡았기 때문에 제품 관리자를 중앙 팀에 두는 것이 가장 효과적이라고 생각했다. 뿐만 아니라 중앙 팀은 스크럼에 있어서도 가장 잘 실천하고 있는 팀이었다. 

돌아보면 그들은 이렇게 구성한 스크럼의 스크럼 방식의 접근과 중앙 팀의 장점에 대한 확신이 충분히 없었다. 그리고 “무조건 빨리 만들자” 라는 생각을 가지고 있었는데 이 생각으로는 그 팀을 보다 효율적으로 움직일 수 없다는 것이 결론이었다. 그들이 몰랐던 사실이 하나 있었다. 그것은 스크럼은 개념이 아닌 행동이기에 적용하는데 있어 많은 노력과 시간이 필요하다는 점이다. 결코 짧은 교육만으로는 이것을 이룰 수 없었다. 

이렇게 프로젝트 환경을 설정하고 각 컴포넌트 팀들은 각자 자신의 맡은 바를 진행했다.


무엇이 잘못 되었던 것일까?

무엇이 잘못 되었던 것일까? 두 번째 스프린트를 진행할 때까지 프로젝트는 진척이 잘 되지 않고 있었다. 그들은 백로그(유저 스토리와 업무 리스트가 저장되어 있는 곳) 를 채울 수 없었다. 그나마 백로그에 있는 항목들은 대부분은 불확실한 것들이 대부분이었다. 제품 책임자가 사용자 스토리를 만들고 백로그에 할당하게 되는데 그들이 임명한 제품 책임자가 기능들을 불명확하게 작성한 것이었다. 왜냐하면 그 한 명의 제품책임자가 모든 내용을 다 정확하게 이해하기 어려운 부분이 있었기 때문이다. 

아홉 팀들은 모두 스프린트 주기를 동기화 시켰기 때문에, 동시에 중앙 팀의 제품 책임자에게 다음 스프린트 계획을 물어봐야만 했다. 하지만 많은 팀과 불확실한 업무들 때문에 제품 책임자가 스프린트 계획을 세우는데 많은 시간이 걸렸다. 한 팀당 이터레이션 계획미팅에 소요되는 시간이 보통 네 시간 정도 걸렸다. 거기에 불확실한 백로그 항목들을 상세화 하는데 네 시간이 더 소요되었다. 영국에서는 근로시간이 7시간이기 때문에 하루에 한 팀을 끝내기도 힘들었다.

그들에게 나타난 문제들을 정리해 보자면 다음과 같다.


• 제품 책임자는 너무 바빴고 결정을 제 때 내리는 것이 불가능 했다.

• 제품 책임자가 정신 없이 바쁘기도 했지만 그는 어떤 결정도 단독으로 내릴 수 없었다. 결국, 그 결정은 각 팀으로 넘겨졌다. 대부분의 팀들은 이런 이유로 개발 속도가 매우 느려졌고, 심지어 어떤 일도 진행하지 못하는 팀이 생겨 나기도 했다. 그래서 혼잡한 상황이 조금 진정이 된 상황에서만 제품 책임자가 정확한 방향을 제시해주는 것이 가능했다. 

• 백로그 항목들의 우선순위가 정해지지 않았기 때문에 각 팀은 자신이 원하는 항목부터 처리했다. 팀에서 꺼려하는 항목들은 가장 나중에 처리했다. 

• 백로그 항목들의 우선순위를 정할 때마다 제품 책임자는 고군분투 했다. 그 이유는 각 항목을 작성한 팀만 이해가 가능했기 때문이다.

• 제품 책임자가 결정을 내릴 수 없었기 때문에, 시간이 지날수록 미팅의 참석범위는 넓어지고 횟수는 잦아졌다.



이 상황은 그렇게 오래 지속되지 않았다. 그 동안 애자일에 비판적이던 사람들이 “스크럼으로는 결코 프로젝트를 성공할 수 없다”는 반대 목소리를 내기 시작했기 때문이었다.

스크럼 마스터들은 함께 모여서 현재의 상황을 파악하고자 하였다. 그들은 교육을 받았고 관련 서적들을 읽었으며, 타사 사례를 찾아봤다. 그들은 자신들의 스크럼이 책이나, 타사 사례와 크게 다른 점을 찾지 못했다. 하지만 분명한 점은 이대로가면 프로젝트가 실패할거라는 사실이었다. 다른 관점에서 그 스크럼은 잘 동작했지만 잘 안되었던 부분은 분명하고 빠른 결정이었다. 이는  백로그의 우선순위를 정할 권한이 제품 책임자에게 없고 결정을 내리기 위해서는 복잡한 절차가 필요했기 때문이었다. 

그들은 그 당시의 제품 책임자가 어떤 기능을 결정하는데 걸리는 시간을 소요될지 알 수 없었다. 그리고 가끔 제품 책임자는 이상하다고 생각이 들 정도로 현명하지 못한 결정을 내리고 있었다.



해결방안의 모색

한 명의 제품 책임자가 처리할 수 있는 업무는 제한되어 있다는 것을 깨닫게 되면서 그들은 중앙 팀에서 갖고 있는 제품에 대한 책임을 두 개의 조직으로 나누어서 관리하였다. 그들이 이런 결정을 내릴 수밖에 없었던 것은 한 명이었던 제품 책임자의 일에 부하가 너무 심했기 때문이다. 빠른 의사 결정을 위해 중앙 팀을 둘로 나누고 각 팀에 제품 책임자를 둠으로써 각자의 팀에서 독립적으로 결정을 내릴 수 있게 하려는 것이었다. 이 방법은 효과가 있었다. 제품 책임자에게 이전 보다는 제품 책임자에게 쉽게 접근하는 것이 가능해진 것이고 어떤 결정도 보다 쉽게 내릴 수 있었다. 그에 따라 제품 개발도 다시 진전이 있었다. 

하지만 여기서 빨라지고 쉬워졌다는 뜻은 이전과 비교해서 그렇다는 것이다. 여전히 문제가 남아 있었다. 사용자 스토리들이 제대로 되어 있는지 점검하고 또 다시 고치고 하는 부분이 반복되었고 결국 만족할 만한 산출물이 나오지 않았다. 그래서 그들은 다시 직면한 문제를 고민하게 되었는데 한가지 놓친 것이 있었다. 바로 한 주에 36시간 일할 수 있는 2명의 제품 책임자가 각 그룹의 계획을 커버 하려고 하고 있었지만 그들은 여전히 각 팀들의 스프린트들을 동기화 시키는 작업을 진행하기에는 너무 버거운 일정이 이었다는 것이다.

확실한 것은 두 명의 제품 책임자가 물리적으로는 일을 나눠서 처리하고 있었지만 정신적으로는 그 일이 나눠지지 않은 것이다. 즉, 그 둘 모두가 전체 제품에 책임이 있다고 생각한 것이다. 그래서 제품 책임자들은 여러 팀간의 의존성에 대해서 항상 고려해야 했다. 이러한 잘못된 생각이 팀간의 충돌을 야기할 수 밖에 없었다. 그래서 제품 책임자는 여기에 대해서 말이 안되고 비효율적인 결정을 내릴 수 밖에 없었다. 이런 일들이 매일 같이 있었다. 

결국에는 어떤 지시도 없는 것이 더 낫다고 생각될 정도였다. 왜냐하면 지시가 있어도 그것이 올바른지에 대한 확신이 없었고 그런 이유로 팀의 사기를 저하했기 때문이다. 두 제품 관리자의 의견이 대립 되었을 때, 개발팀들이 할 수 있는 것은 그저 잠시 회의를 멈추고 지켜보는 것뿐이었다. 

그들은 다시 한번 현재의 상황을 다음과 같이 정리했다.


• 제품 책임자에게 접근 하는 것이 확실히 접근하기 수월해 졌다.

• 두 제품 책임자의 의견대립이 자주 발생하였고 이는 업무진행을 힘들게 만들었다.

• 이러한 결과로 개발 팀들은 제품 책임자를 무시하기 시작했고 자기 팀이 원하는 대로 제품을 만들기 시작했다. 그래서 제품 책임자들은 프로젝트의 우선순위를 결정하는 책임자와 백로그에 있는 각각의 업무에 대한 책임자로서의 역할 보다는 팀간의 애매한 부분을 정리해주는 역할을 하게 되었다.



이렇게 시도한 새로운 구조에서 거의 4개월 동안 프로젝트를 진행하였다. 그 기간 동안 격한 토론을 비롯하여 팀 간의 갈등이 많았다. 일부 팀들은 다른 팀과의 협업을 거부하고 혼자 일하기도 하였다. 그러다 보니 스프린트 범위도 지켜지지 않았다. 결국, 2개의 그룹으로 나눴던 제품 책임자구조를 해산하고, 다시 중앙 팀에 한 명의 제품 책임자를 두기로 결정하였다. 그리고 가장 중요한 결정이었던 것은 각자 팀 별로 제품 책임자를 임명하기로 한 것이다.



자기 주도적으로 일하기

각자 팀에서 제품 책임자를 두는 방안을 실행한 후에 중앙 팀의 역할이 많이 축소되었다. 그저 몇몇 공통된 지시를 내리고 제품의 전체 로드맵을 그리는 정도였다. 그들은 각 팀에 임명된 제품 책임자를 개발 프로듀서라고 호칭했다. BBC는 다른 기업들과 다른 부분이 하나 있는데, BBC가 이익을 추구하는 사기업이 아닌 공기업이기 때문에 제품 책임자에게 자금 부분은 큰 고려사항이 아니었다. 그 보다 그들은 모든 사용자들에 유용한 제품을 만드는 것에 집중하였다. 그렇기 때문에 비즈니스 분석가의 관점이 BBC의 제품 책임자 역할에 있어서 이상적이었다. 

각 팀 별로 우선순위를 만들게 되었다. 중앙 팀은 업무목록을 제공했는데 단지 목록일 뿐 하나의 통일된 제품의 모습으로 준 것이 아니었다. 중앙 팀은 단순히 각 팀들이 필요한 요구 사항들을 정리했다. 즉, 하나의 제품을 개발함에 있어 각 팀들이 필요한 것들을 요구하고, 중앙 팀에서 이를 조율한 것이다.

각 팀에 소속된 새로운 제품 책임자들은 애자일에서 설명하고 있는 제품 책임자 역할을 큰 어려움이 없이 수행하였다. 예상치 못했던 점은 BBC 내부팀이 아닌 외부 협력업체와의 대화가 지속적으로 증가 했다는 것이었다. 프로젝트 준비하기에서 두 협력업체와 BBC 사내 팀으로 프로젝트 그룹을 형성했다고 설명했다. 중앙 팀은 바로 이 집단들과 대화를 진행하는 역할을 맡았다.

스크럼을 도입할 때 가장 중요한 것 중 하나는 애자일의 기본원칙에 기반하여 도입해야 한다는 점이다. 그리고 애자일 원칙 중 하나가 바로 팀 안에서 상호적인 대화가 열려있어야 한다는 것이다. 아쉽게도 팀을 변형하기 전에는 외부 협력업체를 포함한 여러 팀들이 모였을 때, 각 팀에 필요한 것을 정확히 몰랐었다. 때문에 서로 무엇을 요청해야 하는지 몰랐던 적이 많았다. 하지만 팀이 바뀐 뒤에 팀의 요구를 정확하게 알 수 있었기 때문에 전체 그림을 같이 공유하는데도 원활하였다.

이러한 제품 책임자의 변화를 통해서 그들은 다음과 같은 효과를 얻을 수 있었다.


• 각 팀들은 보다 분명한 제품의 책임 의식이 있었다.

• 프로젝트 요구사항이 명시적으로 정의 될 수 있었다.

• 질문에 대한 빠른 답변을 얻을 수 있었다.

• 각 팀들이 명확한 제품 백로그를 생성하고 스프린트 계획수립이 가능해졌다.

• 해야 할 업무의 배분이 적절이 이루어졌고 새로운 기능들을 매 스프린트마다 고객에게 전달할 수 있었다. 

• 각 팀의 제품 책임자들은 각자 맡은 분야의 전문가가 되었다.  

• 일관성이 없었던 제품 백로그 항목들이 각 팀들에 의해서 완화될 수 있었다.



독립적인 팀들로 나누고 나서 앞에서 언급한 효과들을 체험할 수 있었다. 하지만 여전히 부족한 부분이 있다고 말하는 사람들이 있었다. 전체적으로 프로젝트가 진행되는 상황을 파악하기가 복잡했고 릴리즈 계획을 세우고 여러 팀들의 결과물을 하나의 제품으로 통합하는 과정에 여러 날이 소모되기도 했다. 전체 프로젝트가 진행되는 상황들은 팀들이 일하는 공간에 업무보드, 포스트잇, 카드를 이용해서 관리했고 제품 릴리즈 계획의 경우 피벗 테이블(엑셀의 기능)을 통해서 만들어졌다.

그래도 이러한 구조가 완벽한 것은 아니었다. 두 가지 아쉬운 부분이 있었다. 먼저, 누구의 업무인지 명확하지 않은 경우 누구도 그 업무들을 하려고 하지 않았다. 다른 하나는 아홉 팀이 제품 로드맵을 각자 다르게 해석하고 있었다는 것이었다. 

후자의 경우 팀들이 그들의 백로그의 항목의 우선순위를 정할 때, 다른 팀들이 필요여부가 고려되지 않고 각자의 이해관계에서 정하고 진행했기 때문에 문제가 되었다. 이것은 심지어 가까운 공간에서 일하고 있는 팀들 간에게도 발생되었다.

그들이 진행상황을 점검하고 다시 반영하는 주기를 통해서 많은 개선을 가져 올 수 있었고 전체적으로 제품을 효과적으로 만들어 낼 수 있었다. 이러한 방법으로 약 6개월을 일을 지속했고, 각 팀이 독립적으로 일하면서 보다 성공적인 모델이 되었다. 



비즈니스 제품 책임자

그들은 이렇게 다양한 제품의 책임 구조를 통해서 많은 것을 배울 수 있었다고 말한다. 그들은 추가적으로 중앙 팀에서 일하는 “비즈니스 제품 책임자”의 역할을 만들었다. 즉, 기존의 제품 책임자 대신 비즈니스 제품 책임자로 일하는 것이다. 이 비즈니스 제품 책임자는 기능에 대한 결정을 내리지 않는다. 대신에 각 팀들의 제품들과 비즈니스 전체적으로 유지되어야 할 것들에 대한 책임을 갖고 있다. 뿐만 아니라 팀 사이에 갈등 발생하거나 협업이 원할지 진행되는지 관찰하고 각 팀 별로 우선순위가 적절한지 확인하는 것이다. 그 팀 내 제품 책임자들은 백로그 항목의 우선순위를 부여하는 제품 책임자의 역할을 넘어서 각 제품의 전문가로서의 역할을 할 수 있었다.

이러한 조직구조를 유지하고 모든 계층의 사람들에게 리포트를 작성하기 위해서 그들은 “테마”라는 컨셉을 작성하기로 했다. 즉, 사용자 스토리의 상위 레벨이라고 보면 된다. 예를 들어 “사용자가 검색이 가능해야 한다” 와 “사용자에게 추천 검색 단어를 알려줄 수 있어야 한다” 라는 검색에 대한 사용자 스토리들이 있다면 우리는 이것을 “검색”이라는 테마로 묶는 것이다. 그렇게 해서  비즈니스 제품 책임자는 이런 테마들의 우선 순위를 결정했다. 그렇게 함으로써 모든 팀들에게 무엇을 해야 할지를 명확하게 전달하는 것이 가능했고, 각 팀 별로 이에 맞는 자신들의 우선순위를 정할 수 있게 되었다. 모두 총 45개의 테마를 만들었고 이것은 총 828개의 제품 백로그들과 연결되었다.

예로 몇 개만 소개하자면 아래와 같은 테마들이 존재했다. 


• 사용자 가이드

• 설치, 업그레이드 그리고 언인스톨

• 접근성 – 자막


팀 안에서 스프린트를 계획하는 동안에 팀 내의 제품 책임자는 제품 전문가로서 제품에 대한 질문에 대해 답하는 것이 가능했고 팀의 스프린트 목표를 전체 프로젝트의 목표에 비춰 설명하는 것이 가능했다. 

마지막으로 팀들 간의 커뮤니케이션을 개선하기 위해서 진행했던 제품데모와 테마리뷰와 미팅을 진행했다. 각 팀들은 제품데모 미팅을 통해서 프로젝트의 청사진을 쉽게 확인할 수 있었고 최근 특정 기능에 변화를 주었을 때 그것을 쉽게 전달이 가능했다. 그리고 이 미팅은 최대한 간결하게 진행하고 끝내도록 노력했다. 각 팀들은 제품데모에서 합쳐진 하나의 제품을 보여주는 것이 아니라 각자 자신의 제품 그대로 보여주었다. 그렇기 때문에 각 팀이 발표한 내용은 대부분 기술적 이었다. 따라서 비즈니스적으로는 이해하기 어려운 부분이 있었다.

지금은 제품데모를 할 때 항상 사용자 중심으로 데모를 진행하고 있다. 이를 통해서 비즈니스 사람들에게뿐만 아니라 다른 팀들도 더 깊은 이해를 할 수 있었다.

테마리뷰 미팅의 경우도 처음부터 잘 진행되었던 것은 아니었다. 처음에 테마미팅에서 어떤 구현을 하기로 결정한 것이 있으면 그것들이 각 팀들 여러 이유들 때문에 결정을 수월하게 진행하지 못했다. 즉, 한 팀이 A라는 기능을 구현하기 위해서 다른 팀이 B를 구현해주어야 하고 그 B를 구현하기 위해서는 또 다른 팀이 무엇을 해주어야 하는 식의 의존성 때문이었다. 그래서 그들은 스크럼 마스터들과 함께 의존성 미팅을 매주마다 진행해야 했다. 이것은 팀끼리의 기술적 의존성만 논의하기 때문에 비즈니스 결정을 필요로 하지 않았다.

그들이 중앙 팀에 비즈니스 제품 책임자의 역할을 만든 다음부터 기존의 의존성 미팅 없이도 자연스럽게 진행할 수 있었는데 그 이유는 바로 테마라는 항목이 존재했기 때문이었다. 그 뒤에 의존성 미팅은 사라지고 테마미팅이 그 역할을 대신하게 되었다. 테마미팅 참여자는 각 팀의 제품 책임자, 비즈니스 제품 책임자, 스크럼 마스터, 테크니컬 리드 정도였다. 그리고 그 미팅에서는 다음과 같은 일들을 진행했다.


• 우선순위의 점검

• 특정 테마에 해당하는 각 팀들의 백로그 점검

• 테마 별 예상 개발기간

• 각 작업의 팀별 의존성

• 팀 단위에서 작성할 수 없었던 백로그 항목의 추가


이러한 방식의 접근을 진행한 뒤에 효율이 높아졌을 뿐만 아니라 각 팀 별로 전달해 주어야 할 기능을 정확하게 정의 할 수 있었다. 물론, 특정 작업들은 이 미팅 외에도 추가적인 미팅들이 요구되기도 했지만 대부분의 기능들은 이 미팅만으로 진행되었다.



정리


이 BBC의 사례를 살펴봤을 때 대규모 조직의 경우 올바른 비즈니스 방향과 더불어 각 개인 팀들 또한 같은 목표를 가지는 것이 어렵다는 사실을 알 수 있다. BBC에서는 다양한 팀들 사이에서 단 한 명의 혹은 두 명의 제품 책임자를 둠으로써 프로젝트를 정상적으로 진행할 수 없었고 이 문제를 단번에 알아채기도 어려웠다. 즉, 한 명의 제품 책임자를 두면서 그들은 결국 일관성 있는 방향을 제시하는 것이 어려웠고 빠트린 기능들도 많았던 것이다.

여기서 우리가 되짚어봐야 하는 이슈는 BBC에서 누구도 스크럼의 문제라고 보지 않고, 제품 책임자만의 문제로 접근하고 해결하려 했다는 것이다. 하지만 애자일 원칙을 볼 때 애자일 팀은 자기 주도적 팀이 되기를 요구한다. 만약 이 점을 토대로 접근했다면 보다 일찍 각 팀에 제품 책임자를 배치하지 않았을까 생각한다.

만약 대규모 조직에서 다양한 팀들이 함께 일을 진행해야 하는 경우라면 다음 BBC가 전하는 팁을 참고해 보도록 하자.


• 프로젝트 안에서 각 팀을 구성할 때 제품 책임자와 함께 할 수 있는 시간을 고려해야 한다. 

• 한 명의 제품 책임자에 의존하다 보면 결국 일 진행이 늦어지고 프로젝트의 올바른 방향을 설정하는 것이 어렵다.

• 제품 책임자들의 역량은 팀이 크거나 여러 팀의 목표를 동시에 고려하다 보면 줄어든다.

• 조직적이지 못한 팀이 하나의 프로젝트에서 같이 일하면 비즈니스 목표와 다른 제품이 만들어 질 수 있다.


대규모 스크럼 프로젝트를 성공시키기 위해서는 다음과 같은 요소들을 필요로 한다. 


• 스크럼의 스크럼

• 같은 공간에서 일하는 개발 팀들

• 팀 안에서 적절한 역할의 사람들 

• 권한이 있는 스크럼 마스터



BBC는 명확한 비즈니스 목표와 주관적인 역량이 잘 조화되었을 때, 프로젝트 내 여러 팀들이 효율적으로 일할 수 있다고 말한다. 스크럼은 BBC에게 간단하고 반복적으로 프로젝트 결과를 조금씩 완성시킬 수 있는 방법을 전달해 주었다. 하지만 성공적인 스크럼을 위해서 모든 구성원들의 역량과 업무처리 속도를 고려해야 하고 제품 책임자가 프로젝트를 완벽하게 지원할 수 있는지를 고려해야 한다. 

BBC에서처럼 80명의 구성원들이 일하는데 단 한 명의 제품 책임자를 두는 오류를 범하지 않도록 하자.




저작자 표시
신고
Posted by 박경훈
애자일 이야기2014.11.19 14:02

애자일 도입에 있어서 큰 기업일수록 그 결정이 더욱더 신중해질 수 밖에 없는 것이 사실이다. 무엇보다도 큰 변화에 따른 회사의 리스크가 가장 큰 부담이기 때문이다. 하지만 철저한 동기부여와 준비가 뒷받침 하며 그 리스크를 최소화하는 것이 가능하다. 애자일은 팀 멤버들의 동기부여와 더불어 모두 애자일에 익숙하지 않으면 큰 성과를 당장 기대하는 것에는 한계가 있다. 만약 모든 팀이 애자일을 도입하면서 여러 팀들의 노하우를 서로 배울 수 있다면 어떠할까? 이번 사례에서는 대규모의 집단이었지만 애자일을 모든 팀이 한번에 도입하면서 변화를 시도한 사례를 살펴볼 것이다. 바로 세일즈포스라는 기업이다.




 

세일즈포스는 CRM(고객 관리 솔루션)을 클라우드 컴퓨팅 서비스 형태로 제공하는 기업이다. 비즈니스 응용프로그램 및 응용프로그램 플랫폼을 인터넷으로 제공하고 있다. 이 회사는 1999년 3월에 마크 베니오프가 설립하였고 현재 만명 이상의 직원들이 일하고 있다. 국내에서도 세일즈포스 제품은 큰 인기를 얻고 있으며 전세계적으로 굉장히 많은 고객을 두고 있다.

세일즈포스는 3개월에 거쳐서 약 200명 규모의 팀들에 애자일 방식을 도입하는데 성공했다. 이 사례는 애자일 도입에 있어서 가장 크고, 빠르게 도입된 사례들 중 하나로 손꼽힌다. 세일즈포스의 애자일 도입 사례가 처음 알려진 것은 2007년도에 프라이 그린(Fry Greene)이 애자일 커뮤니티에 자신의 회사에 대한 사례를 공유하면서 빠르게 퍼져나갔다. 만약 애자일 도입을 고려하고 있는데 어떻게 도입을 해야 할지 고민하고 있는 조직이라면 굉장히 좋은 참조 모델이 될 수 있을 것이다. 특히나, 대규모 조직을 교육하고 혁신을 이루기 위해 어떻게 준비하여 실행에 옮겼는지를 확인해 볼 수 있을 것이다. 뿐만 아니라 그들이 애자일 프로세스를 선택하게 된 이유와 어떻게 도입에 성공할 수 있었는지, 또 도입 후에 어떻게 확장해 나갔는지에 대해서 배울만한 내용을 공유해보도록 하겠다. 

먼저 세일즈포스는 3개월이라는 짧은 기간 안에 30개의 팀들을 워터폴(Waterfall) 개발 방법론에서 애자일 방법론으로의 변화시키려고 했다. 무엇보다도 그들이 처음에 집중했던 것은 확실한 개발주기와 투명성 그리고 스스로 일을 진행할 수 있는 팀을 만드는 것이었다. 세일즈포스는 애자일을 도입하면서 6개월 동안 자체적인 기존 개발 프로세스를 벤치마크 했었고 두 개의 메인 릴리즈를 완성했으며 또, 매달 코드의 배포가 가능하게 진행했다. 

그들은 애자일을 도입하기 전에 애자일의 원칙들을 먼저 리뷰했다. 애자일의 원칙 중에 보면 팀이 어떤 사람의 압력과 요구로 이루어지는 것이 아닌 팀은 스스로 움직여야 한다는 요구사항이 있었는데 그들은 신중한 결정을 내리기 위해서 스태프들을 대상으로 설문 조사를 했다고 한다. 그 설문조사의 결과 87% 가량의 개발 구성원들이 스크럼 팀이 스스로 알아서 움직일 수 있는 팀이라고 믿고 있었고, 80% 정도의 기술 스태프들이 새로운 개발 방법론이 자신들의 팀을 보다 효율적으로 만들 수 있다고 답했다. 

그들은 지금도 지속적으로 개발 조직을 개선하기 위해서 노력하고 있을 뿐만 아니라 명확한 데이터와 자료를 기반으로 올바른 결정들을 내리고 있다. 여담이지만 많은 기업들이 자료조사는 진행하지만 확실히 내려야 하는 결정 앞에서는 확신이 없어서 망설이는 경우가 많이 있다. 하지만 세일즈 포스는 충분한 자료조사를 기반으로 과감한 결정을 실행해 옮길 수 있는 점을 보여주고 있다. 그럼 세일즈포스가 애자일을 도입하게 된 배경부터 살펴보도록 하자.


도입 배경

세일즈포스는 고객의 필요에 따라서 서비스를 확장하는 온디맨드 서비스에 있어서 시장 선도와 기술 리더로 발돋움 하였고 지금도 계속해서 정상의 자리를 지키고 있다. 세일즈포스에서는 매일 같이 8천5백만 결제가 이루어지고 있고, 약 65만명의 구독자들을 가지고 있다. 즉, Salesforce.com이라는 웹사이트는 CRM 솔루션을 제공하는데 사용자의 요구에 맞추어 개발된 플랫폼이다. 국내에서도 CRM 솔루션으로 많이 활용되고 있다. 아무튼 세일즈포스의 서비스 기술 조직은 Salesforce.com 이라는 서비스를 운영하고 개발하고 있다. 더 놀라운 것은 회사가 처음 설립되고 약 8년 동안 매년 50%씩 꾸준한 성장을 가지고 있는 부분이 고무적이다. 

그들은 매년 평균 4개 정도의 주요 업데이트를 진행하고 있다고 발표했었지만 그들이 애자일을 도입하기 전에는 일년에 한 개의 주요 업데이트만 진행이 가능했다고 밝히고 있다. 그렇다면 애자일을 도입하기 전에 어떤 문제들이 있었을까? 그들은 다음과 같은 다섯 가지의 문제를 가지고 있었다고 이야기 했다. 


- 정확하지 않은 전체 개발기간 

(일찍 산정하고 평가하는 것은 결국 각 기능별 정학한 완성일자와 완전한 테스팅 스케줄을 제공할 수 없었다.)

- 실제 릴리즈의 모든 단계별로 눈에 보여지는 결과물의 부재

- 거의 릴리즈 끝에 이루어지는 기능들의 늦은 피드백

- 길고 예측이 어려운 릴리즈 스케줄

- 팀이 확장될수록 줄어드는 생산성


R&D 그룹에서는 애자일을 도입하기 전에는 워터폴(Waterfall) 개발방법론 기반으로 프로젝트를 진행했다. 즉, 기획이 끝난 다음에 디자인을 하고 그 다음에 개발이 길게 늘여져서 마치 폭포수 같이 쏟아지는 것 같은 차트를 만들어내기 때문에 워터폴 개발 방법론이라고 이야기 한다. R&D 그룹은 모두 기능별 팀으로 조직화 되어 있었다. 예를 들면, 사용자경험팀, 제품개발팀, 제품 관리팀, QA팀 그리고 문서화팀 등과 같이 기능에 따라 팀이 구성되었다는 것이다. 비록 그 팀들은 프로젝트에 따라서 팀의 구조가 조금 유연하게 바뀔 수 있었다고는 하지만 결국, 전체적으로 기능별로 진행되는 워터폴 개발방법론 방식을 따르고 있었다. 

세일즈포스의 워터폴 방법론을 예를 들면 이런 것이다. 제품관리팀은 제품 각각의 기능들만 정의했다. 사용자경험 팀의 경우 각 기능의 프로토타입과 인터페이스들만 생산했고, 개발자들은 그저 기술명세서와 코드들만 작성했다. QA팀은 각각의 기능을 테스트하고 검증하는 역할을 진행했고, 문서화팀은 각 기능을 문서화 했다. 

그들의 이런 워터폴 개발방법론 기반 프로세스는 팀이 작았던 초창기에는 굉장히 성공적이었지만 회사가 갑자기 커지면서 대규모 조직을 이런 방식으로 관리하는 것이 쉽지만은 않았다. 비록 개별적인 기능과 패치는 성공적으로 배포할 수는 있었지만 메인 업데이트의 경우에는 짧게는 3개월에서 길게는 12개월까지 굉장히 길었다. 회사가 빠르게 성장하고 또 릴리즈 기간이 늘어났기 때문에 R&D의 많은 사람들이 주요 제품의 릴리즈에 참여하지 않았다. 그 결과 조직은 학습기회를 잃어 버렸을 뿐만 아니라 실제 시장에 고품질 제품을 전달하는데 있어서 사기를 저하시키는 영향을 주었다.


애자일 도입 방법


이런 악순환이 계속되면서 세일즈포스의 기술 책임자는 결단을 내려야만 했다. 결국, 세일즈포스의 초기 창업자이자 R&D의 기술 연구센터장은 조직변화 프로그램을 발표했다. 그는 먼저 앞에서 설명한 기능별로 이루어진 팀들이 가진 느린 업무속도와 낮은 예측력 그리고 제품의 안정성과 같은 문제를 지적했다. 그리고 이 기능별로 이루어진 팀들을 바닥에서부터 다시 재구성하고 개발 프로세스를 다시 만들기로 한 것이다. 

이 리빌딩에서 가치 있는 개발 원칙들을 찾을 수 있었는데 KISS(Keep it Simple Stupid) 즉, 간단한 것이 제일 좋다라는 개념과 빠른 반복주기 그리고 고객들의 의견에 귀 기울이는 것들이었다. 이렇게 발견한 새로운 개념들이 바로 애자일 개발 방법론과 거의 매치가 되었던 것이다. 그리고 이러한 변화를 도울 수 있는 중요한 세 부분의 영역이 존재하고 있었다. 첫 번째는 바로 온 디맨드 소프트웨어 모델자체가 애자일 방법론에 잘 맞았고 두 번째는 잘 개발된 자동화 된 테스트 시스템이 새로운 개발 방법론에 잘 맞게 틀이 잡혀있었다는 것이다. 마지막으로 R&D 그룹의 중요성에 대해서 이미 인지가 되고 있었다는 것이다.

이 변화에 있어서 가장 중요한 부분은 어떻게 소프트웨어를 개발할지에 대한 계획이 아니라 이러한 개념들을 어떻게 기술 조직들에게 전달하느냐는 것이었다. 한명의 팀 구성원이 새로운 개발 프로세스를 설명하는 문서를 작성했는데 여기서 이 프로세스의 장점들과 왜 우리가 이 오래된 개발 프로세스에서 변화가 필요한지에 대한 이유를 기술하게 했다. 더불어 각 조직 별로 모든 레벨의 핵심 구성원들과 한 시간 정도의 미팅을 45번이나 가졌고, 이런 미팅에서 나왔던 피드백들을 모두 문서에 기록했을 뿐만 아니라 새로운 프로세스의 디자인의 모형들과 조직 별로 다르게 적용해야 되는 변화들도 기록했다. 이렇게 오픈 된 커뮤니케이션들의 피드백들의 반복들을 통해서 모두가 새로운 개발 프로세스를 정립하는데 목소리를 내게 하는데 결정적인 역할을 했다고 이야기 한다. 초기 문서에 포함되었던 두 가지 중요한 포인트는 먼저 사용 가능한 프로세스들의 디자인을 통합하기 위한 계획이었고 두 번째는 각각의 주요 릴리즈 별로 우리가 얼마만큼의 시간을 필요로 했는지에 대한 내용을 담았다.

이 문서를 정리하면서 두 가지 도입방법을 고려했다. 첫 번째는 시범적으로 도입해서 점진적으로 천천히 결과를 내보자는 것이고 또 다른 것은 한꺼번에 모든 팀들에게 적용해서 바꾸자는 것이었다.  이 큰 변화를 도입하는데 있어서 가장 중요한 요소는 바로 조직간의 불협화음을 피하는 것이고 이러한 변화에 대한 갈망이 팀에 있냐는 것이었는데 다행히도 대부분의 팀 원들이 같은 시간에 같이 도입하고 싶어 했다. 

그래도 논쟁이 없었던 것은 아니었다. 주된 논쟁은 만약 모든 팀들이 한꺼번에 새로운 프로세스를 도입할 경우에 몇 개의 팀들이 시범적으로 도입하는 것에 비해서 같은 실수들을 하게 될 경우가 많다는 것이고 매일 모든 팀들을 지원할 코치 인력들이 부족하다는 것이다. 하지만 여기에 희망스러웠던 것은 한 팀이 스크럼(Scrum)을 이용한 결과 위주의 프로젝트를 이미 성공한 경험이 있었다는 것이다. 즉, 세일즈포스는 이 부분의 경험을 높게 사서 전체 팀이 이동하는 대규모의 변화를 적용하기로 결정을 내릴 수 있었다.

그들은 먼저 기능 관리자나 프로그램 매니저와 같은 굉장히 많은 그룹의 사람들을 교육시켰다. 먼저 스크럼마스터 자격증을 취득할 수 있게 교육을 지원했고, 굉장히 많은 애자일 도서들을 구입하여 오피스에 배치시켰다. 스크럼 마스터 자격증의 경우에 아직 한국에서는 기관이 없지만 실제로 현지에서는 2일 동안의 스크럼 교육을 진행하고 시험을 보게 한다. 그리고 결과에 따라서 스크럼 마스터(Scrum Master)나 스크럼 개발자(Scrum Developer)와 같은 자격증을 수여한다. 필자가 있는 영국에서도 이 자격 기관이 존재한다. 약 200만원의 교육비를 내서 이틀 정도의 교육을 수료하면 자격증 시험에 응시할 수 있는 자격을 부여한다. 

아무튼 세일즈포스에서는 세 명의 주요 구성원이 있었는데 이 구성원들이 통합된 교육자료를 만들었고 사내 스태프들을 위한 교육을 진행했다. 교육 내용은 스크럼과 XP(eXtreme Programming) 그리고 린(Lean) 방법론들이 있었다. 그들은 각 팀마다 2시간 정도의 애자일 교육을 진행했다. 추가로 스크럼 제품 책임자(Product Owner) 교육을 제공했고, 또한 현장에서 업무량을 산정 (Estimation)하는 방법과 계획하는 방법에 대한 교육도 제공했다. 여기서 산정이라는 것은 기존에 정해진 업무의 복잡도를 평가하면서 한 단위의 사용자 스토리가 얼마만큼 걸리게 될지를 산정하게 되는데 이 미팅으로 팀원 모두가 참여해서 각 업무별로 복잡도와 걸릴 시간들을 측정하는 것을 이야기 한다. 그들은 또한 내부적으로 위키 기반의 웹사이트를 만들어서 애자일을 도입하는데 필요한 모든 지식들을 공유했고 새로운 개발방법론에 대한 중요한 추가적인 자료들을 공유했다.

애자일 도입 팀은 스크럼을 사용해서 하루 단위의 결과를 만들어 공유하는데 초점을 맞추었다. 그리고 모두가 보고 공유할 수 있는 제품의 전체 스케줄을 만들었고 전체 조직들에 거쳐서 애자일의 비전을 전달하고 성공도를 모니터 했다. 그리고 애자일을 도입하는데 있어서 시스템적인 장애들을 제공하려고 노력했고, 전문적 자료들을 전달함과 동시에 가이드와 교육을 진행했다.

그들이 공개한 몇몇의 성공 요인들을 정리해 보자면 다음과 같다.


- 개인의 생산성 보다는 팀의 처리량에 초점을 맞추는 것

- 각 기술 별로 나뉘어진 팀들은 매일 만나서 진행하는 미팅

- 공통으로 사용하는 언어의 정의와 간단한 애자일 프로세스

- 모든 팀 별로 일들의 명확한 우선 순위 리스트

- 사용자 스토리와 새로운 업무 측정방법의 정의

- 빌드 속도와 유연성에 초점이 맞추어진 자동화 팀

- 제품과 릴리즈의 완성도를 하루 단위로 확인할 수 있는 도표

- 스크럼을 이용한 제품 라인과 주별로 모든 팀이 볼 수 있는 어떤 결과물

- 넓은 분야의 스프린트 리뷰와 매달 진행하는 회고

- 제품 책임자(Product Owner)와 스크럼 마스터(ScrumMaster)들의 주기적 미팅

- 큰 릴리즈를 앞두고 정확한 시간 단위로 정확하게 만들어지는 작은 릴리즈

- 약 1500개 이상의 버그의 감소

- 매달 진행되는 잠재적인 제품들의 릴리즈



물론, 지금도 세일즈포스 조직은 계속해서 애자일을 연구하고 있다고 밝혔다. 


세일즈포스만의 성공전략


세일즈포스와 같은 대규모의 조직이 어떻게 애자일을 자연스럽게 도입하고 또 성공할 수 있었을까? 무엇보다도 먼저 높은 직위의 사람들의 적극적인 지원이 있었다는 것이고, 이런 변화를 주도하는 팀을 만든 것을 가장 큰 이유로 꼽고 있다. 그리고 무엇보다도 단순한 기법을 넘어 기본 원칙에 집중했고, 일찍이 자동화와 지속적인 통합(Continuous Integration)에 집중했다는 것이다. 그리고 애자일을 도입하는데 있어서 필요한 의사 결정을 철저히 투명하게 진행하였고, 외부의 애자일 트레이닝과 교육을 적재적소에 잘 이용했기 때문이라고 밝히고 있다.

먼저 높은 사람들의 변화에 대한 지원에 대한 부분을 살펴보자. 이것은 큰 조직이 변화를 타개해나가는데 있어서 가장 필수적인 조건이기도 하다. 만약 임원 레벨에서의 변화에 대한 지원이 없었다면 아마 애자일 프로세스는 실패하고 말았을 것이다. 예를 들어, 세일즈포스의 임원들은 각 릴리즈의 내용에 상관없이 굉장히 터프한 일정을 꽂아 넣었다. 비록 많은 팀들이 개발 주기에 대해서 불평을 했지만 관리팀들은 그 릴리즈 날짜를 지키고 새로운 개발 방법론으로 옮겨 갈 수 있게 독려해 주었다는 것이다. 때문에 애자일의 원칙 때도 완벽하지는 않더라도 일찍 결과물을 전달할 수 있었고, 필요 없는 것을 만드는 것을 어느 정도 막을 수 있었다.

두 번째 성공 요소에서는 실행 팀의 헌신이 존재했다는 것이다. 즉, 이 실행 팀들은 모든 조직들을 통합할 수 있는 권한이 주어졌다. 이 팀의 구성원들은 각 영역별로 다양한 사람들이 추천되어 구성되었다. 예를 들어 QA팀, 개발조직, 개발 관리팀, 제품 관리팀, UX 팀 그리고 임원의 구성원들로 구성되었다. 이 팀은 무엇보다도 어떤 결정을 만들고 새로운 방법론을 적용할 수 있는 권한이 주어졌고 공공장소에서 미팅을 실행하였다. 이 팀은 항상 투명하게 미팅 내용들을 투명하게 공유했고 누구나 쉽게 의견을 전할 수 있게 오픈 했다. 뿐만 아니라 이들은 업계의 전문가들과 연결되었고, 비슷한 기술 회사들의 전문가들과 의견을 주고 받을 수 있었다.

세 번째는 단순한 기술을 넘어 원칙에 집중하는 것이다. 어떤 기업이 애자일을 맹목적으로 도입해서는 성공하기 힘들다. 그것보다 왜 그 기업이 애자일 프로세스를 진행해야 되는지에 대한 이유를 이해하는 것이 가장 중요한 일이다. 즉, 기존의 문제를 해결하기 위한 어떤 해결방안으로 접근하기 어려워질 경우에 그 팀들은 애자일이 전혀 도움이 되지 않는다고 불평의 목소리를 낼 수도 있고 또 이전 패턴과 비교하면서 새로운 패턴을 거부하게 될 것이다. 하지만 세일즈포스의 실행 팀들은 애자일의 기본 원칙들 즉, 커뮤니케이션, 지속적인 통합 또 고객들에게 빠른 전달과 피드백과 같은 원칙들을 제공하려고 노력한 것이다. 그래서 세일즈포스의 애자일 실행 팀은 각각의 기술 팀들에게 애자일의 목표들과 원칙들의 인쇄물들을 만들어서 공유했다.

네 번째는 자동화이다. 대규모의 자동화 도구와 빌드 시스템은 일찍이 존재했었고 변화에 큰 도움이 되었다. 이것이 큰 도움이 될 수 있었던 이유는 그들은 CI(Continuous Integration) 시스템, 즉, 지속적인 통합이라는 툴을 가지고 있었고 개발 조직 전체적으로 기능과 단위별 테스트를 자동으로 할 수 있다는 것이었다. 그들은 기존에 가지고 있는 시스템을 다시 만들기 보다는 개선하면서 지원하려고 노력했다. 그 결과 모두 보다 철저한 코드 라인을 생성하는데 집중할 수 있었고 실제 통합 테스팅 시간을 줄일 수 있었으며 코드를 하나로 통합 시킬 수 있었다고 밝혔다. 그들은 상당한 효율을 개선하기 위해서 자동화된 빌드시스템을 이용하기 보다는 자주 체크인 하고 자주 테스트 할 수 있게 제공할 수 있는 시스템이 필요했었다. 이러한 짧은 프로세스들은 짧은 개발과 짧은 테스트 주기를 가능하게 해주었기 때문이다.

다음은 철저한 투명도이다. 그들이 애자일을 도입하는 동안에 모든 것을 투명하게 한 것이 그들의 성공의 키였다. 무엇보다도 그들은 매일 공공 장소에서 미팅을 진행하였고, 모든 사람들이 진행과정을 지켜 볼 수 있었다. 그리고 그들의 카페 같은 곳에 업무보드를 비주얼적으로 볼 수 있게 제공하였기에 누구나 그 정보들을 쉽게 볼 수 있었다. 그들은 항상 모두의 계획과 정보 그리고 비전들을 과할 정도로 나누었다. 그들은 일자별 진행도를 만들어서 R&D 전체 팀이 실제 릴리즈를 위한 진행과정(실행 결과, 테스트 결과, 버그 수, 개발활동)을 체크할 수 있게 하였다. 이렇게 일자 별로 제공되는 오픈 된 정보들은 모두에게 그들의 능력과 모든 팀들의 역량을 확인할 수 있는 중요한 정보였다. 

마지막으로 애자일 교육에 대한 부분이다. 애자일 도입에 큰 기여를 한 부분이 바로 R&D의 약 25%나 되는 인원을 애자일 교육에 투자했다는 것이다. 전문가 교육을 지원했을 뿐만 아니라 팀 내부의 스크럼 마스터와 제품 책임자 들을 지원할 외부의 컨설턴트들을 고용했다는 것이다. 아마 국내에서는 교육비용 때문에 선뜻 이 변화를 받아드리기 어려웠을 수도 있다. 하지만 이런 교육들을 통하여 애자일 원칙들을 잘 자리잡는데 큰 역할을 하였고 모든 팀들을 지원하면서 확장해 나가는데 큰 일조를 했다. 외부 교육뿐만 아니라 조직내의 모든 구성원들에게 애자일 성공 스토리와 다른 회사들이 진행했던 노하우 들을 전했다. 이러한 활동들을 통해서 몇몇 팀들은 스스로 2주 기반의 주기를 만들고 보다 비주얼 적인 결과물을 전달하는데 초점을 맞추었다. 즉 애자일이 단, 소수의 리더만으로 성공하기 어렵다는 것을 잘 보여주고 있는 것이다.



일찍 알았으면 좋았던 것들

비록 세일스포스가 애자일을 도입하면서 초기에 목표했던 보다 주기적인 릴리즈, 스스로 일하게 되는 팀들, 자동화, 눈에 보이는 결과물과 같은 것들을 달성했다고 하더라도 그들 스스로 일찍 시도했으면 더 큰 도움이 되었을 것이라고 밝힌 것들이 있다. 즉, 진행하고 나니 왜 그때 몰랐을까 했던 것들이다. 다음 여섯 가지를 살펴보자.


1. 일찍 애자일 도입 피드백에 귀 기울이는 것

2. 제품 책임자를 일찍 교육 시키는 것

3. 외부의 코치들을 일찍 섭외하는 것

4. 자동화 부분을 보다 일찍 시작하는 것

5. 경영진들에게 애자일 도입에 대한 구체적인 업무들을 요청하는 것

6. 조금 더 클리어하게 애자일의 역할이 무엇인지를 전달하는 것


세일즈포스는 초기에 애자일 도입에 필요한 주요 스태프들로부터 피드백을 많이 받지 못했다고 이야기 한다. 모든 구성원들을 참여시킬 수 있는 하나의 좋은 방법은 열린 공간에서 미팅을 진행하는 것이다. 여러 방법들 중에 하나를 소개하자면 먼저 모두에게 쪽지나 포스트잇을 나누어주고 하나의 토픽 안에서 자기가 생각하는 세가지 문제들을 적게 하는 것이다. 그 문제들의 테마 별로 그룹을 만들게 하고 거기서 제시한 해결 내용들을 애자일 진행 팀에서 수집하여 반영하는 방법이다. 세일즈포스는 이러한 처리 과정들을 애자일 도입 뒤에 시작했지만 일찍 도입할 수 있으면 충분히 좋았을 것이다.

두 번째는 제품 책임자들을 조금 더 일찍 교육을 시켰으면 어땠을까 라는 것이다. 보통 애자일의 도입에 있어서 가장 중요한 성공의 열쇠는 바로 제품 책임자에게 달려있다고 많이 이야기 한다. 하지만 세일즈포스도 이 말의 진정한 뜻을 처음에는 이해하지 못했다고 했다. 즉, 제품 책임자는 모든 계획에 우선순위를 부여해야 하고 릴리즈를 어떻게 가져갈지를 결정해야 한다. 뿐만 아니라 그렇게 계획한 스케줄에서 매일 팀들과 커뮤니케이션 해야 하면서 기능들을 점검해야 하는 것이다. 또한, 모든 애자일의 시작은 제품 책임자로부터 시작된다. 예를 들어, 제품 책임자는 제품 백로그(유저스토리들과 처리해야 할 일들의 리스트)를 만들어야 하고 사용자 스토리를 디자인 하고 또 복잡도를 평가하고 계획해야 하는데 이 모든 것이 제품 책임자에게 있다는 것이다. 제품 책임자의 초기 교육을 넘어서 새로운 프로세스와 문화를 도입하기 위해서 지속적으로 제품 교육자를 애자일 도입에서 교육을 진행하는 것이 필수적이다.

세 번째는 일찍이 외부의 컨설팅 인력을 섭외하는 것이다. 몇몇의 외부 전문가들은 그들을 더 빠르게 갈 수 있는 방법들을 인지할 수 있었다. 그들은 또한 이미 다른 회사에서 애자일을 시도하면서 쉽게 실수하는 부분들을 알고 있었기에 그런 것들을 쉽게 고쳐줄 수 있었다. 무엇보다도 내부적으로도 외부의 조언과 의견들을 더 쉽게 귀담아 들으려고 하기도 했다. 

네 번째는 자동 빌드와 테스트 시스템을 일찍 셋업하는 것이다. 자동화가 애자일 기법에 있어서 가장 핵심적인 부분이 자동화 부분이고 전체 조직들에게 눈으로 확인할 수 있는 제품을 자동화를 통해서 전달하는 것이다. Salesforce.com은 JUnit 기반의 기능에 많은 투자를 가졌고 또한 통합에 실패한 리스트를 유닛 테스트들 기반으로 가져갈 수 있었다.

다섯 번째는 회사 임원들에게 애자일 도입에 대한 구체적인 업무들을 요청하는 것이다. 세일즈포스 임원들은 성공의 주요 요소였다. 임원들에게 애자일 도입에 필요한 작은 혹은 큰 업무들을 전달하는 것을 통하여 조직적인 변화를 가속화 시킬 수 있었다.

마지막은 애자일의 역할을 모다 명백하게 정의하는 것이다. 팀들을 스스로 일할 수 있도록 하는 것은 굉장히 중요한 부분이고 실제로 팀 구성원들에게도 열정을 전달할 수 있는 방법이기도 하다. 세일즈포스 또한 스스로 일하는 문화의 정립을 인식하고 있었다. 때문에 어떤 일을 할당하고 그 것을 끝내고 보고하고 또 할당하는 작업을 진행하려 하지 않았다. 이미 완료한 일을 확실히 정의하고 팀들의 이해범위 안에서 이미 처리된 것과 처리되지 않은 것을 스스로 결정하게 했다. 즉, 이런 작업을 통해서 그 팀은 어떻게 그리고 보다 유연하게 스프린트 목표들을 수행할 수 있을지를 이해하는데 큰 도움을 주게 되는 것이다. 또한 다른 중요한 점은 주요 임원들과 각 기능별 매니저들이 스프린트 경계 안이 아닌 밖의 경계에서 수정사항들을 제시해야 된다는 것이다.


세일즈포스를 통해서 얻을 수 있는 교훈들

세일즈포스의 애자일 사례를 통해서 우리는 많은 교훈들을 얻을 수 있다. 무엇보다도 새로운 팀으로 애자일의 도입을 고려하고 있다면 다음의 교훈들을 참고하도록 하자.

- 애자일을 도입을 진행할 헌신적이고 모든 권한을 가지고 있는 팀을 만드는 것

- 전문가의 도움을 얻는 것

- P2P처럼 개개인이 서로 코치할 수 있게 하는 것

- 여러 개의 팀을 뛰어나게 만드는 것

- 회사 레벨의 스프린트를 만드는 것

- 일찍 필요한 도구를 만드는 것

- 진행사항을 눈에 볼 수 있게 하는 것과 최대한 많은 커뮤니케이션을 만드는 것

- 실수를 인정하고 그것에 관대해지는 것


자, 그럼 하나의 요소 별로 살펴보도록 하자. 


애자일을 도입을 진행할 헌신적이고 모든 권한을 가지고 있는 팀을 만드는 것


이 팀은 중앙에서 변화를 관리하는 조직으로 그 조직 내에서 모든 조직들과 커뮤니케이션이 가능해야 하고, 만약 어떤 조직에서 문제가 생겼거나 했을 때 쉽게 접근이 가능해야 한다. 더 중요한 것은 변화들에 대해서 충분히 커뮤니케이션을 해야 한다는 것이다. 

회사 전체가 한번에 모두 변화를 진행한다고 두려워할 필요는 없다. 많은 사람들이 먼저 한 팀에서 시범 운영을 진행하고 그 다음에 천천히 다른 팀들에게 전달해 나가도 된다고 말할 것이 분명하다. 하지만 회사 전체가 모두 한번에 변화를 진행하는 것도 가능하고 이 방법이 더 큰 이익들을 가지고 온다. 먼저 한 팀만 진행할 경우에 이미 다른 조직들과의 커뮤니케이션이 필요한 경우에 커뮤니케이션을 원활하게 해주는 애자일 효과를 누리기 힘들다는 문제가 있다. 하지만 회사 전체적으로 애자일을 도입할 경우에 전체 조직이 같이 참여하여 원활한 커뮤니케이션과 각 조직 별 도움들을 제공할 수 있다.


전문가의 도움을 얻는 것


외부 전문가들은 이미 우리가 경험할 장애물들을 전에 경험했을 뿐만 아니라 다른 회사들로부터 비슷한 사례의 경험을 가지고 있기 때문에 충분히 도움이 될 수 있다. 그들은 지금 회사에서 사용자 스토리들이나 업무산정과 계획 등과 같은 새로운 영역의 프로세스를 도입할 때 도움을 줄 수 있다.


P2P처럼 개개인이 서로 코치할 수 있게 하는 것


먼저 각자 팀에서 이미 일찍 애자일 방법론을 경험했거나 다른 조직과 팀에서 성공을 경험한 구성원들을 찾을 수 있을 것이다. 이러한 구성원들은 개인적인 경험들을 나눌 수 있고 또한 우리가 보지 못한 실수들을 보는 것이 가능할 것이다. 


여러 개의 팀을 뛰어나게 만드는 것


때로는 우리의 시선이 고군분투하는 팀들에 초점이 맞추어지는 경우가 많이 있다. 하지만 그 초점을 성공적인 여러 팀들에게 맞추어지다 보면 탄력을 만들 수 있고 새로운 프로세스들을 잘 정착한 팀들의 본보기를 찾아낼 수 있을 것이다. 때문에 주변에 성공한 팀들이 생겨나다 보면 많은 팀들이 조언을 얻어서 잘못된 부분들이 자연스럽게 개선되는 것을 볼 수 있다.


회사 레벨의 스프린트를 만드는 것


세일즈포스는 한 달에 한번 스프린트 주기를 만들었고 모든 팀들이 같으 주기를 가지고 있었다. 이것은 세일즈포스의 스프린트 리뷰들이 한달 이라는 경계 안에서 같이 진행될 수 있게 해주었고 임원들과 팀들이 모두 어떤 것들을 진행했는지 발표하는 것을 가능하게 해주었다. 또한 모든 제품 라인이 매 달 탄력을 받을 수 있었다. 많은 팀들이 2주라는 내부 스프린터 주기를 가지고 있었기 때문에 4주 단위로 진행하는 회사단위의 리뷰를 진행하는 것이 가능했다.


일찍 필요한 도구를 만드는 것


세일즈포스는 개발을 관리할 수 있는 애자일 툴을 직접 만들었다. 엑셀과 같은 시트는 쉽게 관리가 어려워지기 때문에 그들이 직접 만든 제품을 이용하는 것이 많은 이익을 가지고 왔다. 



[그림1] 세일즈포스의 애자일 툴 (스크럼포스)


[그림1]은 세일즈포스가 처음 애자일을 도입할 때 자체적으로 만든 스크럼포스라는 툴이고 모든 팀 구성원들과 스크럼마스터 그리고 제품 책임자가 업무들을 관리할 때 사용한다. 기능 매니저들은 여기서 제공하는 레포트 기능을 이용해서 팀을 관리하고 또 릴리즈를 관리했다.

이 툴은 Salesforce.com 에서 제공하고 있는 플랫폼이기 때문에 모든 개발자가 매일 그들의 제품을 이용하는 이유를 주기도 할 것이다. 세일즈포스의 툴은 사용자 스토리의 우선순위를 드래그&드랍 하면서 수정할 수 있는 기능을 제공하고 있고, 업무를 관리하고 업무진행 과정을 볼 수 있는 차트도 지원하고 있다. 물론, 이 툴 외에도 굉장히 많은 애자일 프로젝트 관리 툴들이 있기 때문에 조사해보면 대등한 툴들을 쉽게 찾을 수 있을 것이다.


진행사항을 눈에 볼 수 있게 하는 것과 최대한 많은 커뮤니케이션을 만드는 것

진행사항을 눈으로 직접 볼 수 있게 하는 것은 구성원들이 가지고 있는 특정 정보를 넓게 공유하는 것에 대한 두려움을 극복하는데 도움을 준다. 변화라는 것 자체가 굉장히 어려운 부분이 있고, 또 모든 사람들이 이메일을 읽지 않는 부분이 있다. 그래서 커뮤니케이션에 대한 여러 채널을 가지는 것과 같은 메시지들을 그 채널들을 통해서 반복적으로 전달하는 것이 굉장히 도움이 되었다. 즉, 만약 자신의 팀들이 새로운 방법론과 진행 프로세스에 대해서 잘 이해하고 있는 만큼 더 자주 커뮤니케이션을 진행할 필요가 있다. 


실수를 인정하고 그것에 관대해지는 것

애자일을 도입할 때 실험적인 문화 안에서 서로를 격려하는 것이 중요하다. 대부분의 사람들이 조직을 딱 맞는 애자일 방법론을 도입하는 것이 힘들 수 있기에 실수는 어떻게 보면 당연히 수반되는 결과일 수 있다. 팀 안에서의 사람들에게 보상을 하되 실수에 대한 어떤 불이익을 가지게 하는 것은 옳지 않다. 


정리

지금까지 세일즈포스라는 큰 연구 조직을 기존 워터폴 개발방법론 방식에서 애자일을 도입하여 전환하기까지의 노하우들을 담아보았다. 세일즈포스가 이야기 하고자 했던 가장 중요한 포인트는 바로 애자일을 도입하고자 한다면 몇몇 팀이 아닌 모든 팀들이 한꺼번에 애자일을 실행한다면 큰 시너지를 얻을 수 있다는 것이다.


참고주소

Agile Methodology at Salesforce, an Inside Look

http://sforce.co/1tq6k1X

Salesforce.com Agile Transformation - Agile 2007 Conference

http://slidesha.re/1s2zxPU



저작자 표시
신고
Posted by 박경훈