애자일 s/w 개발

If I sleep now I will have a dream, but if I study now I will make my dream com true …

Time goes now

Made in 2013.01

SE Lab

김영기 책임

애자일 S/W 개발

2

Time goes now

What’s your point ? This presentation created by Youngki, KimDo not modify arbitrarily without agreement

애자일 개발이란 무엇인가?

3

Time goes now


기존 개발 방법론

Build FirstVersion

Modify untilclient is satisfied

Maintenance

Maintenance

Development

Build and Fix Waterfall

Iteration Model

기존 개발 방법론의 문제

과도한 초과 근무

심각한 품질 문제

계속되는 문제점과 사투

납기지연

4

Time goes now


애자일 헌장

http://agilemanifesto.org/

5

Time goes now


애자일 방법론 (1/2)

‘Agile’의 의미

Marked by ready ability to move with quick easy grace

Having a quick resourceful and adaptable character

기민한, 날쌘 (Ref http://agile.egloos.com/4368289)

Agile 방법론의 등장 배경

S/W 개발 환경의 변화

결과물의 Time to market(적시배포) 가 중요해짐

개발 생산성 저하

기존 방법론의 한계

문서 및 절차 위주의 기존 방법론

• 변화에 신속한 대응이 어려움

개발자의 개발 능력의 차이 불인정

Waterfall model의 문제점

불명확하고, 변화하는 사용자의 요구사항

개발된 모듈들의 통합의 어려움

Software 품질의 하락

• 충분한 테스트가 이루어지지 않음

http://agile.egloos.com/4368289

6

Time goes now


애자일 방법론 (2/2)

Agile 방법론의 정의

특정한 방법론을 지칭하는 것이 아님 Agile 개발을 가능하게 해주는 다양한 방법론들을 통칭함

(Wikipedia)

SW개발환경 등 주위 변화를 빠르게 수용하고, 이에 능동적으로 대응하는 여러 방법론 통칭

특징

더 나은 의사소통

지속적인 변화 관리

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

대표적인 Agile 방법론

Agile Disciplined

인원규모 소규모 대규모

Criticality 낮음 높음

Dynamism 잦은 요구사항 변화 요구사항 변화 통제

개인성향 능동적 규범에 잘 따름

문화 혼란 극복 질서 유지

익스트림 프로그래밍(XP: eXtreme Programing)

Agile 방법론의 대표주자로 Agile 방법론 보급에 큰 영향을 끼침 고객과 함께 2주 정도의 반복 개발을 하고, 테스트와 우선 개발을 특징

- 극단적인 효율성 추구 (동료, 고객, 관리자와의 의사소통을 중시)

스크럼(Scrum)

한 달마다 동작 가능한 제품을 반복적인 개발주기(Sprint)를 중심 개발 팀의 짧은 미팅(Stand-up Meeting)이 프로젝트 관리의 중심 일의 진행 동안에는 누구도 팀을 방해할 수 없음

FDD(Feature-Driven Development)

기능 마다 2주 정도의 반복 개발을 실시 다른 Agile 접근 방법의 장점을 조합 (UML 설계 기법과의 연관성이 있음) 이해 당사자에게 정확하고, 의미 있는 진행 정보를 제공

ETC 이외에도 다음과 같은 Agile 방법론들이 있다.

- Crystal Family(규모에 따라 다른 접근 방법), Lean (불필요한 요소 제거) …

7

Time goes now


애자일의 핵심

8

Time goes now


매주 가치 전달하기

매주 고객에게 가치를 전달하려면 …

큰 문제들을 작은 문제들로 세분화하라

가장 중요한 것에 먼저 집중하라

소프트웨어가 제대로 동작하는지 확인하라

피드백을 구하라

필요하다면 계획을 바꾸어라

책임감을 가져라

애자일의 핵심

애자일 팀

인셉션 덱 소개

인셉션 덱 리스트

사용자 스토리

애자일 추정

애자일 계획

이터레이션 관리

애자일 커뮤니케이션

작업 환경

단위 시험

리팩토링

테스트 주도 개발

지속적인 통합

애자일에서 가장 우선시하는 것은 신속하고 지속적으로 가치 있는 소프트웨어를

고객에게 전달함으로써 고객 만족을 이루는 일이다

9

Time goes now


애자일 프로젝트 계획

애자일로 계획하기

현실적이고, 유연해야 한다

정보의 공개는 기본

프로젝트 범위, 비용, 출시 날짜 등에 관한 결정은 사실을 바탕으로

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

10

Time goes now


완료의 의미

잔디 깎기 아르바이트

여러분의 할머니가 앞마당의 잔디를 정리하기 위해 이웃집 소년

을 고용했다. 소년이 다음과 같은 일을 마쳤다면, 이 소년은 정말

자신의 일을 다했다고 생각할까?

개발 결과를 전달한다는 것은 …

코드를 출시 가능한 상태로 만들기 위해 해야 할 모든 일을 수행

• 분석, 설계, 코딩, 테스트, UX와 디자인 모두를 포함한다

출시되기에 부족하다면, 아직 완료되지 않았다는 뜻이다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

작동하는 소프트웨어는 프로젝트의 진척을 알 수 있는 주된 척도이다.

어떻게 잔디를 갈퀴질 할 것인지에 대한 계획서 작성

우아한 잔디 무늬에 대한 디자인 제시

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

11

Time goes now


S/W 프로젝트에 대한 세 가지 진실

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

<

1. 프로젝트 초기에 모든 요구사항을 수집하기는 불가능하다.

2. 수집한 요구사항을 무엇이든 변하기 마련이다.

3. 시간이나 비용이 허용하는 것보다 항상 할 일이 더 많다.

모든 것을 만족시키는 단 하나의 방법론은 없다 상황과 맥락에 따른 최선의 선택을 하자

12

Time goes now


애자일 팀

13

Time goes now


Setting the Stage

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

14

Time goes now


애자일 팀

애자일 팀은 …

팀원 각각의 역할을 미리 정의하지 않는다.

직위나 역할에 상관없이 누구나 프로젝트에 필요한 일을 한다.

분석, 코딩, 설계, 테스트를 지속적으로 실행한다.

하나의 팀 (품질은 팀 모두의 책임)

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

전통적인 방법

한 단계씩 완성하고넘어가는 시스템

애자일

분석과 개발, 테스트 활동이끊임없이 진행되는 개발 과정

VS

VS

15

Time goes now


애자일 팀

애자일 팀의 특징

같은 공간에서 일한다.

참여하는 고객

프로젝트가 진행 동안 “업무 전문가들(Business people)”과 “개발자”

는 매일 함께 일해야 한다.

자기 조직화 (Self-Organizing)

최고의 아키텍처, 요구사항, 그리고 설계는 자기 조직화된 팀에서 나

온다.

책임감과 자율성

의욕이 가득한 사람으로 팀을 구성하고, 그들에게 필요한 환경과 지

원을 한 후, 이들이 업무를 완성할 것이라 믿어야 한다.

교차 가능팀 (Cross-functional Team)

팀 구성원은 다방면에 걸쳐 많이 알고 관심을

갖는 사람(Generalist)가 좋다.

특정 기술에 종속되지 말아야 한다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

16

Time goes now


애자일 팀

애자일 팀에서의 역할(Role)

애자일 개발팀

애널리스트 – 사용자 스토리 작성, 세부 사항 분석, 태스크 완료 확인

개발자 – 소프트웨어 작성, 추정치 정하기, 기술적인 결정 내리기

테스터 – 개발 스토리에 대한 테스트

프로젝트 관리자 – 프로젝트 진행 확인, 걸림돌 없애기

UX 디자이너

기타 – DB Admin, System Admin, Technical Writer, Trainer …

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

고객 개발팀

애자일 프로젝트에서 역할이란 구체적이지 않으며 누구나 여러 가지 역할을 수행할 수

있다고 이해하는 것이 필요하다

무엇을 개발할지결정한다.

우선 순위를 정한다.

어떻게 개발할지결정한다.

17

Time goes now


애자일 팀

애자일 팀 구성 Tip

제너럴리스트를 찾아라.

애매모호한 상황을 개의치 않는 사람을 찾아라.

제멋대로 행동하는 사람이 아닌, 팀 플레이어를 찾아라.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

Technician GeneralistSpecialist Professional

깊이

너비

경험

18

Time goes now



19

Time goes now


프로젝트 실패

대부분의 프로젝트는 시작하기도 전에 실패한다.

적절한 기대치를 알지 못해서 …

껄끄러운 질문을 하지 못해서 …

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

이거 누가 운전하는 건가요?

난 멀미 나는데...

아직 도착 안 했어?

왼쪽, 오른쪽, 잠깐… 오른쪽..

어디로 가는 거죠?에어컨 좀틀어줘요 !

너무 시끄러워..

20

Time goes now


프로젝트 실패 이유

대부분의 프로젝트가 실패하는 이유는...

사람들이 생각하는 의미가 다르게 해석된다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

현명한 선택을 하기 위해, 목표, 비전, 프로젝트의 상태에 대하여 팀원과 소통하기

이해관계자들이 적절한 결정을 내릴 수 있도록 필요한 프로젝트 정보 제공하기

21

Time goes now


껄끄러운 질문은 언제 하는가?

이런 질문은 프로젝트 초기에 해야 한다.

팀의 프로젝트 경험은 얼마나 되는가?

예산은 얼마나 배당되어 있는가?

프로젝트는 누가 지휘하는가?

유사한 프로젝트 경험이 있는가?

…

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

필요하지만 껄끄러운 질문은 이때 해야 한다.

22

Time goes now


인셉션 덱(Inception Deck)

인셉션 덱

프로젝트 성공률을 높이기 위한 아이디어

프로젝트 관련자들이 함께 모여 ..

프로젝트에 대한 기대치를 동일하게 하기 위해 ..

서로 적절한 질문을 통하여 …

생각을 공유한다

S/W 프로젝트 시작 전에 꼭 물어야 하는 10가지 질문으로 구성

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

인셉션(Inception)은 어떤 활동이나 단체를 시작, 설립하는 단계라는 사전적 의미가 있다. 인셉션을 프로

젝트 초기 단계에 고객과 개발팀이 서로를 알아가는 과정을 갖는 일정 기간(1~2주)이며, "인셉션 덱

(Inception Deck)"은 이 기간 동안 사용하는 도구이다

23

Time goes now


인셉션 덱 리스트 (Inception Deck)

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

24

Time goes now



25

Time goes now



IL1 - 우리가 왜 여기에 모였는가?

프로젝트를 진행하는 이유를 팀원들이 이해하면…

더 많은 정보를 충분히 고려한 보다 나은 결정

서로 대립하는 세력과 Trade-off의 균형 유지

자율적으로 생각하고 판단하는 능력으로 혁신적인 해결책 모색

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

26

Time goes now



IL2 – 엘리베이터 피치 만들기

좋은 엘리베이터 피치는 …

프로젝트의 핵심을 분명히 이해할 수 있다.

팀원으로 하여금 고객의 입장에서 생각하도록 한다.

핵심을 공략한다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

27

Time goes now



IL3 – 제품 상자 디자인하기

제품 광고를 제작하면서 아래와 같은 점을 알 수 있다.

우리 제품이 고객에게 끌릴만한 점이 무엇인지

• 기능보다는 혜택이 무엇인지

이 제품만의 장점이 무엇인지

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

28

Time goes now



IL4 – 하지 말아야 할 것 정리하기

범위 내 – 프로젝트를 진행할 때 꼭 해결해야 할 중요사항

반드시 구체적이지 않아도 좋다.

범위 외 – 다음 릴리즈나 이 프로젝트에서 해결 할 수 없는 것들

미해결 – 더 고민한 후 결정해야 할 사항

나중에 범위 내, 혹은 범위 외의 범주로 옮겨져야 한다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

29

Time goes now



IL5 – 프로젝트 관련자 알아보기

어떤 그룹의 사람들이 이 프로젝트와 관련 있는지 알았다면,

그들과 대화를 나누고, 각 그룹마다 연락 가능한 사람을 만들자

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

단것이도움이된다.

30

Time goes now



IL6 – 해결책 보여주기

해결책을 이야기함으로써 얻는 이점들

어떤 도구나 기술을 사용할지 추측할 수 있다.

프로젝트의 제약사항이나 범위를 시각화 해 볼 수 있다.

리스크에 대해 상의해 볼 수 있다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

31

Time goes now



IL7 – 야근거리가 될 만한 것들 파악하기

리스크(Risk)를 미리 파악하면 좋은 점

프로젝트를 하는 동안 감수해야 할 문제점들을 일찍 파악

납득할 수 없는 이야기에 대한 반론의 기회를 준다.

팀의 결속력을 강하게 하고, 서로의 경험을 배울 수 있는 기회가

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

32

Time goes now



IL8 – 규모 정하기

프로젝트가 얼마나 걸리는지 예측해보는 것으로, 정확하지 않아도

언제쯤 소프트웨어가 출시될 지 알아야 한다.

작은 단위로 생각하기

작고 다룰 수 있는 크기로 나누어야 한다. (Iteration based)

규모에 적당한 기대치를 세우기

현재 상태의 가능한 정보를 기반으로 합리적인 기간을 예측하여

관련자에게 알려주어야 한다. 상황이 변경되면 계획은 수정

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

33

Time goes now



IL9 – 기회 비용 파악하기

프로젝트의 제약을 파악하고, 이에 대한 대책을 생각하자

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

* They can’t all be ‘ON’* No two can occupy the same level

34

Time goes now



IL10 – 우선 순위 파악하기

계획을 세웠으면, 이를 구현하기 위해 필요한 것과 비용을 알아

내야 한다.

최고의 팀 구성

최종 결정권자 파악

비용에 대한 예측

모든 정보의 수집

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

고객

이 프로젝트는 언제 끝나는 건가요?

그리고 비용은 얼마나 드는 건가요?

35

Time goes now


사용자 스토리

36

Time goes now


문서 작성의 문제점

소프트웨어 개발 시 문서에 의존하게 되면 ..

문서를 좀 더 자세히 작성하면 문제가 해결된다.(?)

나는 그녀가 돈을 훔쳐갔다고 말하지 않았어요






애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

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

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

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

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

많은 시간을 낭비한다.

내가 말한 것이 아님

내가 말한 것이 그게 아니라..

다른 사람이 훔친 것 같은데.

빌려간 건데...

돈이 아닌 다른 것을 훔친..

37

Time goes now


사용자 스토리(User Story)

사용자 스토리

고객이 소프트웨어에 원하는 기능을 짧게 표현해 놓은 것이다

작은 인덱스 카드에 적는다.

필요한 것만 짧게…

자세히 모르는 세부 사항은 나중으로 미룬다.

가장 정확하고 효과적으로 정보를 전달하는 방법은 직접 대면 하면

서 이야기 하는 것이다

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

개발 시 요구사항에 관하여 서로 소통할 수 있도록 해주는 무엇이 필요하다. 고객이 원하는 핵심 사항이

적혀있고, 계획 할 때 사용 가능하면서도, 짧고, 무엇을 하고자 했는지 알 수 있는 그 무엇이..

좋은 사용자 스토리는고객에게 가치가 있어야 한다.

그리고 스토리를 완료하기 위해필요한 정보를 포함해야 한다.

가치 = 돈을 주고 사고 싶다

38

Time goes now


좋은 사용자 스토리의 요소

좋은 사용자 스토리는 다음 요소를 갖추어야 한다. (INVEST)

독립적이다. (Independent)

다른 스토리에 종속되지 않아야 한다.

협상 가능해야 한다. (Negotiable)

너무 세세하게 작성하지 말아야 한다.

가치가 있어야 한다. (Valuable)

추정 가능해야 한다.(Estimable)

적당한 크기여야 한다. (Sized right)

하나의 이터레이션에서 개발할 수 있어야 한다.

테스트 가능해야 한다. (Testable)

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

사용자 스토리 템플릿

스토리의 세 측면을 반영

서술: 고객의 요구사항을 문서화하기 보다는 표현하기 위한 것

대화: 대화를 통해 세부사항을 구체화

테스트: 스토리의 완료 여부를 판단

39

Time goes now


사용자 스토리 워크숍

User Story Workshop

개발팀과 고객이 함께 모여,

개발하고자 하는 시스템에 필요한 사용자 스토리를 수집

Workshop Tip

Step 1. 크고 이것저것 붙일 수 있는 벽면이 많은 방을 구하라

Step 2. 그림을 많이 그려라

Step 3. 스토리 많이 쓰기

Step 4. 그 외 모든 것에 대해 브레인 스토밍하라

Step 5. 리스트를 깔끔하게 정돈하자

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

40

Time goes now


애자일 추정

41

Time goes now


애자일 추정

일반적인 추정을 할 때의 가정

대략적인 추정치는 그저 추측일 뿐이다.

대부분 현실성이 떨어지는, 낙관적인 추측일 뿐이다.

정확하게 측정된 추정치란 있을 수 없다.

실제 인셉션 기간에 정한 추정치의 400%까지 달라지는 게 현실이다.

추정치가 말해 줄 수 있는 사실은 …

“이 주어진 시간과 비용으로 프로젝트가 가능한가?”

추정치가 제공하는 기능은 다음과 같다.

미래의 계획을 짤 수 있는 정보를 제공

추정치는 추측일 뿐이라는 사실을 상기

S/W 개발에는 본래 복잡성이 있다는 걸 인지시켜 준다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

소프트웨어의 추정의 주된 목적은 프로젝트의 결과를 예측하는 것이 아니다. 프로젝트의

목표가 통제 가능할 만큼 충분히 현실적인지 알아보기 위한 것이다.

42

Time goes now


상대적인 추정

상대적인 크기 구하기애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

이걸 먹는데

10초가 걸린다면 …요만큼을 먹어 치우는데

걸리는 시간은 대략 얼마 ?

쿠키 2개

쿠키 6개

쿠키 8개 + 우유

IF 쿠키2개 = 10초

THEN 쿠키 6개 = 30초

AND 쿠키 8개 + 우유 = 60초

상대적인 크기를 구하는 간단한 원리가 애자일에서의 추정과 계획의 기초가 된다.

43

Time goes now


사용자 스토리 점수

사용자 스토리 점수 (Story Point)

절대적인 측정 단위는 아니지만, 수치적인 상대치로 추정이 가능

10점짜리 사용자 스토리는 5점짜리보다 두 배의 시간이 걸린다.

해당 업무의 크기와 복잡도에 기초하여 부가

모든 Story를 점수 별 참조 스토리 활용하여 점수 별로 분류

사용자 스토리 점수 추정 시 장점

상대적인 추정이 가능 사람들은 상대적인 추정에 더 강함

작업 기간이 아닌 크기에 초점을 맞춘다

기간은, 나중에 한 주기당 완료 상태를 기반으로 경험적으로 산출

추정치들을 합산할 수 있다.

물리적인 시간을 기준으로 추정 누가하느냐에 따라 변동이 크다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

44

Time goes now


플래닝 포커(Planning Poker)

Planning Poker 추정

광대역 델파이 기법(Wideband Delphi)을 바탕으로 일정을 추정

하는 반복적인 접근 방법

한 사람 추정치보다 팀원 전체의 추정치가 정확하다

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

? $ #

1 4 5

3 3 3

토론…

1. 고객이 스토리를 읽는다.

2. 팀원들이 추정치를 정한다.

3. 팀원들이 서로 토론한다.

4. 팀원들이 다시 추정치를 정한다.(의견이 일치될 때까지 반복)

45

Time goes now


애자일 계획 기초 사항

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

팀이얼마나빨리개발하는지알고…

스토리의상대적인크기가정해지면 ...

출시일이언제쯤일지예상할수 있다!!!

46

Time goes now


애자일 계획

47

Time goes now


애자일 계획

정적인 계획의 문제점

변화에 대응이 힘들다

팀원이 바뀌고,

팀의 능력이 생각과 다르고,

일정이 줄어들고,

요구사항이 끊임없이 변경된다.

애자일에서 계획은 다음 조건을 만족해야 한다.

고객에게 중요한 가치를 전달

가시성이 높고, 투명하고, 정직해야 한다.

현실적으로 실행 가능해야 한다.

필요하다면 계획을 조정하고, 변경할 수 있는 유연함이 필요하다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

48

Time goes now


애자일 계획

애자일로 계획을 세운다는 것은 …애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

팀이 사용자 스토리를 얼마나 신속하게 잘 동작하면서도 출시 가능한 소프트웨어로

만들 수 있는지를 측정해서 언제쯤 소프트웨어가 완성될지 추측하는 작업에 불과하다.

마스터스토리리스트

소프트웨어를만드는

팀의 업무 속도(Point 단위)

사용자 스토리를 출시 가능한 소프트웨어로 만드는

1~2주 동안의 기간

#이터레이션 = 총 작업량 / 팀의 업무속도예) #이터리에션 = 100 Point / 매 이터레이션마다 10 Point = 10 이터레이션

49

Time goes now


애자일 계획

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

작업량을 줄여야 한다.다시 말해 계획을다시 세워야 한다.

애자일 계획을 세우는 방식은 스토리를 측정하고, 우선 순위를 정해서 마스터 스토리를 만

들고, 팀의 속도를 추정한 다음, 출시 날짜를 정하는 순서로 이루어진다.

50

Time goes now


애자일 계획

범위에 유연하라

사용자 스토리는 계속해서 추가, 삭제 될 수 있다.

계획을 현실적으로 유지하고, 팀이 욕심을 부리지 않도록 해야

한다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

51

Time goes now


애자일 계획 세우기 (1/4)

1단계 : 마스터 스토리 리스트 작성하기

보통 1~6개월 정도의 작업량을 가진다

릴리즈 정의

함께 묶어 전달했을 때 고객에게 가치가 있는 스토리들을 논리적

으로 분류해 놓은 그룹이다.

출시할 만한 최소한의 기능을 모아 놓은 세트(Minimal Marketable

Feature Set, MMF)

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

52

Time goes now



2단계 : 크기 정하기

애자일 추정 참조…

3단계 : 우선 순위 정하기

항상 중요한 것을 먼저 개발해야 한다.

고객이 우선 순위를 정하지만, 개발자도 고객에게 추천 가능

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

53

Time goes now



4단계 : 팀의 업무 속도 측정하기

과거 유사한 소프트웨어 개발 경험에서..

프로젝트 초기의 1~2개의 이터레이션 결과에서..

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

모든 스토리가 같은 크기라면…

- 팀의 업무 속도 = 완성된 스토리 / 이터레이션

모든 스토리의 크기가 같지 않다면…

- 팀의 업무 속도 = 완성된 스토리 포인트 / 이터레이션

54

Time goes now


5단계 : 날짜 예상하기


애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

날짜에 맞추어 출시 기능 세트 별로 출시

무슨 일이 있어도출시일은 지켜야 돼!!!

일정이 변경되어도이 기능들은꼭 넣어야 돼

애자일 계획을 세우는 방식은 스토리를 측정하고, 우선 순위를 정해서 마스터 스토리를 만

들고, 팀의 속도를 추정한 다음, 출시 날짜를 정하는 순서로 이루어진다.

55

Time goes now



56

Time goes now




고려 사항

모든 내용을 다 적어 놓을 만한 시간이 없다

• 빠르고 정확하게, 필요한 정보를 제때에 제공하는 분석을 해야 한다

완료된 기능은 완벽히 작동되어야 한다

• 잘 설계하고, 꼼꼼히 테스트해서, 완전히 통합 할 수 있는 코드를 갖도록 해야 한다

기능이 다 잘 작동하는지 확인하기 위해 기다릴 수는 없다

• 프로젝트의 시작부터 시스템이 건강하고, 문제가 없는지 살펴야 한다

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

애자일 프로젝트에서 이터레이션을 이용하여 어떻게 일을 처리하는지를 의미한다

57

Time goes now


애자일 이터레이션

이터레이션

스토리를 작동하는 소프트웨어로 개발하는 1~2주간의 기간

애자일 프로젝트에서 개발을 완성하기 위해 필요한 엔진 역할

고객에게 가치 있는 것을 생산하는 것이 이터레이션의 목적

• 잘 작동하고, 테스트 된 소프트웨어를 생산해야 한다

이터레이션 중간에 스토리를 바꾸지 않는다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

58

Time goes now


이터레이션 실행 예

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

59

Time goes now



60

Time goes now


애자일 커뮤니케이션 계획

이터레이션에서 해야 하는 4가지

스토리 계획 회의 (SPM)

다음 이터레이션에 할 작업 준비하기

쇼 케이스

지난 이터레이션에서 작업했던 스토리에 대한 피드백 받기

이터레이션 계획회의 (IPM)

다음 이터레이션에서 스토리들을 어떻게 작업할지 계획세우기

미니 회고 (Mini Retrospective)

향상될 부분이 있는지 지속적으로 찾아보기

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

Iteration (n)

SPM IPM

Daily Stand-up Meeting

SPM : Story Planning Meeting IPM : Iteration Planning Meeting

61

Time goes now



스토리 계획 회의

Just in Time 으로 다음 이터레이션 준비를 검토

쇼 케이스

업무 성과를 공개하고, 피드백을 받는다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

Iteration (n)

IPM

이번 이터레이션 스토리 데모하기 고객의 피드백 받기

Show the valuable things

쇼 케이스다음 이터레이션 계획하기미니 회고하기

Iteration (n)

SPM Ready to work ?

해야 할 과제는 다 완성했는가? 다음 이터레이션에서 작업할 스토리를 개발할 준비가 되었는가?

62

Time goes now



다음 이터레이션 계획하기

다음 이터레이션에서 무엇을 할지 계획을 세운다.

팀의 속도를 재검토하고, 다음에는 또 어떤 스토리들이 준비되어 있는지 확인

팀이 얼마만큼의 스토리를 개발할 수 있다고 약속

미니 회고 진행하기

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

회고의 최우선 지침

우리가 무엇을 발견하든, 여기 있는 모든 사람이그 당시에 자신들이 알고 있던 정보와 기술, 능력,당시에 사용 가능했던 자원 그리고 주어진 상황에미루어, 그들이 할 수 있는 최선을 다 했다는 것을진정으로 이해하고 믿는다.

- 회고는 마녀사냥이 아니다.

우리가 잘하고 있는 것은 무엇인가?우리가 더 향상시켜야 하는 것은 무엇인가?

Iteration (n)

IPM

프로젝트가 어떤 상황인지 파악하기 팀의 속도 재검토하기 어떤 스토리를 개발할지 확정하기

Planning the next week


Iteration (n)

IPM

프로젝트가 어떤 상황인지 파악하기 팀의 속도 재검토하기 어떤 스토리를 개발할지 확정하기


63

Time goes now



일일 스탠드 업 미팅

문제를 풀기 위한 자리가 아니다.

누구나 참여 가능하지만, 팀원만 발언할 수 있다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

Iteration (n)


팀원들과 함께 할 활동 구성하기 짧게 하기 (10분) 앉지 말기

1. 어제 무엇을 했는가?2. 오늘은 무엇을 할 것인가?3. 내 작업 속도를 늦추거나 방해하는 요소가 있는가?

64

Time goes now



10 Levels of Intimacy in today’s communication애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

65

Time goes now


작업환경 - 시각적인 작업환경 조성하기

66

Time goes now


진행 상태 보기 (1/2)

릴리즈 상황판

스토리 보드 (현재 이터레이션의 사용자 스토리 진행 현황)

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

완성된 스토리 아직 남아 있는 스토리 보아하니

거의 절반 정도

끝난 것 같군 ~

67

Time goes now


진행 상태 보기 (2/2)

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

번다운 차트

팀의 속도 – 얼마나 빠르게 진행되고 있는가?

언제쯤 끝날 것인가?

68

Time goes now


프로젝트가 원하는 것 …

인셉션 덱의 결과가 모두 볼 수 있도록 되어 있는가?

모두가 과제를 왜 시작했는지, 무엇을 원하는지 알아야 한다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

69

Time goes now


의도를 보여주기

작업 동의서와 공유하는 가치

공통된 도메인 언어 (Metaphor)

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

이것이 바로

우리가 일하는

방식이다 !!!

Our Slang ?

No, It is Jargon

밥을 고슬고슬하게 해서요, 그 위에 소금에 절여서 양념장에 무친 오이를 썰어서 넣어 주세요. 그리고 쓴맛을 뺀 도라지를 양념장에 무쳐서 오이옆에 넣어 주시고요, 소고기를 채 썰어서 양념해서 볶은 후 함께 올려주세요, 더불어 고사리도 볶은 후 올려주시고요, 그리고 계란 프라이를 제일 위에 올려주세요. 마지막으로 이 모든 것을 그냥 그릇이 아닌 불에달군 돌솥에 넣어 주세요..

돌솥 비빔밥 하나요 !!!

70

Time goes now


개발자 책상 …

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

http://www.flickr.com/photos/poem23/1594958507/

http://www.flickr.com/photos/poem23/1594958507/

71

Time goes now


단위 시험

72

Time goes now


S/W 테스팅의 목적

품질 향상을 위하여 결함을 발견하는 것이다

품질 수준에 대한 확신과 정보를 얻는다.

명세를 만족시키는지 확인한다.

사용자 및 비즈니스 요구 사항 충족 확인

결함의 예방을 통한 리스크 감소

S/W 테스팅의 제한성 (Limits of testing)

모든 입력 값을 테스트 할 수 없다.

완벽한 테스트는 불가능하다.

테스트는 결함이 없음을 보여주기 위한 것이 아니다.

S/W 테스팅의 목적

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

73

Time goes now


테스팅 범위 (Big Picture)

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

V-Model

Different View

System Engineering

Requirements

Design

Construction Unit Testing

Integration Testing

System Testing (Software)

System Testing (Final)

Methods

Combinations of methods in class

Packages of classes

OO:

Include use-cases

Function

Module

Module combination

Integration tests

System tests

Unit tests

74

Time goes now


테스팅 타입

Block-, Gray, - & White-Box Testing애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

Black box… requirementsActual outputcompared with required output

White box

Gray box

… requirements &

key design elements

Input determined by... Result

…design

elements

Confirmationof expectedbehavior

As for black- and white box testing

75

Time goes now


단위 테스트

단위 테스트는

각각이 독립적으로 테스트되어야 한다.

최소한 한번은 모든 컴포넌트가 테스트되어야 한다.

결함을 쉽게 골라낼 수 있어야 한다.

테스트 범위가 작을수록, 결함을 고치기가 쉬워진다.

Isolatable, Repeatable, Automatable, Easy to Write

단위 테스트의 효과

빠르게 디버깅할 수 있다.

개발시간을 단축시킨다.

더 좋은 설계를 하도록 유도한다.

회귀 테스트를 쉽게 하도록 한다.

미래의 결함 비용을 줄인다.

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

76

Time goes now


테스트 단위

Unit

독립적으로 테스트 할 수 있는 소프트웨어의 코드 조각

Unit Test

단위 테스트 코드는 다른 코드 부분을 호출한다.

단위 테스트는 임의의 가정에 대한 정확성을 검증한다.

만약 가정이 사실이 아닌 것으로 판명된다면, 단위 테스트는 실패

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

public class MyMath

{

public int Add(int i, int j)

{

return i + j;

}

}

public void MyAddTest(){

MyMath m = new MyMath();Assert.AreEqual(m.Add(2, 3), 5);

}

77

Time goes now


Unit Test Roadmap

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

Unit test plan

Products of

prior testing

Test

results

Code

under test

Identify largest

trouble spots

Requirements

Detailed design

Test set

IEEE, 1986

78

Time goes now


테스트 환경

Driver

테스트 입력을 공급하거나 테스트 항목을 호출하고 테스트 결과를

보고하는 프로그램.

Stub

특정 시스템 컴포넌트의 개발이 완료되지 않은 상황에서도 필요한

시험을 진행하기 위해 생성된 더미 컴포넌트

단위 테스트 환경 구성

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

Test cases

Driver

Test Results

Module to Test

StubStub

Stub

79

Time goes now


TDD Tools

xUnit

Test Framework for Specific Language

JUnit, NUnit, CPPUnit, PyUnit, VBUnit, PearlUnit …

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

80

Time goes now


고급 단위 테스팅 이슈

가상 객체 (Mock Objects)

무엇을, 얼마나 테스트해야 하나?

발견되는 결함의 수

추가된 기능

테스트 수행 시간 (Test Running Time Optimize)

코드 커버리지 (Code Coverage)

테스트 구성 관리

지속적인 통합 (Continuous Integration)

단일 / 분산 개발 (Local / Remote Development)

고급 단위 테스팅

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

81

Time goes now


리팩토링(Refactoring)

82

Time goes now


리팩토링

리팩토링의 정의

왜 리팩토링을 해야 하는가?

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

리팩토링(Refactoring) n. :

현재 존재하는 코드를 재구성하는 잘 다듬어진 기법으로,

S/W의 외부적 행동 변화 없이 내부적 구조를 변경하는 방법

리팩토링 하기(Refactor) v. :

리팩토링을 연속적으로 적용하여 소프트웨어를 재구성 하는 것

소프트웨어 디자인 개선 코드를 쉽게 이해하게 함

버그를 쉽게 찾을 수 있음 개발 기간을 단축

83

Time goes now


리팩토링

언제 리팩토링을 해야 하는가?

‘3’의 원칙

새로운 기능을 추가할 때

버그를 수정해야 할 때

코드의 이해하는데 도움을 줌

코드 리뷰를 수행할 때 : 새로운 아이디어를 보다 쉽게 적용

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

뜨거운 라면을 맨손으로 먹겠다 다시 한번 … 새로운 방법을 찾았다

1. 어떤 일을 첫 번째로 한다면 그냥 그 일을 하라

2. 비슷한 일을 다시 한다면 내키지 않아도, 같은 일을 중복하라

3. 어떤 비슷한 일을 세 번째로 한다면 리팩토링 하라

수정할 부분의 코드를 이해하는데 도움을 줌

새로운 기능이 쉽게 추가될 수 있도록 디자인을

변경할 수 있게 함

84

Time goes now


코드의 나쁜 냄새 (Bad Smells in Codes)

정의

잠재적인 문제를 가리키는 프로그램 코드의 증상들

특성

코드 디자인이 취약한 경우 나타남 (But Not Bug)

개발 속도 지연, 결함(Defect), 시스템 장애(Failure) 발생 원인

• 예) 지나치게 긴 메소드, 중복된 메소드나 코드 등

코드의 나쁜 냄새는 리팩토링을 시작해야 함을 알려줌

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

int func1() {

….

}

<Long Method>

int func1() {…result = calc(a,b,c);…

print_result(result);…

}

int result (int a, int b, int c) {

…return result;

}

void print_result(int r){

…}

• 복잡한 내용• 이해가 어려움• 유지보수가 어려움• 기능별 재사용이 어려움

• 메소드가 간략해짐• 이해가 쉬워짐• 유지보수가 쉬워짐• 기능별 재사용 가능

코드의 나쁜 냄새와 리팩토링의 예

85

Time goes now


리팩토링과 테스트

리팩토링과 테스트

테스트는 리팩토링에 필수 요소임

리팩토링 후 ‘소프트웨어의 외부적 행동 변화 없음’을 확인하는 방

• 테스트 (주로 단위 테스트, 필요 시 패키지 테스트)

리팩토링에 사용될 테스트의 조건

자동화 : 리팩토링 작업 중 매우 많이 테스트 수행 테스트 자동화

테스트 수행 직후 결과(Pass/Fail) 확인 가능할 것

• 판단 시간을 줄임

테스트 수행 시점

리팩토링 전 : 결함 없는 코드임을 확인

리팩토링 중 각 단계마다 (코드 수정 직후) :

• 코드 수정이 기능에 영향을 주는지 확인

리팩토링 후

• 리팩토링 작업이 기능에 영향을 주는지 확인

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

86

Time goes now


리팩토링 분류 기법

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

이름 설명 대표 기법

메소드 정리(Composing Methods)

• 긴 메소드를 정리하는데 필요한 기법• 긴 메소드에서 작은 메소드를 추출하는 방법• 메소드 추출을 위해 변수를 정리하는 방법• 메소드의 쉬운 이해를 위해 코드를 개선하는 방법

Extract Method,Replace Temp with Query,Split Temporary Variable

객체 간 기능 이동(Moving Features Between

Objects)

• 객체간 기능 이동을 통해 ‘책임’울 명확하게 지정• 객체 간 메소드를 이동하는 방법• 객체 간 필드를 이동하는 방법• 새로운 객체를 추출하고, 기능을 정리하는 방법

Move Method, Move Field

데이터 조직화(Organizing Data)

• 데이터를 좀 더 쉽게 다루기 위한 기법• 데이터 필드의 접근성 제어 방법• 다양한 타입을 객체로 변경하는 방법• 객체간의 링크를 단순화하는 기법

Self Encapsulate Field

조건 형식 간소화(Simplifying Conditional

Expressions)

• 조건 형식을 단순화 하기 위한 기법• 조건 형식을 단순화하는 방법• 컨트롤 플래그를 제거하는 방법• switch 문을 제거하는 방법

Decompose Conditional

메소드 호출 간소화(Making Method Calls

Simpler)

• 인터페이스를 직관적으로 만드는 기법• 메소드의 이름 변경 및 파라메터 조정하는 방법• 메소드를 기능별로 분리하는 방법

Rename Method, Add Parameter

일반화 다루기(Dealing with Generalization)

• 효율적인 상속관계를 만드는 기법• 상속 구조에서 메소드의 위치를 이동하는 방법• 새로운 클래스 생성 & 상속 구조 변경 방법• 생성자의 위치를 이동하는 방법

Pull Up Field, Pull Up Method, Push Down Field,

Push Down Method

87

Time goes now


Coding Standard

Coding Standard (Small View)

일치된 coding style and practices

clean code and “적절한” code를 정의한다.

정신 없는 코드를 제거한다. (ex. 너무 많은 arguments)

목표는 누가 그 코드를 보더라도 쉽게 이해할 수 있으며,

누가 만든 코드인지 코드만으로 판별을 못하게 한다.

Standards evolve over time

Coding 영역 외에서도 사용이 된다. (Documents, E-mail)

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

88

Time goes now


테스트 주도 개발(TDD)

89

Time goes now


테스트 주도 개발 (TDD)

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

Testing TDD

Design Implement Test Design ImplementTest

90

Time goes now



Workflow0. Read Requirement

1. Add a test

2. Run Test (Make it Fail)

3. Implementation

4. Run Test (Make it Work)

5. Refactoring (Make it Better)

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

Need

Simple code Bad smell?

통과

Simplicity

Test

Refactoring

Code실패하는

테스트 코드작성

테스트를통과하는코드 작성

코드의중복을제거

N번

Refactoring

The only tests

relevant to TDD is

Black-box Unit Testing

91

Time goes now


Writing Good Tests (1/2)

Better Test Practices

Tests must be Small

Easy to understand

They do not break when other parts of the code are changed

One behavioral-assert per test

Test must be Expressive

Test code should communicate its intent

It should not take more than 2 minutes for readers to understand

what is going on.

Tests must be Maintainable

When a test breaks, what it contains should be easiest to fix

Tests must execute Fast

Slow running tests increase Build Viscosity

Tests are Specifications, not Verifications

Specify what should the code do to function correctly

Tests are should talk the Domain Language

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

92

Time goes now


Writing Good Tests (2/2)

Better Test Practices (cont.)

Tests must run at will

Able to write and execute tests without worrying about how to

execute them

Test must be Isolated

Very little set-up and minimum collaborators

Tests must be Thorough

Test all behavior, not methods

Test must be Automated

Write them such that methods on objects are invoked by code

rather then by hand

Tests must be Self-Verifiable

Setup test expectation and compare outcome with expectations

for verdicts

Tests must be Repeatable

The same conditions must yield same results

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

93

Time goes now


지속적인 통합

94

Time goes now


지속적인 통합(Continuous Integration)

지속적인 통합이란 …

팀 구성원들이 작업한 것을 자주 통합하는 S/W 개발 실천방법

지속적으로 퀄리티 컨트롤을 적용하는 프로세스를 실행

소프트웨어의 질적 향상

소프트웨어 배포 시간의 단축

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

개발자

개발자

개발자

변경사항 Commit

Polling

Feedback

빌드 스크립트

CI 서버Code Repository

통합 빌드 머신

소스 코드 컴파일DB 통합테스트 수행소프트웨어배포

95

Time goes now



지속적인 통합의 장점

S/W 위험 요소 감소

결함 조기 발견

S/W 상태 측정이 가능

불확실성 감소

프로젝트 가시성 향상

빌드 상태, 품질 지표 제공

반복적인 프로세스 감소

배포 가능한 S/W 생성

팀원 모두가 최신의 빌드 결과를 공유

개발팀의 S/W 제품에 대한 자신감 향상

CI는 XP의 Practices 중 하나 …

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

Check in Code

Build

Kicks Off

Tests are Run

Results

Sent

< 1 hour

96

Time goes now



S/W 위험요소들과 자동화 프로세스애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

S/W 위험요소 자동화 프로세스 CI 자동화 Tool

■ 배포 가능한 S/W 부재

- 빌드 실패

- DB 동기화 실패

- 배포 실패

- 소스 컴파일

- DB Script 테스트

- 릴리즈

■ 뒤늦은 결함 발견

- 회귀 테스트 부재

- 테스트 적용 범위 부재

- 테스트 수행

- 테스트 적용 범위 측정

■ 프로젝트 가시성 부재

- 자동화 된 피드백 부재

- S/W 시각화 역량 부재

- 통합 결과 피드백

- 각종 다이어그램 생성

- Dash board

■ 저품질 S/W

- 코딩 표준 비준수 코드

- 설계지침 비준수 코드

- 중복 코드

- 복잡한 코드

- 코딩표준 준수 여부 검사

- 설계지침 준수 여부 검사

- 중복 코드 검사

- 코드 복잡도 검사

https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

http://wiki.eclipse.org/Hudson-ci/Meet_Hudson

http://wiki.eclipse.org/Hudson-ci/Meet_Hudson

http://www.lattix.com/

http://www.lattix.com/

97

Time goes now



CI 수행 지침

Maintain a Single Source Repository

Automate the Build

Make Your Build Self-Testing

Everyone Commits To the Mainline Every Day

Every Commit Should Build the Mainline on an Integration

Machine

Keep the Build Fast

Test in a Clone of the Production Environment

Make it Easy for Anyone to Get the Latest Executable

Everyone can see what’s happening

Automate Deployment

애자일의 핵심

애자일 팀



사용자 스토리

애자일 추정

애자일 계획



작업 환경

단위 시험

리팩토링


지속적인 통합

98

Time goes now


Agile 방법론 - eXtreme Programming & SCRUM

99

Time goes now


XP Introduction

익스트림 프로그래밍 (http://www.extremeprogramming.org)

기본 개념은 여러 가지 효과가 좋은 실천방법(XP Rules)을 극한으로 실천하는 것

전통적인 소프트웨어 개발 방법론과는 달리 문서를 강조하지 않고 변경을 장려

모호하고 빠르게 변하는 요구사항을 가지고 일을 하는 중소규모 팀을 위한 경량화 된 방법론 (Kent Beck)

XP 특징

5명에서 10명 정도로 구성된 프로그래머가 고객과 함께 한 장소에서 일한다.

개발은 점진적으로 이루어지고, 각 단계마다 산출물의 기능을 덧붙여 나간다.

요구사항 정의 시에는 사용자가 새로운 기능을 스토리 형태로 구체적으로 작성한다.

프로그래머는 엄격한 코딩 규칙을 준수하고, 짝(Pair)을 이루어 일하며, 단위 테스트를 실시한다.

요구사항, 아키텍처, 디자인은 프로젝트 중간에 언제든지 발생한다.

http://www.extremeprogramming.org/

100

Time goes now


XP Process and Rules

익스트림 프로그래밍 프로세스

개발 프로세스는 Iteration과 Small Releases가 특징

XP Practices는 개인, 소규모 팀, 조직에 적용 가능한 것으로 분류됨

Rules of XP (http://www.extremeprogramming.org/rules.html )

개인

소규모팀

조직

Planning Managing Designing Coding Testing

User stories are written.

Release planning creates the

release schedule.

Make frequent small releases.

The project is divided into

iterations.

Iteration planning starts each

iteration

Give the team a dedicated

open work space.

Set a sustainable pace.

A stand up meeting starts

each day.

The Project Velocity is

measured.

Move people around.

Fix XP when it breaks.

Simplicity.

Choose a system metaphor.

Use CRC cards for design

sessions.

Create spike solutions to

reduce risk.

No functionality is added

early

Refactor whenever and

wherever possible

The customer is always

available.

Code must be written to

agreed standards.

Code the unit test first.

All production code is pair

programmed.

Only one pair integrates code

at a time.

Integrate often.

Set up a dedicated

integration computer.

Use collective ownership.

All code must have unit

tests.

All code must pass all unit

tests before it can

be released.

When a bug is found tests

are created.

Acceptance tests are run

often and the score

is published

http://www.extremeprogramming.org/rules.html

http://www.extremeprogramming.org/rules/userstories.html

http://www.extremeprogramming.org/rules/planninggame.html

http://www.extremeprogramming.org/rules/commit.html

http://www.extremeprogramming.org/rules/releaseoften.html

http://www.extremeprogramming.org/rules/iterative.html

http://www.extremeprogramming.org/rules/iterationplanning.html

http://www.extremeprogramming.org/rules/space.html

http://www.extremeprogramming.org/rules/overtime.html

http://www.extremeprogramming.org/rules/standupmeeting.html

http://www.extremeprogramming.org/rules/velocity.html

http://www.extremeprogramming.org/rules/movepeople.html

http://www.extremeprogramming.org/rules/fixit.html

http://www.extremeprogramming.org/rules/simple.html

http://www.extremeprogramming.org/rules/metaphor.html

http://www.extremeprogramming.org/rules/crccards.html

http://www.extremeprogramming.org/rules/spike.html

http://www.extremeprogramming.org/rules/early.html

http://www.extremeprogramming.org/rules/refactor.html

http://www.extremeprogramming.org/rules/customer.html

http://www.extremeprogramming.org/rules/standards.html

http://www.extremeprogramming.org/rules/testfirst.html

http://www.extremeprogramming.org/rules/pair.html

http://www.extremeprogramming.org/rules/sequential.html

http://www.extremeprogramming.org/rules/integrateoften.html

http://www.extremeprogramming.org/rules/dedicated.html

http://www.extremeprogramming.org/rules/collective.html

http://www.extremeprogramming.org/rules/unittests.html

http://www.extremeprogramming.org/rules/unittests.html

http://www.extremeprogramming.org/rules/bugs.html

http://www.extremeprogramming.org/rules/functionaltests.html

101

Time goes now


XP Values

CommunicationFeedback

Simplicity Courage

Respect

잘되는 가장

단순한 방법으로 한다

팀원 간의 상하관계나

중요도의 차이는 없다고 생각한다.

프로그래밍과 설계에 있어서

개발자 간의 의사소통에 노력한다

사업 목적에 대하여 프로젝트 팀과

고객의 이해를 도우며 서로 조율한다.

코드를 작성하기 전 테스트케이스를,

가장 간단한 솔루션을 선택할 수 있는,

빠르고 즉각적인 피드백을 줄 수 있는,

코드를 리팩토링 할 수 있는..

그런 용기 !!!

우리가

추구하는 가치들

102

Time goes now


XP Practices

Practices

프로젝트를 진행하면서 지켜야 하는 규칙

고정된 것이 아니라 팀원들의 논의 하에 조정 또는 개선이 가능하다.

아래의 12가지 Practices를 개발 동안에 실천하는 것이 XP 방법론의 핵심

On-Site Customer (Whole Team) 개발은 whole team의 지속적인 의사소통으로 이루어진다 팀원들은 다른 팀원들과 최소의 노력, 기다림으로 의사소통 및 개발

The Planning Game 개발 계획을 대략적으로 수립을 먼저 하고 점진적으로 개선한다

Small Releases 결과물(S/W)를 매 iteration마다 release한다 최종 산출물에 대한

예측

Testing (TDD) “동작하는 깨끗한 코드(clean code that works)”를 개발이 목표

Simple Design 지속적인 테스트와 코드 개선을 S/W 디자인을 simple하게 유지

Pair Programming 모든 코드는 최소한 한 번의 리뷰를 거치게 된다

Refactoring 동일한 기능에 대한 디자인이 지속적으로 개선이 되도록 한다

Continuous Integration 매일 여러 번의 통합 과정을 수행한다 위험 요소 제거 및 비용 절

감

Collective Ownership 모든 개발자들은 어떤 부분의 코드라도 접근하고 수정을 할 수 있어

야 한다

Coding Standard 목표는 누가 그 코드를 보더라도 쉽게 이해할 수 있으며, 누가 만든

코드인지 코드만으로 판별을 못하게 한다 (일치된 coding style)

Metaphor 팀원들간의 의사소통을 위해서 필요하다 이상적인 모델과 언어는 Actual problem domain에 있다

40-Hour Week 피로 누적에 따른 project 위험을 낮출 수 있다 인위적인 요소를 고려 피로와 스트레스는 생산성을 낮춘다

http://shamash.typepad.com/.shared/image.html?/photos/uncategorized/metaphor.gif

http://shamash.typepad.com/.shared/image.html?/photos/uncategorized/metaphor.gif

103

Time goes now


SCRUM Introduction

Scrum의 정의 (http://www.scrumalliance.org)

반복적이며 점진적인 소규모 팀 중심의 개발 방법론

팀을 여러 가지 분열과 방해 요소로부터 보호

빠르고 반복적으로 실제 동작하는 Software 제공

요구사항에 변경에 빠르게 대처

소통을 향상하고 협동심을 극대화

SCRUM Elements

SCRUM Team 프로젝트 팀을 의미하며 일반적으로 5~10명으로 구성된다

- Scrum Master : 방해 요소의 제거- Product owner : 무엇이 언제, 어느 주기에 되어야 하는지를 결정

Product Backlog Product의 현재 파악된 모든 requirement들의 리스트

- Product Owner에 의하여 관리되며, 필요 시 수정 가능

Sprint Backlog 이번 Sprint에서 개발을 할 예정이거나 하고 있는 우선 순위로 리스트 된

Product Backlog item들 현재 수행 중인 Sprint 기간 동안에는 변경되지 않음

Sprint 개발과 테스트가 진행되도록 지정된 기간 (2~4주)

Daily Stand-up Meetings 스크럼 팀이 매일 진행하는 Stand-up 미팅 (15분 정도) 다른 팀도 참석 가능하나 발언은 오직 SCRUM 팀만 가능 팀원들의 개발 상황과 현황을 Tacking

Burndown Chart Sprint 기간 동안에 개발된 Sprint Backlog 비율을 표시하는 chart 개발 진행 속도와 추진 사항을 한 눈에 심플하게 볼 수 있음 지속적인 업데이트와 관리가 용이해야 함

Incremental Delivery Sprint 과정의 결과물 테스트가 되었으며, 동작이 되는 실전 배치가 가능한 개발 결과

Progress

752 762

664619

304264

180104

200

100

200

300

400

500

600

700

800

900

5/3/2002

5/5/2002

5/7/2002

5/9/2002

5/11/2002

5/13/2002

5/15/2002

5/17/2002

5/19/2002

5/21/2002

5/23/2002

5/25/2002

5/27/2002

5/29/2002

5/31/2002

Date

Rem

ainin

g Ef

fort

in H

ours

http://www.scrumalliance.org/

104

Time goes now


SCRUM Process

105

Time goes now


스크럼 주요 요소

제품 책임자가 참여.

제품 책임자가 최신 제품

Backlog를 가져온다.

팀 전체가 참여한다.

회의 후 스프린트 계획을 정리

팀 전체가 동의할 계획인지 확인

제품 책임자가 계획 우선 순위의

타당성 확인

Sprint Planning Meeting

아이템의 목적을 정의

우선순위 정리 (내림차순 정렬)

(Business Need 최우선)

추정치는 팀에 의해 산정 기록

스프린트에 적당한 아이템 배분

상위 아이템들의 추정치 정리

Product Backlog

팀 전체가 참여한다.

문제점과 장애요인들을 찾아낸다.

Daily Scrum

매 스프린트 종료 후 데모를 함

동작되는 테스트된 S/W 보여 줌

이해당사자와 제품 책임자에게

피드백을 받는다.

Sprint Demo

이터레이션 길이를 4주 이하로

고정한다.

항상 제 때에 마친다.

팀이 외부로부터 방해 받거나

통제되지 않게 한다.

팀은 하기로 약속한 것들을

해낸다.

Sprint

구체적인 개선안들을 도출

개선안들의 실제 적용

팀 전원과 제품 책임자가 참석

Sprint Retrospective

106

Time goes now


Scrum for Enterprise

107

Time goes now


Agile Adopting

선택적 Agile 기법 적용

Agile 기법의 선택적 적용

프로젝트/팀 단위 최적화

Start here …

Extends …

Pervades …

XPEngineering practices

ScrumElements

LeanSprit

KanbanProcess Design

XPEngineering practices

Inner-T

eam

com

munica

tion S

upport

108

Time goes now


Reference

도서

Web Site

http://agilewarrior.wordpress.com/articles/

www.scrum.org


http://agilewarrior.wordpress.com/articles/

http://www.scrum.org/


http://cfs9.tistory.com/original/13/tistory/2008/09/27/15/15/48ddcf845eb36

http://cfs9.tistory.com/original/13/tistory/2008/09/27/15/15/48ddcf845eb36

http://2.bp.blogspot.com/_yGwrjJUPMes/TRiNbftO6RI/AAAAAAAAARs/RMQKKmJ76pY/s1600/scrum-xp.jpg

http://2.bp.blogspot.com/_yGwrjJUPMes/TRiNbftO6RI/AAAAAAAAARs/RMQKKmJ76pY/s1600/scrum-xp.jpg

109

Time goes now


애자일 s/w 개발

Technology