1. 박경훈
애자일 의 모든 것
http://blog.hoons.net

2. 진행순서
- 애자일 선언문의 원칙들
- 애자일의 오해
- 스크럼(Scrum)
- User Story
- Estimation
- XP(eXtreme Programming)
- XP Practice #1 – TDD와 테스트 자동화
- XP Practice #2 – Refactoring, CI
- 애자일 사례 소개
1일차
2일차
3일차
4일차
5일차

3. 왜 프로젝트는 실패하는가?
올바른 커뮤니케이션의 부재

4. 프로젝트 매니저 개발자
디자이너
코드의 양이
만만치 않은데
디자인 하기
어려운 기능인데
무조건 빨리
끝내야 하는데
새 요구사항
팀들의 잘못된 목표

5. 애자일의 등장 배경
S/W 개발 환경의 변화
- 결과물의 배포시기가 중요해짐
- 개발 생산성 저하
기존 방법론의 한계
- 문서 및 절차 위주의 방법론 (변화에 대응이 어려움)
- 개발자의 개발능력의 차이 불안정
Waterfall model의 문제점
- 불명확하고 변화하는 사용자의 요구사항
- 개발된 모듈들의 통합의 어려움
- S/W 품질의 하락(충분한 테스트가 어려움)

6. Agile 방법론의 정의
더 나은 의사소통
지속적인 변화 관리
우선순위에 따라 중요한 것 먼저

7. - 어떻게 누가 잔디를 깎을 것인지 계획서
- 섬세하면서 포괄적인 청소 계획서
- 청소 도구 리스트
잔디 청소업체의 사례

9. 애자일 선언문의 원칙들

10. 원칙 #1
우리의 최우선 순위는, 가치 있는 소프트웨어를 일
찍 그리고 지속적으로 전달해서 고객을 만족시키는
것이다.
- 고객이라는 하나의 동일한 목표를 가지는 것
- 자주 보여주는 것이 피드백을 받고 반영할 수 있는 최고의 방법이다.

11. 원칙 #2
작동하는 소프트웨어를 자주 전달하라.
2-4주 간격으로 하되 더 짧은 기간을 선호하라.
- 일정 주기를 통해서 팀에 리듬감을 더할 수 있다.
- 주기를 통해서 평가하고 다시 계획한다.

12. 원칙 #3
작동하고 있는 소프트웨어를 보여주는 것이 진척을
확인할 수 있는 길이다.
- 고객에게 신뢰를 전달할 수 있는 방법이다.
- 결과물 없이 커뮤니케이션이 어렵다.

13. 원칙 #4
비록 개발의 후반부일지라도 요구사항 변경을 환영
하라.
애자일 프로세스들은 변화를 활용해 고객이 경쟁력
에 도움이 되게 한다.
- 프로젝트의 공통된 목표는 고객을 만족시키는 것이다.
- 변화를 통해서 결과를 만들어 가는 것이 애자일 방법론이다.

14. vs

16. 원칙 #5
비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체
에 걸쳐 날마다 함께 일해야 한다.
- 커뮤니케이션의 퀄리티를 높여야 한다.
- 잘못된 지시나 생각의 전달을 줄여야 한다.
- 날마다가 아니여도 바로 피드백이 가능하면 좋다.

17. 원칙 #6
동기가 부여된 개인들 중심으로 프로젝트를 구성하라.
그들이 필요로 하는 환경과 지원을 주고 그들이 일을
끝내리라고 신뢰하라.
- 프로젝트들은 사람을 통해서만 성공할 수 있다.
- 안좋은 환경과 빨리하는 개발의 강조는 협업과 소통을 저해한다.

18. 원칙 #7
개발팀으로, 또 개발팀 내부에서 정보를 전하는 가
장 효율적이고 효과적인 방법은 얼굴을 보며 할 수
있는 대화이다.
- 이메일이나 문서로 충분한 내용을 다루기 어렵다.
- 시간을 절약하는 길이다.

19. 원칙 #8
최고의 아키텍처, 요구사항, 설계는 스스로 움직이
는 조직적인 팀에서 탄생한다.
- 최고의 설계는 팀에 연결된 사람으로부터 나오는 것이지 특정한 역할
로부터 나오는 것이 아니다.
- 일을 하면서 쌓인 작고 큰 지식들이 결국 구조를 만들기 마련이다.

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

21. 원칙 #10
애자일 프로세스들은 지속 가능한 개발을 장려한다.
스폰서, 개발자, 사용자는 일정한 속도를 계속 유지
할 수 있어야 한다.
- 일에 지친 사람은 실수를 만들 확률이 높다.
- 단기간 높은 성과보다 길게 꾸준한 성고가 좋다.

22. 원칙 #11
단순함, 안 해도 되는 일은 최대한 안 하게 하는 기
교, 이것이 핵심이다.
- 사용자와 개발자 그리고 모든 사람들 입장에서 일을 단순화 시킬 수
있어야 한다.
- 아직 안 끝난 일들을 계속 돌아보며 필요없는 일들을 지워나가야 한
다.

23. 원칙 #12
팀은 정기적으로 더 효과적으로 일할 수 있는 방법
을 숙고하고 그에 따라 자신의 행동을 조율하고 수
정한다.
- 커뮤니케이션의 퀄리티를 높여야 한다.
- 잘못된 지시나 생각의 전달을 줄여야 한다.
- 날마다가 아니여도 바로 피드백이 가능하면 좋다.

24. 애자일의 오해

25. 애자일의 오해
애자일 개발 방법론은 새로운 개발 방법론이다.
애자일은 스크럼/XP/칸반 등 하나의
개발 방법론만 이용해야 한다.
No, 가장 큰 차이는 가치와 철학
No, 대부분이 원하는 기술과 프로세스들을
연결하여 사용한다.

26. 애자일의 오해
만약 애자일을 도입하면 100% 프로세스에 따라야
한다.
애자일 개발팀들은 시니어 개발자들로
구성되어야 한다.
No, 작은 것부터 시작해야 한다.
어떤 변화를 주기 전에 충분한 동기가 필요하다.
No, 슈퍼 개발자 집단보다는 능력이 고루
섞인 팀에서 더 큰 장점을 발휘한다.

27. 애자일의 오해
작은 프로젝트에서만 가능하다.
새로운 프로젝트에서만 도입이 가능하다.
No, 가장 큰 차이는 가치와 철학
No, 이미 존재하는 소프트웨어를 확장하고
개발하는 프로젝트에서도 도입이 가능하다.

28. 애자일의 오해
애자일 개발 방법론으로 전환하면 많은 장점을 가
져다 준다.
No, 전환만으로는 어렵다.
팀 전체가 애자일의 가치와 원칙을 공유해야 한다.

29. 커뮤니케이션

30. Exercise - Drawing
Communication Game

31. 스크럼(Scrum)
Ken Schwaber & Mike Beedle

32. 작은 목표를 주기적으로 전달하는 것(Baby
Step)
진행을 모니터링 하고 결과에 따라 계획을 조
절하는 것
비즈니스 목표가 변경되는 것과 개발팀이 민
첩하게 대응하여 완료할 수 있는 것들의 밸런
스를 조정하는 것

33. Values
Commitment
Focus
Openness
Respect
Courage

34. Scrum Team

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)
만든 결과물이 제품 책임자가 원하는 기능인지 확인
진행된 프로그레스의 리뷰 (비즈니스 & 기술적 이슈 공유)
다음 스프린트의 효율을 높이기 위한 아이디어 공유

41. Burndown Chart

42. Scrum Board

44. User Stories

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) 조건

50. Example

51. Example

52. Example

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

54. Exercise – User Story

55. Estimation

56. About Estimation
누가?
왜?
일과 관련된 모든 사람들
스프린트를 계획하고 일들의 우선순위를 정하기
위해서
측정 단위 :
시간 (날짜 or Hours)
복잡도 (포인트)
사이즈 (SS, S, M, L, XL)

57. Planning Poker

58. Exercise – Planning Poker

59. XP(eXtreme Programming)

60. About XP
1999년 켄트 백의 저서인 'Extreme Programming Explained
- Embrace Change‘ 에서 처음 발표
10-12 개의 실천법(Practices)들로 구성

61. Values
Communication
Feedback
Simplicity
Respect
Courage

62. 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

63. XP Anti-practice

64. AntiPatterns of XP Practices
 Introduced by Yoshihito Kuranuki(TIS, Inc.)
and Kenji Hiranabe(Eiwa System Management)
 Japanese XP Community
 Various XP AntiPracties

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

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…

72. Let’s discuss
[story 1. Brownie's Works]

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]

76. Anybody Syndrome - “I’m not
necessary here”

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.

79. Let’s discuss
[story 2. Anybody Syndrome ]

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]

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

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!

89. Let’s discuss
[story 3. Pairing Prison ]

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 ]

92. 테스트 자동화와 TDD

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

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

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

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

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

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

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

101. 자동화 된 테스트가 없다면?
 자체 버그 검출 능력 저하
- 모든 기능을 테스트 하기 어려움
 소스 코드의 품질 저하
- 어디서 버그가 생길지 모르기 때문에 잘못
된 코드도 고치지 않으려 하는 현상
 자체 테스트 비용의 증가
- 작은 수정에도 모든 기능을 다시 테스트 해
야 되는 문제

102. 자동화 된 테스트란?
 모든 테스트 케이스를 코드 스크립트로 변환
한 집합체

104. 3rd party testing tools
 http://www.youtube.com/watch?v=qsh4zWa
6bE8
 http://www.youtube.com/watch?v=4TGkGQo
nmy4#t=64

105. 누가 테스트 스크립트를 만드는가?
Software Engineers
QA Engineers
Software Architect

106. 개발 프로세스
요구사항
Software & QA Engineer
테스트 케이스
수립
- 공백입력 하면 오류 메시지 띄우기
- 사용자가 여러 개의 비디오를 옮길 수
있게
개발
Software EngineerQA Engineer
통합 테스트
코드 작성

107. TDD란 무엇인가?
 Test-Driven Development
- 요구사항의 테스트 요건을 먼저 고려
 Test-First Development
- 개발 전 테스트 코드를 먼저 작성하여 개발
 1999년 XP라는 애자일 기반의 개발 방법론과
함께 소개 됨

108. TDD란 무엇인가?
기존 개발방식
TDD의 개발방식

109. TDD의 장점
 높은 소스코드 품질
- MS와 IBM사의 조사 결과
TDD 약 15~35% 정도의 개발시간 증가 결
함율(버그)은 약 40~90% 정도 줄어듬
- http://research.microsoft.com/en-
us/groups/ese/nagappan_tdd.pdf
 재설계 시간의 절감
 손쉬운 테스트 근거 산출 및 문서화 (test
coverage, performance)
 디버깅 시간의 절감

110. TDD의 단점
 all about 개발 생산성!

111. 1부터 10까지의 수를 출력하는 프로그램 만들기!
- 단, 3의 배수에서는 숫자대신 “HOONS”를 출력
- 5의 배수에서는 “JAEDAM”을 출력

112. 통합테스트와 유닛테스트
Dependency Injection
= AOP

113. 편의점 카운터에서 물건을 스캔한 뒤에 고객에게 최종 가격을 알려주는
프로그램이 필요합니다.
물건들의 가격은 데이터 베이스에 있으며, 한가지 특별한 것은 현재 모
든 물건을 2개 사면 하나 더 주는 이벤트를 하고 있기 때문에 이 로직을
반영해주세요.

114. 데이터 레이어 => 가격정보
비지니스 레이어 => 할인점검 유닛테스트
유닛테스트
통합테스트

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
테스트 요청
결과물
피드백
코드 리뷰

118. Continuous Integration

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

121. Why CI?
구현 기능의 가시화 (작업물의 공유)
프로젝트의 결함 조기 발견

123. CI를 넘어

127. Developer vs Operator

129. Devops tools

130. 코드 리팩토링

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

132. 그 이름은 스파게티,,

133. 좋은 코드란?
“기계가 아닌 사람이 이해
할 수 있게 작성된 코드”

134. 리팩토링(Refactoring) 이란?
“소프트웨어 디자인을 개선하고 코드를 쉽게 사용하
고 이해할 수 있게 만드는 작업”

135. When to refactor?
새로운 함수를 추가할 때
버그를 수정해야 할 때
코드 리뷰를 수행할 때

136. 리팩토링이 무의미한 경우
리팩토링을 실행해도 복구가 어려울 정도로 망가져
버린 코드들
데드라인이 너무 가깝고 리팩토링한 검증할 테스트
코드가 없을 때

137. 나쁜 코드 스멜
복사된 코드 로직
너무 긴 메서드
굉장히 긴 클래스
너무 많은 파라미터 리스트

138. Before Refactoring
테스트 코드의 작성

139. 나의 규칙을 따르라!

140. #1 메서드 추출
void PrintOwing(double amount)
{
PrintBanner();
//print details
WriteLine("name:" + _name);
WriteLine("amount" + amount);
}
void PrintOwing(double amount)
{
PrintBanner();
PrintDetails(amount);
}
void PrintDetails(double amount)
{
WriteLine("name:" + _name);
WriteLine("amount" + amount);
}

141. #2 인라인 메서드
int GetRating() {
return (MoreThanFive()) ? 2 : 1;
}
bool MoreThanFive()
{
return _number > 5;
}
int getRating()
{
return
(_number > 5) ? 2 : 1;
}

142. #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);
임시 변수는 한번만 할당

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가지 단위 테스트 패턴을 통한
테스트 코드 리팩토링 기법 – 저) 제라드 메스자로스

152. 애자일 도입사례

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주 간격의 스프린트
- 일일스크럼미팅 / “스크럼”의 스크
럼 미팅 진행
- 각 팀별로 스크럼 마스터, 제품 책
임자는 중앙팀에 배치

166. 9개의 팀 = 각 팀병1명의 스크럼마스터 + 팀원들
중앙 관리 팀
제품 책임자

167. 무엇이 잘못되었을까?
- 진행 속도가 2주차 부터 현저히 감소
- 1명의 제품 책임자가 너무 바쁨
- 제품 책임자가 어떤 결정을 혼자서 내리기 어려움
- 백로그에 우선순위가 없어서 자신이 원하는 항목
부터 처리
- 제품 책임자가 결정을 내리지 못하여 미팅이 잦아
짐
- 스크럼으로는 성공할 수 없다는 목소리들

168. Let’s discuss

169. 처음 시도
중앙 팀을 2개로 나눠서 관리

170. 하지만
이전과 비교해서는 좀 나아짐
하지만 여전히 각 팀들의 스크럼을 중앙에 동기화 하
는 것이 어려움
각 팀 별로 가지고 있는 의존성 때문에 잦은 미팅
두 책임자들의 잦은 충돌과 비효율적인 결정

171. 자기 주도적으로 일하기
각 9개의 팀 별로 제품 책임자의 역할을 하는 제품
프로듀서를 다시 임명
9개의 팀 = 각 팀병1명의 스크럼마스터 + 팀원들

172. 효과
• 각 팀들은 보다 분명한 제품의 책임 의식 고취
• 프로젝트 요구사항이 명시적으로 정의 가능
• 질문에 대한 빠른 답변 가능
• 각 팀들이 명확한 제품 백로그를 생성 & 스프린트
계획수립 가능
• 해야 할 업무의 배분이 적절이 이루어졌고 새로운
기능들을 매 스프린트마다 고객에게 전달
• 각 팀의 제품 책임자들은 각자 맡은 분야의 전문가
가 됨
• 일관성이 없었던 제품 백로그 항목들이 각 팀들에
의해서 완화됨

173. BBC의 팀
• 프로젝트 안에서 각 팀을 구성할 때 제품 책임자와
함께 할 수 있는 시간을 고려해야 한다.
• 한 명의 제품 책임자에 의존하다 보면 결국 일 진
행이 늦어지고 프로젝트의 올바른 방향을 설정하는
것이 어렵다.
• 제품 책임자들의 역량은 팀이 크거나 여러 팀의 목
표를 동시에 고려하다 보면 줄어든다.
• 조직적이지 못한 팀이 하나의 프로젝트에서 같이
일하면 비즈니스 목표와 다른 제품이 만들어 질 수
있다.

174. 대규모 스크럼 프로젝트의 성공조건
• 스크럼의 스크럼
• 같은 공간에서 일하는 개발 팀들
• 팀 안에서 적절한 역할의 사람들
• 권한이 있는 스크럼 마스터

175. 박경훈
hoonsbara@hotmail.com
http://blog.hoons.net
http://twitter.com/_hoons