애자일 마스터

https://nymets.medium.com/%EC%95%A0%EC%9E%90%EC%9D%BC-%EB%A7%88%EC%8A%A4%ED%84%B0-71565c2b6bfc

맘에 안 드는 건 책 제목(원서)과 표지에 사무라이가 들어간다는 점. 일본 문화가 얼마나 영향력이 있는지 보여주는 일례인 듯

내가 생각하는 방향이 틀리지 않았음을 알게 되었다. 다만 당연히 세부사항에 대해서는 나도 더 발전해야 한다.

오래된 책이지만 역시 좋은 책은 시간과 무관하게 가치가 있다. 애자일에 대한 책이 앞으로 얼마나 가치가 있을지 모르겠으나(당연히 고전과 같은 가치가 있진 않겠지만) 그래도 상당히 오래 가지 않을까? 하는 생각이 들었다.

언젠가는 누구나 다 이런 방식으로 일하는 것을 좋아하게 될 거라고 생각하느냐고? 천만의 말씀, 만만의 콩떡이다. 누구나 건강식을 먹고 운동해야 한다는 걸 알고도 실천하지 못하는 이유처럼 말이다.

(내가 같이 일하는 분들이나 만나서 이야기하는 분들에게 항상 하는 비유인데 정말 똑같이 나와서 깜짝 놀랐고 반가웠다)

세가지 단순한 진실 1. 프로젝트 초기에 요구사항을 모두 수집하기는 불가능하다. 2. 수집한 요구사항들이 무엇이든 반드시 변하기 마련이다. 3. 시간이나 비용이 허락하는 것보다 해야 할 일들이 항상 더 많다.

(이건 정말 변치 않는 진리. 마치 변하지 않는 사실은 모든 게 변한다는 사실과 마찬가지랄까)

같은 공간에서 일하는 경우의 장점을 부인하진 않으나, 보통 개발을 모르거나 어설프게 아는 c level들은 모여서 일하는 게 필수적이지 않냐고 이런 책이나 페이스북 같은 사레를 들곤 한다. 하지만 모여서 일하는 경우에도 단점이 있다는 사실은 외면하고 보통은 눈에 안 보이면 일을 안 하는 줄 착각하곤 한다. 이런 잘못된 인식을 바꿔주기 위해 사내에서 노력하고는 있지만 정말 쉽지 않다.

이루어진 적이 없는 합의가 이루어졌다고 믿는 성급한 가정이 바로 대부분의 프로젝트가 실패하는 이유다.

(그래서 개발을 모르는 사람들이 애자일을 어설프게 아는게 가장 위험하다. 애자일의 가치가 문서화를 경시하는 게 아니라 문서화도 중요하지만 소통을 하는 게 더 중요하다고 하는 건데, 이걸 마치 문서는 필요없다고 착각하거나 외면하는 경우가 종종 있다. 물론 분야를 막론하고 어설프게 아는 사람들을 가장 피해야하긴 하다)

‘신뢰' 내가 CTO로 일하기 시작한 후 첫 c level 회의에서 강조했던 부분. 역시 이렇게 책에서 만나게 되니 반갑다.

이미 모두가 여러분이 제시한 해결책에 동의했다고 생각할지라도, 모두가 볼 수 있는 곳에 해결책을 붙여두라. 최악이라고 해봤자 모두가 이 사실을 안다는 걸 확인하는 정도겠지만, 원래 생각했던 해결책이 아닌 것에 베팅하는 일은 피할 수 있을 테니 말이다.

(flow diagram을 그리도록 한 게 나의 방법. 기술쪽 뿐만 아니라 비즈니스에서도 마찬가지로 필요하다)

각 항목에는 반드시 하나의 순위만을 매겨야 한다. 예를 들어, 네 가지가 모두 우선순위 #1로 매겨질 수는 없다.

(나는 그래서 CEO에게 속도 — 시간 — 와 품질 중에 하나만 선택해 달라고 했다. 물론 둘 다 선택할 수는 없다고)

개발 팀 내의 누구에게든 가장 정확하고 효과적으로 정보를 전달하는 방법은 그 사람과 직접 대면하면서 이야기하는 것이다.

(이건 동의할 수 없다. 직접 대면해서 이야기하면 말은 휘발성이 있기 때문에 기록에 남지 않아 나중에 다시 이야기할 때 서로 다르게 해석하는 경우가 100% 발생한다. 써서 남겨도 여러 의미로 해석된다면 설명이 불충분한 경우이다. 그래서 나는 가능하면 image나 video로 남기는 걸 권한다. 쓰는 거 보다 더 많은 사항을 구체적으로 나타내기에 대부분 좋기 때문이다)

소프트웨어의 기능 중 64%는 사용자가 거의 사용하지 않거나 한 번도 쓰지 않는다는 걸 알고 있는가? 놀랍게도 사실이다!

(그러므로 우리는 비즈니스의 본질에 집중해야 한다. PO들에겐 항상 비즈니스의 본질만 구현하는데 집중하고, 그 외의 기능, 소위 “~있으면 좋잖아요"라고 말하는 기능들은 사실 우리에게 오히려 해가 된다고 설명한다. 기능을 구현할 부분은 없으면 우리 비즈니스가 동작하지 않는 경우로 말하면 보통 이해를 잘 한다)

비행기의 이착륙 현황판은 참 훌륭하다. 흘깃 보는 것만으로도 어떤 비행기가 도착하는지, 출발하는지 혹은 취소됐는지 쉽게 알아 볼 수 있으니 말이다. 여러분의 프로젝트에도 이런 현황판이 있다면 어떨까?

(Dashboard를 구현하는 게 이래서 중요하다. Data source만 가능하다면 grafana를 이용하면 큰 노력을 들이지 않고 이런 현황판을 구현할 수 있다. 모니터의 여유가 있다면 모두가 보기 쉬운 위치 — 사무실 코너 천장같은 — 에 항상 dashboard에 가장 중요한 지표들이 나오게 하면 모두가 상황을 인식하고 확인하기 더 편해진다)

여러분이 소프트웨어를 개발할 때 사용하는 언어들이 비즈니스를 하는 사람들의 언어와 맞지 않는다면, 여러 가지 문제점이 생길 수 있다.

(최악의 경우는 비즈니스 하는 쪽 뿐만 아니라 개발팀/개발자 사이에서도 같은 명칭이 서로 다른 의미로 사용되기도 한다. DB column name과 code의 variable name과 UI에 표현하는 name이 모두 다르다고 상상해보자. Communication cost가 항상 낭비될 수 밖에 없다)

데모를 준비하고 출시할 코드를 서버에 올리는 작업은 스트레스 받거나, 노심초사해야 할 커다란 이벤트가 되어서는 안 된다.
…
소프트웨어를 개발, 통합하고 배치하는 과정이 특별나지 않아야 한다. 그러기 위해서는 코드를 매끄럽고 지속적으로 통합하는 프로세스와 항상 출시에 대비하는 문화가 필요하다.
…
애자일을 하는 사람들은 코드를 언제든 출시할 수 있도록 하는 문화를 선호한다.
…
하지만 이런 팀 문화를 유지하는 일이 거저 얻어지지는 않는다. 엄청난 훈련이 필요할 뿐 아니라 일정이 중요하다는 명목으로 출시할 코드의 품질에 대한 투자를 차일피일 제쳐 두고픈 유혹도 있기 때문이다.

(그래서 항상 균형을 적당하게 잡는 게 중요하다. 속도만 중시해서 초기에 이런 걸 잡아놓고 준비하지 않은 채 어느 정도 발전을 하고 나면 이런 CI/CD를 갖추는 게 정말 힘들다)