애자일 프로세스 모델

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

• 애자일: 납렵한, 민첩한
• 애자일 프로세스 모델: 고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는 방법론
• 가벼운 프로세스 방법론의 공통적인 특성을 정의

1. 애자일의 기본 가치

• 프로세스와 도구 중심이 아닌, 개개인과의 상호 소통을 중시
• 문서 중심이 아닌, 고객과의 협력을 중시
• 계획 중심이 아닌, 변화에 대한 민첩한 대응을 중시
• 프로세스 품질 자체보다는 산출물의 실행 가능성과 사용자 피드백을 더 중시

 

2. 애자일의 원칙

• 고객 만족을 위한 소프트웨어를 빠르고 지속적으로 제공
• 개발 후반 새로 추가되는 요구사항 허용
• 동작 가능한 소프트웨어를 자주 고객에게 전달 (짧으면 2주 길면 2달)
• 대면 의사소통 중시
• 자율적 사고와 자유로운 분위기 중시

 

3. 애자일 프로세스 개발 방법

• 기본기능만 1차 요구사항으로 분석 후 이를 반복으로 나누어 개발
• 사용자가 릴리스 1을 사용하는 동안 개발자는 2차 개발
• 반복적인 개발을 통한 잦은 출시를 목표
• 실행 가능한 프로토타입을 만들어 사용자에게 확인받음
• 빠른 시간안에 일부라도 소프트웨어를 사용할 수 있게 하는 걸 중시

 

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

• 팀이라는 단어가 주는 의미를 개발 팀에 적용해 효율적인 성과를 얻기 위해 소프트웨어 개발 프로세스에서 사용
• 소프트웨어 개발보다는 팀의 개선과 프로젝트 관리에 중점을 둔 애자일 방법론
• 경험적 관리 기법 중 하나(경험이 많은 사람 필요)
• 구체적인 프로세스를 명확하게 제시하지 않음

5. 스크럼 방식의 진행 과정

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

 

6. 제품 기능 목록의 정의

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

 

7. 사용자 스토리

• 제품 기능이 도출되면 각 기능을 간략하게 서술
• 주로 한 장의 인덱스 카드(포스트잇)로 작성
• 기능을 상세하게 적는 것이 아니라 개발자와 대화를 지속할 수 있는 단서 정도로만 활용할 수 있게 작성
• 작성된 사용자 스토리는 스토리 보드에 나열되고 우선순위와 스토리 포인트가 결정
  • 스토리 포인트: 요구사항의 규모를 측정하는 단위로 업무량을 이용해 산정
  • 스토리 간의 상대적인 업무량을 비교해 가장 적을 때를 1로 두고 이를 기준으로 얼마나 큰지에 따라 스토리 포인트를 산정
  • 일반적인 소프트웨어 개발 방법론에서는 개발에 소요되는 시간을 일/주/월의 시간 단위로 예측
  • 애자일 방법론에서는 스토리 포인트라는 추상 개념으로

 

예측8. 스프린트 계획 수립

• 스프린트: 작업량이 그렇게 많지 않고 개발 기간도 짧은 경우를 의미
  • 보통 1~4주 정도를 하나의 스프린트로 봄
• 하나의 스프린트에 어떤 사용자 스토리를 몇 개 포함할 것인지 스프린트 계획 회의에서 결정
• 계획된 일정 안에 개발을 마치지 못해도 정해진 일정이 끝나면 하나의 스프린트가 끝남

9. 스프린트 계획 회의

• 전체적인 스프린트 계획 회의:
  • 제품 책임자를 통해 사용자가 원하는 것이 무엇인지를 파악하는데 중점
  • 스크럼 마스터는 어떤 항목을 가장 높은 순위로 놓았는지 확인
• 세부적인 스프린트 계획 회의:
  • 우선순위가 높은 항목을 어떻게 구현할 것인지 구체적인 작업 계획 설립
    • 제품 기능 목록에서 개발 항목을 결정
  • 스프린트 구현 목록 작성
    • 정해진 작업을 수행하는 데 소요되는 시간을 추정

 

10. 소멸 차트

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

11. 일일 스크럼 회의

• 스프린트 기간에 하는 회의
• 모든 팀원이 매일, 서서, 약속된 시간에 짧게, 진행 상황만 점검하여 현황판 업데이트

12 . 스프린트 개발 완료 후

• 하나의 스프린트 반복 주기가 끝났을 때 생성되는 실행 가능한 제품을 검토
• 작업한 결과를 참석자들에게 시연하고 요구사항에 얼마나 부합하는지 검토
• 검토는 가능한 한 4시간에 마치며 회고를 진행할 수 있음
  • 개선점, 규칙 준수 등을 검토
  • 추정 속도와 실제 속도를 비교하고 차이가 크면 그 이유를 분석

 

13. 배포 목록 작성

• 배포 목록은 제품 기능 목록의 항목 중에서 이번 배포 본에 포함하기로 결정한 것

14. 스크럼 개발 관련자의 역할

• 제품 책임자:
  • 제품 기능 목록 만들기
  • 비즈니스 관점에서 운선순위와 중요도 매기고 새로운 항목을 추가
  • 스프린트가 시작되면 팀 운영에 관여 안함
• 스크럼 마스터:
  • 제품 책임자를 돕는 조력자
  • 업무 배분만 하고, 일은 강요 안함
  • 개발 과정에 방해될 만한 요소 제거
• 스크럼 팀:
  • 기능을 작업 단위로 나누고, 일정이나 속도를 추정해서 제품 책임자에게 알려줌
  • 하나의 스프린트에서 생산된 결과물을 제품 책임자에게 시연

 

15. 스크럼 방식의 장점과 단점

• 스크럼 방식의 장점:
  • 반복 주기마다 생산되는 실행 가능한 제품을 통해 사용자와 충분히 의견을 나눌 수 있음
  • 일일 회의를 통해 팀원들 간의 신속한 협조 가능
  • 다른 개발 방법론에 비해 단순하고 실천 지향적
  • 프로젝트 진행 현황을 볼 수 있어 목표와 결과 추정이 용이하며 목표에 맞는 변화 시도 가능
• 스크럼 방식의 단점:
  • 반복작업이 많아지면 작업 시간이 그만큼 많아짐
  • 회의 시간이 길어지면 작업하는데 방해가 됨
  • 투입 공수를 측정하지 않기 때문에 작업이 얼마나 효율적으로 수행되었는지 알기 어려움
  • 프로세스 품질을 평가하지 않아 품질 관련 활동이 미약하고 품질의 정도를 알 수 없음

투입공수: 프로젝트에 투입된 사람과 시간에 보고 프로젝트의 규모를 측정하는 것