2022. 3. 10. 11:48ㆍSW개발론
Scrum(스크럼)
- 반복적이고 점진적인 프로세스를 기반으로 한 애자일 개발 방법론 중 하나
- 가장 널리 사용되는 애자일 프레임워크
- 소프트웨어 개발보다는 팀의 개선과 프로젝트 관리를 위한 애자일 방법론
- 경험적 관리 기법 중 하나
- 구체적인 프로세스를 명확하게 제시하지 않음
- 개발 팀(조직)을 운영하는 효율적인 운영 방식(지침)
overview
- Product Owner(프로덕트 오너)는 Product Backlog 생성
- 스크럼 팀은 Product Backlog에 있는 요구 사항을 쉽게 다룰 수 있게 작게 쪼개는 일을 하는 스프린트 planning 세션을 함.
- 팀은 sprint backlog를 만들고, 실행 계획을 짬 - 한 sprint의 결과물이 배포할 수준으로 나눠야 함
- 팀은 sprint의 기간을 설정(보통은 2주)
- 팀은 매일 Scrum Meeting을 함
- Scrum Master가 팀을 관리함
- 매 sprint마다 이해관계자들과 PO(Product Owner)가 리뷰를 실행함 - 리뷰때는 실제 실행을 함
- (보통) 제품 release를 하면 회고를 실행함
스크럼 방식에서 사용되는 용어
Product Backlog(제품 기능 목록)
- 우선순위가 매겨진 사용자의 요구사항 목록
- 새 요구사항, 수정 사항, 특징, 일일이 변경되거나 더해지면 업데이트
User Story(사용자 스토리)
- 메모지 한 장에 구현할 기능을 사용자 관점에서 사용자 언어로 작성한 사용자 요구 사항
- 사용자에게 가치를 평가 받을 수 있도록 기능을 표현한 것
- 유스케이스보다 작은 규모
- 스토리가 큰 것보다 많은 것이 좋음
- 다른 스토리에 종속되지 않고 독립적이며, 협상가능해야 함
- 추정 및 측정 가능해야 함
- 테스트가 가능해야 좋은 사용자 스토리
Story Point(스토리 포인트)
- 사용자 스토리를 수행하는데 걸리는 상대적인 개발 시간
Sprint(스프린트)
- 스크럼에서 기본 일의 단위
- 출하 가능한 제품 증진을 생성하기 위해 필요한 짧은 단위의 개발 사이클
- 보통 1~4주. 더 긴 스프린트는 예측성과 유연성 부족
Sprint Backlog(스프린트 구현 목록)
- 각각의 스프린트 주기에서 개발할 작업 목록
- 세부 작업 항목, 작업자, 예상 작업 시간(Story Point) 등이 포함되어있어야 함
- 원칙 상 수정이 불가
- PO와 스크럼팀이 모여 하는 스프린트 회의시 결정됨
Burndown Chart(소멸 차트)
- 시간이 지남에 따라 소멸되고 남은 것을 표현
- 계획 대비 작업이 어떻게 진행되고 있는지를 날짜별 남은 작업량으로 표현
- 매일매일 진행 사항을 보여주어 스프린트 목표가 스케쥴에 맞게 달성될 수 있는지 예측 가능
Scrum Meeting(스크럼 미팅)
Sprint Planning Meeting(스프린트 계획 회의)
- 전체적인 스프린트 계획 회의
- 가장 높은 우선 순위의 항목에 관심
- 그 배경과 목표에 대해 팀원들과 토의
- 제품 책임자의 의도 파악
- 세부적인 스프린트 계획 회의
- 우선순위가 높은 항목의 구현 방법에 대한 구체적인 작업 계획
- 결정된 개발 항목에 대한 스프린트 구현 목록 작성
- 정해진 작업 수행 소요 시간 추정
- 스프린트에 관련괸 모든 이가 참가
- 1달 기준 8시간이 적합
Daily Scrum Meeting(일일 스크럼 회의)
- 매일 짧게(15분 정도)
- 진행 상황만 점검, 스프린트 작업 목록을 잘 개발하는가 확인
- 모든 팀원이 참석, 한 사람씩 어제 한 일, 오늘 할 일, 문제점 및 어려운 점 정도만 이야기
- 매일 완료된 세부 작업 항복을 완료 상태로 옮겨 스프린트 현황판 업데이트
- 개별 팀원에 대한 진척 상태 확인
- 그 날의 남은 작업량을 소멸 차트에 표시
Sprint Review(스프린트 검토회의)
- 매 각 스프린트의 끝에 팀과 PO가 만나는 회의
- 매 스프린트 이후 생성되는 실행 가능한 제품에 대해 검토
- 스프린트 목표를 달성했는지 작업 진행과 결과물을 확인
- 전체 흐름을 확인하여 비즈니스 가치를 점검
- 1달 기준 4시간이 적합
Sprint Retrospective(스프린트 회고)
- sprint review ~ 다음 sprint 사이에 진행
- 개선점은 없는가, 팀이 정한 규칙을 잘 준수했는가를 검토
- 문제해결이 아닌, 문제점 확인 후 기록
- 프로세스 품질은 측정하지 않음
- 1달 기준 3시간이 적합
스크럼 역할(Scrum Roles and Accountabilities)
Product Owner(제품 책임자)
- 보통 고객 또는 이해 관계자로 제품 기능 목록 작성
- 비즈니스 관점에서 우선순위와 중요도를 매기고 새로운 항목 추가
- 스프린트 계획 수립 시까지만 역할을 수행, 스프린트가 시작되면 팀 운영에 관여 않음
- 매 스프린트가 끝나고 일에 대한 적절한 피드백 제공
Scrum Master(스크럼 마스터)
- 제품 책임자를 돕는 조력자
- product backlog를 효과적으로 관리하는 방법을 찾음
- po의 요구사항을 프로젝트 팀에 말하는 것을 도움
- produck backlog를 조정 및 최적화함
- 스크럼 팀이 스스로 조직하고 관리하도록 지원함
- 스크럼 채택을 이끌고 코치함
- 스크럼 실행 계획함
- 팀의 생산성을 높이기 위해 변화와 단계를 실행
- 다른 스크럼 마스터와 협동하여 방법론의 효율성을 높임
- 업무를 배분만 하고, 강요하지는 않음
- 개발 과정에서 스크럼의 원칙과 가치를 지키도록 지원
- 개발 과정에 방해될 만한 요소를 찾아서 제거
Scrum Team(스크럼 팀)
- 팀원은 보통 5~9명으로 구성
- 사용자 요구사항으로부터 사용자 스토리를 도출, 구현
- 기능을 작업 단위로 나누고, 일정, 속도를 추정하여 PO에게 알려줌
- 하나의 스프린트에서 생산된 결과물을 PO에게 시연
- 매일 스크럼 회의에 참여, 진척상황 점검
스크럼의 장/단점
장점
- 실행 가능한 제품을 통해 사용자와의 충분한 의견 조율 가능
- 일일 회의를 통해 팀원들 간의 신속한 협조와 조율 가능
- 일일 회의 시 직접 자신의 일정 발표를 통한 업무 집중 환경 조성
- 단순하고 실천 지향적
- 팀의 문제를 해결할 수 있는 스크럼 마스터의 능력과 역할
- 프로젝트 진행 현황을 통해 신속하게 목표와 결과 추정 가능, 목표에 맞는 변화 시도 가능
단점
- 추가 작업 시간 필요 - sprint가 끝날 떄마다 실행 가능하거나 테스트 가능한 제품을 만들어야 함
- 일일 스크럼 회의를 15분 안에 마쳐야 함
- 투입 공수 불측정에 따른 효율성 평가 부족
- 프로세스 품질 평가 불가
Epic, User Story, Task
Epic
- user story로 나눠지지 않은 요구사항들
- 하나의 sprint로 달성할 수 없는 큰 story
- 범위가 넓고, 디테일이 부족함 --> 작고, 여러개의 story로 분리되어야 함
User Story
- 프로젝트 안에서 해야하는 아이템들의 리스트
Task
- story를 완성시키기 위해 필요한 세부적인 작업의 세트
출처
https://medium.com/dtevangelist/scrum-dfc6523a3604
https://gdtbgl93.tistory.com/127
https://www.scrum-institute.org/The_Scrum_Product_Backlog.php
https://www.simplilearn.com/scrum-project-management-article?source=frs_category
https://adaptmethodology.com/epic-user-story-task/
https://www.visual-paradigm.com/scrum/theme-epic-user-story-task/
'SW개발론' 카테고리의 다른 글
| 소프트웨어 개발 방법론 - 폭포수 방식(waterfall) (0) | 2022.03.10 |
|---|---|
| 소프트웨어 개발 방법론 - 애자일(Agile) (0) | 2022.03.10 |