애자일의 모든것

박경훈

애자일 의 모든 것

http://blog.hoons.net

진행순서

- 애자일 선언문의 원칙들

- 애자일의 오해

- 스크럼(Scrum)

- User Story

- Estimation

- XP(eXtreme Programming)

- XP Practice #1 – TDD와 테스트 자동화

- XP Practice #2 – Refactoring, CI

- 애자일 사례 소개

1일차

2일차

3일차

4일차

5일차

왜 프로젝트는 실패하는가?

올바른 커뮤니케이션의 부재

프로젝트 매니저 개발자

디자이너

코드의 양이만만치 않은데

디자인 하기어려운 기능인데

무조건 빨리끝내야 하는데

새 요구사항

팀들의 잘못된 목표

애자일의 등장 배경

S/W 개발 환경의 변화

- 결과물의 배포시기가 중요해짐- 개발 생산성 저하

기존 방법론의 한계- 문서 및 절차 위주의 방법론 (변화에 대응이 어려움)- 개발자의 개발능력의 차이 불안정

Waterfall model의 문제점- 불명확하고 변화하는 사용자의 요구사항

- 개발된 모듈들의 통합의 어려움- S/W 품질의 하락(충분한 테스트가 어려움)

Agile 방법론의 정의

더 나은 의사소통

지속적인 변화 관리

우선순위에 따라 중요한 것 먼저

- 어떻게 누가 잔디를 깎을 것인지 계획서

- 섬세하면서 포괄적인 청소 계획서

- 청소 도구 리스트

잔디 청소업체의 사례

애자일 선언문의 원칙들

원칙 #1

우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는

것이다.

- 고객이라는 하나의 동일한 목표를 가지는 것

- 자주 보여주는 것이 피드백을 받고 반영할 수 있는 최고의 방법이다.

원칙 #2

작동하는 소프트웨어를 자주 전달하라.

2-4주 간격으로 하되 더 짧은 기간을 선호하라.

- 일정 주기를 통해서 팀에 리듬감을 더할 수 있다.

- 주기를 통해서 평가하고 다시 계획한다.

원칙 #3

작동하고 있는 소프트웨어를 보여주는 것이 진척을확인할 수 있는 길이다.

- 고객에게 신뢰를 전달할 수 있는 방법이다.

- 결과물 없이 커뮤니케이션이 어렵다.

원칙 #4

비록 개발의 후반부일지라도 요구사항 변경을 환영하라.

애자일 프로세스들은 변화를 활용해 고객이 경쟁력에 도움이 되게 한다.

- 프로젝트의 공통된 목표는 고객을 만족시키는 것이다.

- 변화를 통해서 결과를 만들어 가는 것이 애자일 방법론이다.

원칙 #5

비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.

- 커뮤니케이션의 퀄리티를 높여야 한다.

- 잘못된 지시나 생각의 전달을 줄여야 한다.

- 날마다가 아니여도 바로 피드백이 가능하면 좋다.

원칙 #6

동기가 부여된 개인들 중심으로 프로젝트를 구성하라.

그들이 필요로 하는 환경과 지원을 주고 그들이 일을

끝내리라고 신뢰하라.

- 프로젝트들은 사람을 통해서만 성공할 수 있다.

- 안좋은 환경과 빨리하는 개발의 강조는 협업과 소통을 저해한다.

원칙 #7

개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 얼굴을 보며 할 수

있는 대화이다.

- 이메일이나 문서로 충분한 내용을 다루기 어렵다.

- 시간을 절약하는 길이다.

원칙 #8

최고의 아키텍처, 요구사항, 설계는 스스로 움직이는 조직적인 팀에서 탄생한다.

- 최고의 설계는 팀에 연결된 사람으로부터 나오는 것이지 특정한 역할로부터 나오는 것이 아니다.

- 일을 하면서 쌓인 작고 큰 지식들이 결국 구조를 만들기 마련이다.

원칙 #9

기술적 탁월성과 좋은 설계에 대한 지속적인 결과물의 전달이 민첩함을 높인다.

- 좋은 설계는 한번에 정의 내려질 수 없다. - 우리는 지속적인 결과물을 만드는 것과 동시에 기술적으로도 충분히탁월함을 유지해야 한다.- 잘 캡슐화된 디자인이 민첩함을 높일 수 있다.

원칙 #10

애자일 프로세스들은 지속 가능한 개발을 장려한다.

스폰서, 개발자, 사용자는 일정한 속도를 계속 유지

할 수 있어야 한다.

- 일에 지친 사람은 실수를 만들 확률이 높다.

- 단기간 높은 성과보다 길게 꾸준한 성고가 좋다.

원칙 #11

단순함, 안 해도 되는 일은 최대한 안 하게 하는 기교, 이것이 핵심이다.

- 사용자와 개발자 그리고 모든 사람들 입장에서 일을 단순화 시킬 수있어야 한다.

- 아직 안 끝난 일들을 계속 돌아보며 필요없는 일들을 지워나가야 한다.

원칙 #12

팀은 정기적으로 더 효과적으로 일할 수 있는 방법을 숙고하고 그에 따라 자신의 행동을 조율하고 수

정한다.

- 커뮤니케이션의 퀄리티를 높여야 한다.

- 잘못된 지시나 생각의 전달을 줄여야 한다.

- 날마다가 아니여도 바로 피드백이 가능하면 좋다.

애자일의 오해

애자일의 오해

애자일 개발 방법론은 새로운 개발 방법론이다.

애자일은 스크럼/XP/칸반 등 하나의개발 방법론만 이용해야 한다.

No, 가장 큰 차이는 가치와 철학

No, 대부분이 원하는 기술과 프로세스들을연결하여 사용한다.

애자일의 오해

만약 애자일을 도입하면 100% 프로세스에 따라야한다.

애자일 개발팀들은 시니어 개발자들로구성되어야 한다.

No, 작은 것부터 시작해야 한다.어떤 변화를 주기 전에 충분한 동기가 필요하다.

No, 슈퍼 개발자 집단보다는 능력이 고루섞인 팀에서 더 큰 장점을 발휘한다.

애자일의 오해

작은 프로젝트에서만 가능하다.

새로운 프로젝트에서만 도입이 가능하다.

No, 가장 큰 차이는 가치와 철학

No, 이미 존재하는 소프트웨어를 확장하고개발하는 프로젝트에서도 도입이 가능하다.

애자일의 오해

애자일 개발 방법론으로 전환하면 많은 장점을 가져다 준다.

No, 전환만으로는 어렵다. 팀 전체가 애자일의 가치와 원칙을 공유해야 한다.

커뮤니케이션

Exercise - Drawing Communication Game

스크럼(Scrum)

Ken Schwaber & Mike Beedle

작은 목표를 주기적으로 전달하는 것(Baby Step)

진행을 모니터링 하고 결과에 따라 계획을 조절하는 것

비즈니스 목표가 변경되는 것과 개발팀이 민첩하게 대응하여 완료할 수 있는 것들의 밸런스를 조정하는 것

Values

Commitment

Focus

Openness

RespectCourage

Scrum Team

스프린트(Sprint)

“The team works for a fixed period of time called a Sprint”

- 1~6주 범위 내에서 특정 기간을 선정

- 일반적으로 2주 or 4주를 가장 많이 사용함

- 스프린트 기간 동안에는 분석, 설계, 코딩 그리고테스트와 배포까지의 모든 과정을 포함함

— Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 50)

Sprint Planning Meeting

“Customers, users, management, the Product Owner and the Scrum Team determine the next Sprint Goal and functionality at the Sprint Planning meeting. The team then devises the individual tasks that must be performed to build the product increment”


Input: 백로그, 수용 가능한 시간, 과거의 퍼포먼스

Output: 스프린트 목표, 스프린트 백로그

Output Example

Sprint Goal:

A non-developer can create a basic invoice on their machine

Sprint Backlog:

– Create basic invoice (no tax etc)– Generate VAT invoice– Deploy application to a non-developer Scrum team member’s PC– Set-up automated test environment

Daily Scrum Meeting

“Software development is a complex process that requires lots of communications. The Daily Scrum meeting is where the team comes to communicate”


매일 짧은 미팅(15분):

- 내가 한 일- 오늘 할 일- 있었던 이슈들

Sprint Review

“The Sprint Review meeting is a four-hour informational meeting. During this meeting, the team presents to management, customers, users and the Product Owner the product increment that it has build during the Sprint”


만든 결과물이 제품 책임자가 원하는 기능인지 확인

진행된 프로그레스의 리뷰 (비즈니스 & 기술적 이슈 공유)

다음 스프린트의 효율을 높이기 위한 아이디어 공유

Burndown Chart

Scrum Board

User Stories

User Story?

…understandable to customers and developers, testable,valuable to the customer and small enough so that theprogrammers can build half a dozen in an iteration.…A user story is nothing more than an agreement that thecustomer and developers will talk together about afeature. — Beck et al, 2001, p. 45-6

개발자와 제품 책임자와의 소통을 위한 요구사항 정의서

개발 문서에 의존하면?

변화를 받아 들이지 못한다.

고객이 원하는 것이 아닌 적혀있는 명세에 따라 개발한다.

실제 20%만 제대로 된 요구사항이다.

잘못된 추측과 가정이 난무한다.

Ex) “나는 그가 설계서를 안 만들었다고 말하지 않았습니다.＂

사용자 스토리 규칙

1. 다른 스토리에 종속적이지 않아야 한다.

2. 너무 세세하게 적지 않아야 한다.

3. 추정 가능해야 한다.

4. 적당한 크기로 작성해야 한다. - 한 스프린트 안에서 개발이 가능한

5. 테스트 가능해야 한다.

Template

As a I … < role> …I want … <short description of feature> …So that … <value or why need functionality> …

Example:

As a regular travelerI want my cell-phone to wake me up at a set time so that I don’t need to pack an alarm clock.

스마트폰 이용자는내가 있는 지역의 날씨를 알기 위해서날씨 앱을 이용하고 싶다.

Acceptance Criteria

Given … <some initial context (the givens)> …When … <an event occurs> …Then … <ensure some outcomes> …

Example:

Given my cell-phone is switched offWhen the time for my alarm is reachedThen turn the cell-phone on and sound the alarm

다른 나라를 여행하고 있는데인터넷이 되는 환경에서 날씨 앱을 실행했더니그 해당 지역의 날씨의 정보를 가져와 보여주었다.

=> 통합 테스트(Integration Test) 조건

Example

Example

SnapshotAs a user, I want to take a snapshot of any part of the book where I don’t understand so that the snapshot can be uploaded to the program.

CriteriaVerify that user is able to take a picture in the application.

Estimation8

Exercise – User Story

Estimation

About Estimation

누가?

왜?

일과 관련된 모든 사람들

스프린트를 계획하고 일들의 우선순위를 정하기위해서

측정 단위 :

시간 (날짜 or Hours)복잡도 (포인트)사이즈 (SS, S, M, L, XL)

Planning Poker

Exercise – Planning Poker

XP(eXtreme Programming)

About XP

1999년 켄트 백의 저서인 'Extreme Programming Explained - Embrace Change‘ 에서 처음 발표

10-12 개의 실천법(Practices)들로 구성

Values

Communication

Feedback

Simplicity

RespectCourage

XP Practices

Small Release

Simple Design

Refactoring

Testing (unit and acceptance)

Pair Programming

Collective Ownership

Continuous Integration

40-hour week

On-site customer

Coding Standards

XP Anti-practice

AntiPatterns of XP Practices

Introduced by Yoshihito Kuranuki(TIS, Inc.) and Kenji Hiranabe(Eiwa System Management)

Japanese XP Community

Various XP AntiPracties

Brownie's Works – “The boss refactored our code!”

[story 1. Brownie's Works]

WR

WR a freshman, began to learn the fun of programming.

CR

CR also a freshman, had quite a good experience of programming in the university.


AF (Coach)

This is the first “freshman pair”.

Can you guys finish this task?

Yes, sir


Late in the evening, they checked in their code to their code base. The "fanfare" sounded nicely (their auto- build/test batch played fanfare if it is successful).

It worked! It was a hard one,

thank you for your help.

Thank you... let's go home.


RG -Senior Developer

Late at the night, the senior programmer RG was working alone.

What's this messy code!!!? This supposed to be like this...

He refactored all the code the freshman pairhad just checked in.


Our code is gone.

Yes, I refactored thecode. That’s collective

ownership.

The next morning…


The boss refactored our code!

CR and WR were really depressed…

Let’s discuss


What if they are not there?Mail to the list why

and how you refactored.

I think you should have pair programmed when

you refactored their code.


This kind of thing would happen repeatedly,

so it would be easier to teach them once.



RG’s action made a new move in the team dynamics. CR and WR learned a lot from RG with pair programming. The team got back its normal or even better condition.

[After]

Anybody Syndrome - “I’m not necessary here”

[story 2. Anybody Syndrome ]

One morning, WR got a bad cold. He called in to the office and said to the coach.

"I think I have a cold. May I take a day off?"

Sure, it was a tough iteration. Don't worry about the team.

Take a rest


After four days' off, he came to the office and saw the team working just as well as the day he left. He was happy that everything was fine, but felt some loneliness.

What is my value for the team?

I’m not necessary here…

After that, he began to stay away from his work quite often.

Let’s discuss



The coach had an interview with WR face to face

You are frequently absent from the office these days,

is anything the matter with you?

when I took some days off and came back, I found that the

team did not have any trouble at all.


“Yes, that's a good thing!

That means the team is fine without me.


That’s not quite right. Everybody wants to work with you, and

you have your own goal in the project. You participate in the project with that goal,

don’t you?

The coach and WR talked about his goal in the project and his career plan. WR was grateful to the coach for giving an opportunity to talk over these kinds of things in a big picture.

The project members found that they had theirown goals as well as the project goal and they

were free to talk about them anytime. That became a grand rule set by the coach. They now talked about their dreams, plans,

and families. They started acting more autonomously, and the fresh energy came back to

the team.


[After]

Pairing Prison – “I'm always under observation!”

[story 3. Pairing Prison ]

CR was a senior programmer with three years of experience in waterfall type development environment. He had been interested in XP, and this was his first XP experience in a real project. He had wanted to try pair programming, so this was a wonderful opportunity for him.

When he paired with juniors, he got serious so he become a good example.


With seniors, he felt like he was taking an examination. Pair programming made him feel observed in a prison.


He could not stand the situation anymore, and consulted the coach. He said


I'm always under observation!

Let’s discuss


The next day, the coach told the team that he recommended to take breaks more often.

The team adopted this as a ground rule. In addition, they doubled the lunch time for their personal time.


테스트 자동화와 TDD

소프트웨어의 소스는 복잡하게 연결되어있다.

작은 한 부분이 수정된다면?

모든 기능을 다시 테스트 해야 한다.

소스코드는 시간이 흐르면 녹이 슨다.

끊임없이 OOD(Object Oriented Design)와 패턴 구문들을적용해가며 리펙토링 해야 한다.

하지만 리펙토링이 어려운 이유

모든 기능을 다시 테스트 해야 한다.

자동화 된 테스트가 없다면?

자체 버그 검출 능력 저하- 모든 기능을 테스트 하기 어려움

소스 코드의 품질 저하- 어디서 버그가 생길지 모르기 때문에 잘못된 코드도 고치지 않으려 하는 현상

자체 테스트 비용의 증가- 작은 수정에도 모든 기능을 다시 테스트 해야 되는 문제

자동화 된 테스트란?

모든 테스트 케이스를 코드 스크립트로 변환한 집합체

3rd party testing tools

http://www.youtube.com/watch?v=qsh4zWa6bE8

http://www.youtube.com/watch?v=4TGkGQonmy4#t=64

http://www.youtube.com/watch?v=qsh4zWa6bE8

http://www.youtube.com/watch?v=4TGkGQonmy4#t=64

누가 테스트 스크립트를 만드는가?

Software Engineers

QA Engineers

Software Architect

개발 프로세스

요구사항

Software & QA Engineer

테스트 케이스수립

- 공백입력 하면 오류 메시지 띄우기- 사용자가 여러 개의 비디오를 옮길 수있게

개발

Software EngineerQA Engineer

통합 테스트코드 작성

TDD란 무엇인가?

Test-Driven Development- 요구사항의 테스트 요건을 먼저 고려

Test-First Development- 개발 전 테스트 코드를 먼저 작성하여 개발

1999년 XP라는 애자일 기반의 개발 방법론과함께 소개 됨

TDD란 무엇인가?

기존 개발방식

TDD의 개발방식

TDD의 장점

높은 소스코드 품질- MS와 IBM사의 조사 결과TDD 약 15~35% 정도의 개발시간 증가 결

함율(버그)은 약 40~90% 정도 줄어듬- http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

재설계 시간의 절감

손쉬운 테스트 근거 산출 및 문서화 (test coverage, performance)

디버깅 시간의 절감

http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

TDD의 단점

all about 개발 생산성!

1부터 10까지의 수를 출력하는 프로그램 만들기!

- 단, 3의 배수에서는 숫자대신 “HOONS”를 출력- 5의 배수에서는 “JAEDAM”을 출력

통합테스트와 유닛테스트

Dependency Injection= AOP

편의점 카운터에서 물건을 스캔한 뒤에 고객에게 최종 가격을 알려주는프로그램이 필요합니다.

물건들의 가격은 데이터 베이스에 있으며, 한가지 특별한 것은 현재 모든 물건을 2개 사면 하나 더 주는 이벤트를 하고 있기 때문에 이 로직을

반영해주세요.

데이터 레이어 => 가격정보

비지니스 레이어 => 할인점검 유닛테스트

유닛테스트

통합테스트

Test Automation /TDD

AOP

Repository Pattern

MVC, MVP, MVVM

Dependency Injection

SOLID, DRY, KISS

ORM - Entity

CI

Pair programing

Git – code review

BDD/DDD

Agile – XP/Scrum

Daily Standup

User Story & Estimation

패턴 문화

결과 중심적 개발 프로세스

Project Manager

Software Engineer

Tester

요구사항

결과물

개발

품질 중심적 개발 프로세스

Project Manager

① 요구사항

Architect / Lead developer

Software Engineers

② 분석/설계 전달

개발

결과물③ 코드리뷰 요청

(pull request)

Architect / Lead developer

Tester

테스트 요청

결과물

피드백

코드 리뷰


“팀원들이 작업한 결과를 자주 지속적으로 통합하고 그것을 자동화 하는 것”

Why CI?

구현 기능의 가시화 (작업물의 공유)

프로젝트의 결함 조기 발견

CI를 넘어

Developer vs Operator

Devops tools

코드 리팩토링

소스코드는 시간이 흐르면 녹이 슨다.

그 이름은 스파게티,,

좋은 코드란?

“기계가 아닌 사람이 이해할 수 있게 작성된 코드”

리팩토링(Refactoring) 이란?

“소프트웨어 디자인을 개선하고 코드를 쉽게 사용하고 이해할 수 있게 만드는 작업”

When to refactor?

새로운 함수를 추가할 때

버그를 수정해야 할 때

코드 리뷰를 수행할 때

리팩토링이 무의미한 경우

리팩토링을 실행해도 복구가 어려울 정도로 망가져버린 코드들

데드라인이 너무 가깝고 리팩토링한 검증할 테스트코드가 없을 때

나쁜 코드 스멜

복사된 코드 로직

너무 긴 메서드

굉장히 긴 클래스

너무 많은 파라미터 리스트

Before Refactoring

테스트 코드의 작성

나의 규칙을 따르라!

#1 메서드 추출

void PrintOwing(double amount) {

PrintBanner();

//print detailsWriteLine("name:" + _name);WriteLine("amount" + amount);

}

void PrintOwing(double amount){

PrintBanner();PrintDetails(amount);

}

void PrintDetails(double amount){

WriteLine("name:" + _name);WriteLine("amount" + amount);

}

#2 인라인 메서드

int GetRating() {return (MoreThanFive()) ? 2 : 1;

}

bool MoreThanFive() {

return _number > 5;}

int getRating() {

return (_number > 5) ? 2 : 1;

}

#3 임시변수의 중복 사용

double temp = 2*(_height + _width);WriteLine(temp);temp = _height * _width;WriteLine(temp);

double perimeter = 2*(_height + _width);WriteLine(perimeter);double area = _height * _width;WriteLine(area);

임시 변수는 한번만 할당

#4 파라미터의 값 할당을 피해라

int Discount (int inputVal) {if (inputVal > 50) inputVal -= 2;…

}

int Discount (int inputVal) {int result = inputVal;if (inputVal > 50) result -= 2;…

}

파라미터를 변경하려면 임시 변수를 이용하라

#5 메서드를 객체로

class Order...

double price() {

double primaryBasePrice;double secondaryBasePrice;double tertiaryBasePrice;

// long computation;...

}

한 메서드 안에서 진행되는 작업이 너무 많은 경우

#6 복잡한 수식의 표현

if( ( platform.toUpperCase().indexOf("MAC") > -1 ) &&( browser.toUpperCase().indexOf("IE") > -1 ) &&( wasInitialized() && resized > 0 )

{// 작업...

}

bool isMasOS = platform.toUpperCase().indexOf("MAC") > -1;bool isIEBrowser = browser.toUpperCase().indexOf("IE") > -1;bool wasResized = 0;

if( isMacOS && isIEBrowser && wasInitialized() && wasResized ){// 작업...

}

복잡한 수식을 이해하기 쉽게 변수를 적절히 이용

#7 Single Responsibility

class Customer{public void Add(){try{//DB 접근코드

}catch (Exception ex){System.IO.File.WriteAllText(@"c:\Error.txt", ex.ToString());}

}}

class FileLogger{public void Handle(string error){

System.IO.File.WriteAllText(@"c:\Error.txt", error);}

}class Customer{

private FileLogger obj= new FileLogger();public void Add() {

try{// DB 접근코드

}catch (Exception ex) {

obj.Handle(ex.ToString());}

}}

하나의 클래스에서는 하나의 책임만 할당

“나는 우아하고 효율적인 코드를 좋아한다. 논리가간단해야 버그가 숨어들지 못한다. 의존성을 최대한줄여야 유지보수가 쉬워진다. 오류는 명백한 전량에의거해 철저히 처리한다.” — 이야네 스트룹스트룹(Bjarne Stroustup), C++창시자

의존성 줄이는 것

= 객체간의 강한 참조를 줄이는 것

= Loose coupling

= 클래스 참조 대신 Interface를 이용

class FileLogger{public void Handle(string error){


}

class Customer{

private FileLogger obj= new FileLogger();public void Add() {

try{// DB 접근코드

}catch (Exception ex) {

obj.Handle(ex.ToString());}

}}

File Logger가 아닌 DBLogger도 구현해야 한다면?

#8 의존성 제거

interface ILogger{

void Handle(string error);}

class FileLogger :ILogger{

public void Handle(string error){


}

class DBLogger : ILogger{

public void Handle(string error){

//DB 저장 로직}

}

인터페이스의 도입

class Customer{

private readonly ILogger _obj;public Customer(ILogger obj){

_obj = obj;}public virtual void Add(){

try{

//Some codes}catch (Exception ex){

_obj.Handle(ex.ToString());}

}}

var customerDB = new Customer(new DBLogger());var customerFile = new Customer(new FileLogger()));

Customer의 loose coupling

리팩토링 추천도서

리팩토링 : 코드 품질을 개선하는 객체지향 사고법 - 저)마틴 파울러

xUnit 테스트 패턴 : 68가지 단위 테스트 패턴을 통한테스트 코드 리팩토링 기법 – 저) 제라드 메스자로스

애자일 도입사례

세일즈포스 – 대규모 개발팀에서,,

CRM 끝판왕 (클라우드 기반, SaaS)

87,200여 회사에 이용

200만명 이상의 사용자

3개월 기간 동안의 30개의대규모 개발 팀에 애자일도입

도입 배경

- 정확하지 않은 전체 개발기간(일찍 산정하고 평가하는 것은 결국 각 기능별 정학한 완성일자와 완전한 테스팅 스케줄을 제공할 수 없었다.)

- 실제 릴리즈의 모든 단계별로 눈에 보여지는 결과물의부재

- 거의 릴리즈 끝에 이루어지는 기능들의 늦은 피드백

- 길고 예측이 어려운 릴리즈 스케줄

- 팀이 확장될수록 줄어드는 생산성

도입 결정

KISS(Keep it Simple Stupid)개발 원칙과 빠른 반복주기, 고객들의 의견이 중요 -> 애자일 원칙과 유사

시범적 팀에 도입 vs 일부 팀에 도입=>대부분의 팀 원들이 같은 시간에 같이 도입을 원함

도입 과정

- 상당수의 개발자들에게 외부 스크럼 교육을 지원

- 스크럼 마스터/개발자 자격증 응시 지원

- 애자일 TF팀이 꾸려져 사내 팀에 Lean과 XP 교육

성공요인 #1

- 개인의 생산성 보다는 팀의 처리량에 초점을 맞추는 것

- 각 기술 별로 나뉘어진 팀들은 매일 만나서 진행하는 미팅

- 공통으로 사용하는 언어의 정의와 간단한 애자일 프로세스

- 모든 팀 별로 일들의 명확한 우선 순위 리스트

- 사용자 스토리와 새로운 업무 측정방법의 정의

- 빌드 속도와 유연성에 초점이 맞추어진 자동화 팀

- 제품과 릴리즈의 완성도를 하루 단위로 확인할 수 있는 도표

성공요인 #2

- 스크럼을 이용한 제품 라인과 주별로 모든 팀이 볼수 있는 어떤 결과물

- 넓은 분야의 스프린트 리뷰와 매달 진행하는 회고

- 제품 책임자(Product Owner)와 스크럼 마스터(ScrumMaster)들의 주기적 미팅

- 큰 릴리즈를 앞두고 정확한 시간 단위로 정확하게만들어지는 작은 릴리즈

- 약 1500개 이상의 버그의 감소

- 매달 진행되는 잠재적인 제품들의 릴리즈

일찍 알았으면

- 일찍 애자일 도입 피드백에 귀 기울이는 것

- 제품 책임자를 일찍 교육 시키는 것

- 외부의 코치들을 일찍 섭외하는 것

- 자동화 부분을 보다 일찍 시작하는 것

- 경영진들에게 애자일 도입에 대한 구체적인 업무들을 요청하는 것

- 조금 더 클리어하게 애자일의 역할이 무엇인지를전달하는 것

세일스포스 사례를 통한 교훈

- 애자일을 도입을 진행할 헌신적이고 모든 권한을가지고 있는 팀을 만드는 것

- 전문가의 도움을 얻는 것

- P2P처럼 개개인이 서로 코치할 수 있게 하는 것

- 여러 개의 팀을 뛰어나게 만드는 것

- 회사 레벨의 스프린트를 만드는 것

- 일찍 필요한 도구를 만드는 것

- 진행사항을 눈에 볼 수 있게 하는 것과 최대한 많은 커뮤니케이션을 만드는 것

- 실수를 인정하고 그것에 관대해지는 것

BBC – 제품 책임자의 역할

영국 방송국(British Broadcasting Corporation)

iPlayer 프로젝트 진행

대규모 프로젝트에서 프로젝트 진행

iPlayer 프로젝트 목표

- 1. 홈페이지 개발

- 2. “다운로드”, “지금 보기” 와 같은 사용자 기능 제공 및 액션의 처리

- 3. 내려 받은 미디어를 관리하기 위한 애플리케이션

- 4. 내려 받을 수 있는 컨텐츠를 검색하고 내려 받을 수 있는 환경 제공

- 5. 웹 기반의 프로그램 스케줄과 사용자 가이드

- 6. 프로그램 제목, 방영날짜 등과 같은 메타데이터의 정보 관리

- 7. 기존의 인증 시스템과 연동하여 자동로그인 기능 (SSO:SigleSign On) 제공

- 8. IP 체크를 통한 위치 기반의 사용자가 맞춤 환경 분석

- 9. 사용자 경험과 인터렉션

iPlayer 프로젝트

- TV 프로 다시보기/실시간시청 기능제공

- 9개의 컴포넌트 팀 & 중앙 관리팀(80여명)

- 2개 팀은 이미 스크럼 경험

- 2주 간격의 스프린트

- 일일스크럼미팅 / “스크럼”의 스크럼 미팅 진행

- 각 팀별로 스크럼 마스터, 제품 책임자는 중앙팀에 배치

9개의 팀 = 각 팀병1명의 스크럼마스터 + 팀원들

중앙 관리 팀

제품 책임자

무엇이 잘못되었을까?

- 진행 속도가 2주차 부터 현저히 감소

- 1명의 제품 책임자가 너무 바쁨

- 제품 책임자가 어떤 결정을 혼자서 내리기 어려움

- 백로그에 우선순위가 없어서 자신이 원하는 항목부터 처리

- 제품 책임자가 결정을 내리지 못하여 미팅이 잦아짐

- 스크럼으로는 성공할 수 없다는 목소리들

Let’s discuss

처음 시도

중앙 팀을 2개로 나눠서 관리

하지만

이전과 비교해서는 좀 나아짐

하지만 여전히 각 팀들의 스크럼을 중앙에 동기화 하는 것이 어려움

각 팀 별로 가지고 있는 의존성 때문에 잦은 미팅

두 책임자들의 잦은 충돌과 비효율적인 결정

자기 주도적으로 일하기

각 9개의 팀 별로 제품 책임자의 역할을 하는 제품프로듀서를 다시 임명

9개의 팀 = 각 팀병1명의 스크럼마스터 + 팀원들

효과

• 각 팀들은 보다 분명한 제품의 책임 의식 고취

• 프로젝트 요구사항이 명시적으로 정의 가능

• 질문에 대한 빠른 답변 가능

• 각 팀들이 명확한 제품 백로그를 생성 & 스프린트계획수립 가능

• 해야 할 업무의 배분이 적절이 이루어졌고 새로운기능들을 매 스프린트마다 고객에게 전달

• 각 팀의 제품 책임자들은 각자 맡은 분야의 전문가가 됨

• 일관성이 없었던 제품 백로그 항목들이 각 팀들에의해서 완화됨

BBC의 팀

• 프로젝트 안에서 각 팀을 구성할 때 제품 책임자와함께 할 수 있는 시간을 고려해야 한다.

• 한 명의 제품 책임자에 의존하다 보면 결국 일 진행이 늦어지고 프로젝트의 올바른 방향을 설정하는것이 어렵다.

• 제품 책임자들의 역량은 팀이 크거나 여러 팀의 목표를 동시에 고려하다 보면 줄어든다.

• 조직적이지 못한 팀이 하나의 프로젝트에서 같이일하면 비즈니스 목표와 다른 제품이 만들어 질 수있다.

대규모 스크럼 프로젝트의 성공조건

• 스크럼의 스크럼

• 같은 공간에서 일하는 개발 팀들

• 팀 안에서 적절한 역할의 사람들

• 권한이 있는 스크럼 마스터

박경훈

[email protected]

http://blog.hoons.net

http://twitter.com/_hoons