1.  글을 시작하며

개발자가 가장 행복할 때는 개발에 집중할 수 있을 때입니다. 화창한 아침 기분 좋게 출근해서 어제 작업하던 화면을 하나씩 불러옵니다. 모니터에 코드가 적인 편집툴이 하나씩 올라오고 머리속에도 해당 기능개발을 위한 자료구조와 알고리즘이 로드 됩니다. 이 데이터는 이쪽으로 보내고 이 부분은 이렇게 로직을 짜봐야지. 집중해서 코드를 짜고 있으면 어느새 모니터 외에는 아무것도 보이지 않습니다. 누군가 어깨를 톡톡 노크합니다. “점심 먹으러 가요” 많은 개발자가 이러한 순간을 행복해 합니다. 집중해서 일할 때의 엔돌핀은 초콜릿 다섯개를 한꺼번에 입에 넣을 때 보다 더 샘솟습니다. 상황을 좀 바꾸어 볼까요. 집중해서 코드를 짜려는 그때, 누군가가 어깨를 톡톡 노크합니다. ‘회의합시다’. ‘요구사항 명세서는 다 작성하셨나요?’. ‘새로 개발해야 하는 기능이 있는데 언제까지 가능한가요? 사실, 다음주까지 완료해야 합니다만'. ‘저번에 말한 그 기능에서 이것 좀 추가해줄 수 있어요?’. ‘아아…’ 어깨를 톡톡 노크한 그분의 심정을 이해 못 하는 것은 아닙니다. 상황이 어쩔 수 없다는 것도 이해 못 하는 것은 아닙니다. 소프트웨어가 가진 본래적 특성에 따라 그 복잡성을 다루는 것이 쉽지가 않기에, 개발자가 행복하게 개발할 수 있는 상황을 만들기가 쉽지는 않습니다. 하지만, 계속해서 이렇게 힘들게 살아야 하나요? 아마도 아닐 것 같습니다. 그동안 많은 분들이 같은 문제를 겪어왔고 상황을 타개하고자 노력해왔습니다. 많은 개발 방법론과 도구가 등장하였고 개발 패러다임 또한 끊임없이 진화해 왔습니다. 자, 그렇다면 우리도 우리 선조들이 고생해서 일구어 놓은 유산을 통해서 좀 더 나은 환경을 만들 수 있겠죠?

2. 배경: 애자일 소프트웨어 개발

개발자 혹은 관련 분야 종사자라면 한번쯤 이 쿨내 진동하는 단어를 들어봤을 겁니다. ‘기민한' 소프트웨어 개발이라니 이 얼마나 멋집니까. 하지만 사실 이 쿨한 이름과 달리 애자일에 대한 이야기는 꽤 오래 되었습니다. 어떻게 하면 이 지긋지긋한 소프트웨어의 복잡성을 덜어낼 수 있을까 하는 고민들이 각기 다른 이름으로 하나씩 정리되어 오다가 2001년에 켄트 벡, 마틴 파울러, 로버트 마틴, 제프 서덜런드 등 이름만 들어도 쟁쟁한 리더분들끼리 한 스키장 리조트에서 모여 애자일 선언문을 작성합니다.

Agile Manifesto (참고 자료: 애자일 선언문)

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.

이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

‘애자일' 이라는 이름에서도 알 수 있듯이 애자일 선언문은 속도에 집중합니다. 다만, 속도에만 집중하는 것이 아닌 일을 되게 만드는 속도에 집중합니다. 간단히 식사하려고 분식집에 김밥먹으러 온 손님에게 최고의 식사를 대접한다며 재료손질부터 시작한다면 손님은 이미 떠나가고 없을 겁니다. 분명 최고의 김밥일지라도요.

애자일을 이야기할때 사람들이 많이 혼돈하는 것이 있습니다. 애자일은 방법론인가? 프로세스인가? 그렇지는 않습니다. 애자일은 RUP나, SPICE, CMMI process와 깉이 정형화된 개발 단계와 산출물이 존재하는 프로세스는 아닙니다. 위의 애자일 선언문에서도 볼 수 있듯이 소프트웨어를 개발함에 있어서 어디에 더 중요한 가치를 두어야 하는가에 대한 철학이라고 생각할 수 있습니다. 말이 어렵네요. 저처럼 어려워하는 사람들을 위해서 애자일 선언문을 작성한 멋진 구루들은 아래와 같은 12가지 원칙들로 다시 설명해주고 있습니다.

애자일 선언 이면의 원칙

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

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

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

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

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

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

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

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

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

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

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

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

그렇다면, 십계명과 같은(애자일은 십이계명이네요) 이 원칙들에 따라서 버즈빌은 어떻게 일하고 있는가 살펴보기로 했습니다. 사실, 우리 훌륭한 PM(Young과 Eric에게 감사를 - 버즈빌은 수평적인 소통을 위하여 영어이름을 사용하고 있습니다.)께서 이미 애자일 마스터로서 스크럼과 칸반에서 좋은 프랙티스들을 따와서 전도해주셨습니다. 우리가 실천하고 있는 좋은 경험들은 아래 그림에 마크해 두었습니다. 굳이 이 내용들을 하나씩 언급하면서 교과서적인 내용을 서술하기 보다는 실제로 우리가 12원칙에 얼마나 가까운지 살펴보는게 더 의미가 있을 것 같아서 아래 그림으로 대체하겠습니다. 빨간색 네모 박스는 하고 있거나 도입중인 부분입니다. 구체적인 필요하신 분들은 구글에만 검색해봐도 깔끔하게 정리된 자료가 무궁무진하게 많아요.

[Image Source: Subway Map to Agile Practices]

3. 버즈빌 애자일 소프트웨어 개발 12계명

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

소프트웨어가 필요한 이유는 고객이 존재하기 때문입니다. 아무리 멋지고 훌륭한 제품을 만들더라도 그것을 사용할 고객이 존재하지 않는다면 아무 가치가 없습니다. 버즈빌의 고객은 크게보면 넷으로 나눌 수 있습니다: 잠금화면 유저, 광고주, 퍼블리셔, 오퍼레이터. 각각의 고객에게 필요한 가치는 여러가지가 있습니다. 질 좋은 광고/컨텐츠를 통한 유저 경험의 극대화, 고도화된 타게팅을 통한 광고 효율 향상, 안정적인 서비스를 통한 수익창출, 오퍼레이션의 편리성 등 다양한 니즈를 가지고 있습니다.

고객은 너그럽지 않습니다. 우리의 제품이 이러한 고객의 가치를 온전히 제공할 수 없다면 고객은 기다려주지 않습니다. 유저는 우리 서비스에서 떠나갈 것이며 광고주는 더이상 우리에게 광고를 주지 않을 것입니다. 퍼블리셔는 우리 서비스를 믿을 수 없어서 사업을 포기할 수도 있고 오퍼레이터는 지루하고 복잡한 작업으로 심지어 버즈빌을 떠나버릴 수도 있습니다.

따라서 우리는 해당 가치를 측정할 수 있는 데이터를 수치화해서 실시간으로 모니터링 하고 있으며, 빠른 배포와 피드백을 통해서 지속적으로 그들을 만족시키려 노력하고 있습니다. 그 어느것도 이보다 우선시될 수는 없습니다.

[Image Source: 버즈빌 데이터 대쉬보드]

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

개발자의 입장에서 요구사항의 변경은 그리 반가운 일은 아닙니다. 기껏 애써가며 설계와 구현을 진행 했는데 그간의 노력이 까만 화면위의 글자 뿐인 아무 가치 없는 낙서로 남게 되는 상황을 아무도 좋아하지 않을 것입니다. 하지만, 요구사항은 변경되기 마련입니다. 고객이 스스로 뭘 원하는지 모를 수도 있고 비지니스 상황에 따라서 더이상 필요 없거나 바꿔야 할 수도 있습니다.

인정합시다. 요구사항은 자주 변합니다. 심지어 제품이 출시되고 나서도 변할 수 있습니다.

버즈빌은 이 현실을 인정합니다. 그렇다면 이 현실을 극복하기 위해서 어떻게 해야 할까요? 문제를 나눠보겠습니다.  

• 요구사항의 인입 및 정제

요구사항 인입 초기에 서로간의 이해가 조금 더 분명하다면 오해는 줄일 수 있고 요구사항 변경 또한 덜 빈번해질 것 같습니다. 개발팀으로 요청되는 모든 요구사항은 PM(Product Manager)를 통해서 이루어집니다. 제품 관점에서 가장 폭 넓게 이해하고 있는 PM은 고객의 요구사항이 정확하게 무엇인지 다시 한번 정제하고 필요하다면 개발자와 상의해서 구현가능한지 검토합니다. 이를 통해서 요구사항은 좀 더 구체화되며 불확실성과 모호성은 제거됩니다. 버즈빌의 PM은 총 네명인데, 각각 엔드유저, 광고주 및 광고 시스템, 퍼블리셔, 제품 고도화에 관련된 제품을 맡고 있습니다. 각 PM 이 대응하는 고객에 따라서 요구사항의 인입과 정제방식이 다르며 정리된 요구사항은 매 스프린트 계획 회의 전에 다시 한번 정리되어 프로덕트 백로그에 우선순위에 따라 나열됩니다.  

• 요구사항의 개발 및 확인

프로덕트 팀에 요구사항을 제기한 사람은 본인이 요청한 사항이 어떻게 진행되고 있는지 항상 확인할 수 있습니다. 개발팀의 스크럼보드는 개발팀 뿐만 아니라 모두에게 공개되어 있습니다. 스크럼보드는 Trello를 통하여 관리하고 있는데, 각 카드는 구체적인 내용을 얼마든지 담을 수 있고 카드를 통해서 얼마든지 논의할 수 있습니다. 개발자가 개발중인 내용은 카드를 통해서 진척사항을 기록하고 있으며 피엠 및 요구사항 발주자는 해당 카드를 통해서 개발사항에 대해서 질문하거나 요구할 수 있습니다. 큰 틀을 벗어나지 않는 요구사항의 변화는 이 카드를 통해서 적응해 나갈 수 있습니다.

[Image Source: 버즈빌 업무툴 ‘트렐로’]

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

앞서 이야기한 것처럼 고객의 요구사항은 변화무쌍하여 언제 어떻게 바뀔지 모릅니다. 따라서 우리는 가능한 빠르게 고객의 피드백을 받고 이를 다시 제품에 반영할 수 있어야 합니다. 이를 위해서 배포하는 방법은 쉽고 자동화 되어 있어야만 합니다. 지속 통합과 나아가 지속 배포가 그 해답이 될 수 있습니다. 모든 소프트웨어 자산은 github을 통해서 형상관리를 하고 있으며 각 브랜치는 마스터에 머지되기 전에 Jenkins를 통해 필수적인 테스트를 자동으로 거치고 머지됩니다. 물론 새로운 기능에 대한 유닛 테스트도 새롭게 작성될 수 있으며 CI과정에 포함됩니다.

무중단 배포, 빌드 버전, 라이브러리 패치 등 대부분의 배포 스크립트는 Fabric을 통해서 자동화되어 있으며 개발자가 할 일은 개발을 마친 뒤에 fab deploy 명령어만 실행하면 됩니다. 최근에는 형상관리 시스템에 코드를 푸쉬하는 것만으로 배포까지 될 수 있도록 자동화하는 작업을 진행하고 있습니다. 배포가 간결하고 쉽기 때문에 작은 변경에 대한 배포를 자주 할 수 있고 그 만큼 고객의 피드백은 더 빠르게 받을 수 있습니다.

[Image Source: 시스템 업데이트 푸쉬메세지]

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

버즈빌에는 특이한 문화가 있습니다. 2달마다 한번씩 제비뽑기를 해서 이후 2달동안 근무할 자리를 정하는데, 예외없이 모두에게 해당합니다. 때문에 버즈빌에는 팀 간의 경계가 없습니다. 바로 옆자리 사람이 디자이너가 될 수도 있고, 비지니스 담당자가 될수도 있습니다. 같은 공간안에서 밀접하게 일할 수 있기 때문에 커뮤니케이션의 비용은 상당히 적고 서로의 언어를 더 잘 이해할 수 있습니다.

다만, 비지니스/파트너쉽 팀은 나머지 팀과 공간이 분리되어 있습니다. 업무의 특성상 비지니스/파트너쉽 은 전화통화와 방문자가 많습니다. 해당 팀은 좀 더 자유롭게 소통할 수 있고 나머지 팀은 좀 더 집중할 수 있는 환경을 구성하기 위해서 공간을 나누어 쓰고 있습니다. 물론 비지니스/파트너쉽 팀원들도 해당 공간에서 2개월마다 자리배치는 랜덤입니다.

[Image Source: 버즈빌 사무실 전경]

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

Trust & Respect. 버즈빌 문화 중 가장 좋아하는 문화 입니다. 우리 모두는 최고의 팀원과 함께하고 있으며 각 팀원이 스스로 올바른 결정을 내리고 책임감있게 일하고 있다고 믿습니다. 우리는 서로를 상호 존중합니다. 주니어라 할지라도 의견을 개진하는데 있어서 주저하지 않으며, 시니어라 할지라도 본인의 의견만 관철시키려 하지 않고 모두가 모두에게 배울것이 있다고 생각합니다.

매 스프린트 시작시에 일정 산정과 계획회의를 하는데 각 일감에 대한 조금 더 관련된 개발자가 있을 수는 있으나 어떤 일감을 가져갈지는 오로지 각 개발자의 몫입니다. 본인의 판단하에 일감을 정하고 각자는 일감을 해결할 수 있도록 스스로 계획해서 일합니다.  

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

버즈빌에서는 다양한 협업 도구를 이용합니다. Slack, Trello, Github, GoogleCalendar, GoogleDocs, Email, Skype 등등. 모두 훌륭한 커뮤니케이션 수단입니다. 하지만, 한계는 분명히 존재합니다. 면대면으로 이야기하는 것보다 더 효율적인 의사소통 수단은 없습니다. 하지만, 이슈가 있을 때 매번 상대를 간섭하는 것은 부담스러운 일입니다. 때문에 서로 편하게 의견을 나눌 수 있는 시간을 정했습니다.

매일 아침 개발팀은 약 15분 정도의 데일리스크럼을 진행하는데, 이는 일반적인 스크럼에서의 그것과 크게 다르지 않습니다. 어제 하던일, 오늘 할일, 이슈나 도움이 필요한 사항에 대한 브리핑을 약 1분간 짤막하게 공유합니다. 이때 간단한 질문은 할 수 있지만, 구체적인 논의는 데일리스크럼이 끝난 직후에 당사자들만 모여서 다시 진행합니다. 때로는 필요에 따라 짝 프로그래밍도 진행합니다. 주로 새로 합류한 개발자 혹은 기존 개발자 중에서도 주로 다루지 않았던 코드에 대한 작업이 필요할 때 진행합니다.

[Image Source: 개발팀 데일리 스크럼]

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

매 스프린트 리뷰 시간에는 각자 약 5분씩 그간 개발해온 기능을 가볍게 공유합니다. 필요하다면 소스코드를 같이 보기도 하고, 실제 동작하는 모습을 데모하기도 합니다. 서로 박수로 칭찬하기도 하고 궁금한 점을 질문하기도 합니다. 물론 기능 적인 구현만 공유하는게 아니라 비기능적인 구현도 공유합니다. 리팩토링을 통해서 훨씬 이해가 쉽고 확장성있는 코드를 만들었다던가 새로운 기술에 대한 연구 및 고찰에 대한 내용을 공유하기도 합니다.

 

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

각 스프린트에 개발할 과제는 개발자 스스로 결정합니다. 보통 하루에 개발에만 집중할 수 있는 시간을 5시간이라고 했을 때 2주일을 기준으로 50시간 정도의 업무량을 가진다고 가정합니다. 개발 과제의 난이도나 작업량을 고려하여 스스로 업무량을 산정하고 장애처리나 예상치 못한 상황에 대한 버퍼를 고려하여 30~40 시간정도의 일감을 스프린트에 올립니다. 각 제품의 피엠은 스프린트 중에 계속하여 각 개발자의 로드를 확인하여 과도한 업무가 가중되지 않도록 리스크를 관리합니다.

스프린트라는 단어의 의미에서 오해가 생길 수 있습니다. 스프린트는 목표를 정하고 집중하자는 의미이지 체력적으로 모든걸 쏟는 전력질주는 아닙니다. 밤을 세워서 개발하는 것은 절대로 자랑스러운 일이 아닙니다. 밤을 세울 수 밖에 없다면 스스로 계획을 잘못 세웠거나 사장님이 나쁜겁니다. 단기간의 성과 보다 지속적이고 예측가능한 성과가 장려되어야만 합니다.

개발자는 엉덩이로 개발하기보다 머리로 개발해야 합니다. 집중할 수 있는 시간에 집중해서 일하고 쉴 때는 과감하게 쉴 수 있어야 합니다. 버즈빌에는 탁구대를 테이블로 쓰고 있는 회의실이 있는데, 점심시간 즈음에는 항상 사람들로 북적입니다. 휴게실에는 커다란 티비와 플레이스테이션이 있습니다. 때로 위닝일레븐 대회가 열리기도 합니다.

[Image Source: 점심시간 탁구 시합]

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

버즈빌의 서버는 하루에도 수백만의 유저로부터 수백건의 요청을 받습니다. 따라서 단순히 기능적으로 동작하는 것 뿐만 아니라 다양한 아키텍쳐가 고려되어야만 합니다. 광고 할당 로직을 위한 최적화에서부터 타게팅을 고도화 하기 위한 검색에 대한 고려, 데이터의 수집과 가공에 대한 고려, 열거하자면 수도 없이 많습니다. 따라서 설계에 대한 고민은 지속적인 요구사항의 구현과 더불어 당연히 계속되어야만 합니다. 최근에는 복잡성을 줄이기 위해서 마이크로 아키텍쳐로의 진화, 성능을 고려하여 일부 병목이 되는 기능을 Golang으로 구현하는 최적화 등을 진행하고 있습니다. 필요한 사항은 어떻게든 시작을 합니다. 나중으로 미루면 절대로 시작하지 않습니다.

그럼에도 불구하고 기술부채가 남아 있을 수 있습니다. 이를 위해서 3회의 스프린트가 끝나면 이러한 고민을 집중할 수 있는 유지보수 스프린트를 1회 진행합니다. 이때는 잠시 새로운 요구사항의 인입을 보류하고 기술 부채를 해결하기 위하여 시스템을 보수합니다. 대체로 프레임워크나 서버 등의 인프라 관리, 보안과 모니터링 등과 같이 평소에 진행하기 어려운 과제 위주로 진행 됩니다.  

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

요구사항을 이해하고 구현하는데 있어서 최대한 시간을 절약하고 단순화 하는게 중요합니다. 개발 일정에 대한 추정과 진행사항 확인을 위해서 복잡한 방법을 쓰거나 보고 하는 일이 필요할까요? 중요한 것은 일을 되게 만든다는데 있습니다. 일정 산출과 추정을 위해서는 단순하게 트렐로 카드에 얼만큼의 시간이 필요하고 얼만큼 진행되었다고 적는게 나아 보입니다. 개발일정에 대해서 해당 개발자만큼 잘 아는 사람은 없을 것 같아요.

아래 그림은 구글 캘린더에서 캡쳐한 실제 저의 일반적인 스프린트 동안의 일정입니다. 스터디, 꿀다방 정기모임(드립커피 소모임입니다.)는 개인적인 일정이고,  StrategyTalk는 한달에 한번 있는 전사 모임입니다. 이들을 제외하면 프로덕트 팀의 회의는 스프린트계획/리뷰 미팅, 매일 있는 15분간의 스크럼 미팅, 개발리더와의 1:1미팅이 전부입니다. 소모적인 회의는 없으며, 보고를 위한 미팅도 없습니다. 누구도 개발자를 마이크로 매니지 하지 않고, 누구도 보고를 원하지 않습니다. 스프린트계획/리뷰 미팅과 데일리 스크럼을 통해서 충분히 소화할 수 있습니다.  

[Image Source: 버즈빌 업무툴 ‘Google Calendar’]

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

누가 시켜서 하는일은 재미 없습니다. 만약에 누군가 저에게 ‘다른 일은 넘보지 마시고 이 일만 집중해서 하세요' 라고 했다면 회사를 뛰쳐나갔을지도 모릅니다. 실제로 전 직장에서 뛰쳐나온 가장 큰 이유중의 하나가 제가 재미있어하고 좋아하는 일을 빼앗아가버렸기 때문이었습니다.(팀 매니저가 되면서 개발할 수 있는 시간보다 회의와 보고해야 하는시간이 너무 많아졌어요)

개발자들이 개발할 대부분의 개발 과제는 백로그에서 스스로 가져옵니다. 하고 싶은 일에 집중할 수 있을때에 생산성이 높은 것 같습니다. 본인이 스스로 일감과 스케줄을 계획하고 진행하기 때문에 책임감을 가질 수 밖에 없습니다. 코드 한줄을 작성하더라도 이 기능이 왜 필요한지 다시 한번 확인하고 다음번 수정을 위해서 유연하게 변경가능하지 검토합니다. 우리는 코드에 Ownership이 없다는 원칙에 동의하지만 그렇다고 책임질 수 없는 코드를 작성하지는 않습니다.  

12. 어떻게하면 더 효과적일지 정기적으로 숙고하고 팀을 조율한다.

매 스프린트 마무리에 각 일감에 대한 리뷰와 데모가 끝나고 나면 스프린트동안 잘 했던 일들과 개선이 필요한 사항에 대해서 이야기 합니다. 그 중 몇가지를 나열해보면 아래와 같습니다.  

• 과제에 대한 정의가 명확하지 않다 -> 과제 인입되기 전에 PM을 통해서 구체화 한다.
• 장애나 긴급 이슈로 인해서 스프린트 초기 설정한 계획이 무용지물이 된다 -> 버퍼를 고려한다.
• 코드 리뷰 요청이 일부 개발자에게만 집중된다 -> 리뷰가 업무를 토스 할 수 있는 방안 마련
• 테스트 폰 관리가 어렵다 -> 테스트 폰에 라벨링 하여 사물함에 보관하고 필요시 명함을 꽂아넣고 사용함
• 유닛 테스트 코드 활용방안 마련 -> 중요한 코드에 대해서 먼저 작성될 수 있도록 가이드
• 코드 리뷰가 밀리는 경우가 발생한다 -> 슬랙 봇을 이용하여 아침출근 직후 점심 식사 직후에 알람을 보내도록 설정하고 다른 업무 전에 리뷰 먼저 처리하도록 가이드
• 스탠딩 데스크 활용 방안 -> 먼저 4개의 스탠딩 데스크를 구매하여 시범 사용 후 확대 방안 논의
• 개발과 관련된 지식정보 모으기 -> github에 프로젝트 생성하여 위키로 활용

이와 같이 회고 시간에는 다양한 의견을 나눕니다. 의견이 수렴되면 바로 액션 아이템으로 삼아서 실행합니다. 버즈빌 개발 팀은 계속해서 적응해 나갑니다. 심지어 데일리 스크럼 시간의 분위기가 자칫 무거워질 수 있으므로 잔잔한 음악을 깔아놓고 해보는 것은 어떤가 하는 이야기도 있습니다. 유지보수 스프린트에 대한 논의는 뜨거운감자입니다. 유지보수 할 일감을 미뤄두고 하는게 맞는 것인가 아니면 일반적인 스프린트에 같이 진행하는 것이 맞는 것인가. 우리는 계속해서 논의하고 있으며 아마도 적절한 답을 찾아갈 것 같습니다.

4. 결론

다시 이야기 하지만 애자일 소프트웨어 개발은 프로세스나 방법론이 아닙니다. 물론 흔히 알려진 스크럼이나 익스트림 프로그래밍, 칸반과 같은 정리된 도구들이 존재하긴 합니다만, 사람들이 좋다고 말한다하여 그대로 적용하는건 바보같은 일입니다.

사람의 성격과 성향이 다양하게 많은 것처럼 팀의 성격과 성향 또한 다양합니다. 어떤 팀은 구조화된 조직을 가지고 있는가 하면 다른 어떤 팀은 수평적인 조직일 수 있습니다. 또한 어떤 팀은 결함을 용납할 수 없는 Mission Critical한 제품을 만드는 반면 다른 어떤 팀은 예측하기 어려운 환경에서 빠른 피드백이 필요할 수도 있습니다. 각 팀은 자기 팀에게 적절한 방법을 생각해볼 수 있어야 합니다. 그리고 서로간의 신뢰를 바탕으로 새로운 방법들에 적응할 수 있어야 합니다.

최근에 버즈빌은 슬라이드조이와의 합병으로 프로덕트 팀의 문화가 한층 더 성숙하고 있습니다. 비슷한 부분도 있고 다른부분도 있는 두 개발조직이 하나로 합쳐지면서 서로의 좋은 방법을 배우고 양보하고 이해하면서 더 나은 개발 문화를 만들어가고 있습니다. 만약 버즈빌이 어떤 한 방법만을 고집하고 있었다면 지금과 같이 멋진 팀을 만들어갈 수 없었을 것입니다. 핵심 가치를 이해하고 서로를 신뢰하기에 가능한 성과라고 생각합니다.

앞으로 또다른 문제를 만날 수도 있습니다. 하지만, 우리는 또다시 적응하고 더 좋은 방법을 찾을 겁니다. 늘 그래 왔듯이.