[카이젠저니] 07장 ~ 11장

나는 절대 오지 않을 구세주를 계속 기다리고만 있다는 것을 깨달았다.
그런 허울 좋은 일은 일어나지 않는다.
스스로 바꿀 수 밖에 없다.

 

제07장 둘이라면 더 바꿀 수 있다

• XP(eXtreme Programming) is about social change.
  • 지금까지 자신이 하던 행동을 바꾸고 다른 사람과 관계하는 방법을 바꾼다.
• 언제든 시작은 자신, 한사람. 하지만 언제까지나 혼자이면 안 된다.
• 소외 이론과 건설적 상호 작용
  • 사람은 자신이 경험한 것을 바탕으로 사물을 생각하고 가족이나 타인과의 일상을 통해 배운 지혜를 조합해 경험을 강화해나간다. 이러한 지식들의 집합. (Lv.1)
  • 직접 체험하지 않아도 학교나 서적을 통해 자연 현상이나 물리 원칙등을 배움 (Lv.3)
  • 이해하기 쉽게 설명할 수 있는 방울형 이해 (Lv.2)
    • 건설적 상호 작용
      • 여러 질문에 대해 상호 의존적으로 함께 생각하여 이해의 정도가 진화하는 것
      • 인식하지 못했던 일이나 관점이 서로의 사고를 성장시킴.

 

 

 

제08장 둘이서 경계를 넘다

• 빙산 모델
  • 현상 : 변화 또는 행동의 전체적 결과에 따른 패턴으로부터 발생
  • 패턴 : 구조 또는 짜임새에 기인
  • 구조
  • 멘탈모델 : 경험에 의한 신념 또는 세계관
    • 인지 편향 (cognitive bias) : 과거의 경험이나 선입견에 따른 고정 관념. 무의식중의 판단이나 평가.
      -> 이 때문에 그 전제를 부수기는 조금 어려움
• 문제가 발생했을 때 눈에 보이는 현상 뿐만 아니라, 어떤 시간의 흐름에서 발생했는지, 어떤 구조를 기반했는지, 결과적으로 어떤 멘탈 모델에 기인했는지 생각

 

 

Fail Fast. 일찍 실패하라.

제09장 혼자에서 팀으로

• 스크럼 기본
  • 정의 및 특징
    • 스프린트라 불리는 고정된 기간을 반복하면서 설계, 개발, 테스트, 딜리버리 등을 수행해 가치를 담은 제품을 낭비없이 구현하는 프레임워크
    • 회고를 통해 개선해 나가는 경험주의
    • 주요 이론 
      • 투명성(Transparency) : 스프린트 정보와 상황을 가시화 -> 함께 인식.
      • 검사(Inspection) : 팀이나 제품, 프로세스 상황을 항상 검사 -> 신속한 문제 인식
      • 적응(Adaptation) : 문제가 발생하면 개선안을 검토하고 문제 해결에 초점 -> 적용
    • 폭포수(Waterfall) 모델과의 차이점
      • 앞 단계로 되돌리기 어려운 폭포수 모델과 달리 이전 단계의 산출물 기반 
      • 과거 실패로부터의 학습도 중시
      • 사람 사이의 신뢰 관계가 필요하며, 상호 존중이 업무 진행에 중요하다 주장
        -> 개발 과정만을 관리하기 위한 프레임 워크가 아님
  • 이벤트
    • 스프린트(Sprint) : 개발 주기. 일반적으로 1개월 이하.
    • 스프린트 플래닝 (Sprint Planning) : 한 스프린트 내 계획
      • 스크럼 팀 모두가 무엇을 만들지 함께 생각하고 계획을 수립하는 것.
      • 1) 무엇을 만들지 2) 어떻게 고객에게 전달할지
    • 데일리 스크럼 (Daily Scrum) : 스프린트 목표 달성을 위해 매일 업무진행, 우선순위, 장애 등 확인
      • 매일 같은 시간, 같은 장소에서 15분 동안 진행
      • 아침 회의와 달리 꼭 아침에만 해야하는 건 아님
    • 스프린트 리뷰 (Sprint Review) : 스프린트 마무리 시점에 산출물 리뷰 및 피드백
    • 스프린트 리트로스펙티브 (Sprint Restrospective) : 스프린트 프로세스 개선을 위한 회의
  • 팀 구성
    • 제품 책임자 (Product Owner) : 제품 가치를 최대화하는 책임
    • 개발팀 (Development Team) : 자기조직화(Self-Organized)된 전문가 집단
    • 스크럼 마스터 (Scrum Master) : 개발팀 성과 향상을 위한 지원
  • 산출물
    • 제품 백로그 (Product Backlog) : 구현할 제품에 대한 요구사항, 요청, 기능 목록 (written by 제품 책임자)
      • 목록의 각 항목을 제품 백로그라 함. 세부 사양 및 추정 등을 기재
      • 팀 전원이 개발 대상을 동일하게 이해해야 함 -> 항상 오픈
      • 스프린트 골(Sprint Goal) : 산출된 달성 목표. 제품 백로그를 구현한 결과가 될 것.
    • 스프린트 백로그(Sprint Backlog) : 제품 백로그에서 스프린트 기간 내 구현할 것이라 결정한 백로그 아이템과 그 작업 목록 (written by 개발팀)
      • 태스크 정리 : 제품 백로그 아이템과 이를 고객에게 전달하는데 필요한 목록도 포함.
        • 분석, 설계, 테스트, 문서 작성 (단, 중간 산출물은 태스크가 아님)
      • 태스크 추정 : 다른 업무가 없을 때 태스크 완료 시간 예측
    • 증분(Increment) : 구현 결과. 제품.

 

 

 

제10장 완료 기준을 팀에서 결정하다

• 어떤 상태를 완료라고 할 수 있는가?
  • 회사의 품질 관리 기준 달성 여부를 제품 범위에 넣을 것인가? 등
  • 완료 정의 (Definition of Done) : 멤버 모두가 제품이 '완료'됐음을 동일하게 인식하게 하는 어떤 것
    • ex) 스테이징 환경에서 동작하는 것. 단위 테스트를 통과하는 것. 인수 조건을 만족하는 것 등.
  • 인수 조건 (Acceptance Criteria) : 해당 조건을 만족시키기 위한 요구사항을 확실하게 구현했다고 판단할 수 있는 리스트.
    • 제품 백로그 아이템 별로 있어야 함
• 벨로시티(Velocity) : 정해진 기간(여기선 스프린트) 동안 팀이 개발할 수 있는 업무량. 팀의 속도.

 

 

 

바라보는 방향을 합의함으로써 팀은
망설이지 않고 프로젝트를 스스로 주도할 수 있다.

Start with why.

 

제11장 팀이 가야 할 곳을 내다 보다

• 벨로시티를 올리는 것을 목적으로 한다면 팀은 눈앞의 태스크에 압도 당한다.
• 입셉션 덱 (Inception Deck) : 프로젝트의 Why와 How를 명확하게 해주는 도구.
  • Why를 명확하게 해주는 질문들
    • Why are we here? 프로젝트의 미션은 무엇인가?
      • (필수1) 미션이나 목적 공유
    • Create an elevator pitch. 제품의 필요성, 고객, 차별화 포인트는 무엇인가?
    • Design a product box. 사용자가 바라보는 제품의 가치는?
    • Create a NOT list. 범위에 포함되지 않아 하지 않을 작업은 무엇인가?
      • (필수3) 범위 내외의 경계를 확실히
    • Meet you neighbors. 팀을 둘러싸고 있는 이해관계자는 누구인가?
  • How를 명확하게 해주는 질문들
    • Show the solution. 사용할 수 있는 기술과 아키텍처는 어떤 것이 있는가?
    • Ask what keep up us at night. 불안이나 리스크는 어떤 것이 있는가?
      • (필수2) 리스크나 불안한 목록 작성
    • Size it up. 필요한 개발 기간은?
    • Tradeoff slider. Be clear on what's going to give. 출시, 범위, 예산, 품질의 우선 순위 관계는 어떠한가?
      • (필수4) 판단 기준을 가시화하고 우선순위를 명확히
    • Show what's going to take? 기간, 비용, 팀 구성은 어떻게 되는가? 무엇이 얼마나 필요한가?

 

 

---

오늘의 감상

• 이제껏 애자일애자일 말만 많이 들어봤다. 애자일이 일을 하는 방식에 대한 것이라면 스크럼은 그에대한 보다 구체적인 모델같다는 생각이다. 스크럼이 대충 뭔지는 안다. 매일매일 조금씩 체크하는 느낌으로다가. 하지만 생각보다 정말 많은 도구와 절차가 있었다. 이걸 정말 다 한다면 반드시 좋을까? 라는 의문이 들 정도로.
  • 그나마 납득되는 건 각 절차와 방법에 대해 모두 그럴싸한 이유와 목적이 있다는 점이다. 글로 설명하듯 적으려니 많은거지 체화가 되면 자연스럽게 진행하게 될 일종의 업무 방식일 수도 있겠다.
  • 그럼에도 일반적인 한국 회사와 팀에 적용시키기엔 다소 어려움이 있어보인다. 첫째는 대부분은 위에서 시키는대로 일하는 경우가 많아서이고. 둘째는 이를 도와줄 니시가타 같은 스크럼 마스터는 본 적이 없다는 점이다. 즉 한국에선 애자일이던 스크럼이던 제대로 아는 사람이 굉장히 희귀하다. 책 몇 권 읽으면 그나마 아는 축일 것이다. 실제 조직에 접목시키고 변화를 도출해낸 경험이 많은, '마스터'라 할만한 사람이 얼마나 있을까? 일반적인 기업 문화에선 괜히 스크럼 마스터라고 세워뒀다가 오히려 어설프게 배워 프로젝트 단계별로 지나친 부담을 줄 가능성이 높아보인다.
  • 그럼에도 현재 업무 방식에 문제가 있다면 바꾸어 나가는게 옳다. 이 책에서 소개하듯 이상적인 그림이 아니더라도 구간구간별로 어려웠던 단계에 소개하는 도구들을 한번 실험해보는 것에는 긍정적이다.
• 이번 장은 팀으로 확장하는 단계에 대해 많은 이야기가 있었다. 처음 혼자 접목하는 부분까지는 해볼만하겠다 싶은 방법들이 몇가지 있었고, 실제로 내일부터도 시작해볼까 싶었는데 팀 단위로 확장해나가는 모습을 보니 역시 여간 어려운 일은 아닐 것 같다는 생각이 든다. 나도 지금 애자일이니 스크럼이니 하는 행위적 문화를 글로 배우고 있으니 말이다.