클린 애자일 요약

클린 애자일 1장 애자일 소개

애자일의 탄생은? 선사시대. 작은 목표를 세우고 그 진행 상황을 측정하여 다음 목표를 세워 실행한다. 측정 가능한 작은 단계!

pre-agile v.s. waterfall의 대결. 분명 워터폴의 우위가 30년 간 지속됐다. 계획하고, 계획대로 실행한다는 게 워터폴. 멋지다! 하지만 워터폴은 제대로 동작하지 않았다. 무엇이 문제였을까?

소프트웨어 프로젝트의 특성 때문이다. 좋음, 나쁨, 저렴함, 완성. 이 중 셋만 고를 수 있다. 넷은 불가능하다. 애자일은 필요한만큼 적당히 이 4가지를 모두 함께 가지기를 추구한다.

어떻게? 데이터를 기반으로 프로젝트를 관리한다. 팀의 속도, 그리고 남은 일이 애자일에 필요한 데이터다. 왜 이래야 하냐고? 마감일은 정해졌지만, 요구 사항은 유동적인 것이 소프트웨어 프로젝트의 본질이기 때문이다.

워터폴 프로젝트의 진행을 살펴보자.

1. 시작: 느닷없이 날아온 프로젝트 수주와 오픈일자 통보
2. 분석: 요구사항을 분석해보자
3. 설계: 분석을 보다 명확히 해보자
4. 개발: 분석 설계의 꿈나라를 느낀다. 그 와중에 요구사항은 계속 바뀐다.
5. 오픈 직전: 야근, 특근과 오픈 실패는 피할 수 없다.

그렇다면 애자일은 폭포수 모델과 무엇이 다른가? 찍먹 애자일은 작은 반복주기(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%면 충분
  • 테스트 커버리지를 묙표나 목적으로 사용하면 안된다. 그랬다가는 개발자가 성공하는 테스트만 만들거다.
  • 테스트 먼저 짜면 잘 분리된 설계가 가능하다.
  • 테스트가 있어야 코드를 개선할 용기가 생긴다.
• 리팩터링
  • 코드의 구조를 개선하면서 동작은 바꾸지 않는 실천 방법
  • 개발 순서: 우선 동작하게 하고 -> 코드를 정리한다
  • 리팩터링은 일상적인 작업이어야 한다. 개발 중에 계속 하라.
  • 대규모 리팩터링도 일상적으로 하라. 오래 걸리더라도 계속 하면 된다.
• 단순한 설계
  • 규칙
    1. 모든 테스트를 통과할 것
    2. 의도를 드러낼 것
    3. 중복을 없앨 것
    4. 구성 요소를 줄일 것
  • 목표: ‘설계 무게’를 가능한 가볍게
  • 설계가 복잡해지면 설계 무게가 늘어난다. 대신 복잡한 기능을 만들 수 있다. 설계의 복잡도와 기능의 복잡도 사이에서 균형을 잡자.
• 짝 프로그래밍
  • 의무가 아니다.
  • 잠깐씩 한다. 업무 비중은 50%가 좋다. 하지만 상황에 따라 유동적이다.
  • 정해진 방법은 없다.
  • 팀이 되기 위한 최고의 방법
  • 많은 팀에서 코드 리뷰를 짝 프로그래밍으로 대체한다.
  • 여럿이 해도 된다.
• 결론
  • 어렵지만 필수적
  • 테스트, 짝 프로그래밍, 리팩터링을 해도 되냐고 허락을 구하지 말라. 니가 전문가니 니가 결정해라.

---

클린 애자일 제6장 애자일해지기

왜 애자일이 실패하나? 애자일이 아니라 그렇다.

• 애자일의 가치
  • 애자일에 필요한 것 4가지
    • 용기: 일을 제대로 하려면 필요
    • 소통: 자주 교류해야 통찰이 생김
    • 피드백: 잘못을 조기에 파악하고 고침
    • 단순함: 문제의 수를 최소한으로 줄임
  • 프로젝트의 모든 주기에 애자일 방법론을 도입하라. 기술 실천 방법도 필수. 계속해서 최선을 다하라.
• 전환
  • 어렵다. 많은 실패 사례가 있다. 그래도 많은 조직이 애자일로의 전환을 시도할 것이다.
• 코치하기
  • 필요한가? 아니오. 하지만 가끔은 필요할 수 있다.
  • 스크럼 마스터: 코치여야지 관리자여서는 안된다.
  • 애자일에 참여하는 사람은 팀 구성원 모두여야 한다.
• 대규모 애자일
  • 애자일은 작은 팀부터 중간 크기의 팀을 위한 것. 큰 팀을 위한 것이 아니다.
  • 큰 조직을 위한 방법은 이미 해결됐다.
  • 소프트웨어 개발의 독특함 때문에 특별한 종류의 규칙(애자일)이 필요한 것.
  • 대규모 애자일이란 없다. 있다면 그저 작은 애자일 팀을 조직하는 것
• 애자일 도구
  • 깃
  • 도구에 종속되면 안된다. 우선 자신의 작업 방식부터 파악하라.
  • ALM 도구가 어려워 헤매는 짓을 하느니 그냥 쓰지 마라. 물리적 도구 추천. 필요하면 트렐로 추천.
• 코치하기 - 다른 견해(데이먼 풀 씀)
  • 기존 방식을 바꾸기란 어렵다. 그러니 코치가 필요하다.
• 결론
  • 애자일해지기란 단순한 원칙만 지키면 되는 것 같지? 그게 어렵다.

---

클린 애자일 제7장 장인 정신

애자일 전환 시대가 되었다. 하지만?

• 애자일 후유증
  • 문화를 바꾸기란 쉽지 않다. 리팩토링 하는 데 시간을 쓰고 있으면 그만 두라고 할 제품 책임자는 많다.
  • 우선순위 높은 문제만 처리하다보면 기술 부채가 생긴다.
  • 애자일을 지키지 않고 나서 애자일에 책임을 전가하는 경우가 많다. 이것이 애자일 후유증
• 서로 다른 기대
  • 주기가 끝날 때마다 상용 배포는 개발팀에게는 엄청난 도전.
  • 그저 우선순위 높은 기능 하나 개발한다고 되는 게 아니다. 유연하고 튼튼한 소프트웨어를 지속적으로 만들어야 한다.
  • 유연함과 튼튼함 사이의 균형을 맞추려면 엔지니어링 기술이 필요하다. 협업만으로는 부족하다. 기술 역량을 위한 지원이 필요하다.
• 떠나감
  • 많은 문제가 기술적인 문제임을 알아야 한다. 애자일만 강조할 게 아니라 기술도 강조해야 한다.
• 소프트웨어 장인 정신
  • 선언
    • 작동하는 소프트웨어 뿐 아니라, 잘 만들어진 소프트웨어
    • 변화에 대응할 뿐 아니라, 꾸준히 가치를 더하기
    • 개인과 상호작용 뿐 아니라, 전문가 커뮤니티
    • 고객과의 협력 뿐 아니라, 생산적인 동반 관계
  • 개발자는 장인이 되어야 한다. 최고가 되자.
• 전문가는 그 사람이 일하는 방식으로 정의할 수 있다.
• 더 나은 실천 방법을 계속 찾자.
• 실천 방법보다 가치에 집중하자.
• 공부하자.
• 개발 방법은 스스로 결정하자.
• 일에서 삶의 의미를 찾자.

---

클린 애자일 제8장 결론

애자일은 진짜임.

---

클린 애자일: 새로운 세대를 위한 애자일 가치와 실천, 로버트 C. 마틴 저/정지용 역, 인사이트(insight), 2020년 12월 04일, 원서 : Clean Agile: Back to Basics

20211015