scrum ch6

• 스크럼 회의 - 신뢰를 구축하는 상호작용

신제품 개발이라는 관점

• 제조업의 반복 가능한 공정은 먹히지 않는다
• 경쟁력 있고 혁신적인 회사의 공통점 by 노나카, 타케우치
  1. 내재된 불안정성
  2. 자기 조직적인 프로젝트 팀
  3. 중접 개발 단계
  4. 다중 학습
  5. 눈의 띄지 않는 제어
  6. 학습의 전파

리스크 관리와 예측의 관점

1. 고객을 만족시키지 못하는 리스크

• 매 스프린트 마다 실제 작동하는 소프트웨어 보여줌. 우선순위 결정.

1. 전체 기능 구현 중 일부를 끝내지 못하는 리스크

• 낮은 우선 순위의 기능은 포기하더라도 높은 우선순위의 기능은 구현

1. 잘못된 추정과 계획에 대한 리스크

• 일일 스크럼과 스프린트 주기 동안 변경되지 않는 백로그 유지

1. 문제점들이 즉각 해결되지 않은 수 있는 리스크

• 매일 관리자에게 적극적인 관리를 요구

1. 개발 주기 내에 완수하지 못할 수 있는 리스크

• 매 스프린트마다 동작하는 소프트웨어를 배포

1. 초과 근무와 기대 변경에 대한 리스크

• 스프린트 기간 동안 백로그 고정

패러다임 전환적 관점

• 명시적이고 반복 가능한 프로세스 접근법은 실패

지식 생성의 관점

1. 암묵지, 형식지
2. 사회화, 구체화, 내재화, 연결화

복잡계 과학의 관점

• 자기 조직화된 조직의 역동성
• 특징
  1. 열린 시스템
  2. 역동적
  3. 몰입
  4. 밀도있는 국소 상호작용에 의지하기
  5. 창발성
  6. 구성 단위와 집합성
  7. 꼬리표 달기
  8. 다양성과 전문성
  9. 내부의 공유 모델들
  10. 비선형 역학
• 스크럼 조식, 프로세스, 규칙
  1. 스크럼 팀의 가치
  2. 일일 스크럼 회의
  3. 스프린트 데모
  4. 스프린트 종료와 스프린트 계획 회의
  5. 적응과 자연 선택

인류학적 관점

• 문화를 바꾸는 실천
  1. 지지
  2. 언어
  3. 역할과 멘토
  4. 가치
  5. 믿음
  6. 실천 방법과 규칙

시스템 역학적 관점

• 재고량을 충분하지만 최소로 유지하기
  • 적은 양을 짧은 기간 동안 이동시켜라
• 개발자의 시간 사용 상황을 조금씩 빠르게 사용

정식 분석적 관점

• 몰입의 상태

럭비의 메타포

• 스크럼 회의 - 허들
• 하루의 일과 - 다운
• 스프린트 - 퍼스트 앤드 텐
• 제풀 출하 - 터치다운

소감

• "왜 스크럼이 실패했을까?" 라는 챕터가 있었으면...
• 코드 품질에 대한 얘기가 없다

사례

• 다음 사례는 성공일까? 실패일까?

     팀은 Sprint 4 동안 매우 무리한 계획을 잡고 스스로 세운 계획들을 완료하기 위해 부던히 노력 한 결과, 
    전체 스토리 포인트를 괄목할 만큼 줄였습니다. 제가 이런 계획은 현실적이지 않으니 고객과 합의하여 
    일의 양을 줄여야 한다고 여러차례 말씀드렸지만, "할 수 있다" 라는 말씀만 반복하셨죠.
     어쨌든 그 만큼을 수행하셨으니, 고객도, 관리자도 모두들 좋아했습니다.
     개발자들의 속은 까맣게 타 들어갔지만 말이죠.
  

• http://neonebula.egloos.com/2149642

• http://cavin.egloos.com/4758088

  • 역시 희종님 센스 짱. 그럼 내일 토론해 보아요~ [ParkPD]