• 으어졸려

XP (eXtreme Programming)

• 아이스 브레이킹 - Job Crafting
  • 자신의 업무를 스스로 변화시켜 의미있고 행복한 활동으로 바꾸는 것
  • 지각으로 제대로 못 들었다

스크럼은 이해관계자 측면에서 제품 책임자나 경영진 (스크럼마스터)이 참여할 수도 있지만 XP의 경우에는 철저하게 개발팀 중심으로 진행된다. 비즈니스를 배제하려고 노력해야 한다는 것이 큰 차이.

• SW Development Methods

  • 지속적인 테스트 및 고객 참여. XP에서 가장 높은 성과를 보여주는 실천방법이 바로 고객 참여 기법이고 업계에서 검증된 기법이기도 하다.
  • Frequent Release: 짧은 반복 개발주기 (1주)

• Biz model development Methods

• XP는 전방위적인 테스트 자동화, 빌드 자동화에 의존한다.

• XP는 문서보다는 구두전달, 테스트, 소스코드에서 시스템 구조와 의도를 전달한다.

• 과거에는 잘 통했지만 지금은 잘 안 되는 습관과 양식을 버려라.

• 성공을 준비하라. 자신을 보호하지 말고 최선을 다한 뒤 결과에 대처하라.

• 가치와 원칙에 의하여 XP를 적극적으로 커스텀하라.

• 이름뿐인 풍부한 기능을 버리고 오직 우선순위가 가장 높은 작업들만 다룰 것을 요구하라.

최고는 오직 하나

• 직원 교체시에도 인간적인 교류를 통하여 책임을 받아들이도록 격려 받는다.
• [?] 코드보다 테스트를 먼저 작성하라고?

XP의 5가지 핵심 가치

• 의사소통

  • 팀 개발을 하게되면 대부분 의사소통 문제가 발생하게 된다. 문제를 공통적으로 인지, 문제반복을 잡고, 문제가 감추어진 것을 드러내라.

• 용기

  • SW는 대부분 했던 일을 반복하는 일이 없기 때문이다. 요구상황이 비주기적으로 바뀌고 신 기술을 계속 받아들여야만 한다. 모르는 동료, 모르는 고객을 포함해 객관적이지 않고 주관적인, 감정적인 면을 보고 소통해야 한다.
  • 용기란, 먼저 손을 내어 도움을 주고 도움을 요청할 수 있는 용기. → 피드백이라는 중요한 가치를 얻을 수 있다.

• 피드백

  • 개발 도중에도 지속적인 피드백을 받으면 만들어진다. 내가 지속적인 피드백을 받고 있는지 셀프 회고를 해야함.
  • 빠른 시일 내에, 자주, 이왕이면 고객으로부터 피드백을 받는 것이 좋다. 본능적으로 피드백의 간격을 늘리거나 횟수를 줄이려고 할테지만 오히려 프로젝트가 크게 변경되거나 드랍될 확률을 높이기 때문에 새로운 요구사항을 가능한 빨리 받아들여야 한다.

• 단순함

  • 점점 더 어렵고 복잡한 문제를 풀고있다. 그만큼 우리가 만드는 SW가 복잡해져야만 할까? 이러면 유지보수가 안된다.
  • 이글루스를 최근에 종료했는데, 그 이유가 바로 레거시 때문이다. 고칠 엄두도 못내는 상황이었다는거.

• 존중

  • 존중이 잘 이루어지는 팀은 계속 데리고 다닐 수 있다. 끊임없이 성장할 수 있는 특징을 가지고 있다.

    소프트웨어 개발에서 생산성과 인간성을 동시에 개선하려면, 팀에 속한 모든 개인의 기여를 존중해야 한다. 나도 중요한 사람이고 당신도 중요한 사람이다.- 켄트 벡

• 다른 가치들

  • 안정성, 보안, 예측가능성, 삶의 질

XP의 12가지 원칙

• 인간답게 개발해라. 안정감, 소속감, 확장, 친밀감,
• 경제성의 원칙에 따라 모든 것들에는 돈이 오간다.
• 모든 활동은 그 활동과 관련된 모든 사람에게 상호이익이 되어야 한다. 모두가 닮아진다.
• 자기 유사성 해결책의 구조를 다른 맥락에서도 적용.
• 개선 SW개발에서 완벽함이란 없다. 완벽해지기 위해 노력한다만 있다.
• 다양성 완벽한 하나의 방법은 없다.
• 반성 실수를 숨기지 않고 실수를 드러내어 거기서 배운다.
• 흐름 개발의 모든 단계를 동시에 진행함으로써 가치있는 SW를 물 흐르듯 끊임없이 제공해야 한다. 특정 작업자가 특정 단계에서 막힌다면 다른 동료들이 도와주어야 한다. 조금씩 점진적으로 자주 배포한다.
• 기회 생각을 전환하여 문제를 기회로 보는 방법을 배우자.
• 잉여 해결하기 어려운 문제는 해결방법을 여러 개 만들어 놓아야 한다. Plan C,D까지도 만들어 놓자.
• 실패하는 데 두려워하지 말라. 성공하는데 어려우면 실패하라. 스토리를 진행하는데 동작을 잘 하지 않거나 사용성이 떨어질 것 같다는 판단이 든다면 유의미한지 여부를 회고하고 아니다 싶으면 중간에 드랍을 하는 것이 더 효율적임. 짝 프로그래밍 예시에서도 코딩 도중 본인 스스로 막혔을 때 타이머를 키고 15분동안 다시 집중하고 안되면 실패했다고 간주하고 도움을 요청한다.
• 품질을 희생하는 것은 프로젝트 관리 수단으로 삼기에 효과적이지 않다.
• 책임소재 어떤 일을 하겠다고 선언한 사람이 그 일의 책임도 가진다. - 꼭 그런 건 아님. 용기있게 제안을 할 때 수습을 해야만 하다는 부담감이 가해질 수도 있어보인대.

결론

원칙을 이용하면 실천방법을 더 잘 이해할 수 있다. 적합한 실천법이 없다면 위의 원칙을 활용한 새로운 실천법을 고안하라. 우리는 야생학습을 해야만 하는 상황에 놓여있다. SW 개발의 모든 면을 다 담을 수 있는 올라운드 실천방법의 목록은 존재하지 않는다.

XP 실천방법 (도서 '애자일 101' 참고)

![[애자일 101.pdf]]
무엇을 배우게 될까?
현장고객, 사용자스토리, 릴리즈 계획, 짝 프로그래밍, CI, 속도, 팀방 꾸미기 , 활기찬 작업, 스토리, TDD, 일주일별 주기, 10분 빌드, 점진적 설계

짝 프로그래밍

CI

• 소스코드, DB 스크립트, 코드 검사, 빌드, 자동화 테스트를 가능하면 자주 통합하는 실천법. SW 항상성을 검증하는 거임.
• 데브옵스 조직을 따로 갖는 경우가 있더라. CI 담당자는 프로젝트에 맞는 자동화 환경을 구성하고 관리한다. 팀원은 통합빌드가 실패하면 이를 빠르게 고치고 실패원인을 팀원들이게알린다.
• 모든 과정을 자동화하는 것이 중요. 신규 프로젝트일수록 더더욱 중요도가 높아진다.
• 통합빌드를 하면 상태의 모니터링이 가능해진다.

공간

팀이 한 방에 모이도록 하는 한자리.

• 가청성 의자를 돌리는 일 없이 다른 사람과 대화
• 가시성 작업 현황판이 눈에 항상 보이게끔
• 단절성 방해를 받을 정도로 외부인원이 한자리에 있으면 안돼.
  • 개발자와 제품 책임자가 한 자리에 있지 않도록
  • 관리자는 수시로 개발팀이 성장할 수 있도록 기다려라.
• 야근 없는 팀

시간

• 일주일 주기
• 분기별 주기
  • 병목 찾기
  • 주제와 스토리 분리

지속적 통합

• 10분 빌드
  • 빌드에 10분보다 오래 걸리게 되면 빌드 실행 횟수가 줄며, 피드백 받을 기회를 놓치게 된다.
  • 자동화된 빌드는 수작업 빌드보다 훨씬 가치있다.
• CI 지속적 통합
  • "제 컴에서는 잘 돌아가는데요"
  • 빌드 서버는 커밋마다 빌드를 새로 하고 모든 테스트를 진행한다. 빌드 실패를 일으킨 코드 변경 사항과 테스트 실행 결과 등의 정보를 포함한 이메일을 전체 팀원에게 보낸다.

TDD

• 자동화된 테스트를 먼저 작성하고 테스트를 통과할 만큼의 코드를 작성한 뒤 가독성을 높이고 중복을 제거하기 위해 코드를 리팩토링하라.
• 기존 코드에 TDD를 도입하는 건 끔찍하게 어렵다.
• 전담 테스터로 구성된 팀이 있어야 하다.
• 수작업 테스트 과정에서의 낭비시간을 줄이는 것. 테스트 세팅을 위한 유틸리티를 만들어 부트스트랩 하기.

점증적(점진적) 설계

• 처음부터 완전한 설계를 만들고 고치지 못하게 만드는 것과는 큰 차이.
  • 리팩토링으로 회사가 망한 사례가 실제로 많다. (Lotus 123의 예시)
• 단순한 설계, 단순한 개발
  • 의사소통을 위해서 설계를 하는 거지
  • 재사용성이 높은 조직. 중복된 코드가 없을것.

XP 보조 실천방법 (확장)

• 높은 수준의 코드 공동 소유
  • 모든 코드에 대한 이해도가 높기 때문에 다른 구성원이 남의 코드베이스에 쉽게 접근할 수 있다.
• 코딩 컨벤션 + 단일 코드 기반
  • 예: 오라클의 코드컨벤션을 보고 그걸 따르자! →규칙을 명세화.
  • 예외처리하는 방법을 프로그래머 나름의 방법으로 열어두면 시스템 설계의 일관성을 매우 심각하게 저해한다.

제약이론 (도서 이름이기도 함.)

https://zdnet.co.kr/view/?no=00000039153790

휴게소에서 고속도로로 합류하는 상황을 보면 엄청난 병목이 걸리는 것을 알 수 있다. 행군도 그렇다. 아이러니하게도 가장 속도가 느린 병사에게 드럼을 치게 한다. 가장 속도가 느린 병사와 앞 병사 사이에 일정한 간격을 둔다. 이 친구의 속도를 계속 일정하게 유지하게 만든다.

많은 일을 벌리지 말고 일단 시작한 일을 완결하는 데에 집중하라.

테스트를 수동에서 설계 단으로 끌어오면 순환의 속도를 빠르게 만들 수 있다.

미래로부터 현재를 바꾸고, 현재로부터 현재를 바꾸고, 과거로부터 현재를 바꾸어 시간을 내 편으로 만든다. - 카이젠 저니

애자일 회고 (도서)

• 애자일이란? 반복적이고 점차적으로 가치를 높이는 것

• 회고란? 팀이 정해진 기간 동안 해왔던 일에 대해 돌아보기.

• 애자일 회고란? 이터레이션이 끝난 후, 방법론이나 팀워크를 자세히 검토하고 수정하고자 모이는 회의.

• 활동의 성격을 가진 회고.

  • 회고 회의가 시간이 정해져 있다는 특징은 회고 자체에 의미가 없다는 것을 명확히 인지시킬 수 있다. (시간낭비X)
  • 회고를 통해 나온 액션 플랜이 훨씬 중요하다.
  • 감정적 공유와 상호 이해

• 일일회고

  • 혼자 해도 좋고 팀이서 해도 좋다.
  • 피드백 주기는 짧을수록 강력해진다.

오늘을 다시 시작한다면 어떻게 할 것 같나요?

• 기업별 회고의 케이스를 찾아보는 것도 많은 도움이 된다.
  • SK CNC의 예 https://engineering-skcc.github.io/culture/agileretrospective/
  • 스포카의 예 https://spoqa.github.io/2018/08/29/retrospect.html
  • 인프런 인프랩 프로젝트 루비콘 https://doc.clickup.com/d/3gfz7-5843/log/3gfz7-120145/프로젝트-루비콘-후기-2021-10-2022-01
    • 수습회고, 연말회고, 프로젝트 회고를 전부 다 기록했다. 개쩌는데
  • 배민의 사례
  • 당근마켓의 사례
  • 요기요 회고 DIY Kit
    • 요기요 해외 테크 블로그
  • 100+ 회고 아이디어 모음
  • https://www.funretrospectives.com/category/futurespective/
  • https://www.atlassian.com/team-playbook/plays?
  • 화이트보드 모양의 회고 템플릿
  • 회고예시

다음 시간에는...

• OKR이 매우 중요하다고 생각하다.
• 성공의 피라미드 & 만다라트 재구성
• QNA 진행할거임