클린 애자일 - 첫 마음으로 돌아가보는 여정

Photo by David Travis on Unsplash

 

클린 애자일 국내도서 저자 : 로버트 C. 마틴(Robert C. Martin) / 정지용역 출판 : 인사이트 2020.12.01 상세보기

밥 아저씨, 로버트 마틴이 잊혀지고 왜곡되어 가는 애자일의 정신을, 첫 마음으로 돌아가 차근히 정리해주는 책이다.

이리 저리 읽고 주워들은 애자일과 관련한 지식들을, 이제 한 번쯤 전체적인 시각으로 조망해보고 싶은 마음으로 읽었고, 그 목적에 부족함이 없는 책이었다. 덧붙여 번역이 참 차분하게 잘 되었다는 느낌을 받았다.

 

몇 편의 포스팅으로 나누어 책의 주요 부분을 정리하고 인상적인 문장을 가져와 본다. 이번 포스팅은 1, 2장을 정리하였다. 

 

지은이의 글

 

로버트 마틴이 바라보는 개발 프로세스 역사의 큰 흐름은 이렇다.

 

1. 1950-60년대 태동기에는 프로그래머들이 프로그래밍이란 작은 일들을 작은 팀이 하는거라는 걸 알고 있었다. 큰 프로젝트는? 작은 일들을 하는 작은 팀들이 협동해서 하는 것

2. 1970년대가 되면서 이런 지혜를 가진 사람들이 미처 지혜를 전달하기 전에 은퇴하고, 프로그래머 수가 수십 만명으로 폭발하면서 단절되었다.

3. 1990년대 중반이 지나면서 옛 지혜를 알아차리는 사람들이 늘어나고, 때가 무르익어 애자일 선언이 나오게 되었다.

4. 이후 애자일이 널리 퍼지게 되었지만 처음의 정신이 흐려지고, 뒤죽박죽이 되어버린 부분이 있다. 그래서 이 책을 낸다.

 

1장 애자일 소개

 

애자일 소프트웨어 개발 선언 부터 읽어보자.

애자일 소프트웨어 개발 선언   우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다   공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를   가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

 

애자일은 데이터를 제공해서 프로젝트 관리를 도운다.

 

"(팀의 개발 속도 차트 + 번다운 차트) 이 두 차트를 벽에 거는 것이 애자일의 중요한 목표다. 관리자가 철십자의 네 가지 축의 가중치를 얼마로 할지 결정해야 할 때, 결정에 필요한 데이터를 제공함으로써 관리자가 프로젝트를 최선의 결과로 이끌도록 한다. 이것이 애자일 소프트웨어 개발의 중요한 강점이다." 26p

 

철십자란 좋고, 빠르고, 저렴하고, 완성된 소프트웨어라는 네 가지 목표중 적어도 하나는 만족할 수 없다는 것을 의미한다. 애자일로 프로젝트를 진행하면 빠르고 주기적이며, 제대로 된 데이터를 얻게 되어서 프로젝트를 위해 무엇을 포기해야 할지 알게 된다는 것이다.

 

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

 

아래는 eXtreme Programming 의 실천방법(practice)를 설명하는 론 제프리스의, Circle of Life 라는 별명을 가진, 그림이다.

 

 

<이미지 출처: https://blog.ynkb.xyz/89/ >

 

- 가장 바깥은 비즈니스 관련 XP 실천방법: 계획 게임, 작은 릴리즈, 인수 테스트, 전체 팀

- 중간은 팀 관련 XP 실천방법: 지속 가능한 속도, 공동 소유, 지속적 통합, 메타포

- 안쪽은 기술적 XP 실천방법: 짝 프로그래밍, 단순한 설계, 리팩터링, 테스트 주도 개발

 

이 책의 3, 4, 5장에서 이 세 범주의 실천방법을 챙겨본다.

 

2장. 왜 애자일인가

 

"애자일 개발이 중요한 것은 더 깊은 철학적, 윤리적 이유 때문이다. 바로 직업의식과 고객의 당연한 기대 때문이다." 42p

"소프트웨어 업계는 직업의식을 정말 많이 높여야 한다. 우리는 너무 자주 실패한다. 너무나 형편없는 제품을 출시한다. 너무 많은 결함을 용인한다. 끔찍한 타협을 한다." 43p

 

밥 아저씨는 2장의 시작부터 가혹하게 이야기한다. 솔직히 말해서 개발자들은 다른 업종에 비해서 실패에 너무 관대하다며 좀 더 제대로 해야 한다고 말한다. 아래는 그 세부적인 기준들이다. 이 기준들에 대해서는 3, 4, 5장으로 가며 세부적인 이야기를 한다. 

 

"시스템은 각 반복주기가 끝날 때마다 기술적으로 배포 가능해야 한다. (중략) 즉, 반복 주기 동안 스토리를 구현한다는 것은 스토리의 모든 코딩과 모든 테스트와 모든 문서와 모든 안정화를 다 끝낸다는 것이다." 51p

 

"고객이나 관리자는 소프트웨어팀이 점점 느려질 것이라 생각하지 않는다. (중략) 개발자도 똑같이 생각해야 한다. 아키텍처, 설계, 코드를 가능한 한 계속해서 깨끗하게 관리하여 생산성을 높게 유지해야 한다." 55p

 

"바뀌는 요구 사항 때문에 당신 아키텍처가 망가진다면, 당신 아키텍처가 엉망인 거다. (중략) 변화무쌍한 요구 사항이 우리 일의 핵심이다." 55p

 

"소프트웨어 시스템의 설계와 아키텍처는 시간이 갈수록 더 좋아져야 한다." 56p

 

"소프트웨어팀의 구성원들은 필요할 때 서로를 대신해야 한다. (중략) 지식을 공유해야 한다." 61p

 

고객과 개발자의 권리 장전 (Bill of Rights)

책에서 다루는 권리 장전이라는 부분이 크게 와 닿았다. 개발자로서 우리는 고객의 권리를 프로답게, 책임있게 보장해주어야 한다. 마찬가지로 개발자로서 우리 자신의 권리를 당당하게 요구해야 한다.

 

원문 링크: https://www.informit.com/articles/article.aspx?p=2990402&seqNum=3

 

 

Customer Bill of Rights

 

You have the right to an overall plan and to know what can be accomplished when and at what cost.

- 고객은 무엇이, 언제, 얼마의 비용으로 완성될지 알 권리가 있다.

 

You have the right to get the most possible value out of every iteration.

- 고객은 매 반복주기마다 가능한 최선의 가치를 얻어낼 권리가 있다.

 

You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify.

- 고객은 고객이 명시한 테스트를 통과한, 그래서 동작이 검증된 시스템에서의 진행사항을 볼 권리가 있다.

 

You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs.

- 고객은 추가 비용 없이도 마음을 바꿔서 기능을 대체하거나, 우선순위를 바꿀 권리가 있다.

 

You have the right to be informed of schedule and estimate changes, in time to choose how to reduce the scope to meet a required date.

- 고객은 일정의 추정과 변경사항을 알 권리가 있다. 그래야 일정을 맞추기 위한 선택을 할 수 있다.

 

You can cancel at any time and be left with a useful working system reflecting investment to date.

- 고객은 언제든 개발을 멈추게 할 수 있고, 그때까지의 동작하는 결과물을 받을 수 있다.

 

Developer Bill of Rights

 

You have the right to know what is needed with clear declarations of priority.

- 개발자는 요구사항과 우선순위를 알 권리가 있다. 반복주기 내에서는 (거의) 변경되지 않아야 한다.

 

You have the right to produce high-quality work at all times.

- 개발자는 최고의 품질을 추구할 권리가 있다. 이것은 직업 윤리이다.

 

You have the right to ask for and receive help from peers, managers, and customers.

- 개발자는 동료, 매니저, 고객에게 도움을 요청하고, 도움을 받을 권리가 있다.

 

You have the right to make and update your own estimates.

- 개발자는 업무를 추정하고, 그 추정을 업데이트할 권리가 있다.

 

You have the right to accept your responsibilities instead of having them assigned to you.

- 개발자는 책임을 받아들일 권리가 있다. 누군가가 개발자에게 할당하는 것이 아니다.

 

애자일은 무엇일까?

"애자일은 프로세스가 아니다. 애자일은 지나가는 유행이 아니다. 애자일은 단순히 규칙을 모아놓은 것이 아니다."

"윤리적인 직업의 기반을 이루는 권리, 기대, 규율을 한데 모은 것이 애자일이다." 69p

 

이제, 3, 4, 5 장을 통해 XP의 실천 방법을 둘러볼 것이다. 많은 애자일 프로세스 중에서 왜 XP인가?

 

"모든 애자일 프로세스 중에서 XP가 가장 잘 정의되어 있고, 가장 완전하며, 가장 덜 혼란스럽기 때문이다." 37p