- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
5. 애자일의 등장 배경
S/W 개발 환경의 변화
- 결과물의 배포시기가 중요해짐
- 개발 생산성 저하
기존 방법론의 한계
- 문서 및 절차 위주의 방법론 (변화에 대응이 어려움)
- 개발자의 개발능력의 차이 불안정
Waterfall model의 문제점
- 불명확하고 변화하는 사용자의 요구사항
- 개발된 모듈들의 통합의 어려움
- S/W 품질의 하락(충분한 테스트가 어려움)
16. 원칙 #5
비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체
에 걸쳐 날마다 함께 일해야 한다.
- 커뮤니케이션의 퀄리티를 높여야 한다.
- 잘못된 지시나 생각의 전달을 줄여야 한다.
- 날마다가 아니여도 바로 피드백이 가능하면 좋다.
17. 원칙 #6
동기가 부여된 개인들 중심으로 프로젝트를 구성하라.
그들이 필요로 하는 환경과 지원을 주고 그들이 일을
끝내리라고 신뢰하라.
- 프로젝트들은 사람을 통해서만 성공할 수 있다.
- 안좋은 환경과 빨리하는 개발의 강조는 협업과 소통을 저해한다.
18. 원칙 #7
개발팀으로, 또 개발팀 내부에서 정보를 전하는 가
장 효율적이고 효과적인 방법은 얼굴을 보며 할 수
있는 대화이다.
- 이메일이나 문서로 충분한 내용을 다루기 어렵다.
- 시간을 절약하는 길이다.
19. 원칙 #8
최고의 아키텍처, 요구사항, 설계는 스스로 움직이
는 조직적인 팀에서 탄생한다.
- 최고의 설계는 팀에 연결된 사람으로부터 나오는 것이지 특정한 역할
로부터 나오는 것이 아니다.
- 일을 하면서 쌓인 작고 큰 지식들이 결국 구조를 만들기 마련이다.
20. 원칙 #9
기술적 탁월성과 좋은 설계에 대한 지속적인 결과
물의 전달이 민첩함을 높인다.
- 좋은 설계는 한번에 정의 내려질 수 없다.
- 우리는 지속적인 결과물을 만드는 것과 동시에 기술적으로도 충분히
탁월함을 유지해야 한다.
- 잘 캡슐화된 디자인이 민첩함을 높일 수 있다.
21. 원칙 #10
애자일 프로세스들은 지속 가능한 개발을 장려한다.
스폰서, 개발자, 사용자는 일정한 속도를 계속 유지
할 수 있어야 한다.
- 일에 지친 사람은 실수를 만들 확률이 높다.
- 단기간 높은 성과보다 길게 꾸준한 성고가 좋다.
22. 원칙 #11
단순함, 안 해도 되는 일은 최대한 안 하게 하는 기
교, 이것이 핵심이다.
- 사용자와 개발자 그리고 모든 사람들 입장에서 일을 단순화 시킬 수
있어야 한다.
- 아직 안 끝난 일들을 계속 돌아보며 필요없는 일들을 지워나가야 한
다.
23. 원칙 #12
팀은 정기적으로 더 효과적으로 일할 수 있는 방법
을 숙고하고 그에 따라 자신의 행동을 조율하고 수
정한다.
- 커뮤니케이션의 퀄리티를 높여야 한다.
- 잘못된 지시나 생각의 전달을 줄여야 한다.
- 날마다가 아니여도 바로 피드백이 가능하면 좋다.
25. 애자일의 오해
애자일 개발 방법론은 새로운 개발 방법론이다.
애자일은 스크럼/XP/칸반 등 하나의
개발 방법론만 이용해야 한다.
No, 가장 큰 차이는 가치와 철학
No, 대부분이 원하는 기술과 프로세스들을
연결하여 사용한다.
26. 애자일의 오해
만약 애자일을 도입하면 100% 프로세스에 따라야
한다.
애자일 개발팀들은 시니어 개발자들로
구성되어야 한다.
No, 작은 것부터 시작해야 한다.
어떤 변화를 주기 전에 충분한 동기가 필요하다.
No, 슈퍼 개발자 집단보다는 능력이 고루
섞인 팀에서 더 큰 장점을 발휘한다.
27. 애자일의 오해
작은 프로젝트에서만 가능하다.
새로운 프로젝트에서만 도입이 가능하다.
No, 가장 큰 차이는 가치와 철학
No, 이미 존재하는 소프트웨어를 확장하고
개발하는 프로젝트에서도 도입이 가능하다.
28. 애자일의 오해
애자일 개발 방법론으로 전환하면 많은 장점을 가
져다 준다.
No, 전환만으로는 어렵다.
팀 전체가 애자일의 가치와 원칙을 공유해야 한다.
36. 스프린트(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)
37. 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”
— Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 47)
Input: 백로그, 수용 가능한 시간, 과거의 퍼포먼스
Output: 스프린트 목표, 스프린트 백로그
38. 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
39. 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”
— Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 40)
매일 짧은 미팅(15분):
- 내가 한 일
- 오늘 할 일
- 있었던 이슈들
40. 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”
— Schwaber et al, Agile Software Development with Scrum, Prentice-Hall, 2002 (pp 54)
만든 결과물이 제품 책임자가 원하는 기능인지 확인
진행된 프로그레스의 리뷰 (비즈니스 & 기술적 이슈 공유)
다음 스프린트의 효율을 높이기 위한 아이디어 공유
45. User Story?
…understandable to customers and developers, testable,
valuable to the customer and small enough so that the
programmers can build half a dozen in an iteration.
…A user story is nothing more than an agreement that the
customer and developers will talk together about a
feature. — Beck et al, 2001, p. 45-6
개발자와 제품 책임자와의 소통을 위한 요구사항 정의서
46. 개발 문서에 의존하면?
변화를 받아 들이지 못한다.
고객이 원하는 것이 아닌 적혀있는 명세에 따라 개발한다.
실제 20%만 제대로 된 요구사항이다.
잘못된 추측과 가정이 난무한다.
Ex) “나는 그가 설계서를 안 만들었다고 말하지 않았습니다."
47. 사용자 스토리 규칙
1. 다른 스토리에 종속적이지 않아야 한다.
2. 너무 세세하게 적지 않아야 한다.
3. 추정 가능해야 한다.
4. 적당한 크기로 작성해야 한다.
- 한 스프린트 안에서 개발이 가능한
5. 테스트 가능해야 한다.
48. Template
As a I … < role> …
I want … <short description of feature> …
So that … <value or why need functionality> …
Example:
As a regular traveler
I want my cell-phone to wake me up at a set time
so that I don’t need to pack an alarm clock.
스마트폰 이용자는
내가 있는 지역의 날씨를 알기 위해서
날씨 앱을 이용하고 싶다.
49. Acceptance Criteria
Given … <some initial context (the givens)> …
When … <an event occurs> …
Then … <ensure some outcomes> …
Example:
Given my cell-phone is switched off
When the time for my alarm is reached
Then turn the cell-phone on and sound the alarm
다른 나라를 여행하고 있는데
인터넷이 되는 환경에서 날씨 앱을 실행했더니
그 해당 지역의 날씨의 정보를 가져와 보여주었다.
=> 통합 테스트(IntegrationTest) 조건
53. Example
Snapshot
As 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.
Criteria
Verify that user is able to take a picture in the application.
Estimation
8
64. AntiPatterns of XP Practices
Introduced by Yoshihito Kuranuki(TIS, Inc.)
and Kenji Hiranabe(Eiwa System Management)
Japanese XP Community
Various XP AntiPracties
66. [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.
67. [story 1. Brownie's Works]
AF (Coach)
This is the first
“freshman pair”.
Can you guys finish
this task?
Yes, sir
68. [story 1. Brownie's Works]
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.
69. [story 1. Brownie's Works]
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 pair
had just checked in.
70. [story 1. Brownie's Works]
Our code is gone.
Yes, I refactored the
code. That’s collective
ownership.
The next morning…
71. [story 1. Brownie's Works]
The boss refactored
our code!
CR and WR were really depressed…
73. 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.
[story 1. Brownie's Works]
74. This kind of thing would happen
repeatedly,
so it would be easier
to teach them once.
[story 1. Brownie's Works]
75. [story 1. Brownie's Works]
RG’s action made a new move in the team
dynamics. CR andWR learned a lot from RG
with pair programming.The team got back
its normal or even better condition.
[After]
77. [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
78. [story 2. Anybody Syndrome ]
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.
80. [story 2. Anybody Syndrome ]
The coach had an interview withWR 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.
81. [story 2. Anybody Syndrome ]
“Yes, that's a good thing!
That means the team is fine
without me.
82. [story 2. Anybody Syndrome ]
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.
83. The project members found that they had their
own 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.
[story 2. Anybody Syndrome ]
[After]
85. [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.
86. When he paired with juniors, he
got serious so he become a good
example.
[story 3. Pairing Prison ]
87. With seniors, he felt like he
was taking an examination.
Pair programming made him
feel observed in a prison.
[story 3. Pairing Prison ]
88. He could not stand the situation anymore, and
consulted the coach. He said
[story 3. Pairing Prison ]
I'm always under
observation!
90. 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.
[story 3. Pairing Prison ]
101. 자동화 된 테스트가 없다면?
자체 버그 검출 능력 저하
- 모든 기능을 테스트 하기 어려움
소스 코드의 품질 저하
- 어디서 버그가 생길지 모르기 때문에 잘못
된 코드도 고치지 않으려 하는 현상
자체 테스트 비용의 증가
- 작은 수정에도 모든 기능을 다시 테스트 해
야 되는 문제
105. 누가 테스트 스크립트를 만드는가?
Software Engineers
QA Engineers
Software Architect
106. 개발 프로세스
요구사항
Software & QA Engineer
테스트 케이스
수립
- 공백입력 하면 오류 메시지 띄우기
- 사용자가 여러 개의 비디오를 옮길 수
있게
개발
Software EngineerQA Engineer
통합 테스트
코드 작성
107. TDD란 무엇인가?
Test-Driven Development
- 요구사항의 테스트 요건을 먼저 고려
Test-First Development
- 개발 전 테스트 코드를 먼저 작성하여 개발
1999년 XP라는 애자일 기반의 개발 방법론과
함께 소개 됨
109. TDD의 장점
높은 소스코드 품질
- MS와 IBM사의 조사 결과
TDD 약 15~35% 정도의 개발시간 증가 결
함율(버그)은 약 40~90% 정도 줄어듬
- http://research.microsoft.com/en-
us/groups/ese/nagappan_tdd.pdf
재설계 시간의 절감
손쉬운 테스트 근거 산출 및 문서화 (test
coverage, performance)
디버깅 시간의 절감
115. 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
패턴 문화
116. 결과 중심적 개발 프로세스
Project Manager
Software Engineer
Tester
요구사항
결과물
개발
117. 품질 중심적 개발 프로세스
Project Manager
① 요구사항
Architect /
Lead developer
Software Engineers
② 분석/설계 전달
개발
결과물
③ 코드리뷰 요청
(pull request)
Architect /
Lead developer
Tester
테스트 요청
결과물
피드백
코드 리뷰
143. #4 파라미터의 값 할당을 피해라
int Discount (int inputVal)
{
if (inputVal > 50) inputVal -= 2;
…
}
int Discount (int inputVal)
{
int result = inputVal;
if (inputVal > 50) result -= 2;
…
}
파라미터를 변경하려면 임시 변수를 이용하라
144. #5 메서드를 객체로
class Order...
double price() {
double primaryBasePrice;
double secondaryBasePrice;
double tertiaryBasePrice;
// long computation;
...
}
한 메서드 안에서 진행되는 작업이 너무 많은 경우
145. #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 )
{
// 작업...
}
복잡한 수식을 이해하기 쉽게 변수를 적절히 이용
146. #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:
}
}
class Customer
{
private FileLogger obj
= new FileLogger();
public void Add() {
try{
// DB 접근코드
}
catch (Exception ex) {
obj.Handle(ex.ToString());
}
}
}
하나의 클래스에서는 하나의 책임만 할당
147. “나는 우아하고 효율적인 코드를 좋아한다. 논리가
간단해야 버그가 숨어들지 못한다. 의존성을 최대한
줄여야 유지보수가 쉬워진다. 오류는 명백한 전량에
의거해 철저히 처리한다.” — 이야네 스트룹스트룹(Bjarne Stroustup), C++창시자
의존성 줄이는 것
= 객체간의 강한 참조를 줄이는 것
= Loose coupling
= 클래스 참조 대신 Interface를 이용
148. 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());
}
}
}
File Logger가 아닌 DBLogger도 구현해야 한다면?
#8 의존성 제거
149. interface ILogger
{
void Handle(string error);
}
class FileLogger :ILogger
{
public void Handle(string error)
{
System.IO.File.WriteAllText(@"c:Error.txt", error);
}
}
class DBLogger : ILogger
{
public void Handle(string error)
{
//DB 저장 로직
}
}
인터페이스의 도입
150. 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
151. 리팩토링 추천도서
리팩토링 : 코드 품질을 개선하는 객체지
향 사고법 - 저)마틴 파울러
xUnit 테스트 패턴 : 68가지 단위 테스트 패턴을 통한
테스트 코드 리팩토링 기법 – 저) 제라드 메스자로스
154. 세일즈포스 – 대규모 개발팀에서,,
CRM 끝판왕 (클라우드 기
반, SaaS)
87,200여 회사에 이용
200만명 이상의 사용자
3개월 기간 동안의 30개의
대규모 개발 팀에 애자일
도입
155. 도입 배경
- 정확하지 않은 전체 개발기간
(일찍 산정하고 평가하는 것은 결국 각 기능별 정학한 완
성일자와 완전한 테스팅 스케줄을 제공할 수 없었다.)
- 실제 릴리즈의 모든 단계별로 눈에 보여지는 결과물의
부재
- 거의 릴리즈 끝에 이루어지는 기능들의 늦은 피드백
- 길고 예측이 어려운 릴리즈 스케줄
- 팀이 확장될수록 줄어드는 생산성
156. 도입 결정
KISS(Keep it Simple Stupid)개발 원칙과 빠른 반복
주기, 고객들의 의견이 중요 -> 애자일 원칙과 유사
시범적 팀에 도입 vs 일부 팀에 도입
=>대부분의 팀 원들이 같은 시간에 같이 도입을 원
함
157. 도입 과정
- 상당수의 개발자들에게 외부 스크럼 교육을 지원
- 스크럼 마스터/개발자 자격증 응시 지원
- 애자일 TF팀이 꾸려져 사내 팀에 Lean과 XP 교육
158. 성공요인 #1
- 개인의 생산성 보다는 팀의 처리량에 초점을 맞추는 것
- 각 기술 별로 나뉘어진 팀들은 매일 만나서 진행하는 미팅
- 공통으로 사용하는 언어의 정의와 간단한 애자일 프로세스
- 모든 팀 별로 일들의 명확한 우선 순위 리스트
- 사용자 스토리와 새로운 업무 측정방법의 정의
- 빌드 속도와 유연성에 초점이 맞추어진 자동화 팀
- 제품과 릴리즈의 완성도를 하루 단위로 확인할 수 있는 도
표
159. 성공요인 #2
- 스크럼을 이용한 제품 라인과 주별로 모든 팀이 볼
수 있는 어떤 결과물
- 넓은 분야의 스프린트 리뷰와 매달 진행하는 회고
- 제품 책임자(Product Owner)와 스크럼 마스터
(ScrumMaster)들의 주기적 미팅
- 큰 릴리즈를 앞두고 정확한 시간 단위로 정확하게
만들어지는 작은 릴리즈
- 약 1500개 이상의 버그의 감소
- 매달 진행되는 잠재적인 제품들의 릴리즈
160. 일찍 알았으면
- 일찍 애자일 도입 피드백에 귀 기울이는 것
- 제품 책임자를 일찍 교육 시키는 것
- 외부의 코치들을 일찍 섭외하는 것
- 자동화 부분을 보다 일찍 시작하는 것
- 경영진들에게 애자일 도입에 대한 구체적인 업무
들을 요청하는 것
- 조금 더 클리어하게 애자일의 역할이 무엇인지를
전달하는 것
161. 세일스포스 사례를 통한 교훈
- 애자일을 도입을 진행할 헌신적이고 모든 권한을
가지고 있는 팀을 만드는 것
- 전문가의 도움을 얻는 것
- P2P처럼 개개인이 서로 코치할 수 있게 하는 것
- 여러 개의 팀을 뛰어나게 만드는 것
- 회사 레벨의 스프린트를 만드는 것
- 일찍 필요한 도구를 만드는 것
- 진행사항을 눈에 볼 수 있게 하는 것과 최대한 많
은 커뮤니케이션을 만드는 것
- 실수를 인정하고 그것에 관대해지는 것
163. BBC – 제품 책임자의 역할
영국 방송국
(British Broadcasting
Corporation)
iPlayer 프로젝트 진행
대규모 프로젝트에서 프
로젝트 진행
164. iPlayer 프로젝트 목표
- 1. 홈페이지 개발
- 2. “다운로드”, “지금 보기” 와 같은 사용자 기능 제공 및 액션
의 처리
- 3. 내려 받은 미디어를 관리하기 위한 애플리케이션
- 4. 내려 받을 수 있는 컨텐츠를 검색하고 내려 받을 수 있는 환
경 제공
- 5. 웹 기반의 프로그램 스케줄과 사용자 가이드
- 6. 프로그램 제목, 방영날짜 등과 같은 메타데이터의 정보 관리
- 7. 기존의 인증 시스템과 연동하여 자동로그인 기능 (SSO:Sigle
Sign On) 제공
- 8. IP 체크를 통한 위치 기반의 사용자가 맞춤 환경 분석
- 9. 사용자 경험과 인터렉션
165. iPlayer 프로젝트
- TV 프로 다시보기/실시간시청 기능
제공
- 9개의 컴포넌트 팀 & 중앙 관리팀
(80여명)
- 2개 팀은 이미 스크럼 경험
- 2주 간격의 스프린트
- 일일스크럼미팅 / “스크럼”의 스크
럼 미팅 진행
- 각 팀별로 스크럼 마스터, 제품 책
임자는 중앙팀에 배치
167. 무엇이 잘못되었을까?
- 진행 속도가 2주차 부터 현저히 감소
- 1명의 제품 책임자가 너무 바쁨
- 제품 책임자가 어떤 결정을 혼자서 내리기 어려움
- 백로그에 우선순위가 없어서 자신이 원하는 항목
부터 처리
- 제품 책임자가 결정을 내리지 못하여 미팅이 잦아
짐
- 스크럼으로는 성공할 수 없다는 목소리들
170. 하지만
이전과 비교해서는 좀 나아짐
하지만 여전히 각 팀들의 스크럼을 중앙에 동기화 하
는 것이 어려움
각 팀 별로 가지고 있는 의존성 때문에 잦은 미팅
두 책임자들의 잦은 충돌과 비효율적인 결정
171. 자기 주도적으로 일하기
각 9개의 팀 별로 제품 책임자의 역할을 하는 제품
프로듀서를 다시 임명
9개의 팀 = 각 팀병1명의 스크럼마스터 + 팀원들
172. 효과
• 각 팀들은 보다 분명한 제품의 책임 의식 고취
• 프로젝트 요구사항이 명시적으로 정의 가능
• 질문에 대한 빠른 답변 가능
• 각 팀들이 명확한 제품 백로그를 생성 & 스프린트
계획수립 가능
• 해야 할 업무의 배분이 적절이 이루어졌고 새로운
기능들을 매 스프린트마다 고객에게 전달
• 각 팀의 제품 책임자들은 각자 맡은 분야의 전문가
가 됨
• 일관성이 없었던 제품 백로그 항목들이 각 팀들에
의해서 완화됨
173. BBC의 팀
• 프로젝트 안에서 각 팀을 구성할 때 제품 책임자와
함께 할 수 있는 시간을 고려해야 한다.
• 한 명의 제품 책임자에 의존하다 보면 결국 일 진
행이 늦어지고 프로젝트의 올바른 방향을 설정하는
것이 어렵다.
• 제품 책임자들의 역량은 팀이 크거나 여러 팀의 목
표를 동시에 고려하다 보면 줄어든다.
• 조직적이지 못한 팀이 하나의 프로젝트에서 같이
일하면 비즈니스 목표와 다른 제품이 만들어 질 수
있다.
174. 대규모 스크럼 프로젝트의 성공조건
• 스크럼의 스크럼
• 같은 공간에서 일하는 개발 팀들
• 팀 안에서 적절한 역할의 사람들
• 권한이 있는 스크럼 마스터