스크럼(Scrum)방법론에서의측정 지표 분석 및 사례 연구

Yahoo Korea/PMOSoonSam Hwang

Nov. 2008

- 2 -

INDEX

• 서론

• 연구배경

• 연구모델

– 연구 프레임워크 / 스크럼 소개

• 연구결과

– 스크럼 측정 분석 결과

• 사례연구

– 야후코리아 스크럼 측정 사례

• 결론

- 3 -

서론

• 소프트웨어 개발 환경의 변화

– 속도와 융합의 시대 (time to market & Convergence)– 짧아지는 시스템 라이프 사이클

– 높아지는 사용자의 다양한 욕구 충족의 어려움

• 전통적인 방법론의 한계점

– 계획 중심의 통제

• 본래 계획에 집착함으로써 변화하는 고객의 요구사항 충족에 실패

• 계획과 개발이 따로 따로

– 변화 대응의 어려움

• 요구사항 변경을 통제함으로써 프로젝트의 유연성이 사라지고고객의 가치 전달 제공에 실패

– Optimization paradox: Jim Highsmith (Adative Software Devleopment)• 소프트웨어 개발을 선형적이고 순차적인 활동으로 정의하고 예측과 통제를

강조하고 있으나 소프트웨어 개발의 비선형적이고 불확실성으로 인하여오히려 더 큰 실패를 초래

- 4 -

서론

• 가벼운 프로세스 (Light weight process) – 문서와 산출물 중심의 무거운 방법론을 대치할 대안의 필요성

공감

– 2001년 Agile Manifesto for Agile software development 선언

– 애자일 프로세스: Extreme programming, Scrum, Lean software development, Adaptive system development, Dynamic System Development, Crystal method, etc.

• 애자일 프로세스 공통적 특징

– 경험을 바탕으로 출발: XP나 Scrum의 경우 저자의 다양한프로젝트 경험을 바탕으로 발전하였으며, Crystal은 Cockburn이여러 프로젝트 참여자들에게 수행한 인터뷰와 관찰을 통해 시작됨

– 가벼우며 실천적이고 결과 중심

– 의사소통과 협력을 통한 상호 작용 강조

– 짧은 반복 과정에서 얻은 경험을 최대한 반영하여 개선

- 5 -

서론

• 애자일 프로세스 확산

– “ Enterprise Agile Adoption in 2007” by Forrester research (2008)• http://www.forrester.com/Research/Workbook/0,9126,45015,00.html• 미국과 유럽의 기업의 25%가 애자일 프로세스를 활용

• 2007년 도입 속도는 2006년의 2~3배로 가속화 되고 있음

– Dr Dobb’s 2007 Agile Adoption Survery by Ambler (2007) • http://www.ambysoft.com/surveys/• 4,232명의 개발자를 대상으로 애자일 설문 조사 결과를 Dr. Dobb’s

Journal에 발표

• 60% 응답자가 기존 방법론에 대하여 생산성 증가

• 66% 응답자가 시스템 품질 향상

• 56% 응답자가 비즈니스 만족도 향상

- 6 -

연구배경

• 기존연구 1: Schwaber (1995) – 소프트웨어 개발은 Empirical process control (경험적 프로세스 통제)가

적합: Why? Because of noisy!– 상세 계획 수립과 이를 통제하기 위한 많은 측정 지표로 인한 비생산적

자원의 낭비 발생

– 반복적이고 적절한 검사를 통하여 결과에 유연하게 대응해야 함

– 계획 자체가 중요한 것이 아니라 실제 고객에게 전달되는 결과물의 가치에주목해야 함

- 7 -

연구배경

• 기존연구 2: Awad (2005)– 무거운 방법론 한계점

• 복잡하고 예측하기 어려운 개발환경에서 변화를 수용하거나 원활한의사소통을 하는데 어려움

• 프로세스 지향적으로 많은 문서 작업과 비용 중시의 통제

– 애자일 방법론의 한계• 큰 조직에서 적용하기에는 체계적이지 못함

• 구체적인 프로세스나 방법을 제시하지 못함

• 사람의 능력에 너무 의존적인 방법

• 고객과의 어려운 협력 현실을 무시

• 기존 연구 3: Marcal (2007) – CMMI과 애자일 비교 연구

• 프로젝트 관리(Level 2)의 낮은 성숙도 수준을 충족– 프로젝트 산정, 비용 예측, 위험관리, 비용 수립 및 통제, 프로젝트 데이터 관리,

프로젝트 통합 관리에 대한 프랙티스 부족

– Formal documents 부족

- 8 -

연구배경• 기존 연구 4: Gilb (2007)

– 애자일의 한계점 지적 (성능과 품질 부족) • 애자일은 개발 속도와 생산성 향상에 초점

• 요즘과 같은 경쟁 환경에서는 기능은 기본이고 성능과 품질이 제품 경쟁력결정

• 애자일에서도 성능과 품질에 대한 정량적 측정이 수반되어야 함을 강조

• 기존 연구– 초기 연구는 프로세스 및 특성 소개에 치중하였으며 이후 기존

방법론과의 비교/분석 수행, 최근에는 품질 관점에서 한계점지적이나 기존 방법론과의 통합 방안에 대한 탐색 진행

– 측정과 통제 부족을 애자일의 주요 한계점 중 하나로지적하였으나 구체성 측면 미흡

– 결과를 측정 및 차이를 분석하고 목표 달성을 조정하는 통제는프로세스와 마찬가지로 중요함

– 소프트웨어 측정 프레임워크에 따라 새로운 방법론에 대한강점과 약점을 구체적으로 파악하고 대안을 모색할 필요가 있음

- 9 -

연구모델• 소프트웨어 측정

– 활용 관점에 따라 다양한 소프트웨어 측정 프레임워크 존재

– Fenton (1990) SW 측정 프로세스를 프로세스, 프러덕트, 리소스로 구분

– Florac (1999) 소프트웨어 측정에서 목표 지향적 접근을 강조

• 조직의 비즈니스 목표와 우선순위를 수립하고 이를 측정할 수 있는 SW 측정 프레임워크 필요

• 경쟁력 있는 제품 및 서비스를 고객에게 제공함으로써 고개만족도를 향상시키는 것이 궁극적인조직의 목표

– 제품의 기능 향상/ 비용 절감 / 적시 출시 / 고객만족도 향상

– 소프트웨어 개발 과정: 프로세스와 프로젝트 관리로 구분

- 10 -

연구모델

• Florac (1999): Software mesurement framework from “practical software measurement”

비즈니스 목표 프로젝트 측정항목 프로세스 측정항목 측정 지표

기능기능 개선개선(Increase function)(Increase function)

제품제품 성장율성장율(Product growth)(Product growth)제품제품 안정성안정성(Product stability)(Product stability)

제품제품 적합도적합도(Product conformance)(Product conformance)프로세스프로세스 적합도적합도(Process conformance)(Process conformance)

요구사항요구사항 수수 (Number of Requirements)(Number of Requirements)제품제품 크기크기 (Product size)(Product size)제품제품 복잡도복잡도 (Product complexity)(Product complexity)요구사항요구사항 변경률변경률 (Rate of change)(Rate of change)부적합부적합 비율비율 (Percentage of nonconforming)(Percentage of nonconforming)

비용비용 절감절감(Reduce cost) (Reduce cost)

예산예산(Budgets)(Budgets)

실적실적(Expenditure (Expenditure rates)rates)

효율성효율성(Effectiveness)(Effectiveness)생산성생산성(Productivity)(Productivity)재작업율재작업율(Rework)(Rework)

제품제품 크기크기 (Product size)(Product size)제품제품 복잡도복잡도 (Product complexity)(Product complexity)투입투입 공수공수 (Effort)(Effort)변경변경 요구사항요구사항 수수 (Number of change)(Number of change)

적기적기 출시출시(Reduce time to (Reduce time to

market)market)

개발개발 일정일정(Schedule)(Schedule)진척율진척율(Progress)(Progress)

생산율생산율(Production rate)(Production rate)

투입투입 시간시간 (Elapsed time)(Elapsed time)완성된완성된 작업작업 수수 (# of work completed)(# of work completed)

고객만족도고객만족도향상향상

(Improve Customer (Improve Customer Satisfaction)Satisfaction)

제품제품 품질품질(Product quality)(Product quality)

프로세스프로세스 품질품질(Process quality)(Process quality)

결함밀도결함밀도 (Defect density) (Defect density) 단계별단계별 유입된유입된 결함결함 수수 (Number of defects (Number of defects

introduced)introduced)결함결함 발견발견 효율성효율성 (Effectiveness of defect (Effectiveness of defect

detection activities)detection activities)

- 11 -

연구모델• 스크럼(Scrum)

– 스크럼이란 럭비에서 유래된 것으로 반칙이나 경기를 다시 시작할 때 양팀 선수들이 대형을 짜는것을 의미

– Takeuchi와 Nonaka가 1987년 생산성이 우수했던 일부 기업들의 제품 개발 프로세스 유형을가르키는 용어로 사용되었으며 Ken Schwaber와 Jeff Sutherland가 스크럼 방법론으로 창조

– 스크럼은 반복적이고 점진적인 프로세스를 통해 제품을 개발하고 작업을 관리

- 12 -

연구모델• 주요 스크럼 산출물

Sprint BacklogDaily estimate & Burndown chart

Product Backlog

- 13 -

연구결과• 스크럼 측정 평가 기준

• 프로젝트 관리 항목 측정 결과

평가 결과 척도

만족 측정 지표를 정량적으로 만족시킨다.

일부 만족 측정 가능한 산출물이 존재하거나 측정 지표를 부분적으로 만족한다.

불만족 측정 가능한 산출물이 존재하지 않거나 측정 지표를 전혀 만족하지 못한다.

• 프로세스 관리 항목 측정 결과

프로젝트측정 변수

측정 대상스크럼 산출물

충족 수준

제품 성장률제품 안정성

제품 백로그스프린트 백로그

부문 만족

예산/실적 N/A 불만족

개발 일정 스프린트 백로그 만족

진척도 번다운 차트 만족

제품 품질스프린트 데모,테스트 결과

부문 만족

프로세스측정 변수

측정 대상스크럼 산출물

충족 수준

제품 적합도프로세스 적합도

스프린트 데모테스트 결과스프린트 회고

부문 만족

효율성 N/A 불만족

생산성번다운 차트수행 속도(Velocity)

만족

재작업율 스프린트 백로그 부문 만족

생산율스프린트 주기릴리즈 백로그

부문 만족

프로세스 품질 스프린트 회고 부문 만족

- 14 -

연구결과

• 스크럼 측정 분석 결과

– 비즈니스 목표 달성 관점• 기능 개선: 제품 관리 측면에서 요구사항과 스펙에 대하여 백로그를 통하여 관리하고 있으나

정량적이지 못함. 제품에 대해서는 요구사항에 부합하는지는 테스트하고 있으나 개발 프로세스는측정이 아닌 Scrum retrospective을 통한 회고 활동으로 개선 공감대 형성을 목적으로 함 (self-organizing)

• 비용 절감: 전체 비용 예산을 수립하고 계획 대비 실적을 관리하지 않음. 이는 스크럼이 스프린트주기로 작업량을 산정하지만 공수가 얼마나 투입되었는지에 대하여 관리하는 것은 아니며 남은작업을 중심으로 실적 관리

• 적시 출시: 스프린트 주기별로 개발 일정을 산정하고 남은 작업을 매일 측정하고 번다운 차트를통해 개발 속도와 생산성을 측정

• 고객만족도/품질 향상: 스프린트 주기로 증분 결과물을 테스트하고 데모를 통해 사용자의 피드백을짧은 스프린트 주기로 취합하여 계획에 반영

– 프로젝트 및 프로세스 관리 측면• 스크럼 자체가 프로젝트 관리 위주로 CMMI나 ISO 15504와 같은 프로세스의 역량을 측정하고

개선하는데 취약함

• 스크럼 방법론은 소프트웨어 개발 과정을 불규칙적이고 비선형적 프로세스를 통해 구현된다고보고 있기 때문에 정해진 계획보다는 현재 성과를 반복적으로 자주 검토하고 변화에 유연하게대응하기 위한 경험적 프로세스(emprical process)으로 보고 있음

- 15 -

연구결과

• 스크럼 취약점에 대한 고려 사항

– 비용 관리• 백로그를 통하여 릴리즈 범위와 일정을 결정하고 초기 시스템 아키텍트를 검증할 수 있도록

계획 중심의 초기 스프린트 수행

• 총 스프린트 반복 횟수와 대략적 총 투입 공수 산정하여 비용 기준선 수립하고 진행하면서구체화 : Progresive elaboration (점진적 상세화)

• 스프린트 단위로 예산 대비 비용 점검 (획득가치 활용)하여 계획 조정(기준선 재설정)

- 16 -

연구결과• 스크럼 취약점에 대한 고려 사항

– 개발 프로세스• 스크럼은 다른 방법론의 Wrapper 역할

• XP와 같은 애자일 개발 방법론과 결합하여 시너지 효과 발생

• 무거운 방법론과의 결합은 스크럼의 장점과 유연성 감소

- 17 -

연구결과• 스크럼 취약점에 대한 고려 사항

– 프로세스 관리• 프로젝트 위주로 프로세스 관리와 품질 관리에 취약

• Boehm (2003) : Balancing Agility and Discipline• 스크럼을 소규모 조직 단위나 파일럿을 통하여 검증하고 이를 점차 확산해 나가는 것이 필요

• 비즈니스 우선 순위에 따라 핵심 프로세스 지표를 수립하고 지속적으로 측정 / 개선 노력 중요

- 18 -

사례연구

• Yahoo의 스크럼 측정 사례

– 1994년부터 스크럼 방법론 도입하여 현재 표준 방법론 중 하나로 정착하고 프로세스개선을 위한 PPC (process & Project Champion) 전담 조직을 글로벌하게 운영

– 프로젝트 관리 측정 변수

• 개발 일정, 진척도, 제품 품질, 제품 성장율 및 안정성

Sprints lists Sprint backlog

- 19 -

사례연구

Progress & Burn down chart

- 20 -

사례연구

Php undercontrol (unit test) CI (Continuous Integration) 체계

- 21 -

사례연구

Functional test Performance test

- 22 -

사례연구

User test (Beta Test)

- 23 -

사례연구

• 프로세스 관리 측정 변수

– 제품/ 프로세스 적합도, 생산성, 릴리즈 관리

• 기능 테스트와 스프린트 데모, 스프린트 회고

• 번다운 차트, Velocity (수행 속도) • 릴리즈 백로그

Release backlog

- 24 -

결론

• 스크럼의 측정 분석

– 스크럼은 프로젝트 관리 측정 항목에서 개발 일정과 진척도를 만족시키며 일정관리에 강한 반면 비용 관리, 프로세스 효율성, 품질 측정에 취약하므로 조직에서비용 절감이나 품질 관리를 위하여 스크럼을 도입시 이에 대한 보완책 필요

– 스크럼은 프로세스 관점에서는 약한 반면 프로젝트 관리에서는 상대적으로 많은산출물로 측정이 가능함.

– 프로세스 성숙도가 높은 기업에게는 스크럼을 관리 도구나 방법으로 활용하여프로젝트 관리 성과를 높이는데 잘 사용될 수 있으나 프로세스 성숙도가 낮은기업에서는 이에 대한 보완책이 필요할 것으로 보임.

• 향후 연구 주제

– 도출된 결론에 대하여 실제 사용자들 대상으로 설문조사를 통한 연구 결과 타당성검증

– 최근 애자일 확산에 따라 다양한 비즈니스 도메인별로 적용 사례를 넓혀 포괄적결론이나 도메인별 차이점을 분석

– 스크럼뿐만 아니라 애자일에 속하는 여러 방법론에 따른 프로세스에 대한 전반적측정 지표 연구 및 비교 필요

- 25 -

Q & A