Agile Project Management with Scrum

애자일 프로세스를 소개하기전에 일러두기

1. 애자일 개발 방법론은 수많은 개발 방법론 중 한가지 일 뿐 모든 방법론 중 '최고' 또는 '최선'의 방법이 아니다. 가장 좋은 개발 방법론은 각각의 개발팀, 개발 프로젝트가 처한 상황에 맞는 방법론이다. 때로는 고전적인 폭포수 개발 방법론이 최선인 경우도 있다.

2. 본 글에서 소개하는 애자일 개발 방법론의 상세 실천법은 각 프로젝트 및 팀마다 다를 수 있다. 본 글에서는 여러가지 레퍼런스를 참조하여 본인이 판단하기에 적절한 실천법 중 한가지를 소개하는 것이다. 따라서, 실제로 애자일 프로세스를 적용할 때는 본 글에서 소개하는 방법은 참고만 하고, 각 팀에 맞게 적절히 수정해서 사용하는 것을 추천한다.

왜 애자일을 적용해야 하나

전통적 프로젝트 개발방식: 폭포수 모델(Waterfall Model)

폭포수 모델(waterfall model)은 순차적인 소프트웨어 개발 프로세스(소프트웨어를 만들기 위한 프로세스)로, 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 이름이 붙여졌다. 이 폭포수 모델의 흐름은 소프트웨어 요구사항 분석 단계에서 시작하여, 소프트웨어 설계, 소프트웨어 구현, 소프트웨어 시험, 소프트웨어 통합 단계 등을 거쳐, 소프트웨어 유지보수 단계에까지 이른다. - 위키백과

전통적 프로젝트 개발방식의 한계 (ref [5])

• 초기에 설정된 업무 범위, 일정, 비용은 반드시 지켜져야 할 목표로 여겨짐
• 대다수 프로젝트에서는 요구사항은 개발이 진행되고 구체화 되면서 계속해서 변동되고, 이에 따라 실제 투입되는 일정과 비용도 변동 될 수 밖에 없다.
• 프로젝트 일정과 예산이 고정되어 있는 상황에서 요구사항이 자주 변경된다면, 기존 요구사하오가 변경사항의 우선순위를 관리하여 주어진 제약 조건을 충족해야 한다.

• 프로젝트 초기에 구체적인 요구사항을 도출하기 어렵다.
• 프로젝트 초기에 고객의 요구사항은 매우 불명확하고, 포괄적이다.

• 프로젝트 중간에 발생하는 요구사항의 변경을 반영하기 어렵다.
• 폭포수 개발 방식은 프로젝트의 후반부에 시스템을 완성하기 때문에, 고객의 피드백 또한 프로젝트 후반부에 본격적으로 시작된다. 이 단계에서의 변경사항은 전체 일정과 비용에 많은 영향을 미친다.

• 프로젝트 과정 중 중간 산출물(=문서작업)을 많이 요구한다.

• 프로젝트 관리자 중심의 명령과 통제 방식 때문에 구성원은 수동적으로 바뀌고, 커뮤니케이션이 매우 부족 하다.

애자일 소프트웨어 개발의 철학

애자일 소프트웨어 개발 선언문

1. 프로세스와 도구 보다는 개인과 개인 간의 상호작용에 더 큰 가치를 둔다.

2. 포괄적 문서화보다는 동작하는 소프트웨어에 더 큰 가치를 둔다.

3. 계약 협상보다는 고객과의 협력에 더 큰 가치를 둔다.

4. 계획을 따르기 보다는 변화에 대응하는 것에 더 큰 가치를 둔다.

12가지 애자일 소프트웨어 개발 원칙(Principle)

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

2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

3. 작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더 짧은 기간을 선호하라.

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

5. 동기가 부여된 사람들을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

7. 작동하는 소프트웨어가 진척의 주된 척도이다.

8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.

9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

10. 단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다.

11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.

12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

애자일 프로젝트 관리의 목표 (ref [5])

1. 지속적인 혁신

2. 제품 적시 출시

3. 확장성 있는 제품

4. 사람과 프로세스의 적응력

5. 신뢰성 있는 결과

전통적 vs. 애자일 프로젝트 관리의 비교 (ref [5])

애자일 소프트웨어 개발 방법론의 종류

애자일 프로세스 도입 단계

1. 애자일 프로젝트 인셉션: 프로젝트 초기단계에 고객과 개발팀이 서로 알아가는 과정을 갖는 일정한 기간. '인셉션 덱' 이란 도구를 통해 프로젝트를 '왜' 하는지 '어떻게' 수행 할 것인지에 대해 모든 관계자가 공통의 이해를 할 수 있도록 돕는다.

2. 스크럼 계획하기: 모든 요구사항을 리스트업한 백로그를 작성하고, 릴리즈와 스프린트 계획을 세우는 단계

3. 스크럼 실행하기: 스프린트 관리, 일일 스크럼, 스프린트 리뷰, 스프린트 회고 미팅 등을 통한 구현 단계

4. 애자일 프로세스에서 최고의 성능 뽑아내기: 애자일 개발 방법론과 함께 도입되었을 때 그 효과가 배가 되는 개발 방법론들.(단위테스트, 리팩터링, 테스트 주도 개발, 지속적인 통합)

애자일 프로젝트에 들어가기 전: 애자일 프로젝트 인셉션

인셉션 덱(Inception Deck)

1. 우리가 여기 왜 모였는지 물어보라: 우리가 모인 목적이 무엇인지, 우리의 고객은 누구인지, 왜 이 프로젝트를 하기로 했는지 상기시키기 위함.
• 직접 보고 파악하라: 개발할 시스템이 필요한 곳에 직접 방문하거나, 그들의 문제를 직접 체험해 보고, 고객에게 직접 질문하라
• 지휘관의 의도(Commander's Intent) 파악하기: 이 프로젝트가 성취하고자 하는 목표나 임무를 정확히 표현한 것.

2. 엘레베이터 피치를 만들라: 30초동안 단 두 문장으로 프로젝트를 설명하라
• '엘레베이터 피치'는 짧은 시간 안에 핵심을 피력하는 방식이다.
• 엘레베이터 피치 템플릿

[고객이 필요로 하는 사항]을 [목표로 하는 고객]에게 [제품의 카테고리]인 [제품의 이름]은 [제품이 주는 혜택이나 구매해야만 하는 이유]이다. [경쟁사 제품의 기능과 다르게] 우리 제품은 [우리 제품이 가지는 특별한 점]이다.

3. 제품의 광고를 디자인 하라: 제품이 고객에게 끌릴만한 점이 무엇인지, 이 제품만이 가진 남다른 기능은 무엇인지 생각하게 해준다.
• 1단계: 제품이 제공하는 혜택이 무엇인지 브레인스토밍하라.
• 2단계: 슬로건 만들기
• 3단계: 상자 디자인하기

4. Not 리스트를 작성하라: Not 리스트를 작성하면 어떤 것이 프로젝트 범위에 포함되는지, 혹은 포함되지 않는지 분명히 알 수 있다.
• '범위 내' 항목: 프로젝트를 할 때 초점을 맞춰야 할 사항들
• '범위 외' 항목: 다음 릴리즈로 연기해도 무리가 없거나, 이 프로젝트에서는 도저히 해결할 수 없는 사항들
• '미해결' 항목: 더 고민해 보고 결정을 내려할 사항들. 이 항목의 아이템 수는 가능한 최소화 한다.

5. 프로젝트와 관계된 다양한 사람들과 알고 지내자: 개발팀원 외에 프로젝트와 관련된 모든 사람들에 대해 브레인스토밍해보고, 그들과의 친분을 유지하도록 노력한다.

6. 해결책을 보여주라: 기술적인 아키텍쳐 청사진을 보여주면서 과연 모두가 같은 생각을 하고 있는지 확인해보자
• 어떤 도구나 기술을 사용할지 추측
• 프로젝트 제약사항이나 범위를 시각화
• 리스크에 대한 상의

7. 미리 야근 거리가 될만한 것을 찾아보자: 프로젝트 중 예상되는 어려움.

8. 규모를 정하라: 이 프로젝트는 얼마나 걸릴까?(1개월, 3개월, 6개월?)

9. 고객의 우선순위를 파악하라: 시간, 비용, 품질, 범위의 4가지 요소 중 범위는 프로젝트에 따라 변경 가능하다. 4가지 요소 외에 프로젝트의 성패에 영향을 미칠 수 있는 요소도 추가하도록 한다.

10. 기회비용이 무엇인지 파악하라
• 프로젝트 수행을 위한 팀 어떻게 구성되어야 하는가?
• 최종 결정자가 누구인지 파악하라.
• 시간과 비용이 얼마나 들지 추측해보기

스크럼:계획하기

스크럼 개발 흐름

스크럼팀의 구성

• 제품 책임자: 제품 백로그(=요구사항) 관리를 담당하는 유일한 사람. 모든 제품 백로그 변경은 반드시 제품 책임자를 통해야만 한다.

• 개발팀: 매 스프린트에서 "완료"된 기능을 지속해서 추가하여 잠재적으로 출시 가능한 제품을 배포할 수 있는 전문가로 구성된 팀.
• 개발팀은 제품을 만드는데 필요한 모든 기술이 있는 교차기능 팀입니다.
• 스크럼에는 개발팀 안에 하위 팀이 없습니다.
• 제품에 대한 책임은 특정 개발자가 아닌 개발팀 전체에 있습니다.

• 스크럼 마스터: 스크럼 가이드에 따라 스크럼을 장려하고 지원할 책임을 갖는 사람. 스크럼 프로세스 관리자 및 전도사.
• 목표, 개발 및 제품 도메인을 스크럼 팀의 모든 사람이 이해할 수 있도록 확인
• 애자일의 이해와 실행. 스크럼 이벤트의 진행 등
• 개발팀의 개발 진행 방해 요소 제거. 개발팀 코팅

제품 백로그 만들기

• 제품 백로그는 요구사항에 대한 완성본이 아닙니다. 제품 백로그는 제품과 함께 진화하고 유동적입니다.

• 제품의 다음 배포에 추가로 포함된 모든 피처, 기능, 요구사항, 개선사항, 수정항 버그 등을 나열합니다.

• 제품 백로그 항목들은 각가에 대한 설명, 우선순위, 스토리 점수 등을 포함합니다.

• 제품 백로그 정제(refinement)는 제품 백로그 항목(=스토리)들에 대한 상세한 내용, 스토리 점수, 그리고 우선순위를 추가하는 활동입니다. 이는 제품 책임자가 개발팀이 공동으로 각 항목을 검토하고 수정합니다. 상세화 작업을 위해 보통 개발팀 전체 가용시간의 10% 미만을 사용합니다.
• 스토리 점수: 요구사항의 규모를 측정하는 단위로 요구사항에 대한 크기(=업무량)를 의미한다.
• 스토리 점수 추정을 위해 플래닝 포커와 같은 방법을 추천한다.

• 제품 백로그 항목들은 그것이 "완료"되었을 때의 테스트 조건을 포함합니다.

• 제품 백로그 작성 지침: 애자일 전문가 마이크 콘이 제시한 6가지 지침
1. 상호 독립적이어야 한다.
2. 변경이 가능해야 한다
3. 사용자와 고객에게 가치가 있어야 한다
4. 추정이 가능해야 한다
5. 크기가 적절해야 한다
6. 테스트가 가능해야 한다.

• 높은 우선 순위의 제품 백로그 항목들을 좀더 상세하게 정의하고, 낮은 우선 순위 항목은 대략적으로만 표현합니다.

마일스톤 계획/릴리즈 계획 수립하기

• 마일스톤 계획: 프로젝트의 주요 단계외 업무, 이벤트 등을 표시한 요약 일정

• 릴리즈 계획: 프로잭트에서 수행할 제품 백로그를 표현한 전체 일정 계획

• 스프린트 계획: 2~4주 단위로 개발팀이 실제 수행하는 작업들로 구성된 상세 계획

스프린트 백로그 만들기

• 스프린트 백로그는 오직 개발팀만 스프린트 동안에 변경할 수 있습니다.

• 제품 백로그가 고객이 이해할 수 있는 언어로 작성되어 있다면, 스프린트 백로그는 개발팀이 실제 수행하는 개발 용어로 작성합니다.

• 스프린트 백로그에는 개발팀이 하는 일이 모두 나타나야 한다. (코드 리뷰, 업무회의, 교육, 세미나 등 포함)

• 도출된 스프린트 백로그는 스프린트 진행 상황판에 붙입니다.

• 스프린트 백로그의 크기는 2~3일 안으로 끝 낼수 있는 양으로 분할 합니다.

스크럼:실행하기

일일 스크럼(=데일리 스탠드업 미팅)

• 어제 내가 한 일

• 오늘 내가 할 일

• 업무 진행 중 발생한 장애 요인

• 도움이 필요한 사항

• 일일 스크럼은 업무를 보고하는 미팅이 아니다.

• 미팅 시간은 15분을 넘기지 않는다. 논의가 필요한 이슈는 별도의 미팅을 잡는다.

스프린트 진행 상황판

번다운 차트와 프로젝트 속도

스프린트 리뷰

• 미팅에는 스크럼 팀과 제품 책임자가 초대한 핵심 제품 이해관계자들이 참석합니다.

• 제품 책임자가 “완료”된 제품 백로그 아이템과 “완료”되지 못한 아이템을 설명합니다.

• 개발팀은 스프린트 동안 무엇이 잘 진행되었는지, 무슨 문제가 있었는지, 어떻게 문제들을 해결했는지 논의합니다.

• 개발팀은 “완료”된 작업을 시연하고 그 제품 증분에 대한 질문에 답변합니다.

스프린트 회고 미팅

애자일:최고의 성능 뽑아내기

단위테스트

• 단위 테스트는 피드백을 즉각적으로 준다.

• 단위 테스트는 회귀테스트(regression test) 비용을 극적으로 낮춰준다.

• 단위 테스트는 디버깅 시간을 획기적으로 줄여준다.

• 단위 테스트는 우리가 자신 있게 배치(deploy)할 수 있게 해준다.

리팩터링: 기술적 부채 갚기

테스트 주도 개발(Test-Driven Development, TDD)

1. TDD를 하면 개발 시간이 늘어난다. 개발 시간이 TDD를 하지않을 때에 비해 대략 10~30%가 늘어난다.

2. TDD를 하면 결함이 줄어든다: 결함이 1/2~1/10 까지 줄어든다. SW를 개발하면서 예상하지 못했던 시간을 많이 소요하는 것은 대부분이 버그 때문이다. TDD를 하면 이런 버그를 줄일 수 있다.

3. TDD를 하면 코드 복잡도가 떨어진다. 엔트로피(Entropie)가 낮아진다. 깨끗한 코드가 나온다. 유지보수 비용이 낮아진다.

지속적인 통합(Continuous Integration)

• 소스코드 저장소: Git

• 체크인 프로세스 수립하기: 애자일 팀원들 간에 다음과 같은 프로세스를 수립하고 철저히 지키도록 한다.
1. 저장소에서 최신 소스코드 받기
2. 코드 수정
3. 테스트 실행하기
4. 업데이트 더 필요한지 확인하기
5. 테스트 다시 실행하기
6. 체크인

• 자동화된 빌드: Hudson, Jenkins 같은 빌드 에이전트를 이용하여, 코드가 변경될 때마다 자동으로 빌드하고 오류가 발생하는지 여부를 알려주도록 한다.

• 작은 단위로 일하려는 마음가짐: 코드 통합 작업은 가능한 자주, 작은 단위로 수행되어야 한다.