클린 애자일 다시 읽기 - 1장 애자일 소개

 

출처: https://www.wikiwand.com/en/articles/Robert_C._Martin

 

개요

2021년에 클린 애자일을 읽었었는데(당시 블로그), 최근에 사내 스터디를 하며 다시 읽으며 정리를 해둔다. 1장 애자일 소개를 시작하며, 다음 애자일 소프트웨어 개발 선언과 12가지 원칙을 읽어보자. 그리고, 그 의미를 생각해보고 이야기 나누어보자.

애자일 소프트웨어 개발 선언

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고있다.

이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

1. 공정과 도구보다 개인과 상호작용을
2. 포괄적인 문서보다 작동하는 소프트웨어를
3. 계약 협상보다 고객과의 협력을
4. 계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다.

이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

애자일 소프트웨어의 12가지 원칙

우리는 다음 원칙을 따른다:

1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
3. 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
7. 작동하는 소프트웨어가 진척의 주된 척도이다.
8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
10. 단순성이 - 안 하는 일의 양을 최대화하는 기술이 - 필수적이다.
11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

지은이의 글

애자일은 작은 일을 하는 작은 프로그래밍팀이 겪는 작은 문제에 대한 작은 아이디어다. -xiv

그 후로 30년 동안 우리는 큰 팀으로 큰 일을 해야 한다는 생각 속에서 헤맸다. -xv

큰 일은 작은 일을 하는 많은 작은 팀이 협동함으로써 이룰 수 있다는 것을 다시 한 번 깨달아야 했다. -xv

 

요약하자면 다음과 같다.

• 프로그래밍 태동기에는 작은 문제를 작은 팀이 풀어가는 방법을 알았었는데
• 큰 문제는 큰 팀이 해야한다는 잘못된 생각으로 오랜동안 헤매었다.
• 큰 문제는 작은 문제들로 나누고 이를 작은 팀이 풀어나가야 한다.

1장 애자일 소개

엉클 밥이 이 책을 쓰게된 이유

불행하게도 어떤 운동이 인기를 얻으면, 오해나 잘못된 사용 때문에 운동의 이름이 퇴색하기 마련이다. (중략) 스노버드 회의가 열린 이후 거의 20년 만에 오해를 바로잡기 위해 이 책을 쓴다. -p2, 3

소프트웨어 방법론

초기 소프트웨어 방법론

• 과학적 관리법Scientific Management
• 폭포수 관리법Waterfall
  • 분석 → 설계 → 구현

애자일의 탄생

• 이건 아니다 싶은 사람들이 많아지고, 이렇게 하면 어떨까하는 방법론들이 하나 둘 생겨나고
• 그러한 17명의 중년 백인 남성이 솔트레이크 시티 근처의 스키 리조트 스노버드에 모였다.
• 그리고 그 사람들이 이렇게 개발해야 한다는 선언문을 작성하고 이후에 연락하며 원칙들도 정리하였다.

철십자

프로젝트 관리의 철십자(Iron Cross) : 소프트웨어 프로젝트의 근본 물리법칙으로, 다음 네 가지를 모두 만족하도록 관리할 수는 없다는 것이다.

• 좋은 결과물이 나오도록 진행한다.
• 빨리 진행한다.
• 저렴하게 진행한다.
• 완성도가 높게 진행한다.

철십자에 애자일을 끼얹는다면?

좋은 관리자는 네 가지 속성의 가중치를 관리하지, 모든 속성이 100%가 되기를 요구하지 않는다. (중략) 애자일은 개발자와 관리자가 프로젝트를 이렇게 실용적으로 관리할 수 있도록 돕는 체계다. -p18

 

애자일은 데이터를 제공해서 돕는다.

• 속도 차트velocity chart로 팀의 업무 처리 속도를 시각화하고
• 번다운 차트burndown chart로 다음 마일스톤 까지의 남은 포인트를 보여준다.

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

삶의 순환(Circle of Life)

eXtream Programing의 실천 방법이다. 론 제프리스의 그림이며 삶의 순환이라고도 부른다.

출처: https://www.linkedin.com/pulse/xp-circle-life-toby-v-rao-m32mc/

애자일이 정말로 무엇인지 이해하고 싶다면 XP를 공부하는 것이 최선의 방법이다. XP는 애자일의 프로토타입이자, 최고의 대표주자이며, 본질이고, 핵심이다. -p37

 

정현석 생각

• 각 고리들이 엄밀하게 구분된다 생각하지 않는다. 대표적으로는 메타포가 있다.
• 이들을 절대적 가치, 도그마로 생각하지 말자. 우리가 우리 조직에 맞는 새로운 방법을 찾아낼 수도 있다.
• 하나씩 곰곰이 생각하며 읽어보자.

바깥 고리 - 비즈니스와 관련한 XP의 실천 방법

개발팀과 사업부서간의 의사소통, 관리 원칙

• 계획 게임: 프로젝트를 쪼개서 크기를 추정하고, 우선순위를 정한다.
• 작은 릴리스: 작게 자주 릴리스한다.
• 인수 테스트: 완료를 정의한다.
• 전체 팀: 같은 목표를 향해 함께 일한다.

중간 고리 - 팀과 관련한 실천 방법

개발팀의 관리와 의사소통의 체계와 원칙

• 지속 가능한 속도: 우리는 마라톤을 하고있다.
• 공동 소유: 지식이 모두에게 퍼져야 한다.
• 지속적 통합: 피드백이 자주 반복되도록 한다.
• 메타포: DDD의 유비쿼터스 언어

안쪽 고리 - 기술 실천 방법

높은 품질을 유지하도록 이끌고 강제하기

• 짝 프로그래밍: 지식 공유, 리뷰, 협력
• 단순한 설계: 이해하기 쉽다. 수정하기 쉽다. 꼭 필요한 만큼만 구현한다.
• 리팩터링: 지속적으로 개선하고 향상한다.
• 테스트 주도 개발: 품질을 유지하면서도 속도를 낼 수 있다.

애자일 선언과 삶의 순환

1. 공정과 도구보다 개인과 상호작용을
   1. 전체 팀
   2. 메타포
   3. 공동 소유
   4. 짝 프로그래밍
   5. 지속 가능한 속도
2. 포괄적인 문서보다 작동하는 소프트웨어를
   1. 인수테스트
   2. 테스트 주도 개발
   3. 단순한 설계
   4. 리팩터링
   5. 지속적 통합
3. 계약 협상보다 고객과의 협력을
   1. 작은 릴리스
   2. 계획 게임
   3. 인수 테스트
   4. 메타포
4. 계획을 따르기보다 변화에 대응하기를
   1. 작은 릴리스
   2. 계획 게임
   3. 지속 가능한 속도
   4. 테스트 주도 개발
   5. 리팩터링
   6. 인수 테스트