애자일 협력

어떤 프로젝트라도 팀은 필요합니다.

하지만 팀에서 일하는 것은 혼자 일하는 것과 상당히 다르고, 본인의 활동이 전체 프로젝트와 생산성, 진행 상황에 큰 영향을 줄 수 있습니다.

애자일의 초석인 효과적인 협력에 대해 살펴보도록 하겠습니다.

 

- 정규 대면회의 시간을 가져라

 

의사소통은 프로젝트 성공의 열쇠이고, 따라서 우리는 동료 개발자와 의사소통을 잘 해야 합니다.

 

스탠드 업 미팅은 팀을 모으고, 모든 사람에게 정보를 제공하는 효과적인 방법입니다.

이름이 암시하듯이, 스탠드 업 미팅에서 참석자는 앉는 게 허용되지 않습니다. 이 점이 회의를 짧게 유지하도록 유도해줍니다.

 

지금 제가 있는 팀에서도 매일 오후 2시반에 스탠드 업 미팅을 진행합니다.

실제로는 앉아서 하지만, 확실히 앉아서 하다보니 회의가 길어지는 경향이 있어 타이머를 사용하고 있습니다.

각 팀원마다 3분의 시간이 주어지며, 어제 한 일과 앞으로 할 일에 대해 얘기하고 공유할 부분이나 개발간의 허들이 있으면 질문을 하기도 합니다. 경우에 따라 3분을 넘어가는 경우도 있지만, 그 건이 모두에게 공유될 필요는 없을 경우 스탠드 업 미팅이 끝난 후에 따로 연관된 사람들끼리 모여 얘기를 나누도록 하고 있습니다.

 

확실히 스탠드 업 미팅을 통해 각 팀원의 진행상황 캐치 및 이슈 파악이 용이하며 시간 제한이 있다보니 맡고 있는 프로젝트를 말로 설명하는 능력은 조금 향상 된 것 같습니다. 이 점도 팀에서의 의사소통에 중요하다고 생각합니다. 가끔 누군가가 공유하는 내용을 들을 때 너무 장황해서 무얼 얘기하고 싶은건지 파악이 어려운 경우가 종종 있었기 때문입니다.

 

스탠드 업 미팅은 많은 이익을 제공합니다.

 

• 스탠드 업 미팅은 집중하는 방식으로 하루를 시작하게 한다.

• 개발자에게 어떤 문제가 있다면, 개발자는 이슈를 공공연하게 만들고 능동적으로 도움을 구할 기회를 얻는다.

• 추가적인 도움이 필요한 분야를 결정하고 팀 리더나 관리자가 인력을 얻거나 재할당하도록 한다.

• 프로젝트의 다른 분야에서 무엇이 진행되고 있는지 팀원이 인식하게 한다.

• 다른 사람이 해결책을 갖고 있는 분야나 중복을 재빨리 파악하도록 해준다.

• 코드와 아이디어 공유를 촉진해서 개발을 가속시킨다.

• 앞으로 나아가게 서로 북돋는다. 다른 사람이 진행 상황을 보고하는 것을 봄으로써 각자가 같은 일을 하도록 동기를 부여한다.

 

- 아키텍트는 코드를 작성해야 한다

 

설계는 당면한 문제에만 한정되기 때문에, 이 설계를 구현하면서 문제에 대한 이해도가 변하게 됩니다.

따라서 효과적이고 상세한 디자인을 앞서서 제공하는 것은 어렵습니다. 문제에 대한 배경 지식도 충분하지 않고 작은 피드백도 없기 때문입니다.

설계는 시간에 따라서 진화하기에 어플리케이션의 현실을 무시하고 새로운 기능이나 개선을 설계할 수 없습니다.

 

설계자로서, 시스템의 핵심적인 상세 내용을 이해하지 않고는 조금이라도 효과적일 수 없습니다.

좋은 설계자는 본인도 코딩을 할 수 있는 사람입니다.

실제로 작동하는 설계를 현실화하는 것이 설계자, 아키텍트의 책임입니다.

 

- 공동 소유를 실천하라

 

중요한 어플리케이션을 개발하기 위해 공동의 노력이 요구됩니다. 따라서 개발자 혼자 코드를 독점하고 있을 필요가 없습니다.

코드를 이해하는 팀원이라면 코드에서 작업할 수 있어야 합니다.

즉, 한 명의 개발자 손 안에서 코드를 독점적으로 유지하면 리스크가 커집니다.

 

다수의 사람이 코드에서 작업할 때, 코드는 지속적으로 체크되고 리팩토링됩니다.

수정이 필요하다면, 작업을 마치기 위해 어떤 개발자라도 달라붙을 수 있습니다.

어떤 개발자라도 달라붙을 수 있기에, 작업마다 팀원을 순환시키면 팀의 전체적인 지식과 경험 수준이 향상될 것입니다.

누군가가 코드를 이해하려고 노력하는 동안 유용한 질문을 던지기 때문에, 문제에 대한 통찰력을 제공할 수 있습니다.

 

물론 실제로는.. 프로젝트엔 일정이라는게 있다보니 업무는 주로 맡던 개발자가 계속 이어나가는 케이스가 많고 순환을 시킬수록 개발자의 피로도가 올라갈 수 있다는 단점도 있습니다.

따라서 한 분야에서 일하도록 개발자를 배타적으로 배정하면, 개발자는 이 분야에 아주 익숙해져 더 빨리 개발을 이끈다고 주장하는 사람도 있습니다. 실제로 이는 사실이긴 합니다.

 

조금 추상적일 순 있지만, 장기적으로 코드를 주시하는 다수의 시선을 둠으로써 코드의 전체 품질이 향상되고 유지보수와 이해는 용이해지며, 에러는 줄어든다는 점은 확실합니다.

 

- 멘토가 되자

 

특정 주제에 대해 팀에 있는 다른 사람보다 더 많이 안다는 사실을 깨닫는 시간이 올 것입니다.

우리는 아는 것을 공유해서, 주위에 있는 사람을 더 낫게 할 수 있습니다.

 

• 지식은 나누면 커진다

 

많은 사람이 아이디어를 공유해도 아이디어는 사라지지 않습니다.

팀에서 다른 사람과 작업하는 것은 훌륭한 학습 경헙입니다. 누군가를 교육하면, 둘 다 더 많은 지식을 얻습니다.

아는 것을 설명하는 시간을 가지면 아는 것에 대한 더 나은 이해를 얻고, 다른 관점도 얻게 됩니다.

 

이렇게 함으로써 팀의 전체 역량을 향상시키고, 대답할 수 없는 질문은 약점일 수 있다는 사실도 알려줍니다.

실력을 향상시키기 위해 이 약점에 더욱 집중해야 합니다.

 

멘토가 된다는 것이 팀원의 손을 잡고 숟가락으로 정보를 떠먹여 주는 역할은 아닙니다.

멘토가 된다는 것은 자신에게 도움이 될 뿐만 아니라 팀 동료가 실력을 높이도록 돕는 것을 뜻합니다.

 

또한 이러한 역할을 팀의 테두리 안에서 멈춰선 안됩니다.

개인적인 블로그를 시작해서 코드나 코드 관련 기술에 관한 글을 올리면, 많은 다른 사람에게 유용할 것입니다.

 

토멘터(고통을 주는 사람)가 되진 맙시다.

 

- 사람들이 알게 하라

 

좋은 멘토가 되는 것은 날마다 팀 동료에게 생선을 주기보단 낚시를 가르치는 것과 유사합니다.

즉 바로 답을 알려주는 것이 아닌, 힌트를 주고 스스로 알아내게 하는 것인데 여기엔 몇 가지 장점이 있습니다.

 

• 문제에 어떻게 접근하는지 팀 동료가 학습하도록 돕는다.

• 팀 동료는 답 이상의 것을 배운다.

• 팀 동료는 같은 질문을 반복하지 않는다.

• 질문에 대답하지 못할 때도 팀 동료가 뭔가 역할을 하도록 한다.

• 생각하지 못했던 해결책이나 아이디어를 가지고 올지도 모른다. 무언가를 배울 수도 있다.

 

팀 동료가 빈손으로 온다면, 더 많은 힌트를 줄 수도 있습니다.

아이디어를 들고 온다면 장단점을 평가하도록 도울 수 있고, 생각하지 못했던 더 좋은 답이나 해결책을 통해 오히려 역으로 배우며 생각을 공유할 수 있습니다.

 

팀 전체가 이런 태도를 몸에 익힐 때, 팀의 지적 자본이 급속하게 늘어나는 것을 발견할 것이며, 훌륭한 소프트웨어를 만들 수 있습니다.

 

- 준비되었을 때만 코드를 공유하라

 

버전 관리 시스템을 사용하지 않는 것보다 더 나쁜 것은, 버전 관리 시스템을 잘못 사용하는 것입니다.

버전 관리 시스템을 사용하는 방법에 따라 생산성, 제품 안정성, 품질, 일정에 영향을 미칠 수 있고, 특히 코드를 얼마나 자주 체크인 하느냐 와 같은 간단한 부분이 큰 차이를 만들 수 있습니다.

 

우리가 작업중인 코드를 체크인 한다면, 작업할 수 없는 상태에서 코드를 집어 넣는 것입니다.

이러한 코드에는 컴파일 에러가 있을 수 있고, 다른 부분과 호환되지 않을 수 있습니다.

 

코드를 체크인하기 전에 모든 단위테스트가 성공하는지 확인하도록 하고, 그런 경우에만 체크인해서 코드를 공유하도록 합시다.

만약 git 과 같은 시스템을 사용할 때, 준비되진 않았지만 공유를 먼저해서 다른 사람들의 의견을 얻고 싶다면 Draft 라는 기능을 사용하거나 pr 에 WIP (Work In Process) 과 같은 표시를 해서 공유하는 방법도 있습니다.

 

- 코드 리뷰

 

코드 리뷰는 문제 위치를 찾고 해결하는데 유일한 최상의 방법입니다.

지금까지 개발을 해오면서, 코드 리뷰를 두려워 하는 개발자들을 꽤 자주 볼 수 있었습니다.

다른 사람이 코드를 살펴보는 것에 위협을 느끼며, 간혹 코드 리뷰는 개발자의 자아를 침범하기 때문입니다.

 

하지만 개발자의 경험에 관계없이 팀 내 모든 개발자가 작성한 코드에서 리뷰를 수행해야 합니다.

그럼 어떻게 코드 리뷰를 해야 할까요?

 

• 야근형

 

한 달에 한 번 밤을 새면서 거대한 코드 리뷰 세션을 열 수 있습니다.

하지만 이러한 리뷰는 지루하고 광범위한 토론으로 들어가며, 전혀 소용이 없을 수도 있고 진행이 안될 수도 있습니다.

전혀 추천하지 않는 방법이고, 저도 실제로 해본 적은 없습니다.

 

• 뽑기형

 

다른 개발자가 리뷰하기 위해 코드를 집어들고, 최대한 순환시킵니다.

즉 A 가 B 의 코드를 리뷰했다면, 다음번엔 C 가 B 의 코드를 리뷰하도록 순환시키는 것 입니다.

이것은 아주 효과적인 기술이 될 수 있습니다.

 

• 페어 프로그래밍

 

한 사람은 키보드에 앉아 조종사로, 한 사람은 뒤에 앉아서 항해사로 행동하며, 역할을 자주 바꿔줍니다.

지속적인 코드 리뷰처럼 작동하는 제 2의 눈이 있기 때문에, 별도의 리뷰 시간을 갖지 않아도 되는 장점이 있습니다.

 

제가 있는 팀의 경우엔, 각각 중요한 repository 별로 담당자를 2~3명씩 지정해서 코드 리뷰는 해당 repo 의 담당자가 진행하도록 설정했습니다. 팀 전체가 순환되진 않지만, repo 에 따라 깊은 이해가 수반되어야지 리뷰가 가능한 경우도 있으므로 꽤 도움이 되는 것 같습니다.

그 외의 repo 에 대해선 팀원 중 리뷰어를 랜덤으로 선정해 배정합니다. 물론 배정받지 않은 사람도 충분히 리뷰를 할 수 있습니다.

 

코드 리뷰를 하면서 아래와 같은 부분을 살펴보면 좋을 것입니다.

 

• 코드를 읽고 이해할 수 있는가?

• 명백한 에러는 없는가?

• 코드가 어플리케이션의 다른 부분에 바람직하지 않은 영향을 끼치는가?

• 코드 중복이 있는가?

• 코드를 개선시키는 적당한 개선이나 리팩토링이 있는가?

 

저는 여기에 추가로 시니어와 주니어간의 리뷰 차이가 있을 수 있다고 생각합니다.

시니어일수록 그리고 설계에 능하다면, 전체의 구조적인 부분에 좀 더 치중한 리뷰가 가능하다고 생각합니다.

공통적으로는, lint 와 같은 툴을 도입해서 이러한 부분에 다른 팀원이 리뷰하는 시간을 소비하지 않도록 하면 좋을 것 같습니다.

 

 

출처 : 애자일 프랙티스(책)