Clean Agile Back to Basics 클린 애자일 새로운 세대를 위한 애자일 가치와 실천

1장 애자일 소개

중간 단계의 작은 목표를 고르고, 그 진행 상황을 측정한다는 아이디어는 너무나 직관적이고 인간적이다. 혁신이라고 할 것도 없다.

과학적 관리법은 변경 비용이 많이 드는 프로젝트에서 제일 잘 동작했고, 목표가 극도로 명확한 매우 상세하게 정의된 문제를 잘 풀었다.

• 공정과 도구보다 개인과 상호작용

• 포괄적인 문서보다 작동하는 소프트웨어

• 계약 협상보다 고객과의 협력

• 계획을 따르기보다 변화에 대응하기

프로젝트 관리의 철십자Iron Cross. 좋음, 빠름, 저렴함, 완성. 이 중 셋만 고를 수 있다. 네 번째 것은 가질 수 없다.

• 마치 CAP theorem을 보는 느낌. 정말 깔끔한 정리. 이렇게 정리하는 능력이 있어야 이 정도로 업계를 선도할 수 있는가 감탄했다.

애자일 개발은 가장 먼저 만들어졌고, 가장 유명한 피드백 기반 접근법이다... 데이터 없이는 프로젝트를 관리할 수 없다.

• 정말 중요한 건 차트보다 데이터라는 말의 의미는 알겠지만, 역시 차트도 중요하다. 데이터 시각화라는 분야가 별도로 발전하는 모습을 보면 데이터가 가장 중요하긴 하지만, 전달을 잘 하는 거 역시 매우 중요하다. 어쩌면 더 중요할 수도 있다.

프로젝트의 이름이나 요구 사항이 알려지기 전, 모든 것에 앞서서 전해지는 단 하나의 정보가 있다. 물론 마감 기한이다.

요구 사항은 대단히 유동적이고 절대 확정되지 않는다.

분석이 무엇인가에 대한 최고의 정의는 바로 '분석가가 하는 일'이라는 것이다.

따라잡을 수 없는 프로세스 인플레이션Runaway Process Inflation

반복 주기 전체에 걸쳐 요구 사항 분석, 아키텍처 수립, 설계, 구현 활동이 끊임없이 일어난다.

애자일은 희망 대신 춥고 힘든 현실을 초기부터 끊임없이 보여주는 방법이다.

애자일이 빠르게 나아가는 것이라고 생각하는 사람도 있다. 그렇지 않다. 빠르게 나아가는 것이었던 적은 없다. 애자일은 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다. 최대한 빨리 알아야 상황을 관리할 수 있기 때문이다.

 

빠르게 가는 유일한 방법은 제대로 가는 것이다.

합리적인 조직에서는 데이터가 이긴다.

XP는 애자일의 프로토타입이자, 최고의 대표주자이며, 본질이고, 핵심이다.

가장 바깥은 비즈니스와 관련된 XP의 실천 방법 • 계획 게임planning game • 작은 릴리스 small release • 인수 테스트acceptance test • 전체 팀whole team

실천 방법 • 지속 가능한 속도 sustainable pace • 공동 소유collective ownership • 지속적 통합continuous integration • 메타포 metaphor

기술 실천 방법 • 짝 프로그래밍 pairing • 단순한 설계simple design • 리팩터링refictoring • 테스트 주도 개발test driven development

• 공정과 도구보다 개인과 상호작용 - 전체 팀, 메타포, 공동 소유, 짝 프로그래밍, 지속 가능한 속도

• 포괄적인 문서보다 작동하는 소프트웨어 - 인수 테스트, 테스트 주도 개발, 단순한 설계, 리팩터링, 지속적 통합

• 계약 협상보다 고객과의 협력 - 작은 릴리스, 계획 게임, 인수 테스트, 메타포

• 계획을 따르기보다 변화에 대응하기 - 작은 릴리스, 계획 게임, 지속 가능한 속도, 테스트 주도 개발, 리팩터링, 인수 테스트

2장 왜 애자일인가

바뀌는 요구 사항 때문에 당신 아키텍처가 망가진다면, 당신 아키텍처가 엉망인 거다.

변경에 대한 두려움

대신할 동료를 한 명 이상 확보하는 것은 여러분의 책임이다.

개발자는 명확하게 정의된 우선순위와 함께 무엇이 필요한지를 알 권리가 있다.

개발자는 담당 업무를 할당받는 게 아니라 수락할 권리가 있다.

수락할 권리에는 비용이 따른다. 수락은 책임을 뜻한다. 일단 수락했다면, 업무의 품질과 실행에 책임을 져야 한다.

3장 비즈니스 실천 방법

추정은 추측이다. 프로젝트를 실제로 완성하지는 않고 프로젝트가 대략 얼마나 걸릴지 알고 싶은 것이다. 추정에는 비용이 적게 들어야 한다. 따라서 추정이란 본질적으로 엉성하다. 정밀도를 낮추어 엉성하게 추정해야 빨리 추정할 수 있다. 더 엉성하게 추정할수록, 추정에 걸리는 시간이 더 줄어든다.

하지만 추정이 불확실해야 한다는 말은 아니다. 추정은 가능한 한 확실해야 한다. 하지만 추정 비용을 낮게 유지하려면, 필요한 만큼만 정밀해야 한다.

 

 

INVEST

• I: 독립적인 Independent. 사용자 스토리는 서로 독립적이다. 스토리를 어떤 순서로 구현해도 상관없다는 말이다.

• N: 협상할 수 있는 Negotiable. 이것이 세부 사항을 전부 쓰지 않는 또 다른 이유다. 개발자와 사업 부서가 세부 사항을 협상할 수 있어야 한다.

• V: 가치 있는 Valuable. 스토리는 명확하고 계량할 수 있는 비즈니스 가치가 있어야 한다.

• E: 추정할 수 있는 Estimable. 사용자 스토리는 개발자가 작업량을 추정할 수 있을 정도로 구체적이어야 한다.

• S. 작은 Small. 사용자 스토리는 개발자 한두 명이 반복 주기 한 번 이내에 구현하기 힘들 정도로 크면 안 된다.

• T: 테스트할 수 있는 Testable. 사업 부서가 스토리 완료를 증명하는 테스트를제시할 수 있어야 한다.

지속적 배포라고 하면, 오직 배포 주기만 줄이면 된다고 오해할 수 있는데, 그렇지 않다. 우리는 모든 주기를 줄여야 한다.

 

기반이 되는 발상은 엄청나게 단순하다. '사업 부서가 요구 사항을 명시해야 한다'

4장 팀 실천 방법

 

스탠드업 미팅

1. 지난 스탠드업 미팅 이후 무엇을 했는가?
2. 다음 스탠드업 미팅까지 무엇을 할 것인가?
3. 어떤 장애물이 있는가?

• 누구에게 감사하고 싶은가?

5장 기술 실천 방법

기술 실천 방법이야말로 애자일의 진짜 핵심이기 때문이다. TDD와 리팩터링, 단순한 설계, 심지어 짝 프로그래밍도 없다면, 애자일은 원래 의도와는 달리 쓸모없는 빈 껍데기가 되고 만다.

 

켄트 벡이 세운 단순한 설계Simple Design의 규칙은 다음과 같다.

1. 모든 테스트를 통과할 것
2. 의도를 드러낼 것
3. 중복을 없앨 것
4. 구성 요소를 줄일 것

규칙의 순서는 실행하는 순서이면서 동시에 중요한 순서이기도 하다.

설계가 복잡해질수록 프로그래머가 느끼는 인지 부하cognitive load는 늘어난다. 이 인지 부하가 설계 무게다. 설계가 무거울수록 시스템을 이해하고 수정하기 위해 프로그래머가 들이는 시간과 노력은 늘어난다.

6장 애자일해지기

 

켄트 벡은 오래전 애자일의 네 가지 가치를 선언했다. 바로 용기, 소통, 피드백, 단순함이다.

용기: 높은 품질과 수준 높은 규칙을 지켜야 속도가 빨라질 것이라는 믿음은 용기 있는 믿음이다.

피드백: 모든 애자일 규칙은 중요한 결정을 내리는 사람에게 빠른 피드백을 제공하는 데 초점이 맞춰져 있다.

비애자일 조직을 애자일 조직으로 전환할 수 있을까? 솔직히, 이런 상황에서 성공해 본 경험도 많지 않고, 다른 사람이 성공한 사례도 별로 보지 못했다.

• '애자일' 대신 '개발'이라고 써도 별로 다르지 않다

 

 

큰 팀은 이미 해결된 문제다.

소프트웨어 개발과 비슷한 일은 거의 없다. 소프트웨어의 비용/이득과 위험/보상 트레이드 오프는 그 어떤 종류의 일과도 다르다. 소프트웨어는 건축과 같다. 물리적으로는 아무것도 생기지 않는다는 점만 빼고, 소프트웨어는 수학과 같다. 아무것도 증명할 수 없다는 점만 빼고, 소프트웨어는 과학과 같이 실제적이지만, 발견할 물리학 법칙이 없다. 소프트웨어는 회계와 같다. 숫자로 이루어진 사실 대신 시간에 따른 동작을 서술한다는 점만 빼고.

큰 팀의 문제는 어떻게 수많은 다양한 종류의 팀이 협업할 수 있게 만드느냐이기 때문이다. 애자일팀은 큰 프로젝트에서 조율해야 할 무수히 많은 종류의 팀 중 하나일 뿐이다. 다양한 팀을 통합하는 것은 이미 해결된 문제다. 소프트웨어팀의 독특함이 소프트웨어팀을 더 큰 팀으로 통합하는 데 매우 큰 영향을 준다는 증거는 본 적이 없다.

대규모 애자일이란 것은 없다. 애자일은 작은 소프트웨어팀을 조직하는 데 필요한 혁신이었다. 하지만 그 후에는 이 팀들을 수천 년 동안 큰 조직이 사용해 온 구조에 맞추면 된다.

 

소프트웨어 개발자는 반드시 몇 가지 핵심 도구에 능숙해져야 한다.

• 최소 한 가지의 프로그래밍 언어, 대부분의 경우 여러 언어

• 통합 개발 환경이나 프로그래밍용 편집기(빔, 이맥스Emacs 등)

• 다양한 데이터 형식(JSON, XML, YAML 등)과 HTML 등의 마크업 언어

• 운영 체제의 명령 줄 및 스크립트 기반 대화형 인터페이스

• 소스 코드 저장소 도구(깃Git. 다른 대안이 있나?).

• 지속적 통합/빌드 도구(젠킨스Jenkins, 팀시티 TeamCity, GOCD 등).

• 배포/서버 관리 도구(도커pocker, 쿠버네티스Kubenetes, 앤서블 Ansible, 셰프 Chef, 퍼핏 Puppet 등)

• 의사소통 도구(이메일, 슬랙slack, 국어)

• 테스트 도구(단위 테스트 프레임워크, 큐컴버cucumber, 셀레늄selenium 등)

여기까지가 소프트웨어를 만들 때 꼭 필요한 종류의 도구들이다. 요즘 세상에서는 여기서 하나만 빠져도 무언가 만드는 것이 불가능하다. 그런 의미에서 프로그래머 도구 상자에 들어 있는 '간단한 도구'에 해당한다고 볼 수 있다.

훌륭한 도구는 다음과 같은 특징이 있다.

• 사람들이 원하는 일을 성취하도록 돕는다.

• 금방 '충분히 잘 배울 수 있다.

• 사용법이 명료해서 도구에 신경 쓰지 않고 쓸 수 있게 된다.

• 주어진 요구 사항에 쉽게 적응adaptation한다. 원래 의도하지 않은 용도로 사용되는 확장적응exaptation도 한다.

• 가격이 적절하다.

변화를 이끌어 내는 계획을 세울 때 잊지 말아야 할 진리가 있다. 사람은 자신이 원하는 일만 한다는 것이다. 변화를 지속하려면 다음과 같이 해야 한다. 먼저 사람들이 알고 있고 노력을 기울일 생각이 있는 문제나 기회를 찾고, 그들이 요청하거나 필요로 할 때만 조언을 하면서, 목표를 달성하도록 도와야 한다. 다른 방식은 모두 실패한다. 코치는 사람들이 맹점을 발견하도록, 발전을 가로막는 잠재된 생각을 드러내도록 돕는다. 단순히 해결책을 던져 주는 것이 아니라 각자의 과제를 해결하고 자신의 목표를 달성하도록 돕는 것이다.

7장 장인 정신

사람들끼리 함께 일하는 방식을 고치면 엔지니어링도 개선될 것이라는 가정은 완전히 틀렸다.

협업이 원활하게 이루어지면 일을 할 때 장애물이 다소 줄어들기는 하지만, 사람들에게 없던 기술을 만들어 주지는 않는다.

요즈음 대부분의 애자일 코치는 기술 실천방법을 가르칠 만한 기술 역량이 아예 없거나 부족하다. 그래서 엔지니어링 이야기는 거의 꺼내지도 않는다. 이런 상태가 계속되면서 개발자는 애자일 코치를 또 하나의 관리층으로 여기게 되었다. 일을 더 잘할 수 있게 도와주는 사람이 아니라 그냥 일을 시키는 사람으로 보는 것이다.

 

소프트웨어 장인 정신Software Craftsmanship

• 작동하는 소프트웨어뿐 아니라, 잘 만들어진 소프트웨어
• 변화에 대응할 뿐 아니라, 꾸준히 가치를 더하기
• 개인과 상호작용뿐 아니라, 전문가 커뮤니티
• 고객과의 협력뿐 아니라, 생산적인 동반 관계

왼쪽에 있는 것을 추구하다 보면, 오른쪽에 있는 것이 필요해진다는 것이다.

• Manifesto for Software Craftsmanship

짐 하이스미스 “실천 방법이 없는 원칙은 빈 껍데기다. 원칙 없는 실천 방법은 단순히 주어진 절차를 생각 없이 암기하는 것밖에 되지 않는다. 원칙은 실천 방법을 안내하고, 실천 방법은 원칙을 구체화한다. 둘은 늘 함께 가야 한다." 방법론과 실천 사항은 목적을 이루기 위한 도구일 뿐이기는 하지만, 하찮게 보아서는 안 된다. 전문가는 그 사람이 일하는 방식으로 정의할 수 있다. 우리가 일하는 방식, 즉 방법이나 실천 사항이 원칙이나 가치와 맞지 않는다면, 우리는 그런 원칙과 가치를 지키고 있다고 말할 수 없다. 훌륭한 전문가는 주어진 환경에서 어떻게 일하는지 정확하게 설명할 수 있다. 그리고 다양한 실천 방법을 익혀서 필요에 따라 적절하게 사용할 수 있다.

8장 결론