집단 코드 오너십
팀이 코드에 대한 책임을 공유한다. 개선된 코드 품질은 이를 통해 얻을 수 있는 이점 중 하나이다. 집단 오너십이 생소할 때는 모든 사람이 실제로 함께 작업하기보다는 사실상 개별 스토리에 대한 오너십을 갖게 되는 실수가 발생하기 쉽다.
객관화 프로그래밍
집단 코드 오너십을 위해선 자아를 어느 정도 버려야 한다. 당신의 코드가 아니라 팀 코드에 자부심을 가져라. 집단 코드 오너십은 당신이 완벽하지 않아도 된다는 것을 의미한다. 더 개선하기 어려울 것 같으면 그대로 두라. 다른 사람들이 이를 개선할 수도 있다.
익숙하지 않은 코드로 작업하기
한두 명만 이해하고 있는 코드에서 작업한다면 집단 코드 오너십이 다소 위압적으로 보일 수 있다. 여러분이 이해하지 못하는 코드에 대한 오너십을 어떻게 가질 것인가? 시작에 있어선 몸 프로그래밍이 최선의 선택이다. 이를 통해 팀에게 빠르게 지식을 공유할 수 있다.
페어링을 통해 지식을 확장하려면 당신이 이해하지 못하는 태스크에 자발적으로 작업을 해야 한다. 그리고, 그 시스템에 관해 아는 이들에게 페어 프로그래밍을 하도록 요청하라.
프로그래머를 위한 이점
집단 코드 오너십은 조직 관점에서는 매우 상식적이다. 리스크를 줄이고, 사이클 다임을 개선하며, 코드에 더욱 신경을 쓰도록 함으로써 품질을 개선한다. 하지만 개인의 기여를 인정받기 어렵다고 느낄 수 있다. 애자일은 조직에 개인의 영웅적 행동보다는 팀의 기여를 인정하고 가치를 두도록 요구한다.
또한, 기술적인 스킬을 확장할 수 있다. 새로운 디자인과 코딩 기법을 팀의 다른 구성원으로부터 배울 수 있다. 반대로 당신이 가진 전문성을 다른 사람에게 알려줌으로써 멘토링 스키롣 익힐 수 있다.
작성한 코드에 대한 유지보수의 부담을 줄일 수 있다. 팀이 당신의 코드를 지지할 것이다. 질문이나 긴급 상황이 발생해도 편안하게 휴가를 갈 수 있다.
전제 조건
이를 활용하기 전에는 관리자와 팀원 사이에 충분한 대화를 해야 한다. 어떤 프로그래머는 특정 언어 사용을 거부하기도 한다. 그리고 누구든 수정할 수 있기 때문에 길을 잃기 십상이다. 이는 매일 30분 정도 '디자인 요약'을 통해 새로운 아이디어나 최근의 변경 사항에 관한 논의한 것도 좋은 방법이다.
페어 프로그래밍
페어 프로그래밍에서는 두 사람이 같은 컴퓨터에서 작업하면서 같은 시간에 같은 일을 한다. 하지만 이는 애자일에서 가장 논란이 있는 아이디어이다.
이유
단순히 지식을 공유하는 데서 멈추지 않는다. 페어링을 하면 결과물의 품질도 향상된다.
한 사람은 코드를 작성하는 드라이버가 되고, 네비게이터는 코드에 대해 생각한다.
드라이버는 큰 그림에 관해 걱정하지 않고, 구문적으로 올바른 코드를 만드는 전술적 과제에 집중할 수 있다. 네비게이터는 코딩의 세부 사항에 주의를 뺏기지 않고 전략적 문제에 관해 고려할 수 있다.
몰입 상태에서 생산성이 높다는 것은 익히 유명하다. 두 사람이 같이 일하면 방해받을 일이 적고, 만약 누군가 방해한다면 페어 중 한 명이 그 인터럽트를 처리하고, 다른 한 명은 계속 작업한다. 또한, 손목이 아파도 키보드를 파트너에게 넘길 수 있고 무엇보다 재미있다.
페어링 방법
프로덕션 코드, 테스트, 자동화를 포함해 모든 유지 관리해야 하는 항목에 대해 페어링을 하는게 좋다. 태스크에 관한 작업을 시작할 때 다른 프로그래머에게 협업을 요청하라. 새로운 관점이 필요하다면 파트너를 바꾼다. 네비게이터는 세미 콜론이 빠진 것과 같은 사소한 오류를 지적하지 마라. 그리고 키보드를 빼앗고 싶은 충동을 느끼더라도 인내하라. 스스로 수정할 수 있는 시간을 주고 그 시간에는 큰 그림을 생각하라. 드라이버를 할 때 서툴고 손이 떨리는 느낌을 받을 수 있다. 네비게이터가 여러분보다 더 빠르게 아이디어와 문제를 본다고 느낄 수도 있다. 네비게이터는 드라이버보다 생각할 시간이 더 많아 자연스러운 일이다.
도전 과제
페어링은 처음에는 어색하거나 불편하다. 하지만 이는 자연스러운 것이며 한두 달 후에 사라진다.
1.편안함
불편한 페어링은 재미가 없다. 주변 환경을 확인하고 책상에서 잡동사니를 치워라. 개인 공간이 더 필요한 경우 넓은 공간을 사용하라.
2.내향성과 사횢거 불안
이런 사람들에게는 페어링을 넘어 애자일이 어려울 수 있다. 팀원들에게 집단 코드 오너십을 달성할 수 있는 다른 방법이 있는지 이야기를 나눠라.
3.핑퐁 페이렁
핑퐁 페어링에선 한 사람이 테스트를 작성하고, 다른 사람은 그 테스트가 성공하게 코드를 작성한다. 이를 번갈아가며 이터레이션한다. 너무 적거나 무뚝뚝한 커뮤니케이션도 문제다. 코드와 디자인에 관한 솔직한 비판은 가치가 있음에도 처음에는 받아들이기 어려울 수 있다. 보다 협력적인 문제 해결의 태도를 취하라.
몹 프로그래밍
몹 프로그래밍은 드라이버가 한 명이고 나머지는 모두 네비게이터다. 몹 프로그래밍이 효과적인 이유는 협업의 '쉬운 모드'이기 때문이다. 이를 수행하면 스탠드업 회의, 집단 코드 오너십, 팀 룸 등을 고민할 필요가 없다. 몹 프로그래밍에 전부 존재한다.
모빙을 막 도입하면 팀에서 너무 많은 사람이 아이디어를 외쳐서 드라이버가 무엇을 해야 할지 이해하는 데 어려움을 겪을 수 있다. 이 때, 팀 원 한명만 네비게이터로 지정할 수 있고, 이를 순환시켜라.
유비쿼터스 언어
팀이 대화와 코드를 작성할 때 이용하는 용어를 통합함으로써 모든 사람이 효과적으로 협업할 수 있게 하는 방법이다.
전문적인 소프트웨어 개발의 어려움 중 하나는 프로그래머가 일반적으로 소프트웨어 문제 도메인에 대한 전문가가 아니라는 점이다. 다시 말해 도메인 전문가들은 소프트웨어를 거의 작성하지 못하고, 반대로 프로그래머는 도메인 문제를 이해하지 못한다.
이는 커뮤니케이션의 문제다. 도메인 전문가는 그들의 전문 지식을 프로그래머에게 전달하고, 프로그래머는 이를 소프트웨어로 변환한다. 문제는 그 정보를 정확하게 커뮤니케이션하는 것이다.
유비쿼터스 언어는 자동으로 만들어지기 보단 노력해서 만들어야 한다. 도메인 전문가에게 말할 때는 그들이 어떤 용어를 사용하는지 주의 깊게 들어보라. 여러분이 들은 것을 다이어그램으로 그리고 피드백을 요청하라.
프로그래머: 피아노를 쳐서 기본적인 악보를 볼 수 있습니다.
도메인 전문가: 여기선 앙상블과 오케스트라를 위한 악보를 조판할 것이기 때문에 피아노 악보와는 정확히 같진 않습니다. 모든 악보를 오선으로 나누고, 각 오선을 마디로 나눈 뒤에 마디에 음표를 넣습니다.
프로그래머: 아 조판의 기본은 악보라는 것이네요. 그리고 악보에는 보표가 있습니다. 그리고 각 보표에는 마디가 있습니다. 한 악보네능 최대 몇 개의 보표를 가실 수 있습니까?
도메인 전문가: 편곡에 따라 다릅니다. 현악 4중주라면 4개, 오케스트라 악보라면 십여 개가 될 수도 있습니다.
프로그래머: 적어도 하나는 들어가겠지요?
...위 대화로 얻을 수 있은 결과는 단순한 화이트보드 스케치 그 이상이다.