SCRUM

SCRUM의 개념과 특징

 

요구사항 변경에 신속하게 대처할 수 있도록 반복적이고 점진적인 소규모 팀권 간 활발한 소통과 협동심이 필요한 팀 중심의 소프트웨어 개발 방법론이다. 신속하게 반복적으로 실제 작동하는 소프트웨어를 제공하고 기능 개선점에 우선순위를 부여, 개발 주기 동안 작용된  기능이나 개선점의 리스트 실제동작 가능한 결과를 제공한다. 개발자들의 팀의 구성은 팀원 스스로 팀을 구성해야하며, 개발작업에 관한 모든 것. 팀 구성과  구성원의 역활, 일정결과물 및 그 규칙을 스스로 정하고 해결해야한다.

 

SCRUM 기본원리

기능협업을 기준으로 배치된 팀은 스프린트 단위로 소프트웨어를 개발한다. 스프린트는 고정된 30일의 반복이며, 스프린트시 행하는 작업은 고정된다. 정해진 시간은 철저히 지켜져야 하며, 요구사항, 아키텍처, 설계가 프로젝트 전반에 걸쳐 잘 들어나도록 해야하며 완료된 모든 작업은 제품 백로그에 기록된다. 가장 기볹덕인 정보 교환 수단은 일일 스탠드 업 미팅, 또는 일일 스크럼 이다.

 

SCRUM팀

출처 : https://engineering-skcc.github.io/agile-quickguide/Agile-QuickGuide03-%EC%8A%A4%ED%81%AC%EB%9F%BC%ED%8C%80%EA%B5%AC%EC%84%B1/

 

제품 젝임자

개발 목표에 이해도가 높은 개발 의뢰자, 사용자가 담당한다. 제품 요구사항을 파악하여, 기능 목록을 작성하고, 제품 테스트 수행 및 요구사항 우선순위를 갱신한다.

업무 관점에서 우선순위와 중요도를 표시하고 신규항목을 주가한다.

스프린트 계획 수립까지만 임무를 수행하며, 스프린트가 시작되면 팀 운영에 관여하지 않는다.

 

스크럼 마스터

업무를 배분만 하고  일은 강요하지 않으며, 스스로 조직하고 관리하도록 지원한다. 즉, 매니저역활이다.

개발 과정에서 장애요소를 찾아 제거하고, 스크럼의 원칙과 가치를 지키도록 지원한다.

 

스크럼팀

제품 책임자, 스크럼 마스터를 제외한 팀원이 해당되고, 팀원은 5~9명내외로 구성된다. 기능은 작업 단위로 분류하며, 요구사항을 사용자 스토리로 도출 구현한다. 

일정 속도를 추척한 뒤 제품 책임자에게 전달하고, 매일 스크럼 회의에 참여하여 진행상황을 점검한다.

스프린트 결과물을 제품 책임자에게 시연한다.

 

SCRUM 과정

 

Product Backlog

제품 개발에 필요한 모든요구사항을 우선순위에 따라 나열한 목록이다.

개발 과정에서  새롭게 도출되는 요구사항으로 인해 지속해서 업데이트 된다.

제품 백로그에 작성된 사용자 스토리를 기반으로 전체 일정 계획인 릴리즈 계획을 수립한다.

 

Sprint

작은 단위의 개발 업무를 단기간에 전력 질주하여 개발한다는 의미로 반복 주기(2~4주)마다 이해관계자에게  일의 진척도를 보고한다.

 

Srpint Planning Meeting

Product Backing에서 진행할 항목을 선택한다. 선택한 스프린트에 대한 단기 일정을 수립하고, 요구사항을 개발자들이 나눠 작업할 수 있도록 트랙 단위로 나눈다.

개발자 별로 스프린트 백로그를 작성하고 결과물에 대한 반복완료시  모습을 결정한다.

수행에 필요한 요구사항을 SCRUM 마스터에게 보고하여 이해관계자로부터 지원을 받는다.

 

Daily SCRUM  Meeting

매일 약속된 시간에 짧은 시간동안 서서 진행 상황만 점검.

한 사람씩 작일에 한 일과 금일에 할 일을  이야기하고, 개발과정의 확인 및 완료된 세부작업 항목의 체크 및 갱신.

스크럼 마스터는 방해 요소를 찾아 해결하고 잔여 작업 시간을 소멸 차트에 기록한다.

 

피니쉬드 워크

모든스프린트 주기가 완료되면 제품 기능 목록의 개발 목표물이 완성된다.

 

스프린트 리뷰 

스프린트 검토 회이ㅡ에 개발자와 사용자가 같이 참석한다.

하나의 스프린트 반복 주기가 끝나면 실행가능한 제품이 생성되는데 이에 대해 4시간 이내로 검토한다. 개선할 사항에 대하여 제품 책임자는 피드백을 정리하고 제품 백로그를 작성하여 다음 스프린트에 적용한다.

 

스프린트 회고

스프린트에서 수행한 활동과 결과물을 살펴본다.

개선할 점이 없는지 살펴보고 문제점을 기록하는 정도로 진행한다.

팀의 단점을 찾기보다는 강점을 찾아 팀 능력을 극대화한다.

개발 추정 속도와 실제 작업 속도를 비교하고 차이가 있다면 이유를 분석해 본다.