원문은 http://www.infoq.com/articles/building-an-agile-team 이다. 한 시간 정도에 졸속 번역을 했더니, 내가 싫어라하는 번역체가 가득한 글이 되었다.ㅠ.ㅠ

Introduction

agile 소프트웨어 개발 팀을 만드는 것은 보기보다 어렵다. 많은 매니저나 팀 리드 들이 기술력이 좀 있는 사람들을 뽑아다가, 애자일 프로세스 하나를 던져 놓고, 책에서 본 것처럼 잘 돌아가길 바라고만 있는다. 이런 접근법은 비현실적일 뿐만 아니라 실패할 확률도 높다. 이 글에서는 성공적인 팀의 구성 요소와 이 팀을 어떻게 만들 수 있는지 알아본다.

Components of a Successful Team

성공적인 애자일 소프트웨어 개발팀은 기술력 있는 개발자들이 팀의 가치를 형성하고, 우수한 커뮤니케이션을 할 수 있으며, 항상 개선하려는 의지가 있는 팀이다. 이런 것들을 모두 한다는 것이 성공을 보장하지는 않지만, 성공으로 가는 길을 단축시켜 줄 수는 있다.

Core Principles

사람들은 자기 팀을 위해 어떤 문화들을 갖추고 싶은지 모두 제각각 이다. 매니저가 원래 잘 알고 있던 사람들을 고용하지 않는 한, 개발 문화에 대한 비전을 현실로 바꾸는 것은 매우 어려운 일이다. 우리는 개발에 중요한 특성들이 어떤 것들인지는 일찍이 알고 있었다. 고객의 관점에서 바라보고, 효과적으로 협업하고, 사실에 기반하여 관리하고, 실행에 집중하는 것들이다. 이 원리들을 잘 따르고 있는 팀은 성공으로 가는 유리한 위치에 있다. 그런 팀의 멤버들은 여러 가지 좋은 습관들을 가지고 있는데, 고객들에게 질문을 던져보거나, 고객처럼 생각하는 것, 도움을 요청하는 데 거리낌이 없는 것, 그리고 기꺼이 남을 돕는 것, 개인적인 의견보다 사실에 입각하여 결정을 내리는 것, 그리고 완성된 코드를 쉬핑하기 위해 고군분투하는 것이다.

Effective Communication

효율적인 커뮤니케이션은 성공을 위해 필수적이다. 효율적인 커뮤니케이션의 중요한 요소는 직접 얼굴을 맞대고 face-to-face 로 하는 것이다. 사람들을 한 곳에 불러 모으면 커뮤니케이션 진행이 훨씬 원활하다. 또 다른 중요한 요소는 집중하는 것이다. 참가자들을 한 곳에 집중하게 할 정도로 잘 정의된 주제를 가지고 있지 않으면, 대화가 비생산적으로 흐르게 된다. 세 번째 요소는 대화를 fact 와 아이디어에 집중하도록 만드는 것이다. fact 와 아이디어 보다 개인적인 의견들을 내놓기 시작하면, 대화는 금방 싸움으로 번지거나 신경전으로 바뀔 수 있다.

Good People

성공적인 팀의 가장 중요한 것은 바로 사람이다. 소프트웨어 개발팀은 재능 있는 사람을 필요로 한다. 새로운 기술을 사용해서 복잡한 시스템을 만들기 위해서는 기술력 있는 개발자들이 필요하다. 이런 복잡한 시스템들은 한 두 명의 사람으로 만들어지지 않는다. 팀이 필수적이다. 그러므로, 개발자들은 팀으로서 일할 수 있도록 숙련되어 있어야만 한다.

Constant Improvement

우리는 새로운 팀을 만들고 새로운 시스템을 만드는 와중에 무너지는 경우가 많은 것을 이미 알고 있다. 성공적인 팀과 실패하는 팀의 차이는 이런 실수들 속에서 배우느냐 하는 것이다. 과거의 실수들을 돌아보고 필요한 개선들을 만들어 내야만 한 걸음 앞으로 나아갈 수 있는 것이다.

Building the Team

Communication Focus

우리 회사의 시작부터, 우리는 커뮤니케이션에 집중해 왔다. 우리 사무실은 개방된 형태이다. 개발팀은 커다란 방을 함께 쓴다. 개발자들은 각자 책상을 하나씩 사용하고, 책상 배치는 커뮤니케이션을 활성화하는 쪽으로 배치되어 있다. 개방된 환경은 커뮤니케이션을 더욱 쉽게 일어나게 하는데, 왜냐하면 사람들이 칸막이 등에 숨을 데가 없고, 대화가 public 하게 일어나기 때문이다. (이 환경이 강압적이지 않도록 모든 사람이 예의를 지키고 프로페셔널하게 행동해야 한다.)

Establishing Core Principles

팀을 만드는 과정에서 우리는 팀이 가졌으면 하는 특징들을 모아서 명문화해 둘 필요가 있음을 깨달았다. 처음에는 매일 부대끼는 상호 작용이 팀에 이런 것들을 불어 넣어 주리라 생각했었다. 그러나 그거보다는 이런 특성들을 발굴하고, 팀과 공유해서 모든 팀 멤버들이 우리가 느낀 가치들에 대해 적절히 집중하도록 하는 과정이 성공을 위해 필수적이었다. 팀이 가졌으면 하는 특징들을 명문화하는 작업은 우리한테 가혹한 깨달음의 과정이었다. 그 중 하나는 현재 팀 멤버들 중 누군가는 팀의 특성들을 체화하지 못하고 있다는 것이다. 이런 팀 멤버들을 가르치기 위해 아주 긴 시간이 걸렸다. 팀의 몇몇은 매우 긍정적으로 반응했으나 일부는 그러지 못했다. 그러다 어떤 경우에는 몇 몇을 팀에서 뺐다. 두 번째 깨달은 사실은 우리의 인터뷰 프로세스가 우리가 원하는 사람들을 필터링 해내지 못하고 있다는 것이었다. 우리의 초기 인터뷰 과정은 후보자의 기술적으로 어떤 것을 할 줄 아는 지 밝히는 데 주안점을 두고 있었다. 우리가 사람을 뽑는 것도 기술적으로 가장 능숙한 사람을 고르려고 했었다. 그 결과로 매우 똑똑하고 능력 있는 개발자들을 뽑았으나, 그들 모두가 팀 환경에서 잘 자라나진 못했다.

Interview Process

회사의 기존문화와 잘 맞으면서 기술적인 역량도 가지고 있는 사람을 찾는 것은 힘든 일이다. 후보자들을 가려낼 객관적인 측도들을 가지고 있으면 빨리 가려내는 데 도움이 된다. 반면 순수히 객관적인 잣대들은 팀 활동에 도움이 되는 soft 스킬들을 잡아내지는 못한다. 우리는 이 영역을 탐지해내기 위해 고생했다. 우리의 현재 인터뷰 모델은 multi-stage 프로세스다. 첫번째 단계는 전화면접이다. 전화 면접은 우리 회사를 소개하고, 후보자를 큰 그림에서 판단할 수 있게 해준다. 전화면접 동안 우리는 기본적인 기술 능력들이나 애자일 개발에 대한 생각, 이해도 등과 함께 어느 정도의 개인적인 성찰등을 알아본다. 이런 영역들을 물어봄으로써, 그 사람이 우리 팀 환경에 맞는지 아닌지 판단할 수 있다. 후보자가 전화면접을 통과하면, 실제 면접을 스케줄한다. 실제 면접은 세 단계로 나뉘는데, 기술, 프로세스, 개인 이 그것이다. 각 단계동안 최소 2명의 팀멤버들을 할당해서, 팀원의 대다수가 후보자와 얘기해볼 시간을 갖게 한다. 기술 면접은 기술 능력과 함께 실제 코딩을 해보게 한다. 프로세스 단계는 테스팅, 문제 해결, 페어프로그래밍등과 그 외 주제들과 함께 개발에 대한 철학을 물어본다. 개인 면접 단계는 충돌을 해결하는 방법, 스스로 동기부여하는 방법, 그 외 일반적으로 개인의 정신적 안정성 들을 알아본다. 우리는 이렇게 단계를 가지고 진행하는 방법이 제법 잘 통한다는 것을 알게되었다. 만약 모든 단계를 다 통과했고, 후보자에 대한 이견이 없다면, 그는 우리 팀에서 일하게 된다.

Process Improvement

프로세스 개선은 성공적인 소프트웨어 개발 팀을 만들기 위한 핵심이다. 우리는 프로세스 개선을 코드를 쓰고 배포하는 일에 그치지 않고, 업무의 우선순위를 메기거나 새로운 직원을 뽑는데 까지 넓혀 생각한다. 개선에 우리가 쓰는 방법 중 하나는 "3x3" 리뷰라고 부르는 것이 있다. 전체 팀이 한 곳에 모인 다음, 각 팀 멤버들이 지난 석달 동안 긍정적이었던 것 하나와 부정적인 것 하나를 얘기한다. 각 팀 멤버들은 세 장의 투표권을 가지고 앞 서 얘기한 항목에 대해 투표한다. 리뷰가 끝날 때쯤, 팀의 관점에서 긍정적인 것들과 개선이 필요한 것들이 뭔지 볼 수 있는 시야가 생긴다. 명문화 해놓은 팀의 특성에 맞게 개선하는 작업에 이런 팀의 시각을 가지는 것이 도움이 된다. 우리가 개선한 다른 프로세스 영역은 인터뷰이다. 애자일 개발방법에 대한 우리의 이해도가 높아짐에 따라, 기술적으로 역량이 있는 것 뿐만 아니라 팀으로서 기능할 수 있는 사람을 찾고자 하는 요구도 커졌다. 지난 18 개월 간의 노력 끝에 우리는 우리의 인터뷰 프로세스를 우리 팀 환경에서 자라지 못하는 후보자를 미리 걸러낼 수 있을 정도로 가다듬었다. 이 프로세스 개선은 우리가 뽑은 사람들에 대해서 훨씬 큰 신뢰를 가질 수 있게 해줬다. 기존의 프로세스와 그것을 꾸준히 개선하는 데 있어서 균형을 잡을 필요도 있었다. 우리의 프로세스에서 고통을 겪을 때마다, 우리는 그 고통에 대해 평가해보는 짧은 시간을 가졌는데, 만약 그 고통이 시스템에서 오는 것이면, 우리는 프로세스를 개선하기 위한 단계적 변화들이 뭔지 알아내려 했다. 만약 그 고통이 시스템적인 것이 아니라면, 우리는 보통 다른 변화들을 만들지 않고 시간을 두고 기다려 보는 방법을 썼다.

Conclusion

그리 길지 않은 시간 동안, 우리는 성공적인 애자일 개발팀을 만드는데 필요한 소중한 교훈들을 배웠다. 팀의 가치를 확립하고 그것을 추구하는 것이 성공적인 문화를 만드는데 도움이 되었고, 우리의 인터뷰 프로세스 개선에도 도움이 되었다. 좋은 커뮤니케이션이 일어나도록 하는 것은 많은 팀들을 괴롭히는 장애물을 없애주었다. 인터뷰 프로세스를 개선하는 것은 우리 팀과 잘 어울리는 검증된 개발자들을 찾아 낼 수 있게 해주었다. 기존의 프로세스를 뒤돌아 봄으로서 우리 팀을 지속적으로 개선 할 수 있게 해줬다.