•
팀 실천 방법은 팀 구성원 사이의 관계, 그리고 팀원과 팀이 만드는 제품 사이의 관계를 다룬다.
•
그중에 이번 장에서 논의할 실천 방법은 메타포, 지속 가능한 속도, 공동 소유, 지속적 통합이다.
메타포
•
메타포의 기본 아이디어는 다음과 같다. 팀 내에서 효과적으로 의사소통을 하려면, 개념을 나타내는 어휘와 용어를 명확하게 정의하여 일관되게 사용해야 한다는 것이다.
◦
프로젝트를 팀원 모두가 잘 아는 무언가에 비유하는 일이기 때문에 켄트 벡은 이 실천 방법에 메타포라는 이름을 붙였다.
•
켄트 벡이 늘 예로 들었던 것은 크라이슬러 급여 프로젝트에 사용한 메타포였다.
•
벡은 급여 계산을 공장 조립 라인에 비유했다.
◦
급여를 작업대에서 작업대로 움직이면서 부품을 더한다.
⇒ 백지 상태의 급여 명세서가 신원 확인 작업대로 이동하면 직원의 신원 정보가 더해진다. 그리고 지급 작업대로 이동하면 총 지급액이 더해진다. 소득세, 건강보험, 고용보험 등의 작업대를 거친다.
•
프로그래머와 고객 모두 급여 계산 과정에 이 메타포를 쉽게 적용할 수 있다. 덕분에 시스템에 관해 논의할 때 활용할 수 있는 어휘도 생긴다. 하지만 메타포를 잘못 쓰는 경우가 많다.
•
메타포는 어휘를 만들어 주어 팀 내 의사소통을 효율적으로 만든다. 반면에 고객을 모욕하는 어리석은 메타포도 있을 수 있다.
도메인 주도 설계
•
에릭 에반스는 그의 책 “도메인 주도 설계”에서 메타포문제를 해결했다.
◦
이 책에서 에릭은 유비쿼터스 언어라는 표현을 제안했는데, 사실 메타포보다 이 실천 방법에 더 어울리는 이름이다.
◦
도메인 주도 설계에서는 해결하려는 문제 도메인의 모델을 모든 사람이 동의하는 어휘로 표현해야 한다. 여기서 모든 사람은 프로그래머, QA, 관리자, 고객, 사용자를 모두 포함한다.
•
톰 드마르코는 이런 모델을 데이터 사전이라고 불렀다. 데이터 사전에는 응용 프로그램이 다루는 데이터와 응용 프로그램이 데이터를 다루는 절차를 간단하게 기술한다.
◦
에반스는 이 아이디어를 가져다 도메인 모델을 만드는 규칙으로 발전시켰다.
•
드마르코와 에반스 둘 다 이 도메인 모델을 이해관계자 모두가 의사소통하는 도구로 삼았다.
•
저자는 ‘우주 전쟁’이라는 비디오 게임을 만들었다.
◦
우주선, 클링온, 로뮬런, 발사, 명중, 폭발, 기지, 수송 같은 데이터 요소가 있었다.
•
저자는 개념들을 각각의 모듈로 잘 분리하고 응용 프로그램 전체를 통틀어 이름이 겹치지 않도록 주의했다. 이런 이름들이 저자의 유비쿼터스 언어였다.
•
유비쿼터스 언어는 프로젝트의 모든 곳에서 쓰인다.
◦
사업 부서에서도 사용하고 개발자도 사용한다. QA도 운영팀이나 데브옵스도 사용한다. 심지어는 고객도 유비쿼터스 언어 중 적절한 것을 사용할 수 있다.
•
유비쿼터스 언어는 경영 사례에도 쓰일 수 있고 요구 사항이나 설계, 아키텍처, 인수 테스트에도 쓰일 수 있다. 프로젝트의 모든 단계에 걸쳐 사용되며 전체 프로젝트를 일관성 있게 연결한다.
지속 가능한 속도
•
성경에 따르면 일곱째 날, 하느님께서는 쉬셨다. 하느님께서는 나중에 일곱째 날 쉬라는 계명도 만드셨다.
•
하느님마저도 지속 가능한 속도로 일하셔야 했던 것이 분명하다.
초과 근무
•
저자가 철이 들면서 깨달은 것은 가장 말이 안 되는 실수를 하는 때는 늦은 밤 정신없이 일하는 도중이라는 것이었다. 저자는 밤에 저지른 실수를 만회하느라 시간을 써야했다.
•
새벽 2시 즈음, 조그만 데이터를 시스템의 실행 계층 중 낮은 부분에서 훨씬 높은 부분으로 어떻게 보낼지 고민하고 있었다. 스택을 따라 함수의 반환값으로 전달할 수는 없었다.
•
만들고 있던 제품 내부에는 ‘메일’ 전달 시스템이 있었는데, 다른 프로세스와 정보를 주고받을 때 사용하는 것이었다.
•
카페인이 활성화되어 모든 신경이 최고조에 달했던 새벽 2시, 깨달은 것이다. 프로세스의 낮은 부분에서 메일로 자신에게 데이터를 보내며 높은 부분에서 메일을 읽을 수 있을 것이었다.
•
저자는 30년이 넘게 흐른 다음에도 누군가가 잘못된 결정을 했을 때 이렇게 이야기를 하곤 한다. “아이고, 이 사람들 자기 자신한테 메일을 보냈네”
마라톤
•
이 사건을 계기로 소프트웨어 프로젝트가 단거리 경주가 아닌 마라톤이라는 것을 배웠다.
•
좋은 성적을 내려면 자신에게 맞는 속도를 찾아야 한다. 무리에서 뛰쳐나와 전력 질주를 한다면 결승선을 통과하기도 전에 에너지가 바닥나버릴 것이다.
•
장기간 유지할 수 있는 속도로 달려야 한다. 지속 가능한 속도로 달려야 한다. 지속 가능한 속도보다 더 빠르게 달려 버린다면 결승선을 통과하기 전 속도를 늦추고 쉬어야 할 때가 올 것이기 때문이다.
•
관리자가 당신에게 무리하게 빨리 달리라고 할 수도 있다. 그 말을 들어서는 안 된다. 끝까지 일할 수 있도록 당신 자신을 관리하는 것은 자신의 몫이다.
헌신
•
고용주에게 자신이 얼마나 성실한지 보여주고 싶다면 야근은 좋은 방법이 아니다.
•
야근이 증명하는 것은 당신이 계획을 잘못 세운다는 것, 동의하지 않았어야 하는 일정에 동의했다는 것, 하지 말았어야 하는 일정에 동의했다는 것, 전문가가 아니라 다루기 쉬운 초보자라는 것뿐이었다.
•
모든 야근이 나쁘다는 것은 아니다. 절대 야근을 하면 안 된다는 것도 아니다. 어쩔 수 없이 해야할 때도 있다. 그러나 야근을 함으로써 전체 일정은 오히려 더 늦어질 가능성이 크다는 것을 잘 알고 있어야 한다.
잠
•
인간의 삶을 구성하는 성분 중 가장 소중한 것은 바로 충분한 수면이다.
•
7시간은 자야 한다. 하루나 이틀 정도는 6시간만 자도 괘찮다. 하지만 보통 이보다 적게 자면 생산성은 뚝 떨어진다.
•
자신의 몸이 몇 시간을 자야 하는지 잘 파악하고 이 시간을 확보해야 한다. 잠에 투자한 시간은 그 이상을 보답할 것이다.
공동 소유
•
애자일 프로젝트에서는 아무도 코드를 소유하지 않는다. 코드는 전체 팀이 소유한다.
•
팀 구성원 누구나, 언제든지, 프로젝트의 어느 모듈이든 체크아웃해서 개선할 수 있다. 팀 전체가 코드를 공동으로 소유한다.
•
팀의 누구도 특정 모듈을 소유하지 않는다. 구성원 전부가 모든 모듈을 공부하고 개선하기 위해 노력한다.
•
공동 소유가 당신이 전문성을 더 키울 수 없다는 뜻은 아니다. 시스템이 복잡해질수록 반드시 전문성이 필요해진다.
•
시스템 전체에 걸쳐서 온갖 세부 사항을 모두 파악하기 힘들 수 있다. 그러나 전문성을 키우면서 넓게 알아야 한다. 언제나 잘하는 영역을 벗어나서 일할 수 있어야 한다.
•
공동 소유를 실천하면 지식이 팀 전체에 퍼진다. 팀 구성원 모두가 모듈 사이의 경계나 전반적인 시스템 동작을 더 잘 이해하게 된다.
엑스 파일
•
공동 소유를 정확히 반대로 실천한 안 좋은 예를 한 번 살펴보자.
•
X 사는 담당하는 부품에 따라 계급이 결정되는 계급 사회였다. X는 프린터 회사였으니 인쇄 부품 담당의 계급이 제일 높았다.
•
아무도 코드를 공유하지 않았고 인쇄팀이 갖는 권위의 핵심은 인쇄 코드에 있었다. 그래서 인쇄 코드를 꽁꽁 숨겨 놓았다.
•
이로 인해 생기는 문제는 수없이 많았다.
◦
사용해야 하는 코드를 열어볼 수 없으니 당연히 의사소통이 불편했다.
◦
똑같은 코드의 중복이 늘었다.
지속적 통합
•
애자일 초기에는 지속적 통합이 한두 시간에 한 번 정도 소스 코드를 체크인하고 주 브랜치에 머지한다는 뜻이었다.
•
모든 단위 테스트와 인수 테스트는 계속 통과해야 한다. 기능 브랜치가 통합되지 않은 채 남아있어서는 안 되었다. 동작하면 안 되는 기능들은 배포 시 토글로 비활성화시켜야했다.
지속적 빌드 원칙
•
지속적 빌드는 절대 깨지지 않아야 한다.
스탠드업 미팅
•
저자가 생각하는 진짜 스탠드업 미팅이란 이런 것이다.
◦
미팅 참석은 필수가 아니다. 대부분의 팀에서 한 명쯤 빠져도 된다.
◦
꼭 매일 할 필요는 없다. 각 팀에 맞는 일정을 잡으면 된다.
◦
10분이 넘게 걸리면 안 된다. 팀이 크더라도 말이다.
◦
회의는 다음과 같이 단순한 방식으로 진행된다.
▪
기본적으로 팀 구성원이 둥글게 서서 세 가지 질문에 대한 답을 하는 것이다.
1.
지난 스탠드업 미팅 이후 무엇을 했는가?
2.
다음 스탠드업 미팅까지 무엇을 할 것인가?
3.
어떤 장애물이 있는가?
•
저자는 누구에게 감사한가?라는 질문을 추가해보아도 괜찮을 것이라고 제안한다.
결론
•
애자일은 작은 소프트웨어를 만드는 작은 팀을 돕는 원칙과 실천 방법, 규율을 모은 것이다.
•
이 장에서는 작은 팀이 진짜 하나된 팀으로 일하는 데 도움이 되는 실천 방법을 알아보았다.
•
이 실천 방법은 팀 내에서 의사소통할 때 사용하는 언어를 정하도록 도와주며 팀원들이 서로를 어떻게 대하고, 프로젝트를 어떻게 대해야 할지 가늠할 수 있도록 해 준다.
