※ 공부한 것을 정리한 노트입니다. 참고만 하세요. ※
Scrum
scrum이란
- agile 방법론의 한 종류
- agile은 하나의 방법론이기 때문에, agile 원칙을 지키는 방법론들은 모두 agile 방법론이라고 할 수 있다.
- scrum 역시 agile 방법론을 지키는 방법론이고, 즉 agile 방법론의 한 종류이다.
scrum process
- agile에서의 iteration을 scurm에서는 sprint라고 한다.
- sprint의 소요시간은 해당 프로젝트 시행동안 고정된다. 2주면 2주, 10일이면 10일
- sprint가 끝나고 잠재적으로 출 시할 수 있는 제품을 increment라고 한다.
- sprint backlog
- sprint 기간동안 해야할 일이 담긴 목록
- Product backlog에서 우선순위에 따라 가져온다.
- Product Backlog
- Product owner가 고객, 사용자로부터 수집한 요구사항을 모은 것으로, 프로젝트 전 기간동안 해야할 일의 목록
- product owner는 고객에게 더 높은 가치를 줄 수록 당연히 우선순위를 더 높게 책정한다.
- Sprint Planning meeting
- Product Owner, team, scrum master가 모여 product backlog에서 sprint 기간동안 할 일을 정하는 회의
- Daily Scrum Meeting
- 매일, 15분 이내로 짧게 진행하는 회의
- 짧은 시간 진행되어야하기 때문에 team은 3~9명정도로 구성된다.
- stand up meeting(짧게, 일어서서), 2-pizza meeting(피자 2판 시켜 먹으면 끝나는 시간)이라고도 함
- project 현황을 공유하는 아주 중요한 회의
- sprint review
- increment를 만들고, 고객에게 피드백을 받는 시간
- 피드백을 받고, 고객의 가치를 수용하고 반영하기 위함 → agile
- sprint retrospective
- sprint review 종료시 하는 회고
- sprint를 개선하기 위한 회의
3-5-3 rules
- Scrum Roles(3)
- Product Owner
- 무엇을/왜 만들어야 하는지 결정
- 고객이 원하는 바를 파악하여 제품에 반영
- 제품이 추구하는 방향(vision, roadmap) 설정
- 고객이 가장 가치가 있는 제품을 빠르게 전달받을 수 있도록 우선순위
- 고객으로부터 피드백 반영
- 개발팀에 고객의 니즈 설명
- (**매우 중요**) Product Backlog 관리
- vision
- 프로젝트의 방향성
- 누가 제품을 구매하는가? / 목표 대상 고객이 누가인가?
- 고객은 무엇을 필요로 하는가?
- 제품의 어떤 점이 고객에게 가치를 전달하여 구매하게 하는가?
- 다른 제품보다 어떤 점이 이 제품을 선호하게 하는가?
- Scrum Master
- 모든 구성원(PO, Team members)이 scrum process에 따라 일을 수행할 수 있도록 조력
- scrum 일을 하면서 방해되는 장해물이 있을때 이를 치우는 것도 일
- 해당 조직에 scrum이 잘 자리잡도록 코칭, 즉 scrum 팀을 도와주는 리더(servant-reader)
- 하나의 대장이라기보다는 Team의 일원으로써 행동
- the Team
- 개발하는 팀
- 3~9명
- self-organization
- 팀원들이 외부 압박 없이 스프린트 목표를 달성하기 위한 최상의 방법 결정
- Cross-functional
- 다양한 배경과 지식을 가진 팀원들로 팀 구성
- product backlog의 항목을 가져와 스프린트동안 완성하여 동작하는 네품을 만들 수 있는 기술 제공
- 팀 전체로서 성공하고 팀 전체로서 실패함
- 팀의 지속성
- Product Owner
- Scrum Events / ceremonies(5)
- Sprint Planning Meeting
- product backlog에서 우선순위에 따라 가져와 sprint의 목표 설정
- sprint에서 개발할 사용자 스토리 선정
- 스토리를 태스크로 분할
- 스토리 하나는 개발자 한명이 개발하지 않고, 스토리를 분할하여 만들어진 태스크를 개발자 한명이 맡는다.
- product backlog → Sprint backlog
- Capacity based Scrum Planning
- Capacity: 한 스프린트동안 Scrum Events활동(sprint제외), 백로그 정제 회의를 제외 오로지 프로젝트에 관련된 일에 사용할 수 있는 팀의 가용시간
- 사용자 스토리를 태스크로 분할하고, 각 태스크를 완료하는데 걸리는 시간을 추정한다. 이를 팀의 capatcity가 넘지 않을때까지 반복하여 user story를 추가함
- user story는 sprint planning meeting 전에 sprint동안 개발할 수 있도록 충분히 상세화되어야 있으며 크기도 적절하게 분할되어있어야 한다.
- BackLog refinement(grooming) meeting (Scrum Events가 아니다!!)
- epic(large user story)을 작은 user story로 분할하고 스토리 포인트 추정
- 다음 sprint에 완성할 user story들을 정제(refinement)하는 작업
- 새로운 user story에 대한 스토리 포인트 추정 및 (필요시)기존의 user story의 스토리 포인트 재추정
- 우선순위 조정
- sprint의 10% 이내 시간 할애
- DoR (Definition of Ready)
- product backlog에서 sprint backlog로 이동하기 위해 만족되어야 하는 요건 목록
- 가치가 명확히 기술되었는가? 의존 사항이 모두 식별되었는가? 인수기준이 명확하고 테스트 가능한가? PBI가 sprint 내에 완성할 수 있을 정도로 충분히 작게 추정되었는가?
- Velocity
- 한 sprint동안 완료된 스토리 포인트의 합
- 팀의 진도를 평가하는 수단
- 추정 속도와 실제 속도는 다를 수 있기 때문에, 불확실성으로 인한 보정치가 정해지기도 한다.
- DoD (Definition of Done)
- 스토리가 종료상태로 가기 위해 만족햐야할 요건 목록
- team에서 정함
- DoD의 요건을 만족하지 못하는 스토리의 스토리 포인트는 velocity 계산시 고려되지 않는다
- 과정
- Unit Tests 통과
- 코드 리뷰
- 리그레션 테스팅 통과
- 기능 테스팅 통과
- 인수 기준 만족
- 사용자 문서 갱신
- 성능 테스팅 통과
- UX 디자이너 승인
- 제품 책임자 승인
- 등등 항목은 달라질 수 있지만, DoD 항목은 모든 스토리에 적용된다. 하지만 인수 기준은 각각의 스토리에 따라 다르다
- Capacity based Scrum Planning
- Daily Meeting
- 매일, 15분 정도 정해진 장소, 시간에 빠르고 간단하게 진행함(stand up meeting, 2-pizza meeting)
- 어떤 일을 했는가, 어떤 일을 할 것인가 모여서 회의함.
- 팀의 진척상황이나 이슈를 공유함
- Sprint review
- Sprint 종료시 모든 Product Owner, Scrum master, team, 고객 등이 모여 피드백을 공유
- 데모를 수행하며 요구 사항이 제대로 반영되었는지 피드백
- Product Owner는 여기서 도출된 여러 지적, 개선 사항을 Product Backlog에 반영
- Sprint Retrospective
- sprint 종료시, 또는 일정주기로 수행
- 프로젝트 진행과정에서 좋았던 점, 문제, 개선점을 도출하여 개선
- 이미 설정된 프로세스만으로 프로젝트를 진행하는 것이 아닌, 프로세스가 계속적으로 개선되도록 함
→ 변화하는 비즈니스 환경에 능동적 적응 - sprint review는 제품의 개선을, sprint retrospective는 sprint, 프로젝트를 개선하기 위함
- Sprint
- Sprint Planning Meeting
- artifact(3)
- Product Backlog
- 제품에 필요한 모든 것을 기술한 우선순위가 있는 업무 목록
- 각각의 항목을 PBI(Product Backlog Item)라고 함
- PBI의 종류
- 기능
- 비기능 : 성능 등등...
- 오류 수정
- 지식 슥듭 (spike)
- user story
- agile에서는 사용자의 요구사항을 User story 형태로 표현하는 경우가 많다.
- Mike Cohn User story
- who? what? why?
- 간결하게 작성함
- 대화를 위한 매개체의 역할
- 가치가 너무 명확한 경우에는 세 요소(who, what, why)를 생략할수는 있지만, 가능한한 기술하는게 좋다
- 사용자, 구매자에게 가치를 줄 수 있는 기능
- 고객, 개발자 모두가 이해할 수 있도록 고객, 또는 product owner가 대신 작성
- 3Cs
- Card(카드) : 고객의 요구사항을 문서화하기 보단 표현하기 위한 것(대화의 초대)
- Conversation(대화) : 대화를 통해 세부사항 구체화, 이해의 공유 촉진
- Confirmation(테스트) : 스토리의 완료 여부 판단, acceptance criteria(인수 기준)을 통과해야 함
- INVEST
- Independent
- user stroy는 dependency를 최소화해야함
- dependency가 높으면 개발 우선순위 설정 작업이 복잡해짐
- dependency를 완전히 없애라는 것은 아님. 어쩔수 없는 상황이라면 어쩔수 없겠지만, 가능한 한 최소화하라는 뜻.
- Negotiable(what)
- user stroy는 계약서가 아님
- 상세한 사항은 협상 가능해야한다
- placeholder for details
- story를 개발하고 방식을 특정하면 협상 여지가 줄어든다
- ex) DB는 오라클을 무조건 사용해야한다. (mysql이나 좋은 오픈소스 많은데 왜??)
- 회원 로그인시 얼굴 인식을 통해 로그인하여 구독 컨텐츠에 접근할 수 있으면 좋겠다 (왜 하필 얼굴 인식??)
- 특정 방식을 사용해야만 하는 법률적 이유, 규격, 표준 등의 이유가 있다면 Negotiable하지 않아도 된다.
- Valueable(why)
- 가치를 주어야함
- Estimable
- 크기를 추정하여 필요한 노력과 비용을 추정할 수 있어야 한다.
- 너무 큰 story(epic)은 분할
- 정보가 없는 스토리는 spike작업을 한다.
- Small(Size appropriately)
- 스토리의 크기는 알맞은 크기가 되어야 한다
- just-in-time(sprint)
- Testable
- Independent
- DEEP : product backlog가 가져야하는 4가지 특성
- Detailed appropiately
- 우선순위가 높을수록 잘 상세화
- 낮을수록 상세화가 덜 됨
→ 적절한 상세화
- Emergent(창발적, 발생적)
- 환경 변화, 요구사항 변경등의 여러 이유로 product backlog는 고정되지 않고 계속해서 변함
- pbi들은 제거될 수 있고 추가될 수 있고 우선순위도 변경될 수 있다.
- agile 선언에서는 계획을 따르는 것이 아닌 변화에 반응하는 것에 더 가치를 둠
- Estimated
- 각 pbi는 크기(추정치)를 가짐
- 우선순위가 높은 pbi 의 크기가 큼 → 더 분할할 필요가 있음
→ 우선순위가 높은 pbi는 가능한 높은 정확도를 가지도록 크기를 추정해야함
→ " 는 스프린트 내에서 충분히 개발 가능하도록 분할 - pbi의 크기 추정 → 스토리 포인트(pbi 크기 추정 단위), 시간을 사용하는 경우 많다
- 스토리 포인트
- 스토리를 구현하는데 필요한 상대적인 노력의 양과 개발 복잡도, 그리고 내재된 위험성등을 종합적으로 분석하여 나타낸 값
- 추정에는 피보나치 수열을 많이 사용한다. 이때 수열의 값과 살짝 오차(예를 들면 스토리의 크기가 5보다는 살짝 크고 8보다는 약간 작다면?)가 있을 것 같아도 크게 상관 없다. 말 그대로 추정이니까
- plainning poker 게임으로 추정
- 보통 추정치가 13이 넘어가는 경우, 분할할 필요가 있음
- 추정치가 크다 → epic일 확률이 크다
- Prioritized
- 우선순위가 있어야 한다.
- MoSCow
- Must : 필수적인 기능. 없으면 제품으로서 존재가치가 상실되지만 일단 제공되면 제품의 가치를 상승하는데 더이상 기여를 하지 않음.
- Should have : 중요하고 유용한 기능이며 가능하다면 포함되었으면 하는 기능
- Could have : 만약 제공되면 만족도가 오를 바람직한 기능. 여유가 없으면 제공되지 않더라도 큰 문제는 없는 기능
- Wont have : 누락되어도 아무 상관이 없는 기능
- 모든 pbi에 대해 우선순위하려고 노력하지 말라
- Detailed appropiately
- Sprint Backlog
- 해당 sprint에서 해야하는 일을 담은 backlog
- Sprint Retrospective
- Product Backlog
릴리즈 계획
- Iron triangle
- schedule, resource 고정하고 scope 조절
- 개발 범위는 스토리의 크기의 범위
- 속도 20, 보정치 (0.6, 1.6)이 2달동안 2주짜리 sprint 4개 진행 가정
- 만들어질 스토리 크기 = 20 * 0.6 * 4 = 48
- 만들 수 있는 스토리 크기 = 20 * 1.6 * 4 = 128
- 해야할 일이 우리가 최소로 할 수 있는 양보다는 크고 최대한 할 수 있는 양보다는 작을 때?
- 위험 감수하고 개발 진행 → 개발에서 얻은 지식을 바탕으로 진행 여부 결정
- 릴리즈 날짜 연기, 개발 인력 추가
- 기술적 채무(Technical debts, 시간에 쫓겨 제대로 설계하지 않거나, 테스팅을 충분히 하지 않을 때 발생) 소프트 웨어 개발 과정에서 장기적으로 바람직한 접근법 대신 당장 편한 해법을 택해 발생하는 추가적 작업 비용 선택. 기술적 채무가 쌓이면 더 커지기 전에 중간 중간에 채무를 갚아야 한다.
- 최대 할 수 있는 양보다도 많은 양을 해야할때
- 개발 중단
- 연기
- 개발 인력 추가
- 기술적 채무
스크럼 도구
- 스크럼 태스크 보드
- 매일 기록
- 각 스토리 별로 to-do, in progress, done 태스크를 기록
- 상태는 필요에 따라 더 추가 가능
- Burn down chart
- Burn up chart
'대학교 > 소프트웨어공학론' 카테고리의 다른 글
| 5. 요구사항 개발 프로세스 (1) | 2023.04.24 |
|---|---|
| 4. 요구사항 (0) | 2023.04.24 |
| 2. rad, lean startup, agile, DevOps (2) | 2023.03.28 |
| 1. 소프트웨어 공학의 태동, 유지보수, waterfall, Iron triangle (0) | 2023.03.13 |
