성공적인 소프트웨어 신상품 개발가이드
1) 스크럼 프로세스의 기원
스크럼은 ‘미식축구나 럭비에서, 세 명 이상의 선수가 공을 에워싸고 서로 어깨를 맞대어 버티는 공격 태세’이다. 신상품개발에서 ‘스크럼’이라는 용어는 암묵지와 형식지의 창지사인 노나카 교수의 논문인 “The New New Product Development Game(1986, 하바드 비즈니스 리뷰) 에서 처음 사용되었다. 논문에서는 신제품 개발방식을 아래그림과 같이 3가지 유형으로 분류한다. 타입A는 단계의 중복이 없이 문서로 지식이 전달되는 반면 타입 C는 첫단계의 인력이 끝까지 남는 것을 볼 수 있다. 타입 C는 문서를 통해 지식과 정보를 전달하는 것이 아니라 사람을 통해 지식과 정보를 전달하는 방식이다. 노나카는 럭비공 전달방식에 지식전달 방식을 비유하여 스크럼이라는 용어를 사용하였다.
스크럼의 창시자인 제프 서덜랜드와 캔 슈와버도 많은 아이디어를 노나카 교수의 논문에서 얻었음을 공개적인 자리에서 말하였다. 노나카의 논문에서는 성공적인 신상품 개발의 특징을 6가지로 정의하고 있다.
- 불확실한 상태 유지(built-in instability)
도전적인 목표를 제시하고 수행방법은 팀원에게 맡긴다. 구체적인 요구사항이 확정되지 않았기에 신상품 개발은 계획서에 기반한 활동이 아니라 불확실한 상황에서 경험에 기반하여 요구사항을 정의하고 일정을 추정하는 활동이다.
- 자기 조직화 팀 (self-organizing project teams)
불확실한 환경으로부터 팀의 동적인 질서가 만들어진다. 자기 조직화한 팀은
첫째, 팀이 스스로 중요한 의사결정을 하고 둘째, 자신들의 한계를 초월하기 위해 노력하고 셋째, 팀내에서 서로 다른 지식의 교류가 일어난다. 교차기능 팀(Cross Functional Team)을 한 장소에 모이게 하면 나 한 사람의 입장뿐만 아니라 팀 전체 입장에서 최선의 결정을 고민하게 된다.
- 개발단계의 중복(overlapping development phases)
신상품 개발단계를 중복하기 위해서는 여러 단계를 수행하는 사람들이 함께 일해야 한다. 설계, 디자인, 생산, 영업, 연구소, 마케팅 부서의 직원들이 같은 장소에서 근무하는 것이다. 그 결과 산출물을 통해 정보를 전달하는 대신 사람을 통해 정보가 공유된다.
단점으로는 프로젝트 전체에 많은 의사소통이 필요하고 의사소통이 미흡한 경우 다른 분야 사람들과 의견 충돌이 잦을 수 있다.
- 다중학습(multi learning)
다중학습은 개인뿐만 아니라 팀도 학습한다는 의미다. 예를 들어 교차기능 팀원으로 함께 일하면 개인뿐 아니라 팀도 학습한다는 개념이다. 스포츠 경기에서 팀 플레이를 통해 높은 수준의 팀웍을 유지하는 것도 비슷한 비유가 될 수 있다. 다 능력 학습은 다른 분야의 학습을 의미한다. 프로젝트 관리자가 마케팅을 배우고, 생산이 설계를 배우는 것이다.
- 유연한 관리체계 (subtle control)
너무 강한 관리도 문제이고, 관리가 없는 것도 문제이다. 불확실성과 애매함으로 인해 혼돈에 빠질 정도가 되면 안 된다. 유연한 관리의 세 가지 특징은 ‘자기관리’, ‘상호관리’, ‘애정에 의한 관리’이다.
- 조직 내 경험 지식 공유 (organizational transfer of learning)
조직 내에 지식을 공유하는 방법은 핵심인물을 다른 프로젝트에 투입하거나 특정 프로젝트의 수행방법을 조직의 표준으로 정해 확산하는 것이다.
2) 스크럼 프로세스 요약
제프 서덜랜드와 캔 슈와버도는 척박한 소프트웨어 개발 환경을 개선하고자 노나카 교수의 이론을 1994년부터 소프트웨어 개발에 적용하면서 스프린트를 핵심으로 하는 스크럼 프로세스를 정립하여 2002년에 ‘스크럼’을 출간하였다. (국내는 2008년에 번역본 출간) 스크럼 프로세스를 그림으로 요약하면 다음과 같다.
스크럼 구성의 핵심을 설명하면 다음과 같다.
- 상품개발을 위해 필요한 역할자는 모두 하나의 팀으로 작업한다.
- 스프린트라고 부르는 짧고 동일한 개발 주기(1주 ~ 1개월)를 반복 수행한다.
- 각 스프린트에서 개발할 소프트웨어 기능은 스프린트 착수 전에 확정한다.
- 각 스프린트에서 개발할 기능(스프린트 백로그)은 변경하지 않는 것을 원칙으로 한다.
- 프로젝트 가시성을 높이고, 협업을 증진시키기 위해 매일 각자 업무현황을 간단히 공유한다.(일일 스크럼)
- 스프린트 종료 시 개발한 기능에 대한 검토(스프린트 리뷰)와 개발 프로세스의 개선사항 도출을 위한 검토(회고)를 진행한다.
https://brunch.co.kr/@kbhpmp/160