18 Highlights

애자일 방법론들은 모두 빠르고 짧은 피드백 루프에 대한 것이다. 더 빨리, 더 짧게 피드백 루프를 만들수록 더 애자일해진다. 어떤 피드백이 올 때마다 그 피드백에 대응할 기회를 얻고, 그러한 새 정보에 적절한 행동을 취하면 프로젝트가 더 민첩해진다. 피드백 주기가 짧으면 문제를 신속하게파악할 수 있어 상황 파악도, 적응도 빠르다. 애자일은 문제 자체를 해결해 주지는 않는다. 애자일은 문제를 드러나게 한다.

절차에만 집중하고 소프트웨어 개발을 공장 라인처럼 취급하면, 그저 시키는 일만 하고 출퇴근하는 공장 노동자와 다를 바 없는 개발자들만 생긴다.

기술을 이해하지 못하는 사람들이 의사 결정을 하는 것은 프로젝트를 재앙으로 이끄는 지름길이다.

애자일 절차를 포함해서 모든 소프트웨어 절차들은 기술적 탁월함을 기본 배경으로 가정하고 있다. 기술적 탁월함을 갖추지 못한 소프트웨어 프로젝트는 고통과 당황함 일색의 매우 비싼 경험이 되기 쉽다.

애자일 매니페스토에서는 분명하게 ‘절차와 도구보다는 개성과 화합을’ 중요시 함을 선언하고 있지만, 애자일 전환은 온통 절차와 도구로 끝나 버린다. 스크럼을 도입하고, 스탠딩업 미팅을 하고, 백로그 관리툴을 사용하는 것만으로 갑자기 소프트웨어의 품질이 더 좋아지거나 개발자들의 역량이 높아질 수는 없다. 기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미하다.

보이스카웃에는 캠핑 장소를 처음 발견했을 때보다 더 깨끗하게 남겨두라는 규율이 있다. 이는 소프트웨어에도 똑같이 적용할 수 있다. 코드도 처음 발견했을 때보다 더 깨끗하게 관리해야 한다(이 비유를 처음 소프트웨어에 적용하고 소개한 것은 로버트 C. 마틴Uncle Bob이다).

소프트웨어 장인은 공장 노동자가 아니다. 적극적으로 프로젝트의 성공에 기여해야 한다. 요구사항에 질문하고, 비즈니스를 이해하고, 개선사항을 제안하며, 고객 또는 고용주와 생산적인 동반자 관계를 맺어야 한다.

오늘날 우리는 계속해서 늘어만 가는 정보 속에, 계속해서 줄어만 가는 의미를 목도하는 세상에서 살고있다.

Jean Baudrillard

차드 파울러는 저서 『열정적인 프로그래머』에서 그저 실망시키지 않기 위해 말하는 ‘네’는 거짓말에 지나지 않는다고 했다. 그냥 거짓말이 아니라 중독적이고 파괴적인 습관이다. 양의 탈을 쓴 나쁜 습관이다.

많은 기업들이 자신의 소프트웨어에 인질로 잡혀 있다. 소프트웨어가 얼마나 빨리 변경 또는 개선될 수 있느냐에 따라 비즈니스의 민첩성이 드러난다. 소프트웨어의 품질이 좋지 않을수록 변경하기가 더 어려워진다. 기업이 사용하는 소프트웨어의 개선이나 변경이 느릴수록 시장 환경의 변화에 기업이 대응하는 속도도 떨어진다.

코드가 망가지고 있는지를 비즈니스 담당이 눈치채기는 대단히 어렵다. 반면에 개발자가 그것을 숨기는 것은 너무나 쉽다.

기술적 실행 관례들 그 자체를 직접적으로 팔려고 드는 것은 아무런 의미가 없다. 그렇게 해서는 상대방을 납득시킬 수 없다. 실행 관례의 도입 자체를 관리자나 팀 구성원들에게 설득하려 하지 말고 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중을 해야 한다.

어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다.

Yogi Berra

이러한 현상을 ‘피터의 원리’라고 한다. ‘자신의 무능력이 드러날 때까지 승진하려는 경향’으로도 표현된다. 다르게 말하면 어떤 사람들은 정치 게임, 권한 남용, 책임 전가와 비난, 부정직하고 프로페셔널하지 않은 태도를 통해 감당할 능력이 전혀 없는 자리까지 승진한다.

좋은 개발자를 찾기는 꽤 어렵고 오랜 시간이 걸린다. 면접에 시간을 투자하고 있다면 그를 최대한 의미있게 활용해야 한다. 두뇌 장난같은 수수께끼를 내는 등 지원자를 바보처럼 느끼게 하는 면접은 훌륭한 지원자가 당신과 함께 일하기 싫어하게 만드는 지름길이다. 코딩 면접을 할 때 인터넷 접속을 끊거나 종이나 화이트보드에 코드를 작성하게 하는 것 또한 의미도 없고 지원자의 화를 복돋우기 십상이다. 진정 보고 싶은 것은 그 지원자가 할 수 있는 최선의 모습이다. 지원자와 짝을 이루어 좋은 도구로 무언가를 만들어 내는 모습을 지켜보자. 테스트를 어떻게 작성하는지, 리펙토링을 어떻게 하는지, 좋은 네이밍을 할 줄 아는지 등을 평가해야 한다. 지원자가 함께 일할만한 동료인지 알아보기 위해 자연스럽게 대화하자.

그 어떤 바보 같은 개발자도 뭔가를 동작하게 만들 수는 있다. 비범한 개발자와 평범한 개발자를 가르는 기준은 어떤 방식으로 그것을 동작하게 만드느냐이다. 비범한 개발자는 요구사항을 충족하는 가장 단순한 코드를 만들어 경험이 적은 개발자가 이해하는 데 아무런 문제가 없도록 한다.

당장의 합당한 이유 없이 단지 ‘미래를 대비해야 한다’는 모호한 전제로, 초기부터 추상화를 하면 애플리케이션이 엉망이 된다.

앞으로 나아가지 못하고 정체되어 있다고 느낀다면, 무언가를 배우거나 스스로 일을 즐기지 못한다면, 그때는 움직여야만 한다. 회사와 동료들을 사랑한다는 것만으로는 그 일을 계속해야 하는 충분한 이유가 되지 못한다.