책 / 애자일 프랙티스

애자일 프랙티스 / 벤캣 수브라마니암, 앤디 헌트

애자일 프랙티스

 

애자일한 팀을 구축하고, 애자일한 소프트웨어를 만들기 위한 내용들을 담고 있다.
'팀 문화적으로'와 '코드 레벨'에서의 애자일을 실현하기 위한 지침서 같은 느낌이다.

핵심 내용을 정리하면서 지금 우리 팀은 그리고 나는 얼마나 잘 애자일을 행하고 있는지 점검해 보았다.

 

비난은 버그를 수정하지 못한다.

요약: 버그 등의 문제가 발생했을 때, 범인을 색출하고 비난하는 것이 아니라 문제 규정하고 원인을 분석해서 문제해결에 초점을 맞추는 것

 

잘했거나 잘하고 있는 점 👍

- 버그가 발생했을 때 사람을 탓하기보다는 왜 버그가 발생할 수 있는 코드수정이 이루어졌는지 생각해 보고 이를 사전에 발견하지 못한 것에 대해서 생각하여 문제 해결에 초점을 맞추고 있음

- 비단 개발팀뿐 아니라 회사 차원에서도 이런 분위기가 잘 형성되어 있는 것 같음

- 덕분에 팀 내의 신뢰도와 심리적 안정감 향상

 

땜질식 수정에 빠지지 말라

요약:  ’땜질’이란 버그 등이 발생했을 때, 코드 한 줄 추가하는 것으로 문제를 임시방편 해결하는 것을 말한다.

하지만 이는 위험하다. 추가한 한 줄의 코드가 다른 곳에서 또 다른 버그를 초래할지도 모른다.

마치 지뢰밭을 가로질러가는 것과 같다.

코드를 가지고 효과적으로 일할만큼 이해하고(하지만 전문가가 될 필요까지는 없다), 누구나 이해할 정도로 단순화하라. 만약 이해하지 못한 상태라면 가능하면 코드를 건들지 않는 게 좋다.

단위테스트를 작성하는 것도 좋은 방법이다.

 

사람이 아니라 아이디어를 비평

요약: 설계에 대한 토의를 한다고 가정했을 때, ‘멍청한 설계다’ 같은 표현 대신 ‘만약 동시에 두 명의 사용자가 로그인한다면 어떻게 될까?’ 같은 질문을 던져보는 것이 좋을 방법이다. 

비판도 판단도 없이 명료함만 남기는 것을 추구하는 것이 좋다.

회의에서 사람에 대해 노련한 중재자를 두고 마감시간을 정하는 것도 좋다. 시간제한은 회의를 활발하게 만들고 이데올로기적 논쟁을 피하게 만든다.

 

잘했거나 잘하고 있는 점 👍

- 회의를 시작할 때 ‘모더레이터’라는 이름으로 중재자를 두고 회의를 한다.

- 회의 시작할 때 회의의 목표와 예상되는 결과물을 다시 상기함으로써 회의가 다른 방향으로 흘러가는 것을 방지한다.

- 회의가 끝나면 ‘회고’를 통해 회의 방식을 개선시키거나 감정적으로 상한 것이 있다면 털어놓고 간다.

 

아쉽거나 생각해 볼 필요가 있는 점 🤔

- 결정된 사항에 나의 생각을 넣기 위해, 기존의 좋은 생각에 군더더기 넣지 않기!
많은 사람들이 실수하는 부분 같다. 그리고 내가 살짝 찔렸던 부분이다. 정말 좋은 아이디어라서 추가하고 싶은 건지, 아니면 나의 욕심인지 잘 구분해야겠다.

 

위험을 무릅쓰고 앞으로 나아가라.(올바른 일을 하라)

요약: 때로는 코드를 완전히 뒤엎어야 할 때가 있다.

누군가 작성한 코드가 엉망이거나 혹은 지금껏 내가 시도한 접근 방식이 잘 못 되었다고 깨달았을 때 등등.

이럴 때는 과감하게 용기를 가지고 사람들을 설득해라.

 

잘했거나 잘하고 있는 점 👍

- 처음 회사에 입사했을 때, 과감하게 회사 시스템 전체를 마이그레이션 한 점이 비슷한 맥락이지 않을까?(개발 효율이 몇 배 상승 할 것이라며 설득)

 

아쉽거나 생각해 볼 필요가 있는 점 🤔

- 책에 이런 부분이 있었다. ‘… 단지 당장 이해하기 힘들다고 새로 만들지는 말아라. 그렇게 하는 것은 용기가 아니라 인내심이 없는 것이다…’ → 나는 어땠나 돌아보는 부분이었다. 마음 한편에 두고 수시로 돌아볼 필요가 있겠다.

 

기술 변화를 따라가라

요약: 신기술을 배우는데 규칙적으로 일정시간 투자하라.

기술 블로그를 읽거나 학회에 참석하는 것도 좋다.

이런 과정이 없다면 언젠가 버거운 시점이 찾아오기 마련이다.

모든 분야에 전문가가 될 필요는 없지만 업계가 어떤 방향으로 가는지 알아야 하고, 그에 맞춰 프로젝트 계획을 세워야 한다.

 

아쉽거나 생각해 볼 필요가 있는 점 🤔

- 나에게 딱 필요한 조언을 들은 것 같았다. 예전에는 새로운 기술이 있으면 엄청 신기해하면서 한 번씩 둘러보고 사용해 보고 그런 게 있었는데 요즘에는 대충 뭐겠거니 하면서 도외시하는 경향이 있었다.

실무와 관계가 적을수록 더 관심이 없어지는 것 같다.

규칙적으로 시간을 정해두고 회사 일과 관계가 없는 기술이라도 둘러보는 습관이 필요해 보인다.

 

팀에 투자하라

요약: 팀 안에서 지식과 기술을 공유하고 팀 차원에서 수준을 끌어올려라.

 

잘했거나 잘하고 있는 점👍

- 새로 알게 된 기술이 있다면 수시로 서로 이야기하고 공유하는 문화가 잘 형성되어 있음

 

아쉽거나 생각해 볼 필요가 있는 점 🤔

- 하지만 지식이나 기술에 대해서 이야기 나누는 주기적인 자리는 부재…

 

버려할 때가 언제인지 알자

요약: 애자일의 핵심은 변화에 익숙해지는 것이다.

만약 새 기술을 도입했다면 새 기술에 어울리는 새로운 환경, 새로운 툴, 새로운 습관이 필요하다.

 

리듬을 느껴라 (일이 쌓이기 전에 부딪쳐라)

요약: 여기서 말하는 리듬이란, 규칙적인 테스트와 배포 등으로 생기는 리듬을 말한다.

즉, 큰 단위의 작업을 쪼개어 각각 독립적인 작은 작업으로 나누어라.

 

잘했거나 잘하고 있는 점 👍

- 프로젝트를 새로 시작하거나 코드를 리펙토링 할 때 무작정 하지 않고 일의 순서를 정한다.

- 배포 가능한 작은 단위로 쪼개어 일을 나눈다.

- 만약 작업이 꼬리에 꼬리를 물어 걷잡을 수 없이 커졌다면 과감하게 리셋하고 근본이 되는 부분부터 다시 작업한다.(대개 근본이 되는 부분이 하나의 작은 작업이 된다)

 

지금까지 팀 문화적인 내용들이 주였다면 아래부터는 코드 레벨에서 내용들이다.
당연하다고 생각되고, 이미 여기저기서 많이들 강조하는 내용들이 많았다.
그래도 기초는 중요하기에 한번 더 반복!

프로젝트를 항상 릴리즈 가능하게 하라

코드를 일찍, 자주 통합하라

짧은 반복을 사용해서, 점진적으로 배포하라

자동화된 단위 테스트를 사용하라

인수테스트를 자동화하라

의도적이고, 의미 있게 프로그램하라

요약: 독창적이지 않고, 명확하게 코드를 작성하자.  개발할 때의 편리함보다 읽기 쉬운 코드를 선택해야 한다.

 

아쉽거나 생각해 볼 필요가 있는 점 🤔

- 패턴이 반복되는 작업을 할 때면 반복되는 과정을 최소화하고 싶어 진다. 그렇게 반복을 최소화할 수 있는 구조를 찾고 구현하다 보면 어느새 가독성이 떨어지는 코드를 작성할 때가 있었던 것 같아 반성!

코드로 대화하기

변화요약: 가능하다면 주석 대신 좋은 코드로 코드를 문서화를 하라.

능동적으로 트레이드오프 평가하기

요약: 성능은 중요하다. 하지만 이미 꽤 괜찮은 성능이라면 다른 면도 중요하다.

밀리세컨드 성능 개선을 하는 것보다 더 적은 개발 작업량, 비용 절감을 선택하는 게 더 중요할 수 있다.

성능, 편의성, 생산성 등 여러 요소를 고려하여 효율적인 선택을 하는 것에 집중하라.

짧은 수정/빌드/테스트 주기 안에서 코드를 작성하자

단순하게 유지하라

요약: 디자인 패턴으로 덕지덕지 칠해진 코드가 과연 진정 아름다운까?

 

 

후기
책을 읽기 전에 두 가지 마음이 있었다.
'애자일? 나에게는 익숙한 개념이지' vs '그런데 내가 진짜 애자일에 대해서 잘 알고 있나?'

책을 읽으면서 두 가지 마음이 모두 충족되는 기분이었다.
많은 부분에 대해서 그래도 나름 잘 해온 것 같아서 뿌듯하기도 했고, 한편으로는 기초적인 부분일지라도 책에서 한번 더 강조할 때면 한번 더 생각해 보면서 나를 점검할 수 있었다.

애자일에 대해 모른다면 애자일이 무엇인지 잘 느낄 수 있는 책.
애자일에 대해 잘 알더라도 나를 한번 더 점검해볼 수 있는 책이다.