클린 애자일 / 카이젠 저니

클린 애자일은 회사에서 스터디하면서 읽었고

 

 

카이젠 저니는 데뷰 세션 주먹구구 게 섯거라 K-Agile이 나가신다 (우리에게 딱 맞춘 애자일로 함께 팀을 개선한 이야기) 에서

발표자님이 추천해주셔서 읽게 되었습니다.

(소설이라 엄청 재밌을 것이라고 기대를 많이 해서 그런지,,, 별로 재미 없어서 후루룩 읽었습니다,,)

 

 

두 책을 읽으면서 애자일에 대해서 배운 것들 중 기억하고 싶은 것을 기록합니다. ✏️

 

[1] 애자일 (Agile) 이란?

 

Agile은 기민한, 민첩한 이라는 뜻을 가지고 있는 단어 입니다.

'작게 시도하고, 실패하고, 학습하고, 개선함으로써' 기민함을 확보하는 것이 애자일의 지향점입니다.

 

 

[2] 소프트웨어에서 애자일 

 

과학적 관리법

- 철저하게 분석하고 그에 따라 상세한 계획을 만들기 전까지는 행동을 미루는 방법

- 변경비용이 많이 드는 프로젝트에서 잘 동작한다. 목표가 극도로 명확한 매우 상세하게 정의된 문제를 잘 푼다.

- 폭포수(waterfall) 모델이 여기 속한다. 폭포수모델이 1970년 이후로 산업을 지배했다. (소프트웨어쪽도)

 

소프트웨어 프로젝트라는 것이 어떤 종류의 프로젝트인가를 생각해봐야합니다. 

 

소프트웨어(software) 는 합성어 입니다.

- soft = 바꾸기 쉽다

- ware = 제품(product)

 

즉 소프트웨어는 바꾸기 쉬운 제품입니다.

이름부터가 바꾸기 쉬운 제품인데 위의 과학적 관리법으로 관리하는게 당연히 좋은 방법이 아니겠죠...?!?

 

그래서 2001년 컴퓨터쪽 거장(?)분들이 모여 애자일 선언을 합니다. 

 

https://agilemanifesto.org/iso/ko/manifesto.html

 

애자일은 단순히 여러 방법론의 집합이 아닙니다.

오히려 사고방식과 행동방식에 있어서 어떤 것을 우선순위에 두느냐와 같은 가치의 문제 입니다. 

 

두 책에서 모두 애자일의 여러 방법론 보다 가치를 중요시합니다. 

'클린 애자일'을 쓰신 이유가 방법만 너무 중시되는 등 애자일의 본질이 흐려지고 있는 것 같아서 쓰셨다고 합니다.

'카이젠저니'에서도 상황이나 문맥에 대한 이해없이 애자일 방법론들을 적용하려고만 한다면 실패는 뻔하다 라고 말합니다. 

 

 

[3] 애자일 개발 프로세스 

 

프로젝트 일정을 일정한 크기로 더 작게 나눕니다. 이것을 반복주기라고 합니다.

그리고 맨처음부터 모든 반복주기에 분석, 설계, 구현이 각각 조금씩 들어있습니다.

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

그리고 프로젝트 관리자는 각 반복주기를 돌며 얻은 데이터(각 반복 주기의 결과물)에 기반하여

일의 범위, 일정, 사람, 품질을 변경할 수 있습니다.

 

 

[4] 애자일 개발 프로세스 종류

 

애자일 개발 프로세스로 불리는 개발 방법론에는 다음과 같은 것들이 있습니다. (출처: 위키)

 

• 익스트림 프로그래밍(Extreme Programming, XP) - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 하였다. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트우선 개발(TDD)을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.

• 스크럼 - 30일마다 동작 가능한 제품을 제공하는 스프린트(Sprint)를 중심으로 하고 있다. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론이다.

• 크리스털 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공한다. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍 만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론이다.

• Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시한다. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가진다.

• Adaptive Software Development, ASD - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. 내용적으로는 다른 방법론들과 유사하지만, 합동 애플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는 것이 조금 다르다.

• 익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론이다. 다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 한다.

위의 애자일 개발 프로세스들은 서로 조합도 가능하다고 합니다.

여러 방법중에서 자신의 프로젝트에 맞는 부분을 취사 선택하여 조합하거나 또는 독자적인 방법을 만들어도 됩니다. 

 

[5]  애자일 개발 프로세스 > 스크럼 

'카이젠 저니' 책에서 주인공 팀은 스크럼을 도입했습니다.

스크럼은 스프린트라고 불리는 반복주기들을 반복하면서 (참고로 주인공 팀은 2주를 스프린트 기간으로 잡았습니다.)

설계, 개발, 테스트, 딜러버리 등을 수행하는 프로세스를 의미합니다. 

 

스크럼은 회고를 통해 개선해 나가는 경험주의를 기반으로 합니다.

여기서 경험주의란, 경험을 통한 학습을 중시하고 불확실한 상황에서도 혁신적인 일을 추진해 나가는 사고방식입니다.

이전 단계의 산출물을 기반으로 하기 때문에 앞 단계로 되돌리기 어려운 폭포수 접근 방식과는 크게 다릅니다. 

 

 

 

스크럼은 구체적으로 다섯가지 이벤트로 구성됩니다.

 

 

 

그리고 이런 스프린트 보드가 있습니다. 

우선 순위를 정하지 않고 일단 모아두는 장소로 ice box, parking lot 이라는 용어를 사용한다고 합니다. 

 

 

 

[6] 애자일 개발 프로세스 >  XP 

 

'클린 애자일' 에서는 

XP의 실천방법을 소개합니다.

 

 

'클린 애자일'의 저자는 

"기술 실천 방법이 애자일의 진짜 핵심이다. TDD, 리팩터링, 단순한 설계, 짝프로그래밍 이 없다면 애자일은 빈 껍데기가 되어버린다" 라고 말씀하셨는데,

 

그래서 명시적인 기술 실천 방법을 주장하는 XP를 선택해서 설명하신 것 같아요 :-) 

 

XP의 여러 요소들 중, TDD에 대해서 말씀하신 부분이 인상깊었습니다.

TDD를 하면 리팩토링 일정을 따로 잡거나 디버깅을 해야할 필요가 없어진다...!!! 

 

"개발자가 테스트를 쓰는 데 허락을 받으려 해서는 안된다. 단위 테스트나 리팩터링 작업 일정을 따로 잡아서도 안된다. 

이런 기술적인 작업은 기능 개발 과정에서 이미 이루어졌어야한다. 선택이 아니라 필수적인 작업이기 때문이다."

 

 

[7] 애자일과 소프트웨어 장신 정신

 

위에서 말한 것 처럼 애자일의 핵심은 기술 실천 방법입니다.

하지만 애자일이 엔지니어링은 등한시하고 프로세스에만 너무 집중한다면서 애자일 운동을 비판하는 사람들이 있다고 합니다.

그래서 소프트웨어 장신 정신 운동을 만드셨다고 합니다. 

 

애자일의 가치와 소프트웨어 장인정신의 가치는 동일한 목표를 가지고 있고 분리되어서는 안됩니다. 

 

사업이 애자일해지려면 필요한 것이 원활한 협력과 반복하는 프로세스 만이 아니라 좋은 엔지니어링 기술도 있어야 합니다.

애자일과 장인정신은 같이 가야합니다.

 

 

[8] 그 외 좋았던 부분

 

1) 처음 애자일을 도입할 때

 

'클린 애자일' 에서 중간관리자가 애자일을 도입하는 것을 싫어한다고 하는 상황에서

중간관리자와의 무의미한 싸움을 하기보다는 애자일 위에 층을 한 겹 더 놓아서 애자일이 안전하고 중간 관리자의 생각에 부합하는 것 처럼 보이게 하라는 것이 좋았다.

 

" 어떤 소프트웨어 개발 팀은 조용히 애자일 가치를 적용하며 개발을 진행했다. 그러면서도 중간 관리자가 부여하는 엄격한 요구사항을 맞추어냈다. 중간관리자는 자신이 요구하는 절차와 기준만 잘 지켜진다면, 개발팀이 개발팀의 도구를 사용하도록 내버려 둘 수 도 있다. "

 

지혜롭다...!!

 

 

그리고  '카이젠 저니'에서 주인공은 외부 세미나에서 애자일을 듣고 와서 혼자 변화를 시도한다.

근데 화이트보드와 포스트잇 이라는 물리적인 도구를 이용한다.

화이트보드에 TODO, DOING, DONE 을 구분해놓고 포스트잇을 옮겨가면서 일했다. 

 

주인공의 책상에서 화이트보드를 본 동료가 관심을 가지고 같이하고 싶다고 해서

1명은 2명이 되었다. (물론 주인공은 의도하고 한 것은 아니다,,) 

 

팀에 도입하기 전, 물리적인 도구로 관심을 끄는게 좋은 것 같다..!! 

 

 

2) Five Finger 

파이브 핑거는 스프린트나 업무의 현재 상황을 어떻게 생각하는 지 다섯 손가락으로 표현한다.

 

- 5개: 정말 잘되고 있다

- 4개: 잘되고 있는 것 같다

- 3개: 잘되는 것도 그렇지 않은 것도 아니다

- 2개: 약간 불안하다

- 1개: 절망적이다

 

그리고 핵심은 가장 적은 손가락을 편 멤버의 의견부터 먼저 들어보는 것..!

점수가 높은 사람의 의견을 먼저 들으면 부정적인 이야기를 꺼내가 어려워지기 때문.

 

 

3) 몹 프로그래밍

 

 

<몹프로그래밍의 장점>

 

- 여러 명의 뇌를 한번에 사용함으로써 중복 체크, 삼차 체크가 순식간에 일어난다. 모두 함께 봄으로써 품질은 높아지고 효율은 좋아진다.

- 과정이나 결과의 공유가 '항상' 일어남

- '너 대 나' 가 아니라 '문제 대 우리' 구도가 되기때문에 팀워크가 살아난다. 

- 학습효과 (코드 뿐만아니라 단축키, 편집 도구 사용법, 코드 작성하는 순서 등도 배우게 된다)

- 달성감, 재미