Agile Process Model

가볍고 비교적 변화를 수용하기 쉬운 방법론

1. Agile 선언문의 기본 가치

1. 프로세스와 도구 중심이 아닌, 개개인과의 상호작용을 중시한다.

2. 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시한다.

3. 계약과 협상 중심이 아닌, 고객과의 협력을 중시한다.

4. 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시한다.

2. Agile의 원칙

• 목표는 고객을 만족시키기 위해 가치 있는 SW를 빠르고 지속적으로 제공하는 것이다.

• 개발 후반에 새로 추가되는 요구 사항도 기꺼이 받아들인다.

• 동작 가능한 소프트웨어를 자주 고객에게 전달한다. 이 기간은 짧을수록 좋다.

• 업무 담당자와 개발자의 의사소통이 잦아야 한다.

• 면대면 대화가 강조된다.

• 진척상황은 실행 가능한 소프트웨어로 보여주는 것이다.

• 팀 분위기는 자유로우며, 미팅은 정기적으로 진행된다.

3. Agile 개발 방법

1. 반복적인 개발을 통한 잦은 출시를 목표로 한다.

2. Agile 개발 방법론의 종류로는 Scrum, Xp, 린 SW 개발방법론, 기능주도 개발방법론 등이 있다.

4. Scrum 개발방법론

• Scrum 이란 럭비에서 사용되는 용어이며, 반칙으로 인해 경기가 중단되었을 때 사용하는 대형이다.

• 효울적인 성과를 얻기 위하여 사용된다.

• 소프트웨어 개발 기술에 중점을 두지 않고, 팀의 개선과 프로젝트 관리에 중점을 둔다.

• 경험적 관리 기법 중 하나이다.

• 구체적인 프로세스를 명확하게 제시하지 않는다.

• 개발 팀을 운영하는 효율적인 운영 방식이다.

5. Scrum 방식의 진행 과정

• 제품 기능 목록 ( ProductBacklog ) 작성

  • 제품 기능 목록이란 우선순위가 매겨진 사용자의 요구사항 목록이다.

  • 일반적인 개발방법의 요구사항에서의 기능 목록에 해당한다.

  • 우선순위 결정자는 제품 책임자. 즉 고객 측 대표인이다.

  • 개발 중에도 수정이 가능하나, 한 주기가 끝날 때까지는 수정이 불가능하다.

• 사용자 스토리 ( UserStory ) 작성

  • 제품 기능 목록에 정의된 사용자 관점에서의 기능들이다.

  • 구현할 기능이 사용자의 관점에서 사용자의 언어로 작성된다.

  • 우선순위가 결정되어야 하며, 큰 것보다 많은 것이 좋다.

  • 다른 Story에 종속되지 않고 독립적이어야 하며, 협상이 가능해야 한다.

  • UserStory의 업무량을 파악하려면 전체 개발 기간 산정이 필요하다.

• StoryPoint 산정

  • UserStory 를 수행하는데 걸리는 상대적인 개발 시간이다.

  • 산정은 개발자가 하며, 중요도의 판단은 업무분석가가 진행한다.

• Sprint ( 개발 단위 )

  • 전력 질주라는 의미이며, 작업량으로 볼 때 많지 않아야 하고 개발 기간도 짧아야 한다.

  • Sprint 라는 의미처럼 작은 단위의 개발 업무를 단기간 내에 전력질주하여 개발한다는 뜻이다.

  • 이는 스프린트 회의에서 결정되며, 보통 2 ~ 4 주 정도의 기간을 가진다.

  • 스프린트의 주기가 결정되면, 결정된 스프린트의 목표와 내용이 개발 도중 바뀌지 않아야 한다.

  • 스크럼 마스터가 외부로부터 오는 개발 방해 요소를 차단시켜 준다.

• 스프린트 구현 목록 ( Sprint Backlog )

  • 각각의 스프린트 주기에서 개발할 작업 목록이다.

  • 세부 작업 항목과 작업자, 예상 작업 시간 등에 관한 정보를 작성하여 개발의 진척 상황을 파악한다.

• 소멸 차트 ( Burndown Chart )

  • 시간이 지남에 따라 소멸되고 남은것을 표현한다.

  • 계획 대비 작업이 어떻게 진행되고 있는지 날짜 별로 남은 작업량을 표현한다.

  • 기울기가 가파를 수록 빠른 작업 진행이며, 기울기가 완만할수록 느린 작업 진행이다.

• 스프린트 계획 회의 ( Sprint Planning )

  • 전체적인 Sprint 계획 회의와 세부적인 Sprint 계획 회의로 나뉜다.

  • 전체적인 Sprint 계획 회의는 아래와 같이 이루어진다.

    • 제품 책임자는 제품 백로그에서 우선순위가 가장 높은 항목을 팀에게 준다.

    • 팀은 항목을 알아서 나누어 갖는다.

    • 항목과 관련이 있는 모든 미해결 질문에 대해 논의한다.

    • 스프린트 기간 동안 팀 간 조율이 필요한지 논의하고, 필요하다면 세부적인 Sprint 계획 회의를 진행한다.

  • 세부적인 Sprint 계획 회의는 아래와 같이 이루어진다.

    • 우선순위가 높은 항목에 대한 구체적인 작업 계획을 수립한다.

    • 결정된 개발 항목에 대한 스프린트 구현 목록을 작성한다.

    • 정해진 작업을 수행하는데 걸리는 소요시간을 추정한다.

• 일일 스크럼 회의 ( Daily Scrum Meeting )

  • 매일 서서 약속된 시간에 15분 이내로 한다.

  • 진행 상황만 점검하며, 스프린트 작업 목록을 잘 개발하고 있는지 확인한다.

  • 모든 팀원이 참석해야하며, 한 사람씩 어제 한 일을 이야기한다.

  • 매일 완료된 세부 작업 항목을 완료 상태로 옮겨 현황판을 업데이트한다.

  • 그날의 남은 작업량을 소멸 차트 ( Burndown Chart ) 에 표시한다.

• 스프린트 현황판 ( Task Board )

  • 개발 팀의 주기 현황 ( 진척도, 남은 작업, 진행 속도 ) 을 나타낸다.

  • 모든 Sprint 주기가 끝나면 최종 제품이 완성된다.

• 스프린트 검토 회의 ( Sprint Review )

  • 하나의 Sprint 반복 주기 ( 2 ~ 4주 ) 가 끝났을 때생성되는 실행 가능 제품에 대해 검토한다.

  • Sprint 목표에 달성하였는지 작업 진행과 결과물을 확인한다.

• 스프린트 회고 ( Sprint Retrospective )

  • 팀이 정한 규칙을 잘 준수했는지 검토한다.

  • 단점보다는 장점을 극대화하는 데 의미를 둔다.

  • 문제점의 해결 방안이 아닌 확인하고 기록하는 정도로만 진행한다.

• 배포 목록 ( Release Backlog )

  • 배포란 사용자에게 시스템의 일부를 제공하는 것이며, 배포 목록은 제품 기능 목록의 항목 중에서 이번에 배포하기로 결정한 목록을 뜻한다.

6. Scrum 방식의 단계별 진행 절차

단계	수행 목록	내용
1	제품 목록 기능 작성	요구사항 목록의 우선 순위 매기기
2	스프린트 계획 회의	스프린트 구현 목록 작성 | 스프린트 소요 시간 추정
3	스프린트 수행	스프린트 개발 | 일일 스크럼 회의 | 스프린트 현황판 변경 | 소멸 차트 표시
4	스프린트 개발 완료	실행 가능한 산출물 계산
5	스프린트 개발 완료 후	스프린트 검토 회의 | 스프린트 회고 | 두 번째 스프린트 계획 회의

7. Scrum 방식의 장단점

• 장점

  1. 반복주기마다 갱신되는 실행 가능한 제품을 통해 사용자와의 의견 조율이 가능하다.

  2. 일일 회의를 통한 팀원들 간의 신속한 협조와 조율이 가능하다.

  3. 다른 개발 방법론들에 비해 단순하며 실전 지향적이다.

  4. 프로젝트 진행 현황을 통하여 신속하게 목표와 결과를 추정한다.

• 단점

  1. 추가 작업 시간이 필요하다.

  2. 일일 스크럼 회의를 15분 내에 마쳐야 한다.

  3. 품질 관련 활동이 없어 프로세스 품질 평가가 어렵다.