개발자가 행복해지는 Agile

김수현, 강석현

삼성전자 소프트웨어센터

2016.11.17

Presenter

김수현

Agile Process Office, Software R&D center

Samsung Electronics

주요 경력

- Software Engineering & Programmer

- Open Source Compliance & Community

- Agile Coach (Certified Scrum Master)

- Agile Evangelist

애자일이란?

1970 1974 1980 1990

1991 1995 1996 2000

2001 2003

Waterfall Model (winston W. Royce)

Concept of “Adaptive Software Development”

(Edmonds, E.A.)

Rapid App. Development (James Martin)

Scrum (Ken Schwaber, Jeff Sutherland)

Adaptive Software Development(ASD) (Jim Highsmith, Sam Bayer)

FDD (Jeff De Luca)

DSDM (DSDM Consortium)

Crystal clear (Alistair Cockburn)

XP (Kent Beck, Ward Cunningham and Ron Jeftries)

Agile Manifesto

Lean SW Dev. (Marry & Tom Poppendieck)

Rational Unified Process (RUP) *IBM

http://agilemanifesto.org/

애자일과 기업규모와의 상관관계?

※ 출처 : VersionOne 2016 10th STATE of AGILE REPORT

12%

100~250 people

15%

1,001~5,000 people

38%

< 100 people

2016 2006

Agile 적용 기업 SW인력 규모 변화

31%

100~1.000 people

16%

5,001+ people

27%

250+ people

61%

< 100 people

Google 검색 Trends

Waterfall Process Agile Process

2004 2006 2008 2010 2012 2014 2016

애자일스럽다? F

ocu

s

Organization

Engineering

Process

1단계 2단계 3단계

※ 출처 : scrumalliance.org

애자일 프로세스?

▶ Agile 방법론 만족도 조사 결과 - 성취목표의 명확한 파악 및 업무 공유 강화 - 담당업무에 대한 주도적인 일정관리로 업무 효율 강화

0.00

1.00

2.00

3.00

4.00

5.00

프로세스

만족도

팀웍

과제의

가시화

SW 품질

PL과

의사소통

TL과의

의사소통

팀원간의

의사소통

개발

생산성 Agile 적용 후

Waterfall

[ Waterfall 대비 평균 24% 향상] - 프로세스 35%, 과제 가시화 33%, 의사소통 25%

- 팀워크 19%, 개발생산성 & 품질 18%

Sprint Planning

Daily Stand-up

Sprint Review

Sprint Retrospective

User Story Workshop

다음에 해야 할 백로그는?

구현 완료 코드리뷰 완료 단위 시험 완료 통합 시험 완료 시스템시험 완료 사용자 문서 완료 배포 완료

Unit-Testing

(63%)

Continuous-

Integration (50%)

Test-Driven

Development (33%)

Continuous

Deployment (27%)

Pair-Programming (24%)

각 Iteration에서의 완료기준을 강화하여 Potentially Shippable Product 추구

Presenter

강석현

Tizen Platform Lab, Software R&D center

Samsung Electronics

주요 경력

- 2004년부터 모바일 개발 업무 시작

- 국방부, 농촌진흥청 등 스마트 정보화 사업

- 방송통신위원회, SKT, KT 마케팅 컨쇼시엄

- 2012년 삼성전자 이직

Main Practice

매주 사용자 검증을 통한 사용자 피드백에 따른 제품 개선

Whole Team 개발자, 디자이너, PM(Product Manager)이 같은 장소, 시간에서 작업

Pair Work 개발자, 디자이너, PM 모두 Pair Work 수행

User Centric

기능 구현 전 해당 기능의 테스트 코드부터 작성 Test Driven

Development

Dro

p t

he b

eat

Main Practice – (1) User Centric

• 사용자가 원하는 기능을 우선시하여 개발 및 불필요한 기능 스펙아웃

• 가정했던 사항들의 빠른 불확실성 제거 (뜬구름 잡는 개발 X)

Product 제품 가치 증가

• 일방적인 기획&디자인이 아닌 사용자 피드백이 적용된 요구사항 전달

• 사용자 피드백을 통한 주인의식 함양

개발자 만족도 증대

매주 사용자 검증을 통한 제품 개선 및 Feature 우선순위 조절

User Centric

Main Practice – (2) Whole Team

• 같은 장소 및 정해진 근무시간에서 같이 작업

• Product에 대한 의사결정을 내릴 수 있는 권한 보유

빠른 의사 결정

• 각 역할자 별로 유연한 업무 배치

• 역할, 직책과 상관없이 모두 동등한 팀원 (영어 호칭 사용)

공감대 기반 하나의 팀

개발자, 디자이너, PM이 같은 장소, 시간에서 작업 Whole Team

Main Practice – (3) Pair Work

• 조직개편 및 휴가등으로 팀원 부재시 유연한 백업체제 구축

• 신규 인력 투입시 업무 적응이 쉬움

유연한 대응

• 각자 다른 기술을 보유한 개발자끼리 기술 교류로 인한 기술력 증대

• 새로운 기술 및 방법에 대한 도전의식 고취

도전 및 배움의 장

개발자, 디자이너, PM 모두 Pair Work 수행 (개발자의 경우 매일 Pair 변경)

Pair Work

Main Practice – (4) TDD

• 테스트코드 사전 확보로 사용자 검증 후 잦은 기능 변경에 따른 유연한 대응 가능

• 작은 수정에도 모든 기능을 다시 수동으로 테스트해야 하는 상황 방지

잦은 변경에 대한 부담감 해방

기능 구현 전 해당 기능의 테스트 코드부터 작성 Test Driven

Development

• TDD를 위한 초기 투자 시간이 필요. 단, 코드 유지 보수에 사용되는 시간이 더 크게 감소

• Side Effect 발생 우려로 잘못된 코드도 그대로 방치하는 현상 방지

개발자를 위한 최소한의 안전장치

업무 중 궁금했던 사항

(프로젝트별 유연 대응 필요)

궁금사항 (1/4)

• 기본적인 Performance는 2보다는 다소 적은 1.5 정도로 파악

• 퀄리티 향상, 오류 최소화 및 유지보수성 증대를 통한 장기적인 관점에서는 높은 효율

Pair Work시 각자 따로 일할 때보다 효율이 떨어지지 않나요?

• 모듈별 담당자가 아니라 Team Code로 공동 관리 ex) 4개의 모듈을 한팀으로 묶음

• 인력 변동이 있어도 유연한 백업 가능

모듈별 담당이 1명씩이라 Pair Work이 불가능합니다.

궁금사항 (2/4)

• 사용자가 없는 프로그램은 존재할 수 없음

• 고객은 외부 사용자 뿐만 아니라 누구나 될 수 있음

우리 프로그램은 사용자가 없는데 적용 가능한가요?

• Whole Team 이기 때문에 역할자 별 업무는 고정적이지 않음

• PM & Developer가 사용자 인터뷰 가능

디자이너가 없는 프로젝트의 경우, 인터뷰는 누가 하나요?

궁금사항 (3/4)

• 개발자 Pair가 매일 바뀐다면 별도 코드 리뷰는 필요 없음

• 단, Solo Work 후 다른 개발자에게 코드 리뷰를 요청하는 경우 있음

코드 리뷰는 언제 하나요?

• 경험/실력이 많이 다른 경우 Pair Work로 팀 개발역량 향상 가능

• Pair Work를 통하여 부족한 개인역량을 끌어 올릴 수 있음

개발자간 경험/실력이 많이 다른데 Pair Work 괜찮은가요?

궁금사항 (4/4)

• 권한이 팀 내에 없다면 사용자 인터뷰 피드백에 따른 제품 개선이 느려짐

• 의사결정권한을 이양 받거나, 결정권자를 팀 내에 포함시키길 추천

제품수정권한이 팀내 없습니다. 적용이 가능할까요?

• 서로 비판만 하지 않고 사소한 일에도 칭찬을 하는 분위기 조성 필요

• 수평적 조직구조를 통한 일방적인 비난 회피

Pair Work 중 의견충돌로 트러블이 생긴 적은 없나요?

Copyright ⓒ 2016 SAMSUNG ELECTRONICS. ALL RIGHTS RESERVED

THANK YOU