2.소프트웨어 공학과 개발 프로세스 (2)

8. 애자일 프로세스 모델

애자일 프로세스 모델의 이해

애자일 프로세스 모델

• 에자일(agile): ‘날렵한’, ‘민첩한
• 애자일 프로세스 모델: 고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론
• 가벼운 프로세스 방법론의 공통적인 특성을 정의
• 2001년 1월에 ‘애자일 연합’ 그룹에서 서로의 공통점을 찾아 ‘애자일 선언문’ 이라는 공동 선언서를 발표

애자일의 기본 가치

• 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시
• 문서 중심이 아닌, 실행 가능한 소프트웨어를 중시
• 계약과 협상 중심이 아닌, 고객과의 협력을 중시
• 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시
• 환경과 고객의 변화에 능동적으로 대처하는 것을 강조

애자일의 원칙

• 최우선적인 목표는 고객을 만족시키기 위해 가치 있는 소프트웨어를 빨리, 지속적으로 제공하는 것
• 개발 후반에 새로 추가되는 요구사항도 기꺼이 받아들임
• 애자일 프로세스는 고객의 경쟁력 을 위해 요구사항의 변경을 받아들임
• 동작 가능한 소프트웨어를 짧으면 2주, 길면 2개월 간격으로 자주 고객에게 전달, 이때 간격은 짧을수록 좋음
• 프로젝트가 진행되는 동안에 업무 담당자와 개발자는 매일 서로 의견을 주고받으며 함께 참여
• 가장 효과적인 의사소통 방법은 역시 직접 만나 얼굴을 보면서 대화하는 것
• 진척 상황의 척도를 나타내는 방법 중 가장 좋은 방법은 실행 가능한 소프트웨어를 보여주는 것
• 자율적 사고와 자유로운 분위기의 프로젝트 팀에서 최고의 아키텍처, 요구사항, 설계가 나옴
• 프로젝트의 효율성을 향상하기 위해 개발 팀 스스로 정기적인 미팅을 진행해 자신들의 행동을 되돌아보고 조율 및 수정

애자일 프로세스 개발 방법

• 가장 기본이 되는 기능만 1차 요구사항으로 분석하고 이를 반복으로 나누어 개발
• 사용자가 릴리스 1을 사용하는 동안 개발자는 2차 개발을 진행
• 이때 좀 더 복잡한 편집 기능과 고급 기능을 추가해 마찬가지로 이를 반복 으로 나누어 개발
• 프로세스 개발 방법은 반복적인 개발을 통한 잦은 출시를 목표로 함
• 실행 가능한 프로토타입을 만들어 사용자에게 확인받음
• 좀 더 빠른 시간 안에 일부지만 소프트웨어를 사용할 수 있게 하는 것을 중요하게 생각

애자일 프로세스 모델과 폭포수 모델의 비교 (중요)

구분	애자일 프로세스 모델	폭포수 모델
추가 요구사항의 수용	처음 수집한 요구사항을 전체 중 일부로 인정하고 시작하므로 언제든지 추가 요구사항이 있을 것으로 간주한다. 따라서 추가 요구사항을 수용할 수 있는 방법으로 설계되어 있다.	요구사항 분석이 완전히 완료된 후에 설계 단계로 넘어가므로 새로운 요구사항을 추가하기 쉽지 않다. 추가 요구사항을 반영하기 어려운 구조다.
릴리스 시점	가능하면 자주, 빨리 제품에 대한 프로토타입을 만들어 사용자에게 보여준다. 이러한 방식을 반복적으로 수행해 최종 제품을 만들기 때문에 자주 릴리스 된다.	요구사항에 대한 분석, 설계, 구현 과정이 끝나고 최종 완성된 제품을 릴리스한다.
시작 상태	계속적인 추가 요구사항을 전제로 하는 방식이라 시작 단계에서는 부족한 점이 많지만 점차 완성도가 높아진다.	한 번 결정된 단계는 그 이후에 변동이 적어야 한다. 따라서 완성도를 최대한 높여 다음 단계로 넘어가기 위해 시작 단계의 완성도가 매우 높다.
고객과의 의사소통	사용자와 함께 일한다는 개념을 담고 있다. 처음부터 사용자의 참여를 유도하고 많은 대화를 하면서 개발을 진행한다.	사용자 요구사항을 정의한 후 사용자에게 더는 추가 요구가 없다는 확답을 받고 개발에 들어간다. 산출물을 근거로 하기 때문에 사용자와의 대화는 적다.
진행 상황 점검	개발자와 사용자는 개발 초기부터 지속적으로 진행 상황을 공유하며 함께 관심을 갖고 진행해 나간다.	단계별 산출물을 중요시하기 때문에 단계별 산출물에 대한 결과로 개발의 진척 상황을 점검한다.
분석, 설계, 구현 진행 과정	분석, 설계, 구현이 하나의 단계와 그 단계 안의 반복마다 한꺼번에 진행된다. 다만 어떤 단계에서는 분석이 많고 구현이 적고 어떤 단계에서는 분석이 적고 구현이 많다는 차이만 있을 뿐이다.	분석, 설계, 구현 과정이 명확하다. 각 과정에서 생산되는 산출물 중심의 개발 방식이기 때문에 단계가 명확히 구별되어 있다. 따라서 분석이 끝난 후 설계를, 설계가 끝난 후 구현 작업을 진행한다.
모듈(컴포넌트) 통합	개발 초기부터 빈번한 통합을 통해 문제점을 빨리 발견하고 수정하는 방식을 택한다. 문제점을 빨리 발견하므로 비용을 절감할 수 있다는 장점이 있다.	V 모델에서 설명한 것처럼 구현이 완료된 후에 모듈 간의 통합 작업을 수행한다.

애자일 프로세스 모델: 스크럼 

스크럼 방식

스크럼

• 원래 럭비 경기에서 사용하는 용어로 반칙으로 인해 경기가 중단되었을 때 쓰는 대형
• 팀이라는 단어가 주는 의미를 개발 팀에 적용해 효율적인 성과를 얻기 위해 소프트웨어 개발 프로세스에서 사용

스크럼 방식

• 소프트웨어 개발보다는 팀의 개선과 프로젝트 관리에 중점을 둔 애자일 방법론
• 경험적 관리 기법 중 하나
• 구체적인 프로세스를 명확하게 제시하지 않음

스크럼 방식의 진행 과정

제품 기능 목록

제품 기능 목록의 정의

• 사용자가 요구하는 제품의 기능 목록을 말하며, 제품에 관한 모든 요구사항에 대해 우선순위가 정해져 있음
• 우선순위는 고객 측 대표인 제품 책임자가 결정하며 사용자와 계속 미팅하면서 목록이 완성
• 한 번 결정된 제품 기능 목록은 확정된 것이 아니고 개발 중이라도 수정이 가능
• 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않음

사용자 스토리

• 작성된 사용자 스토리는 스토리 보드에 나열되고 우선순위와 스토리 포인트가 결정

스토리 포인트 산정

• 스토리 포인트:요구사항의 규모를 측정하는 단위로 업무량을 이용해 산정
• 스토리 간의 상대적인 업무량을 비교해 가장 적을 때를 1로 두고 이를 기준으로 얼마나 큰지에 따라 스토리 포인트를 산정
• 일반적인 소프트웨어 개발 방법론에서는 개발에 소요되는 시간을 일/주/월의 시간 단위로 예측
• 애자일 방법론에서는 스토리 포인트라는 추상 개념으로 예측

스프린트 계획 수립

• 스프린트: 작업량이 그렇게 많지 않고 개발 기간도 짧은 경우를 의미

• 작은 단위의 개발 업무를 단기간 내에 전력 질주해 수행

• 하나의 스프린트에 어떤 사용자 스토리를 몇 개 포함할 것인지는 스프린트 계획 회의에서 결정
• 보통 1~4주 정도를 하나의 스프린트로 봄
• 외부의 개발 방해 요소를 차단하는 것은 스크럼 마스터의 역할
• 하나의 스프린트 개발이 끝나면 사용자에게 시연하고 사용자는 피드백을 제공
• 계획된 일정 안에 개발을 마치지 못해도 정해진 일정이 끝나면 하나의 스프린트가 끝남

스프린트 계획 회의

• 전체적인 스프린트 계획 회의
  • 사용자의 대변인격인 제 품 책임자를 통해 사용자가 원하는 것이 무엇인지를 파악하는 데 중점을 둠
  • 이를 위해 스크럼 마스터는 제품 기능 목록을 검토하면서 어떤 항목을 가장 높은 순위로 놓았는지 확인
  • 그 배경과 목표에 대해 팀원들과 토의하며 제품 책임자의 의도를 파악
• 세부적인 스프린트 계획 회의
  • 우선순위가 높은 항목을 어떻게 구현할 것인지 구체적인 작업 계획을 설립
  • 먼저 우선순위가 매겨진 사용자 요구사항 목록인 제품 기능 목록에서 개발 항목을 결정
  • 스프린트 구현 목록을 작성한다. 여기에 팀원들은 정해진 작업을 수행하는 데 소요되는 시간을 추정

제품 기능 목록

• 스프린트 구현 목록 작성
  • 제품 기능 목록에 있는 스토리 중에서 선택해 작성
  • 스프린트 구현 목록은 스프린트 계획 회의에서 결정
  • 기준은 기간 내에 완료할 수 있는 만큼의 사용자 스토리
  • 실행 가능한 결과 가 나올 수 있는 수준에서 결정

스프린트 수행

소멸 차트

• 계획 대비 작업이 어떻게 진행되고 있는지를 날짜별 남은 작업으로 나타냄
• 소멸 차트는 개발 후 남은 작업량을 표현하므로 시간이 지남에 따라 차트가 감소

일일 스크럼 회의

• 스크럼 마스터의 역할
  • 팀원들의 개발 작업에 방해되는 요소를 찾아 문제를 해결
  • 개발자 개개인이 수행하고 있는 일의 진행 상황을 확인
  • 소멸 차트에 그날의 남은 작업량을 표시

스프린트 현황판

• 개발 팀의 개발 현황(진척도, 남은 작업, 진행 속도)을 나타냄

스프린트 진척 관리

• 스프린트의 각 작업에 대한 날짜별 작업 시간과 남은 시간 등을 기록해 진척 관리를 할 수 있음

스프린트 개발 완료

• 스크럼 진행 방식을 정리하면 처음에 제품 책임자를 중심으로 제품 기능 목록을 작성
• 스프린트 계획 회의에서 스프린트 구현 목록을 작성하고 일일 스크럼 회의를 통해 스프린트를 개발
• 그 결과 스프린트 개발이 완료되고 최종 제품이 생산

최종 제품

• 모든 스프린트 주기가 끝나면 제품 기능 목록에서 개발하려고 했던 최종 제품이 완성

스프린트 개발 완료 후

스프린트 검토 회의

• 하나의 스프린트 반복 주기(2~4주)가 끝났을 때 생성되는 실행 가능한 제품을 검토
• 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인하고, 전체 흐름을 확인해 비즈니스 가치를 점검하는 데 중점
• 스크럼 팀은 스프린트 동안 작업한 결과를 참석자(고객 포함)들에게 시연하고 요구사항에 얼마나 부합하는지 검토
• 스크럼 마스터는 스프린트 동안 잘된 점, 아쉬운 점, 개선할 점 등을 찾기 위한 회고를 진행할 수 있음
• 검토는 가능한 한 4시간 안에 마침

스프린트 회고

• 그동안 스프린트에서 수행한 활동과 개발한 것을 되돌아보고, 개선할 점은 없는지, 팀이 정한 규칙이나 표준을 잘 준수했는지 등을 검토
• 이때 팀의 단점을 찾기보다는 강점을 찾아 더 극대화하는 데 주안점을 둠
• 또한 문제점에 대한 해결 방안을 찾는 회의가 아니므로 문제 점을 확인하고 기록하는 정도로만 진행
• 추정 속도와 실제 속도를 비교해보고, 차이가 크면 그 이유를 분석(프로세스 품질은 측정하지 않음)

배포 목록 작성

• 배포 사용자에게 시스템 일부를 제공하는 것
• 배포 목록은 제품 기능 목록의 항목 중에서 이번 배포 본에 포함하기로 결정한 것
• 배포 목록을 작성 하면 이번 배포 본의 개발 범위와 일정을 수립할 수 있음
• 사용자에게 전달되는 배포 본의 기능 내역과 시기, 스프린트 주기, 배포 일정을 결정하게 됨

스크럼 개발 관련자의 역할

담당자	역할
제품 책임자	- 제품 기능 목록을 만듦 - 비즈니스 관점에서 우선순위와 중요도를 매기고 새로운 항목을 추가함 - 스프린트 계획 수립 시까지만 역할을 수행하고, 스프린트가 시작되면 팀 운영에 관여하지 않음
스크럼 마스터	- 제품 책임자를 돕는 조력자 - 업무를 배분만 하고, 일은 강요하지는 않음 - 스크럼 팀이 스스로 조직하고 관리하도록 지원함 - 개발 과정에서 스크럼의 원칙과 가치를 지키도록 지원함 - 개발 과정에 방해될 만한 요소를 찾아 제거함
스크럼 팀	- 팀원은 보통 5~9명으로 구성되며, 사용자 요구사항을 사용자 스토리로 도출하고 이를 구현함 - 기능을 작업 단위로 나누고, 일정이나 속도를 추정해서 제품 책임자에게 알려줌 - 하나의 스프린트에서 생산된 결과물을 제품 책임자에게 시연함 - 매일 스크럼 회의에 참여하여 진척 상황을 점검함

스크럼 방식의 장점과 단점

스크럼 방식의 장점

• 반복 주기마다 생산되는 실행 가능한 제품을 통해 사용자와 충분히 의견을 나눌 수 있음
• 일일 회의를 함으로써 팀원들 간에 신속한 협조와 조율이 가능
• 일일 회의 시 직접 자신의 일정을 발표함으로써 업무에 집중할 수 있는 환경이 조성
• 다른 개발 방법론에 비해 단순하고 실천 지향적
• 스크럼 마스터는 개발 팀원들이 목표 달성에 집중할 수 있도록 팀의 문제를 해결
• 프로젝트의 진행 현황을 볼 수 있어 신속하게 목표와 결과 추정이 가능
• 프로젝트의 진행 현황을 볼 수 있어 목표에 맞게 변화를 시도할 수 있음

스크럼 방식의 단점

• 반복 주기가 끝날 때마다 실행 가능하거나 테스트할 수 있는 제품을 만들어야 하는데 이 작업이 많아지면 그만큼의 작업 시간이 더 필요
• 일일 스크럼 회의 시간(15분)이 넘어가면 작업시간이 늦어지고 작업하는데 방해 받을 수 있음
• 투입 공수를 측정하지 않기 때문에 작업이 얼마나 효율적으로 수행되었는지 알기 어려움
• 프로세스 품질을 평가하지 않기 때문에 품질 관련 활동이 미약하고 따라서 품질의 정도를 알 수 없음