LeanSoftwareDevelopment

차례

발제

• 린 소프트웨어 개발
• 린 소프트웨어 개발의 적용
• 저자 세미나 공유
• Toyota Way

이야기나누기

• 각자의 문제들을 Lean으로 풀어보기
• Lean을 어떻게 적용하고 녹여낼 수 있을까?
• Lean과 유사한 방법을 적용했던 경험과 사례 공유

 

Lean Software Development ?

무엇이 가치를 만드는가

왜 빠른 흐름이 필수인가

일하는 사람들의 브레인 파워를 어떻게 자유롭게 활용하도록 해줄것인가

 

스스로 상황에 맞는 Process를 정의하게 하는데 초점.

좋아해서 그냥 가져와서 도입하는 것이 아닌, 생각의 씨앗을 활용해서,

자신의 상황에 가장 적합한 실천방법을 직접 만드는 것.

 

7가지의 린 원칙

낭비를 제거하라 (Eliminate Waste)

실제 고객에게 가치를 제공하지 못하는 것을 없애나가기

 

Seeing Waste - 무엇을 낭비로 볼 수 있을까?

• 부분적으로 완료된 작업
• Extra Process
• Extra Feature
• 대기(Wating)
• 결함(Defect)
• 정보전달비용

 

Value Stream Mapping

프로젝트의 Process흐름을 도식화해보기. 활동시간은? 대기시간은?

무엇보다 지연원인은 어느 부분에 있는가?

배움을 증폭하라 (Amplify Learning)

소프트웨어 개발은? 본질적으로 시행착오를 거치며 배우는 학습 프로세스. 정형화된 것은 없다. (없어야 한다)

 

배움을 증폭하는 도구들

• 피드백

  • 폭포수모델 - 피드백의 고갈
  • 프로세스 강박증 : 도전과제가 있을때, 조직은 잘 훈련된 (순차적)프로세스를 강요하려는 경향이 있다 (상황은 악화, 피드백은 감소)

• 반복주기(Iteration)

  • 고정된 작업기간

    • 짧을 수 록 예측보다는 사실에 기반하기에, 앞으로 나아가기 쉬워진다.
  • 팀 내부의, 또는 고객과의 의견을 동기화하는 시점

  • 잘 작성된 반복계획은 그 자체로

    • 고객의 질문 경로
    • 개발팀의 동기부여 요소가 된다.

• 동기화

  • 공통의 정보를 가지고 의사소통할 수 있게
  • 자동화된 테스트 , 일일 빌드 ,

• 집합 기반 개발(Set Based Development)

  • 목표에 도달하는 방법 : 점 -> 점 -> 점이 아닌,

  • 다양한 조건군(Set)을 기반으로 하는 목표도달( Option Set -> Option Set -> Option Set)

    • 제약조건만 피해가면, 어떤 방법이든

가능한한 늦게 결정하라 (Decide as late as possbile)

결정 - 무언가가 고정된다 - 그만큼 변화에 유연하게 대처할 수 없다.

 

• 동시 개발 Concurrent Development

  • 빨리 결정할수록, 변화 비용이 더 크게 든다. 설계에 대한 확정을 가능한한 지연시킨다
  • 왜 소프트웨어가 생명주기동안 계속 변화할까? 소프트웨어의 비즈니스 프로세스 자체가 계속 진화하기 때문

• 대안 사고 Option Thinking

  • 결정 미루기. 확실히 알수 있는 마지막 순간까지는 다양한 옵션을 유지하기.
  • 개발중인 기술이 성숙해질때까지.
  • 불확실성을 줄이고, 계획을 보다 현실성있게 하기 위해 => 실험 + 학습을 동반한 추론

• 책임이 따르는 마지막 순간 Last Responsible Moment

  • 부분적으로 완료된 설계정보 공유하기
  • 작업자들간의 협력(의사소통) 체계
  • 빨리 반응하기, 도메인에서 중요한것 느끼기
• 의사결정 - 깊이 우선 vs 넓이 우선 - 상황에 따라

최대한 빨리 납품(전달)하라 (Deliever as fast as possible)

늦은 결정을 상충해주는 요소

 

불확실성을 줄이고

더 많은 정보와 사실을 바탕으로

결정할 수 있을때까지 옵션을 유지하기

 

• Pull System. 일정으로 밀어붙이지 않고, 완성한 만큼 가져다 쓰기.

  • 스토리카드 가져다 쓰기  - 정보방열기(Information Radiator)

• Queueing Theory

  • 일정한 도착률? 더 잦은 릴리즈 (한달, 한주) - 대기행렬 짧게 만들기
  • 제약이론 (TOC) - Throughput에 초점을 맞추기. 병목 제거

• 여유(Slack)

  • 변화할 능력을 주고
  • 스스로 재발견하고
  • 성장을 위해 자원을 정리해주고 해줄수 있는
  • 그 자체로 유의미하고 필수불가결한 리소스
• Cost of Delay

팀에 권한을 위임하라 (Empowering Team)

과학적 관리법을 뛰어넘어. 결국 사람이다. Software Development as Mental Game.

 

자기 결정권 ( Self -Determination)

• 통제보다는
• 스스로 능동적으로 업무를 운영하고, 개선하고, 잠재능력을 최대한 발휘할 수 있도록

• 인간 존중.

  • GE Workout Concept - 노동자에게 How to Work를 주입하려하지 않고

    • 노동자가 관리자들에게 제대로 일할수 있는 방법을 가르친다
    • 관리자 - 방해요소, 제약조건을 제거하는 ,  시스템을 정비하는 일에 집중

동기부여(Motivation)

• 확실하고 강력한 목적
• 확실히 달성할 수 있도록
• 스스로 결정 -> 약속
• 관리자의 역할 : 외부의 태클을 막아줌으로써, 동기부여를 유지해주는것

달리 말해 , "목적"

• 동기부여 생성을 위한 방법

  • 소속감
  • 역량-  자신이 잘할 능력이 있는지 확신하고 싶어한다
  • 발전 - 성취감 인정하고 장려하기
  • 안전 - 실수를 장려하는 분위기

Leadership - 방향성 , 동기부여

통합성을 구축하라 (Build Integrity)

인식통합성 - 고객에게 일관된 경험을

개념통합성 - 시스템의 요소가 일관성을 지킨채 통합을

 

결국, 탁월한 정보흐름을 가능하게 하라.

• 문제 인식과 해결을 동시에 - 프로토타입 & 피드백 - 옵션을 유지하기
• 기초 정보를 일찍 공개하기
• 정보를 작게, 그리고 자주 전파하기
• 정보는 양방향 (단방향 지시, 전달이 아닌)
• 대면 Communication

(정보,문제)를 벽 너머로 던지지 않기(Don't throw it over the wall)

 

존재하는 자원을 재활용

모든 영역마다, 경험있는 장인들이 관여하게

 

리팩토링 - 소프트웨어는 순식간에 손쉽게 쓸모없어진다. 비즈니스 가치를 전달할때, 그런 낭비를 제거하는 핵심방법 -> 코드의 수명늘리기

테스트

• 커뮤니케이션
• 피드백
• 발판

전체를 보라 (See the Whole)

조직을 하나의 시스템으로 바라보기

 

성장의 한계, 결과가 아닌 원인에 집중하기 -  5Why

 

• Local Optimization의 오류에 빠지지 않게 하라

  •  랜스암스트롱은 모든 구간에서 1위를 하지 않고서도 매번 우승했다

 

• 측정 - (Local Optmization이 아닌, Global Goal을 기준으로 한 측정)

• 계약 - 계약이란? 자신의 약속을 지키고 약속을 이용하지 않으려는 확신. 즉, 계약의 본질은 시간,비용이 아닌, 신뢰.

  • 그렇다면?

    • 신뢰를 지킬 수 있다면, 그 계약의 형태는 다양해져도 된다.- 다양한 계약의 방법들

      • 단계적, 목표비용
      • 핵심은 선택적 범위 - Goal과 신뢰에만 초점을..
    • 계약의 주체들? - 팀팀 내, 팀/부서 간 , 제휴업체간....