Insight? Practice!

Road to myself. 자기자신에게로 이르는 길.

[책] 애자일 마스터

애자일 마스터. 원제는 The Agile Samurai

Xper 모임에서 알게된 책이다. 미리 알았더라면 베타리딩에 참여했을텐데 아쉬움이 남는다.

애자일을 처음 접하는 사람에게 단 1권의 책만 소개해야 한다면 주저없이 이 책을 골라야겠다. 애자일 입문서로서 충분히 좋은 책.

번역서라는 생각이 들지 않을 만큼 번역도 잘되었을뿐더러 이해를 도와주는 귀여운 그림도 많아서 좋다. 편한마음으로 읽으면서 사무라이 스승님과 대화하다보면 어느새 머리속에는 애자일 선언문이 정리된다.

책 마지막즈음의 말들이 주옥같다.

애자일 프로젝트로 안내해 줄 지도같은건 없다. 여러분 스스로 여러분의 팀과 프로젝트에 맞는 최고의 방법이 무엇인지 알아내야 한다.

누구를 설득하려고 하지 말자. 다른 사람들에게 그들이 무슨일을 해야 한다고도 말하지 말자. 그 대신, 행동을 보여주자. 다른 사람들이 항상 보고 있지는 않겠지만, 그저 여러분이 해야할 일을 해나가는 것이다.

애자일은 여행의 과정이지 목적지가 아니다. 애자일화 되는 것이 목적이 아니라 훌륭한 제품을 개발해서 고객에게 최상의 서비스를 제공하는 것이 목적이라는 것을 꼭 기억하도록 하자.

실천법에 너무 목매지 말자. 여러분만의 상황과 맥락에 적합하게 적용하기 바란다. 그러다가도 여러분이 과연 애자일을 잘 실천하고 있는지 궁금해진다면 다음의 두 가지 질문을 스스로에게 해보자.
우리는 매주 가치 있는 것을 고객에게 인도하는가?
우리는 계속 발전하기 위해 노력하고 있는가?

만약 이 질문에 네라고 대답할 수 있다면, 여러분은 애자일을 하고 있는 것이다.

요즘 팀에 애자일을 적용하다보니 찔리는 말이 많다. 특히 실천법에 너무 목맨다는 말이 가장 찔린다. 내공도 부족하고 경험도 부족하기 때문이리라. 꾸준히 부딪히는 수밖에 없을듯 하다.

특히 같은 말이라도 상대방이 기분나쁘지 않게 말하는 능력은 참 갖고 싶다는 생각이 든다.

애자일 실천법에 대한 간단한 설명들도 좋았다.

다음은 읽으면서 정리한 내용.

책 본문에는 귀여운 그림이 많아서 이해도가 훨씬 높아지니 꼭 책을 보시길 ^^

1장. 애자일의 핵심


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


2장. 애자일 팀 만나기


팀원 각각의 역할을 미리 정의하지 않는다. 누구나 무슨 일이든 할 수 있다. 그런데 신기하게도 이처럼 혼란스럽고 체계적이지 않은 것 같은 틀 속에서 높은 품질의 소프트웨어가 끊임없이 생산된다.

같은 공간에서 일하기, 참여하는 고객, 자기조직화, 책임감과 자율성, 교차기능팀

애자일 고객, 개발팀, 애자일 애널리스트, 애자일 개발자, 애자일 테스터, 애자일 프로젝트 관리자, 애자일 UX 디자이너


3장. 모두 한 버스에 타는 법


인셉션 덱은 프로젝트와 관련이 있는 사람들을 모아, 모든 사람들이 프로젝트에 기대하는 바가 동일하도록 서로 적절한 질문을 통해 생각을 공유한다면 프로젝트가 성공할 확률이 높을 것이다라는 아이디어에서 시작되었다.


4장. 크게 보기


질문하라. 우리는 왜 여기 모였나요?
엘리베이터 피치 만들기
제품 광고를 직접 디자인해보자
NOT 리스트를 작성하라
프로젝트와 관련된 다양한 사람들과 만나라


5장. 실현 방안


리스크를 찾아내기. 리스크는 당신이 이미 아는 것이거나 당신이 죽었다 깨어나도 생각지 못한 일, 이 둘 중 하나일 테니까. 그러니 그때그때 리스크가 발생하는 대로 처리하라.

규모가 크고 시간의 제한이 없는 프로젝트의 문제점은 끊임없이 장밋빛 전망을 해놓고 결국 출시하지 못한다는 데에 있다.
정말 큰 프로젝트를 출시하고자 할 때, 작고 다룰 수 있을 만한 크기로 나눠야 한다.
가장 이상적인 기간은 6개월 이내다.

트레이드 오프 슬라이더.

프로젝트를 위협하는 전설의 사총사. (시간, 비용, 품질, 범위)


6장. 사용자 스토리 수집하기.


사용자 스토리는
고객이 자신의 소프트웨어에 원하는 기능을 짧게 표현해 놓은 것.
짧게. 인덱스 카드로. 다 적을 필요가 없음. 자세한건 face to face.
키워드만을 적어놓기. 세부사항은 나중에.
서로간에 대화를 하도록 권장하는 도구 역할.

스토리의 6가지 요소 INVEST
Independent, Negotiable, Valuable, Estimatable, Small, Testable

템플릿. 누구를 위해, 왜 어떤 이유때문에, 무엇을 원한다.


7장. 추정치 정하기.


미래에 대한 정확한 예측은 불가능.

인간에게 어떤 것을 상대적으로 추측하는 능력이 생각보다 훨씬 뛰어나다.

점수기반 시스템을 사용하면 달력에 나타난 시간에 목매지 않아도 된다.

삼각측량
기준으로 삼을 스토리를 몇 개 사용해서 다른 스토리들의 상대적인 크기를 추정하는 것.

플래닝포커
팀원들이 각각 스토리의 추정치를 먼저 정한 후에 결과를 모두와 비교하는 게임.
추정치가 대략 비슷하다면 유지하고 다르다면 논의를 통해 의견이 일치될때까지 다시 추정한다.


8장. 애자일로 계획짜기.


팀의 속도. team velocity
사용자 스토리를 작동하는 소프트웨어로 만드는 속도.

범위에 유연하라.
새로운 스토리를 추가하고도 그만한 크기의 다른 스토리를 포기하지 않으려는 것은 희망사항일 뿐.

1. 마스터 스토리 리스트 작성하기
릴리스.
함께 묶어 전달했을 때 고객에게 가치가 있는 스토리들을 논리적으로 분류해놓은 그룹.
출시할 만한 최소한의 기능을 모아놓은 세트.
MMF. Minimal Marketable Feature set.

2. 크기 정하기.
소프트웨어 기능 중 64%는 사용자가 거의 사용하지 않거나 한 번도 쓰지 않는다.

3. 우선순위 정하기
번개가 언제 칠지는 아무도 모른다. 프로젝트가 취소되거나 기간이 단축된다는 소식이 언제 들려올지는 아무도 모른다는 말이다. 그래서 우리는 항상 중요한 것을 먼저 개발해야 한다.

4. 팀의 업무속도 측정하기

5. 날짜 예상하기

번다운차트, 번업차트.

변화란 항상 존재하는 것이다. 우리는 그저 이를 얼마나 창의적으로 드러내고, 다루어야 할지를 고민해야 할 뿐이다.


9장. 이터레이션 관리: 구현하기


애자일 분석.
필요한 만큼만 분석하라. 언제고 필요하다면 그때마다 살을 붙이면 된다. 불필요한 짐을 많이 갖고 여행하면 발걸음만 늦어진다. 그러니 시작은 가볍게 하고, 필요한 부분은 그때그때 충족해 나가도록 하라.

순서도를 그려보고 페르소나도 활용

스토리가 완성되려면 만족해야하는 조건을 인수 테스트로 작성.

이터레이션0. 작업 환경 준비하기

칸반.
한팀은 오직 정해진 수만큼의 작업만 동시에 수행할 수 있다.


10장. 애자일 커뮤니케이션 계획


스토리 계획회의 - 쇼케이스 - 이터레이션 계획 회의 - 미니회고

“그런데 단위 테스트가 부족하네요” → “그정도의 섬세함을 단위 테스트에도 적용해봐요. 아마 곧 세계 최고가 될 거에요”

일일 스탠드업을 진행할 때 하면 안되는 것
어제 무엇을 했는가 → 세상을 바꾸기 위해 어제 무엇을 했는가
오늘은 무엇을 할 것인가 → 오늘 그 작업을 어떻게 끝낼 것인가
내 작업 속도를 늦추거나 방해하는 요소가 있는가 → 불행히도 지금 내 앞을 가로막고 있는 이 장애물을 어떻게 없앨 것인가


11장. 시각적인 작업환경 조성하기


인셉션 덱, 릴리즈 상황판, 스토리 보드, 팀 속도, 번다운 차트


12장. 단위 테스트: 제대로 작동하는지 확인하기


버그를 고치기전에 실패하는 단위 테스트를 작성하자

자동화되어 실행하기 쉬운 단위 테스트의 가치는 헤아릴 수가 없다. 소프트웨어에 조금이라도 변화가 있을 때마다 이 단위 테스트를 실행해서 새로운 코드가 고장낸 것이 무엇인지 재빨리 확인할 수 있기 때문이다.

단위 테스트를 전쟁에 나가기 전에 입어야 할 갑옷이라고 생각하자.


13장. 리팩터링: 기술적 부채 갚기


기술적 부채란 임기응변, 난도질, 복사해붙이기 같이 우리가 생산성과 일정이라는 미명 아래에 코드에 저질러 놓은 죄악들이 오랫동안 누적된 결과다.

이런 문제들은 한 번에 알아채지 못하게 슬그머니 찾아든다는 사실이 가장 위험하다. 초기 코드에 만들어진 각각의 위반 사항들은 작고 그리 중요하지 않아 보인다. 하지만 대부분의 부채가 그렇듯이 시간이 가면서 누적된 효과는 결국 큰 골칫거리가 되고 만다.

코드를 쓰는 것은 마치 훌륭한 산문을 작성하는 것과 비슷하다. 분명하고 쉽게 이해할 수 있으면서도 의도하는 바가 무엇인지 파악하는데 많은 노력이 필요해서는 안 된다. 리팩터링은 객체 지향 프로그래머들이 바로 그런 목적을 달성하기 위해 사용하는 비밀병기이다.

거의 끝나가는 프로젝트에서 큰 규모의 리팩터링을 하는 것은 별 의미가 없다. 열심히 일한 보상을 받을 시간이 없기 때문이다.

리팩터링을 작은 단위로 자주 해서 한번에 큰 규모의 피랙터링을 할 필요가 없도록 노력하거라.


14장. 테스트 주도 개발


새로운 코드를 쓰기 전에 먼저 새로운 코드로 성취하고자 하는 바가 무엇인지를 보여주는 실패하는 단위 테스트를 작성한다. 바로 이때 개발자들은 설계에 대해 신중하게 생각하게 된다.

규칙1. 실패하는 테스트를 먼저 작성할 때까지 어떤 코드도 새로 쓰지 않는다.
규칙2. 문제가 생길 가능성이 있는 것이라면 무엇이든 반드시 테스트한다.

여러분의 팀이 TDD를 재빨리 받아들이지 않는다고 당황할 필요는 없다. 이는 단위 테스트나 리팩터링보다 한 차원 높은 코딩 기법이니까.


15장. 지속적인 통합: 출시 준비


지속적인 통합이란 개발자가 지속적으로 소프트웨어를 변경하고, 이 변경사항들을 계속해서 통합하는 활동을 말한다.

아무리 좋은 체크인 프로세스와 자동화된 빌드가 있다고 하더라도, 정말 중요한 것은 바로 작은 단위로 작업하려는 마음가짐이다.

언제든 출시할 수 있는 소프트웨어를 준비하자는 태도가 바로 내가 진정 하고자 하는 말이란다. 버그를 발견하면 즉시 고쳐야지, 카펫 밑에 숨겨 놓고 언젠가 고치겠다는 태도는 버리라는 말이다.

걸린시간

추정은 뽀모도로 7번. 실제로는 10번 걸렸다. ( 10번 x 25분 = 약 5시간 )

Comments