애자일
1장
애자일의 탄생은? 선사시대. 작은 목표를 세우고 그 진행 상황을 측정하여 다음 목표를 세워 실행한다. 측정 가능한 작은 단계!
pre-agile v.s. waterfall의 대결. 분명 워터폴의 우위가 30년 간 지속됐다. 계획하고, 계획대로 실행한다는 게 워터폴. 멋지다! 하지만 워터폴은 제대로 동작하지 않았다. 무엇이 문제였을까?
소프트웨어 프로젝트의 특성 때문이다. 좋음, 나쁨, 저렴함, 완성. 이 중 셋만 고를 수 있다. 넷은 불가능하다. 애자일은 필요한만큼 적당히 이 4가지를 모두 함께 가지기를 추구한다.
어떻게? 데이터를 기반으로 프로젝트를 관리한다. 팀의 속도, 그리고 남은 일이 애자일에 필요한 데이터다. 왜 이래야 하냐고? 마감일은 정해졌지만, 요구 사항은 유동적인 것이 소프트웨어 프로젝트의 본질이기 때문이다.
워터폴 프로젝트의 진행을 살펴보자.
시작: 느닷없이 날아온 프로젝트 수주와 오픈일자 통보
분석: 요구사항을 분석해보자
설계: 분석을 보다 명확히 해보자
개발: 분석 설계의 꿈나라를 느낀다. 그 와중에 요구사항은 계속 바뀐다.
오픈 직전: 야근, 특근과 오픈 실패는 피할 수 없다.
그렇다면 애자일은 폭포수 모델과 무엇이 다른가? 찍먹 애자일은 작은 반복주기(1~2주 단위)로 나눠 업무 속도와 진행률을 측정한다. 이것이 애자일의 데이터다. 이렇게 4~5 사이클을 반복하면 프로젝트를 언제쯤 끝낼 수 있을지 알 수 있다. “희망을 없애는 것이 애자일의 주요 목표다”(p31) “애자일은 우리가 얼마나 망했는지를 최대한 빨리 아는 것이다”(p31) 이 데이터를 사용하여 관리자는 프로젝트를 가능한 한 최선의 결과로 이끈다. 데이터를 기반으로 의사결정을 하기에, 합리적인 조직이라면 프로젝트를 조정할 수 있다. 마감일은 못 바꾸더라도, 필수적인 기능부터 개발하고, 불필요한 기능은 뺄 수 있다.
2장
왜 애자일을 선택해야 하나? 직업의식과 (고객, 동료, 이해관계자)의 당연한 기대 때문이다
직업의식
소프트웨어 없이는 살 수 없는 시대가 됐다. 중요하다. 예: 도요타(p47) 폭스바겐(p48)
애자일 소프트웨어 규율(테스트, 리팩토링, 피드백, 페어 프로그래밍, 단순한 설계 등)이 프로그래밍을 명예로운 직업으로 만들 것
당연한 기대
잘 돌아가는 소프트웨어를 내야 한다. 애자일이 그 해결책
오픈 지연? 애자일은 반복 주기마다 기술적으로는 시스템 오픈 가능하다
고객은 엉망인 레거시 코드 때문에 개발 속도가 느려질거라 기대하지 않는다
요구사항 변경에 강하다
오래된 시스템이라도 망가지지 않는다. 꾸준한 개선이 가능하다
페어 프로그래밍으로 지식이 공유된다.
데이터 기반 계획 추정이 가능
스터디
애자일 권리장전 선언
고객
계획을 알 권리가 있다
진척도를 알 권리가 있다
요구사항을 알 권리가 있다
개발자
우선순위와 요구사항을 명확히 알 권리가 있다
고품질의 결과물을 만들 권리가 있다
동료, 관리자, 고객에게 도움을 요청하고 받을 권리가 있다
업무를 수락한다. 할당받지 않는다.
애자일 권리장전이 지켜지면? 개발자는 멋진 개발자가 되고, 고객은 만족한다. 애자일은 방법론이 아니다. 소프트웨어 윤리 규범이다.
3장
애자일 실천 방법 중 비즈니스와 관련된 것들을 알아보자
계획 세우기
프로젝트를 작은 조각으로 쪼개서 추정하자. 얼만큼 작게 쪼개나? 추정이란 본디 불확실하므로, 필요한 만큼만.
삼변량 분석
대형 프로젝트의 장기 추정에 적합
최선(정확도 5%), 최악(95%), 일반적 경우(50%)로 나눠서 추정
일상적인 관리에는 정밀도가 낮음
스토리와 포인트
스토리: 기능 하나당 사용자 관점에서 아주 간략한 스토리로 만든다. 세부 사항은 생략. 여러 스토리가 나올 것이다.
스토리는 계속 추가, 삭제, 변경된다
반복 주기0: 스토리를 여럿 만들고, 적당한 스토리 하나에 필요한 노력 포인트를 추정한다. 이를 기준으로 다른 스토리의 포인트를 추정한다.
반복 주기1
개발자는 반복 주기 한 사이클 동안 몇 포인트나 처리할 수 있는지 추정
투자 수익률(ROI)를 계산하여 가치높고 저비용인 스토리를 골라 모은다. 개발자가 추정한 포인트만큼.
주기 중 중간 진행 상황을 확인하여 스토리 처리 목표를 조정한다
정리: 이제 1 반복 주기에 처리할 수 있는 노력 포인트를 알았다.
반복: 알게된 주기 1회당 노력 포인트를 토대로 다음 주기에 처리할 포인트를 추정. 반복.
프로젝트 종료: 더이상 구현할 가치가 있는 스토리가 없을 때
스토리는 어떻게 써야하나? INVEST
independant
negotiable
valuable
estimable
small
testable
포인트는 어떻게 메기나? 모든 구성원이 독립적으로 추정하고, 그 평균을 낸다.
반복 주기를 거듭하며 스토리를 합치고, 쪼개고(INVEST를 지키며), 스파이크(스토리 + 스토리 추정하기) 한다
스토리는 할당하지 말고 개발자가 스스로 선택한다
테스트 작성은 주기 시작 시점부터 한다. 테스트를 통과해야 스토리의 완료
이해관계자에게 스토리의 데모를 시연하여 주기를 끝낸다.
주기를 마치면 속도 그래프와 번다운 차트를 기록한다. 이를 기초로 다음 주기를 계획.
속도는 일정한 게 좋다.
속도가 올랐다면? 다들 열심히 일하는 것처럼 보이기 위해 거짓말을 한다. 잘못된 데이터 생성은 곧 반복 주기의 실패
속도가 떨어지면? 코드 품질이 떨어졌을 가능성이 높다.
작은 릴리스
최대한 자주 릴리스하라. 긴 릴리스 주기는 구태에 불과하다. 이제 git 덕분에 빠른 릴리스가 가능하다.
0을 향해 릴리스 주기를 계속 줄여가자. 반복 주기 길이도 줄이자는 말이다.
인수 테스트
가능한 한, 시스템의 요구 사항을 자동화 된 테스트 형태로 작성하는 것
요구 사항은 사업부서가 만든다. 하지만 사업부서는 테스트 작성을 싫어한다. 그럼 누가 테스트를 만들지? 개발자가 만들면? 복잡할 뿐더러 사업부서에서 검증할 길이 없다.
사업 부서에서 각 사용자 스토리의 동작을 설명하는 테스트를 형식에 맞게 작성 -> 개발자는 이를 자동화
반복 주기의 전반부가 끝나기 전까지 인수 테스트를 작성 -> 지속적 빌드에 테스트를 통합한다. 인수 테스트를 통과하면 스토리 완료
QA는 프로젝트 막바지에 투입되는 게 아니라, 프로젝트 초기에 명세를 작성하는 역할부터 시작한다. 역할이 크다.
변경된 부분만 테스트하라. 전부 테스트하면 QA 죽는다.
QA는 결함을 최대한 많이 찾으려 한다. 결함이 발생할 때마다 마감을 미룬다면 개발자는 일부러 결함을 만들 것이다. 그러니 QA는 테스트를 만들기만 하고, 테스트를 개발자가 돌리도록 하라.
전체 팀
우연은 중요하다. 우연히 문제를 해결하고, 결함을 찾아낸다.
고객 등 모든 구성원과 한 장소에서 모여 일하라. 시너지 효과가 난다.
재택 근무를 한다면? 그래도 같이 일하는 것만 못하다. 타임존과 문화가 같다면 잘 된 경험이 있긴 하다.
결론
사업 부서와 개발 부서의 의사소통을 단순하고 명확히 하여 갈등을 줄이고 신뢰를 쌓자.
4장
팀 구성원 사이의 관계, 팀원과 팀이 만드는 제품 사이의 관계를 다룬다.
메타포
효과적 의사소통을 위해 어휘와 용어를 명확하게 정의하여 일관되게 사용해야 한다
메타포는 비유가 좋다. 개발자, QA, 관리자, 고객, 사용자 모두!
동일한 언어 사용이 프로젝트를 일관되게 연결할 것이다.
지속 가능한 속도
우리는 야근하는 것이 자랑스러웠다 -> 우리는 프로그래머였다 -> 지친 나머지 한꺼번에 퇴사해 버렸다
야근을 하면 이상한 실수를 한다. 실수를 만회하기란 어렵다.
소프트웨어 프로젝트는 마라톤
공동 소유
팀 전체가 코드를 공동으로 소유한다.
복잡한 시스템이라면? 전문성을 키우면서도 넓게 알아야 한다.
지식이 팀 전체에 퍼지면 의사소통이 더 잘되고, 더 좋은 결정을 내릴 수 있다.
정치질을 하면 망한다
지속적 통합
지속적 통합은 지속적으로 해야한다. 즉 메인 브랜치로의 머지는 최대한 자주 해야한다.
지속적 빌드는 절대로 깨지면 안된다. 빌드가 깨지면 최대한 빨리 안 깨지게 고쳐야 한다. 빌드가 깨지면 테스트도 깨질거고, 방치하다보면 아무도 고치지 않는다.
스탠드업 미팅
참석 필수 아님
각 팀의 일정에 맞게 할 것(매일 할 필요 없음)
최대 10분
각자 3가지 질문에 답한다
지난 미팅 이후 무엇을 했나?
다음 미팅까지 무엇을 할까?
어떤 장애물이 있는가?
토론, 설명을 할 필요없다. 1인당 30초 걸릴 것
필요하다면 4번째 질문을 추가하라. ‘누구에게 감사하고 싶은가’
결론
작은 팀이 진짜 팀으로 일하는 법을 알아봤다. 위 설명이 의사소통의 언어, 서로를 어찌 대할지, 프로젝트를 어찌 대할지에 도움이 될 것.
5장
이번 장은 실천하기 어렵다. 그래도 빼놓을 수 없는 애자일의 핵심이다.
테스트 주도 개발
반드시 하라.
구현은 2번 해야한다. 한 번은 테스트, 또 한 번은 코드.
TDD 원칙
테스트 먼저
테스트 코드는 실패하기 위한 코드만
프로덕션 코드는 테스트 통과하기 위한 코드만
테스트 코드는 가장 좋은 문서이자 예제다.
테스트 코드를 나중에 만나면 귀찮아서 안하게 된다…
테스트 커버리지 90%면 충분
테스트 커버리지를 묙표나 목적으로 사용하면 안된다. 그랬다가는 개발자가 성공하는 테스트만 만들거다.
테스트 먼저 짜면 잘 분리된 설계가 가능하다.
테스트가 있어야 코드를 개선할 용기가 생긴다.
리팩터링
코드의 구조를 개선하면서 동작은 바꾸지 않는 실천 방법
개발 순서: 우선 동작하게 하고 -> 코드를 정리한다
리팩터링은 일상적인 작업이어야 한다. 개발 중에 계속 하라.
대규모 리팩터링도 일상적으로 하라. 오래 걸리더라도 계속 하면 된다.
단순한 설계
규칙
모든 테스트를 통과할 것
의도를 드러낼 것
중복을 없앨 것
구성 요소를 줄일 것
목표: ‘설계 무게’를 가능한 가볍게
설계가 복잡해지면 설계 무게가 늘어난다. 대신 복잡한 기능을 만들 수 있다. 설계의 복잡도와 기능의 복잡도 사이에서 균형을 잡자.
짝 프로그래밍
의무가 아니다.
잠깐씩 한다. 업무 비중은 50%가 좋다. 하지만 상황에 따라 유동적이다.
정해진 방법은 없다.
팀이 되기 위한 최고의 방법
많은 팀에서 코드 리뷰를 짝 프로그래밍으로 대체한다.
여럿이 해도 된다.
결론
어렵지만 필수적
테스트, 짝 프로그래밍, 리팩터링을 해도 되냐고 허락을 구하지 말라. 니가 전문가니 니가 결정해라.
6장
왜 애자일이 실패하나? 애자일이 아니라 그렇다.
애자일의 가치
애자일에 필요한 것 4가지
용기: 일을 제대로 하려면 필요
소통: 자주 교류해야 통찰이 생김
피드백: 잘못을 조기에 파악하고 고침
단순함: 문제의 수를 최소한으로 줄임
프로젝트의 모든 주기에 애자일 방법론을 도입하라. 기술 실천 방법도 필수. 계속해서 최선을 다하라.
전환
어렵다. 많은 실패 사례가 있다. 그래도 많은 조직이 애자일로의 전환을 시도할 것이다.
코치하기
필요한가? 아니오. 하지만 가끔은 필요할 수 있다.
스크럼 마스터: 코치여야지 관리자여서는 안된다.
애자일에 참여하는 사람은 팀 구성원 모두여야 한다.
대규모 애자일
애자일은 작은 팀부터 중간 크기의 팀을 위한 것. 큰 팀을 위한 것이 아니다.
큰 조직을 위한 방법은 이미 해결됐다.
소프트웨어 개발의 독특함 때문에 특별한 종류의 규칙(애자일)이 필요한 것.
대규모 애자일이란 없다. 있다면 그저 작은 애자일 팀을 조직하는 것
애자일 도구
깃
도구에 종속되면 안된다. 우선 자신의 작업 방식부터 파악하라.
ALM 도구가 어려워 헤매는 짓을 하느니 그냥 쓰지 마라. 물리적 도구 추천. 필요하면 트렐로 추천.
코치하기 - 다른 견해(데이먼 풀 씀)
기존 방식을 바꾸기란 어렵다. 그러니 코치가 필요하다.
결론
애자일해지기란 단순한 원칙만 지키면 되는 것 같지? 그게 어렵다.
7장
애자일 전환 시대가 되었다. 하지만?
애자일 후유증
문화를 바꾸기란 쉽지 않다. 리팩토링 하는 데 시간을 쓰고 있으면 그만 두라고 할 제품 책임자는 많다.
우선순위 높은 문제만 처리하다보면 기술 부채가 생긴다.
애자일을 지키지 않고 나서 애자일에 책임을 전가하는 경우가 많다. 이것이 애자일 후유증
서로 다른 기대
주기가 끝날 때마다 상용 배포는 개발팀에게는 엄청난 도전.
그저 우선순위 높은 기능 하나 개발한다고 되는 게 아니다. 유연하고 튼튼한 소프트웨어를 지속적으로 만들어야 한다.
유연함과 튼튼함 사이의 균형을 맞추려면 엔지니어링 기술이 필요하다. 협업만으로는 부족하다. 기술 역량을 위한 지원이 필요하다.
떠나감
많은 문제가 기술적인 문제임을 알아야 한다. 애자일만 강조할 게 아니라 기술도 강조해야 한다.
소프트웨어 장인 정신
선언
작동하는 소프트웨어 뿐 아니라, 잘 만들어진 소프트웨어
변화에 대응할 뿐 아니라, 꾸준히 가치를 더하기
개인과 상호작용 뿐 아니라, 전문가 커뮤니티
고객과의 협력 뿐 아니라, 생산적인 동반 관계
개발자는 장인이 되어야 한다. 최고가 되자.
전문가는 그 사람이 일하는 방식으로 정의할 수 있다.
더 나은 실천 방법을 계속 찾자.
실천 방법보다 가치에 집중하자.
공부하자.
개발 방법은 스스로 결정하자.
일에서 삶의 의미를 찾자.
Last updated