👉 Chapter 4: 팀 실천 방법

• 론 제프리즈의 삶의 순환 그림에서 가운데 고리는 애자일의 팀 실천 방법을 담고 있다.

• 팀 실천 방법은 팀 구성원 사이의 관계, 그리고 팀원과 팀이 만드는 제품 사이의 관계를 다룬다.
• 그중에 이번 장에서 논의할 실천 방법은 메타포, 지속 가능한 속도, 공동 소유, 지속적 통합이다.

📚 메타포

• 메타포의 기본적인 아이디어는 팀 내에서 효과적으로 의사소통을 하려면, 개념을 나타내는 어휘와 용어를 명확하게 정의하여 일관되게 사용해야 한다는 것이다.
• 메타포는 어휘를 만들어 주어 팀 내 의사소통을 효율적으로 만든다. 반면에 고객을 모욕하는 어리석은 메타포도 있을 수 있다.

🔥 도메인 주도 설계

• 에릭 에반스는 그의 도메인 주도 설계에서 메타포 문제를 해결했는데 이 책에서 에릭은 유비쿼터스 언어라는 표현을 제안했다.
• 도메인 주도 설계에서는 해결하려는 문제 도메인의 모델을 모든 사람이 동의하는 어휘로 표현해야 한다. (여기서 모든 사람은 프로그러머, QA, 관리자, 고객, 사용자를 모두 포함한다.)
• 톰 드마르코는 이런 모델을 데이터 사전이라고 불렀다.
• 드마르코와 에반스 둘 다 이 도메인 모델을 이해관계자 모두가 의사소통하는 도구로 삼았다.
• 유비쿼터스 언어는 프로젝트의 모든 곳에서 쓰인다. (사업 부서, 개발자, QA, 운영팀, 데브옵스, 고객 등)
• 프로젝트의 모든 단계에 걸쳐서 사용되어, 전체 프로젝트를 일관성 있게 연결한다.

📚 지속 가능한 속도

🔥 마라톤

• 소프트웨어 프로젝트는 단거리 경주가 아니라 마라톤이다.
• 좋은 성적을 내려면 자신에게 맞는 속도를 찾아야 한다.
• 무리에서 뛰쳐나와 전력 질주를 한다면, 결승선을 통과하기 전에 에너지가 바닥이 나 버릴 것이다.
• 지속 가능한 속도보다 더 빠르게 달려 버린다면, 결승선을 통과하기 전에 속도를 늦추고 쉬어야 하는 때가 올 것이다.
• 결과적으로는 평균 속도가 지속 가능한 속도보다 더 느려진다.
• 끝까지 일할 수 있도록 당신 자신을 관리하는 일은 당신의 몫이다.

🔥 헌신

• 고용주에게 당신이 얼마나 헌신적인지 보여 주고 싶을 때, 야근은 좋은 방법이 아니다.
• 야근이 증명하는 것은 당신이 계획을 잘못 세운다는 것, 동의하지 않았어야 하는 일정에 동의했다는 것, 하지 말았어야 하는 약속을 해버렸다는 것, 전문가가 아니라 다루기 쉬운 초보자라는 것뿐이다.
• 야근을 함으로써 전체 일정은 오히려 더 늦어질 가능성이 크다는 것을 잘 알고 있어야 한다.

🔥 잠

• 프로그래머의 삶을 구성하는 성분 중 가장 소중한 것은 바로 충분한 수면이다.
• 잠이 두 시간 부족하면 낮에 여섯 시간은 날리게 된다.

📚 공동 소유

• 애자일 프로젝트에서는 아무도 코드를 소유하지 않는다. 코드는 전체 팀이 소유한다.
• 팀 구성원 누구나, 언제든지, 프로젝트의 어느 모듈이든 체크아웃해서 개선할 수 있다. 팀 전체가 코드를 공동으로 소유한다.
• 공동 소유를 실천하면, 지식이 팀 전체에 퍼진다. 팀 구성원 모두가 모듈 사이의 경계나 전반적인 시스템 동작을 더 잘 이해하게 된다.
• 그 결과, 팀 의사소통이 훨씬 원활하게 이루어지고, 더 좋은 결정을 내릴 수 있게 된다.

🔥 엑스 파일

• 코드를 공유하지 않으면 아무도 코드를 볼 수 없다. 그러면 사용해야 하는 코드를 열어볼 수 없으니 의사소통이 불편해진다. 당연히 서로에 대한 비난과 험담이 뒤따른다.
• 사람들의 불안감과 적대적이고 가식적인 태도 말고도 인적 자원의 낭비 때문에 매우 불편한 분위기가 만들어진다.

📚 지속적 통합

• 지속적 통합은 통합을 지속적으로 할 때만 제대로 동작한다.

🔥 지속적 빌드 원칙

• 지속적 빌드는 절대 깨지지 않아야 한다.
• 프로그래머는 체크인 전에 모든 인수 테스트와 단위 테스트를 수행해 봐야 한다.
• 만약 빌드가 깨졌다면??
• 한 번이라도 빌드가 실패한 날에는 달력 네모 칸에 빨간색 점을 칠하고, 반대로 빌득 한 번도 실패하지 않은 날은 초록색 점을 칠한다.
• 이런 단순한 시각적 요소만으로도, 한두 달 만에 빨간색이 대부분이던 달력이 초록색이 대부분인 달력으로 바뀐다.

🔥 윤전기를 멈춰

• 다시 한번 말아지만 지속적 빌드는 절대 깨지지 않아야 한다.
• 깨진 빌드는 모든 프로그래머가 하던 일을 멈추고 빌드를 살펴보아야 한다.
• 그래서 다시 통과하게 만들어야 한다.

🔥 속임수를 쓴 대가

• 마감 일정의 압박이 심해지면 지속적 빌드를 깨진 채로 방치하는 팀이 더러 있는데 이건 자살 행위이다.
• 실패하는 테스트를 아예 빼버리고 나중에 다시 추가하고 고칠꺼라고 다짐했을 것이다. 하지만, 나중에 고치기로 하고 치워둔 실패하던 테스트 무더기는 모두가 잊어버린다. 결국 망가져 있는 시스템이 배포된다.

📚 스탠드업 미팅

• 진짜 스탠드업 미팅이란 이런 것이다.

1. 미팅 참석은 필수가 아니다. 대부분의 팀에서는 한 명쯤 빠져도 된다.
2. 꼭 매일 할 필요는 없다. 각 팀에 맞는 일정을 잡으면 된다.
3. 10분이 넘게 걸리면 안 된다. 팀이 크더라도 말이다.
4. 회의는 다음과 같은 단순한 방식으로 진행한다.

• 기본적으로 팀 구성원이 둥글게 둘러서서, 세 가지 질문에 대한 답을 하는 것

1. 지난 스탠드업 미팅 이후 무엇을 했는가?
2. 다음 스탠드업 미팅까지 무엇을 할 것인가?
3. 어떤 장애물이 있는가?

• 모든 사람이 30초 정도 안에 세 가지 질문에 대한 답을 해야 한다.
• 그리고 스탠드업 미팅이 끝나면 다시 일을 시작한다.
• 위키백과 참고

🔥 돼지인가? 닭인가?

• 핵심은 스탠드업 미팅에서는 개발자만 말해야 한다는 것이다.
• 관리자나 다른 사람은 들을 수는 있지만 끼어들어서는 안 된다.

🔥 감사 인사

• 다음 질문을 네 번째 질문으로 추가하는 것이다.

• 누구에게 감사하고 싶은가?

• 당신을 도와준 사람이나 칭찬받아 마땅하다고 생각하는 사람에게 가볍게 감사를 표하는 것이다.