데브옵스 스터디 5~6장

5장 - 시작할 가치 흐름을 선택하기

• 데브옵스 전환 작업은 문제 발생 시, 더 큰 손실이 발생하므로 신중하게 결정해야 한다.

노드스트롬 데브옵스 트랜스포메이션

• 전환 작업을 시작할 위치(기능 or 서비스 등)를 선정한다.
• 특정 비즈니스 영역에 집중해 성공 사례를 만든다.
• 전환 작업 진행
  1. 전담 팀 구성
  2. 1년 단위 계획 => 온디맨드 기획으로 변경
  3. 단일화된 우선순위 목록이 구성됨.
     동일한 우선순위 목록으로 원활한 의사소통 및 업무 진행이 가능해짐.
  4. 별도 테스트 제거 => 일상 업무와 통합.
     월 출시 기능 2배 증가, 결함 1/2 감소

그린필드 서비스 VS. 브라운필드 서비스

• 그린필드 프로젝트

  • 계획이나 구현의 초기 단계 => 신규 프로젝트 시작 시점.
  • 제약이 거의 없어 애플리케이션, 인프라 구축이 용이함.

• 브라운필드 프로젝트

  • 오픈하여 고객이 실사용하는 상용 서비스
  • 운영 과정에서 발생하는 이슈들로 인해 테스트 부족, 지원되지 않는 플랫폼에서 실행되는 등 기술부채가 발생한다.

• 데브옵스는 브라운필드 프로젝트 전환도 가능하다.

  • 예시) 아메리칸 에어라인즈, CSG

• 데브옵스 전환 성과에 대한 예측 요소

  • 테스트 용이성
  • 배포 및 재설계가 용이한 아키텍쳐 구조로 만들어져 있는지

• 전환 사례 중 인상깊은 부분

  • 케슬 런: 공중 급유 시스템의 브라운필드 전환(2020)
  1. (p.145)업무를 하기 위해 과거로 회귀해서는 안 된다.
  2. 갈의 법칙: 간단한 시스템 구축 -> 시간을 들여 개선

기록 시스템과 참여 시스템을 모두 고려하라.

• 바이모달 IT
  • 기록 시스템 + 참여 시스템
• 기록 시스템
  • 트랜잭션과 데이터의 정확성이 중요한 비즈니스 시스템과 유사함.
  • ERP 등 사내시스템과 유사함.
  • 올바른 수행이 중요한 유형1
• 참여 시스템
  • 고객 또는 직원과 상호작용
  • 대고객 서비스와 유사하며 빠른 피드백 루프를 지원한다.
  • 빠르게 수행하는 것이 중요한 유형2
• 바이모달IT 거부 철학(CSG)
  • 모든 서비스는 기술적 우수성 + 빠른 배포 가 같이 이루어져야 한다.

가장 공감적이고 혁신적인 그룹에서 시작하라.

• 데브옵스 전환 초기 단계에선 이해도가 있고 신뢰하며, 검증된 인원을 보유한 팀을 선별한다.
  => 혁신 수용자, 선각 수용자 찾기
• 선별된 팀으로 진행하여 성공하면, 이를 선례로 조직적으로 확장시킨다.
  => 모든 곳에서 동시에 실행하는 빅뱅 접근법은 지양한다.
  

데브옵스를 전체 조직으로 확장하기

데브옵스 전환 성공 후, 성공 사례를 기준으로 데브옵스 전환 범위를 조직으로 확장한다.
1. 임계량 및 전기 다수 수용자 확보

• 성공 사례를 받아들일만한 인원을 확보하여 데브옵스 프랙티스 영향력을 키운다.
• 데브옵스 프랙티스를 확장하여 임계량을 확보한다.

2. 저항자 확인

• 다수의 데브옵스 전환 성공 케이스를 근거로 저항자들에 대해 데브옵스 전환 작업을 진행한다.

• 사례 연구: '아메리칸 에어라인즈 데브옵스 전환' 에서 눈여겨본 부분

  • 모든 것을 시도하기보단 명확한 미션 수행
    => 시작하기보다 끝내기
  • 개인의 과도한 노력보다 권한의 위임
    => 팀 단위 작업이므로 위임하여 목표 달성을 위한 효율을 올린다고 생각함.
  • 위계보다 '우리는 할수 있다' 를 강조
    => 목표 달성을 위한 협업이 중요한 만큼 분위기 조성이 중요하다는 것을 느낌.
  • 리더십은 상태 보고 회의가 아닌 실행 회의에 참여
    => 팀이 하는 일을 구체적으로 알고 가이드를 제공
    => 같은 목표로 나아감을 느끼게 하며, 팀원으로서 리더십을 느낄 수 있는 부분이라고 생각함.

• 사례 연구: 'HMRC 데브옵스 도입' 에서 눈여겨본 부분

  • 비즈니스 작업 팀에게 최대한의 자유를 부여해 문제 해결에 집중하도록 함.
    => 단기간 목표 달성을 위해 의사결정 과정 등을 최소화하는 부분이 현재 GPU-Live 와 유사하다고 느낌.
  • 규정된 플랫폼 사용
    => 공통 모듈/라이브러리, 개발 컨벤션, 프레임워크 고정 등 우리 팀의 개발과 유사함을 느낌.
    => 서비스를 다른 팀에 이관하더라도 동일 플랫폼이기에 기술적인 이슈가 없는 장점이 있다고 함.
    신규 기술들이 나온다면 적용하는데 오히려 불편한 것은 아닌지,,?

결론

• 데브옵스 전환 작업이라도 목표 시스템과 범위를 잘 설정하면 다른 부분에 영향을 주지 않고 전환하여 가치를 창출할 수 있다.
  => 강결합인 서비스는 나누기 어려울텐데 이런 경우는 어떻게 할지,,?

6장 - 가치 흐름 내 작업의 이해 및 시각화와 조직 전체로의 확장

노드스트롬의 가치 흐름 매핑 경험

• 각 팀이 담당하는 가치에 대해 이해를 돕기 위해 워크샵을 진행하여 가치 흐름을 실제 작업과 매핑한다.
• 가치 흐름 매핑 작업으로 제약 사항이 어디서 발생하는지 구체적으로 확인할 수 있다.

가치 흐름을 지원하는 팀 식별하기

• 가치 흐름을 발생시키는 팀을 선별해야 한다.

가치 흐름 맵을 만들어 작업을 이해하라

• 각 팀이 만들어낸 가치가 어떻게 흘러가는지 매핑하고 이를 문서화해야 한다.
• 전통적인 조직은 가치 흐름이 수백 단계로 나뉘어 있기 때문에 복잡하고 문서화에 별도의 시간이 필요할 수 있다.
• 이를 해결하기 위해 워크샵을 진행하여 방해요소를 제거할 수 있다.
• 가치흐름 맵 단계
  1. 상위 프로세스만 블록으로 구성(리드/프로세스 타임, %C/A 등 지표가 되는 값을 포함)
  2. 해결하려는 문제의 프로세스 확인
  3. 미래의 가치 흐름 맵 구성
     1. 미래 상태 정의
     2. 가설, 대응책 브레인스토밍하여 작성
     3. 가설 테스트 및 결과 해석
     4. 1~3 반복

전담 트랜스포메이션 팀 구축하기

• 승인 절차를 강조하는 관료주의는 변화하는 시장 상황에 맞춰 업무 방식을 변경하기 어렵다.
• 각각의 팀들은 일상 업무를 같이 수행해야 하기 때문에 업무 방식 변경에 어려움이 있다.
• 이를 해결하기 위해선 전담 팀을 구성해야 한다.(고빈다라잔 박사, 트림블 박사 주장)
  => 일상 업무와 데브옵스를 병행하는 방식과는 반대됨.

개선 계획

1. 공유된 목표에 동의하기

   • 계획을 작성하고 조직의 모든 구성원에게 이해시킨다.
   • 이를 바탕으로 업무 과부하 방지를 위해 계획 개수를 제한해야 한다.
   • 규칙적인 작업 주기를 정해 반복적이며 점차적인 방법으로 진행한다.
     => 스프린트와 유사한듯?

2. 개선 계획을 위한 기간을 짧게 유지하기
   기간을 짧게 유지하여 아래와 같은 이점을 얻을 수 있음.

   • 다시 계획하고 조정할 수 있는 유연성 확보
   • 빠른 피드백 루프 가능
   • 목표 달성을 위한 에너지 감소 => 번아웃 발생 방지

3. 개발 및 운영 주기의 20%를 비기능 요구사항에 투자해 기술 부채 축소하기

   • 기술 부채로 인해 발생하는 일상 업무(장애 대응 등) 부담을 줄이기 위해 기술 부채를 해결해야 한다.
   • 점진적으로 해결할 수 있도록 꾸준한 시간 투자가 필요하다.
   • 대상 - 리팩토링, 자동화 작업, 아키텍쳐, 테스트 용이성, ...

4. 업무의 가시성 증대하기

   • 업무 진행 상태를 시각화하여 목표 달성을 위한 현재 상태를 꾸준히 파악하고 이를 바탕으로 지속적으로 개선해야 한다.

행동 변화를 촉진하기 위한 도구 사용

• 공통된 도구(지라, 슬랙, ...) 사용으로 개발과 운영이 같은 목표를 가지게 한다.
• 공통 백로그를 갖게 함으로서 개발과 운영 간 사일로를 해결하고 업무의 연관관계를 명확히 인지시킬 수 있다.

결론

• 가치 흐름 맵을 작성하여 문제를 효율적으로 발견하고 업무 우선 순위를 배정할 수 있다.