Agile 방법론에서의 측정지표분석 및 사례 연구:

Scrum practice를 중심으로

Yahoo Korea/PMO

황순삼

- 2 -

INDEX

• 서론

• 연구배경

• 연구모델

– 연구프레임워크, 스크럼 측정 분석 결과

• 스크럼 측정 사례

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

• 결론

- 3 -

서론

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

– 적시 출시 (Time to market)– 복잡하고 대규모 시스템간의 통합

– 짧아지는 시스템 라이프 사이클

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

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

– 계획 중심의 통제

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

– 변화 대응의 어려움

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

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

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

- 4 -

서론

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

공감

– 2001년 Agile Manifesto for Agile software development 선언

– Agile 방법론 등장: Extreme programming, Scrum, Lean software development, Adaptive system development, Crystal, etc.

• 기존의 애자일 연구들

– 가벼운 방법론의 특징과 프로세스를 소개하거나 기존의 전통적방법론과의 프로세스 비교 위주로 이루어짐

– 애자일 방법론을 조직의 목표 달성을 위하여 어떻게 활용할 수있는가에 대한 연구가 필요

– 조직의 목표 달성을 위해서는 프로세스와 마찬가지로 목표와실적을 비교하고 조정하기 위한 측정에 대한 연구도 필요

- 5 -

연구배경

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

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

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

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

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

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

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

• 기존연구 2: Ken (2006) – Empirical process control 필요

– 상세 계획 수립과 이를 통제하기 위한 많은 측정 지표로 인한 비생산적 자원의낭비 발생

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

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

- 6 -

연구배경

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

• 프로젝트 관리(Level 2)의 낮은 성숙도 수준 충족– 형식적인 문서 부재

– 위험이 정의되지만 분석되어 관리되지 못함

– 이슈 및 리소스에 의지하는 관리

• 기존 연구 한계점

– 기존 연구에서 주로 프로세스에 대하여 다루어 옴

– 측정과 통제 부족을 애자일 방법론 한계점으로 지적하고 있으며

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

– 조직의 비즈니스 목표 달성을 위하여 새로운 방법론에서 무엇이측정되어야 하는지에 대한 구체적 방법에 대한 연구가 필요

- 7 -

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

– 소프트웨어 개발 과정을 포괄하는 일반적인 측정 프레임워크 활용 필요

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

• 제품의 기능 향상

• 비용 절감

• 적시 출시

• 고객만족도 향상 (품질 개선) – 소프트웨어 개발 개발 관리는 크게 프로세스와 프로젝트 관리 프로세스로 구분 가능:

William (1999), Measuring the software process

- 8 -

연구모델

• 비즈니스 목표 달성을 위한 측정 프레임워크

비즈니스 목표 프로젝트 측정변수프로세스측정변수

측정 가능한 제품 및 프로세스측정 변수

기능 개선(Increase function)

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

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

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

비용 절감(Reduce cost)

예산(Budgets)

실적(Expenditure rates)

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

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

적기 출시(Reduce time to

market)

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

생산율(Production rate)

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

고객만족도향상

(Improve Customer Satisfaction)

제품 품질(Product quality)

프로세스 품질(Process quality)

결함밀도 (Defect density) 단계별 유입된 결함 수 (Number of defects introduced)결함 발견 효율성 (Effectiveness of defect detection

activities)

- 9 -

연구모델

• 스크럼 프로세스

- 10 -

연구모델

• 스크럼 산출물 및 측정 변수

Sprint Backlog

Daily estimate & Burndown chart

- 11 -

연구모델

• 스크럼 측정 분석

– 프로젝트 측정 변수 (평균:60)

– 프로세스 측정 변수 (평균: 41)

프로젝트 측정 변수 측정 가능한 스크럼 산출물 충족 수준

제품 성장률/안정성 제품 백로그 부문 만족

예산/실적 N/A 불만족

일정 스프린트 백로그 만족

진척률 번다운 차트 만족

품질 스프린트 데모, 테스트 결과 부문 만족

프로세스 측정 변수 측정 가능한 스크럼 산출물 충족 수준

제품/프로세스 적합도스프린트 데모, 테스트 결과스프린트 회고

부문 만족

효율성 N/A 불만족

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

만족

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

생산률 스프린트 주기(Sprint cycle) 부문 만족

프로세스 품질 N/A 불만족

- 12 -

연구모델

• 스크럼 측정의 강/약점 분석

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

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

• 비용 절감: 전체 비용 예산을 수립하고 계획 대비 실적을 관리하지 않는데 스크럼은 스프린트주기로 작업량을 산정하지만 공수가 얼마나 투입되었는지에 대하여 관리하는 것이 아니라 현재시점에서 남은 작업량을 번다운 차트를 통해 관리한다.

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

• 고객만족도/품질 향상: 매 스프린트 단위로 결과물을 테스트하고 데모를 통해 사용자의 피드백을수집

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

개선하는데 취약함

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

- 13 -

측정 사례

• Yahoo의 스크럼 측정 사례

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

– 프로젝트 관리 측정 변수

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

Sprints lists Sprint backlog

- 14 -

측정 사례

Progress & Burn down chart

- 15 -

측정 사례

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

- 16 -

측정 사례

Functional test Performance test

- 17 -

측정 사례

User test (Beta Test)

- 18 -

측정 사례

• 프로세스 관리 측정 변수

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

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

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

Release backlog

- 19 -

결론

• 스크럼의 측정 분석

– 스크럼은 비즈니스 목표 달성 관점에서 기능 개선과 적시 출시 측면에서 비교적 강한반면 비용 절감과 품질 관리 측면에서는 매우 취약하므로 조직에서 비용 절감이나품질 관리를 위하여 스크럼을 도입시 이에 대한 보완책을 마련해야 함

– 스크럼은 프로세스 관점에서는 매우 약한 반면 프로젝트 관리 관점에서 비교적 많은측정 지표를 제공함. 따라서 프로세스 성숙도가 높은 기업에게는 스크럼을 관리도구나 방법으로 활용하여 프로젝트 관리 성과를 높이는데 잘 사용될 수 있을 것으로보이는 반면 프로세스 성숙도가 낮은 기업에서 도입시 이에 대한 보완책이 필요할것으로 보임. (Ex: 측정 매트릭, 개선 프로세스, QA 활동 등)

• 향후 연구 주제

– 최근 애자일 확산에 따라 다양한 비즈니스 도메인별로 적용 사례를 연구

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

– 무거운 방법론과 가벼운 방법론간의 장점을 고려한 구체적 적용 방법과 성공 사례를제공하여 전통적인 방법론에 익숙한 조직에게 애자일을 활용할 수 있는 실무적가이드 마련

- 20 -

Q & A