5 분 소요

본 글은 HARD CODE:나잘난 박사의 IT 정글 서바이벌 가이드에서 인용했습니다.

6시그마

정의

6시그마는 소위 ‘도구 상자’라는 기법 모음을 사용해 체계적으로 문제를 해결하는 시스템이다. 정의(define), 측정(measure), 분석(analyze), 개선(improve), 통제(control)의 순서를 갖는다.

6시그마 전문가가 필요한 이유

  • 돌발상황이 발생했을 때, 이미 잘 아는 지식도 잊어버리므로, 전문가를 통해 현재 단계에서 해야하는 프로세스를 분석하고 다음 업무를 수행하도록 도와줌.
  • 다만, 지나치게 체계적이라 팀내 열정과 개성이 사라질 수 있다.

6시그마는 TQM(Total Quality Management)과 CQI(Continuous Quality Improvement)의 재활용 개념인 듯하다.

내 생각: 6시그마 전문가는 요즘 기준으로 DevOps 전문가 같다.

린 개발론

개발 방법론은 집착하는 것이 아니라 유연하게 따라가는 것이고 가장 중요한 것은 ‘원리를 파악하고 디버깅하는일’이다. 항상 어떤 문제에 대해 ‘왜’라느 질문과 ‘어떻게’라는 원리를 이해하려는의지가 필요하다. 개발 패러다임이 갖고 있는 아이디어가 나쁜게 아니다. 단지 생각하다보니 그것보다 좋은 생각이 떠올라서 제안한 것 뿐인데 패러다임 추종자들은 날뛰며 화를 낸다. 마치 종교처럼.

정의

낭비하는 노력을 줄여서 고객에게 최고 가치를 전달한다는 개념으로, 도요타에서 적용한 기법이다. 즉, 필요한 일만하고 필요하지 않은 일은 하지 않는다. 여기에 지속적인 개선으로 낭비를 줄이고 고객 가치의 원맣난 흐름을 추구하는데 초점을 맞춘다. 린은 고객 가치의 흐름을 방해하는 낭비 원인으로 일곱 가지를 꼽는다.

  1. 과잉생산(Overproduction)
  2. 불필요한 운반(Transportation)
  3. 불필요한 동작(Motion)
  4. 대기(Waiting)
  5. 불필요한 공정(Overprocessing)
  6. 재고(Inventory)
  7. 결함(Defect)

1.과잉생산

  • 이미 명세하고 구현했다는 이유로 기능을 쳐내지 않고 제품 출시
  • 고객이 원하지 않는 기능을 넣은 채 제품 출시

럭비 용어를 딴 '스크럼(Scrum)' 프로젝트 관리 기법
팀은 고객 대표와 주기적으로 (대개 30일) 만나서 상태를 보고하고, 우선순위를 조정하고, 프로세스를 개선한다. 매달 우선순위를 조정하고 매일 작업을 재조정하는 방식으로 스크럼팀은 고객에게 중요한 업무에만 노력을 집중한다. 또한 주기적으로 프로세스를 개선함으로써 가치 흐름도 지속적으로 최적화한다. 이 때 주기를 스프린트(Sprint)라고 한다.

깊이가 먼저다

‘기반 설비’를 구축하는 동안 고객이 무작정 기다려야 한다면 스크럼과 XP(eXtreme Programming)는 별다른 효과를 발휘하지 못한다. 극단적인 폭 우선(Breadth First)방식은 모든 기능을 명세하고 나서, 모든 기능을 설계하고, 모든 기능을 구현한 다음, 모든 기능을 테스트한다. 극단적인 깊이 우선(Depth First)방식은 한 기능을 명세하고 설계, 구현, 테스트한 후 다음 기능으로 넘어간다. 당연히 어느 쪽이든 극단은 바람직하지 못하지만, 깊이 우선 방식이 폭 우선 방식보다 훨씬 낫다. 폭 우선 방식으로 전체적인 설계를 진행한 후 재빨리 깊이 우선 방식으로 전환해 구체적인 설계와 구현을 진행하는 방법이 바람직하다. (MS의 방식)

MS Office팀 방식

  1. 전체적으로 필요한 기능과 각 기능의 상관관계를 결정
  2. 한 번에 명세 하나에만 집중할 기능팀 구성 (기능팀은 되도록 작게 구성) 깊이 우선방식 개발로 멋진 예로는 테스트 주도 개발 방법론(TDD, Test Driven Development)이 있다.

2.불필요한 운반

불필요한 운반은 뭔가 도착하기를 기다리는 시간이다. 불필요한 운반 문제를 일으키는 세 가지 까다로운 원인은 빌드, 가지치기, 이메일이다.

  1. 빌드 : 애자일에서는 일일빌드를 주장하지만, 규모가 큰 프로젝트의 경우 어렵다.
  2. 가지치기 : MS에서 소스 형상관리 툴을 Source Depot를 사용하는데 여러 가지를 치는데 있어 개발자 간 서로 역통합을 해야해서 문제가 발생할 수도 있고 속도도 더디다.
  3. 이메일 : 개발팀에서 테스트팀에 이메일을 보내고 대기하는 시간이 반복 될 수록 불필요한 시간이 낭비된다.

내 생각: Source Depot를 찾아보니 MS에서는 더 이상 쓰지 않고 Git을 사용하며(VS Code에서 확장으로 제공됨), 요즘은 Git에 Commit Trigger를 가로채서 자동빌드를 도와주는 Jenkins 서버가 잘 되어있다.

3.불필요한 동작

불필요한 동작은 뭔가 찾느라 보내는 시간이다. 소프트웨어에서는 할 일을 찾거나, 갈 곳을 찾거나, 고칠 방법을 찾느라 낭비하는 시간 등을 말하며, 부실한 기술 검색이 좋은 예다.

4.대기

대기는 뭔가 기다리느라 보내는 시간이다. 가장 흔하고도 치명적인 낭비는 팀들이 우선순위에 동의하지 못하거나 미리 정한 우선순위를 따르지 않아서 허비하는 시간이다.

5.불필요한 공정

과도한 엔지니어링도 치명적으로 낭비되는 시간이다. 기능을 너무 복잡하게 설계하거나, 성능에 문제가 없는 코드를 조율하거나, 필요하지 않은 곳에 확장성과 일반성을 추가하는 행위다. 이 낭비는 과잉생산과 유사하지만 구체적인 기능 구현 문제에 초점을 맞춘다. 해결책은 TDD다.

TDD의 절차

  1. API나 공개 클래스 메소드를 정의한다.
  2. API 또는 클래스가 요구사항을 만족하는지 확인하는 단위 테스트를 작성한다.
  3. 프로그램을 컴파일하고 빌드한 후 단위 테스트를 수행하여 통과 여부를 확인한다.
  4. 단위 테스트에 통과할 정도로만 코드를 작성한다.
  5. API 또는 클래스가 요구사항을 모두 만족할 때까지 2단계에서 4단계를 반복한다. TDD를 적용하는 습관을 들이면 꼭 필요한 코드만 구현하게 된다. 결과적으로 코드 응집도(cohesion)는 높아지고, 결합도(coupling)은 낮아지며, 중복성(redundancy)은 줄어든다.

6.재고

재고는 출시하지 않는 작업 결과물이다. 이 낭비는 완료하고도 안 넣은 기능만이 아니라 현재 진행 중인 작업도 포함한다. 실현되지 않은 가치는 낭비다. 고객이나 협력업체에게 시연하지 못하며, 따라서 피드백을 받지도 못한다. 고객 가치 흐름을 개선하거나 최적화하지도 못한다. 게다가 프로젝트 계획이 바뀌면 실현되지 못한 가치는 노력만 낭비한 애물단지로 전락한다. 스크럼과 TDD에더 보듯이, 린의 풀 모델은 필요한 일만 하므로 재고가 줄어든다.

7.결함

재작업 또한 치명적인 낭비다. 결함으로 인한 재작업을 줄이려면, XP와 Agile 기법을 적용하여, 프로젝트를 진행할 수록 지식이 쌓여가는 구조를 선택해야한다.

Dr.Watson은 윈도우 응용프로그램이 비정상적으로 종료할 때 등장하는 ‘오류 보고서 전송’ 대화상자 이면에 숨겨진 기능 이름이다. SQM(Software Quality Metrics)은 MS제품군에서 고객 경험과 사용 현황 패턴을 익명으로 수집하는 기술이다.

MS가 Agile을 선택하지 못한 이유

사실 모든 개발팀에게 Agile 방법론을 제시하고, 채택하라고 하고 싶지만, MS 처럼 고객 수가 10억 가까이되는 경우, 불가능하다. 10억의 고객을 모두 2주마다 미팅하고 그 피드백을 반영하는 것은 쉬운 일이 아니며, 그래서 고객과 간접적인 커넥션을 통해 요청을 자동화 할 수 있도록 시스템을 구축해두는 것이 좋으며, 좋은 예가 Dr.Watson과 SQM 이다. 실제로 MS는 Dr.Watson으로 고객에게 상당한 이익을 줬다.

버그 제보 역추적하기

  1. 문제의 코드를 작성하는 이유는? 어느 요구사항인가? 혹은 무슨 기능인가?
  2. 문제의 요구사항이나 기능은 어디서 나왔는가? 고객 시나리오에 있었는가?
  3. 문제의 고객 시나리오는 어디서 나왔는가? 시장 기회 문서나 고객 의견 조사에 있었는가?
  4. 누가 시장 기회 문서를 작성하고 고객 의견 조사를 수행했는가? 담당자 이메일 주소는?

추적성

추적성이 있으면 기능을 요청하는 고객 시나리오를 이해하게 된다. 즉, 각 기능이 가지는 연관성을 이해하므로, 아키텍처와 의존성을 올바로 파악하게 되고, 결국 프로젝트를 체계적으로 이끌기가 쉬워진다. 또한 기능을 올바로 구현하고 우선순위와 장단점을 파악하기 쉬워진다. 이 점은 기능을 수정할 때 일정관리에 도움을 준다. 추적성을 얻기 위해서는 버그와 충돌을 추적하듯이 시나리오와 요구사항을 추적하는 도구가 필요하다.

  • 영업팀과 컨설턴트는 이 도구를 사용해 고객 요구사항, 시나리오, 약속을 문서화한다.
  • 마케팅팀과 제품 기획자는 이 도구를 사용해 시장 요구를 제출하고, 시장 요구를 고객 의견 조사 결과와 연계하고, 여러 제품에 걸치는 핵심 시나리오를 정의한다.
  • 제품 기획자와 PM은 이 도구를 사용해 요구사항을 통합하고, 중복성을 추적하고, 시나리오와 제품을 연계하고, 제품 단위로 시나리오와 요구사항과 기능 명세를 작성한다.
  • 제품 그룹은 이 도구를 사용해 기능 요청을 선별하고, 설계와 구현단계에서 진도를 추적한다.
  • 데스크탑은 테스트 케이스와 버그를 시나리오와 연계해 문제의 중요성을 가시화한다.
  • 고객 요구사항을 수집한 담당자는 진행 상태를 추적하고, 제품팀이 자문할 경우 문제를 설명하거나 피드백을 제공하고, 상황이 변하면 제품 개발팀에 연락해서 요구사항을 고친다.

내 생각: 책에서 사내 작업 항목을 관리하는 프로그램으로 Product Studio를 언급하는데, MS에서 Product Studio는 없어진 제품이고, 현재 세계적으로 프로젝트를 관리하는데 많이 사용되는 프로그램은 Atlassian사의 JIRA 또는 Trello를 사용한다. 사내 대화 프로그램으로 MS Teams나 Slack를 사용한다면 JIRA, Trello 플러그인을 통해 간편하게 사용할 수 있다.

Agile 기본규칙

  • 변경을 위한 변경은 피하라 : 팀이 이미 기업 가치에 부응해 잘 해나가고 있다면 기존 방식을 변경할 필요가 없다. 개선이 필요하지 않다면, 변경도 필요 없다.
  • 과도한 시도는 자제하라 : 변경이 필요하다고 한 번에 모두 뒤엎어서는 안 된다. 조금씩 시도해서 조금씩 배우면서 조금씩 전진해야 한다.
  • 프로젝트 수준과 기능 수준을 구분하라 : 프로젝트에서는 일정이 최우선이다. 프로젝트의 수준을 파악하여 일정을 위배할 것 같은 수준의 고수준 기능을 넣는 것은 자제한다. 팀 간 비슷한 기법을 사용하면 업무 효율이 높아진다.

Agile 방법론에 속한 방식 : 스크럼(Scrum), 익스트림 프로그래밍(XP), 테스트 주도 개발(TDD), 짝 프로그래밍(Pair Programming), 사용자 스토리(User Story), 리팩토링(Refactoring), 지속적인 통합(Continuous Integration)

참고

스크럼 용어

  • 스크럼: 매일 모여서 진행하는 간단한 회의
  • 스크럼 마스터: 기능팀 조직자
  • 백로그: 기능 목록 혹은 작업 항목 목록
  • 번다운: 남은 업무를 표시하는 그래프
  • 스프린트: 작은 중간 목표
  • 닭과 돼지: 기업 농장에 사는 동물