pineoc.github.io/study/study/agile-study/Scrum-Kanban.html
스크럼
- 조직을 작고, 교차 기능적이며 자기 조직적인 팀으로 쪼개라.
- 일을 출시 가능한 작은 단위의 목록으로 나누어라.
- 목록을 우선순위에 따라 정렬하고 각 항목에 대해 상대적인 노력을 추정하라
- 시간을 짧고 고정된 길이의 이터레이션으로 나누고, 이터레이션을 마칠 때 잠재적으로 출시가능한 코드를 시연하라.
- 출시 계획을 최적화하고, 매 이터레이션 이후 결과물을 검토하면서 얻어진 지식을 바탕으로 고객과 협업을 통해서 우선순위를 수정하라.
- 이터레이션을 마칠 때마다 회고를 실시하여 프로세스를 최적화하라.
* 소규모 팀에서 짧은 시간 동안 작은 것을 만들도록 한다.
단, 전체적인 모습을 볼 수 있게 정기적으로 통합한다.
칸반
- 일을 작은 조각으로 나누고, 카드에 각 항목을 기입한 후 벽에 붙인다.
- 이름이 부여된 열을 사용하여 각 항목이 작업 흐름의 어디에 있는지 표시한다.
- WIP(Work In Progress: 작업중인 일) 개수를 제한한다.
- 각 작업흐름 상태 별로 작업 중인 항목을 얼마나 허용할 것인지 확실한 수치를 부여한다.
- 리드타임(한 항목을 완료하는 데 소요되는 평균 시간, 사이클 타임)을 측정하고, 리드 타임을 가능한 짧고 예측가능하게 만들 수 있도록 프로세스를 최적화 한다.
스크럼과 칸반의 연관성
1) 스크럼과 칸반은 둘 다 프로세스 도구이다.
=> 스크럼과 칸반은 무엇을 해야 하는지 알려줌으로써 일을 어느정도 더 효과적으로 처리하는 데 도움을 주는 프로세스 도구이다.
2) 무엇이 더 좋고 나쁜 것이 아니다.
=> 포크, 나이프 ,젓가락과 같은 것들이 밥을 먹기 위한 도구인 것처럼,
각각에 맞는 상황이 있기 때문에 비판이 아닌 이해를 통해서 도구를 비교해야 한다.
칸반, 스크럼도 완벽하지도, 완전하지도 않다.
필요한 모든 것을 알려주지 않고, 그저 제약조건과 지침을 조금 제공할 뿐이다.
3) 스크럼은 칸반보다 규범적이다.
스크럼은 칸반보다 지켜야할 규칙이 많고,
칸반은 스크럼보다 지켜야할 규칙이 적어서 적응적이다.
비교대상 | 스크럼 | 칸반 |
기간 | 기간이 고정된 이터레이션을 규정 | 기간이 고정된 이터레이션은 선택사항 |
약속 | 팀이 이터레이션에서 할일의 양을 결정, 약속 | 약속은 선택사항 |
지표 | 계획하기와 공정 개선에 속도를 기본 지표로 사용 | 리드 타임을 기본 지표로 사용 (리드타임: 한 항목을 완료하는데 걸린시간) |
팀 | 교차 기능 팀을 규정 | 교차 기능 팀은 선택사항, 전문가 팀도 허용 |
아이템 크기 | 아이템을 한 스프린트 안에 완료될 수 있을 정도의 크기로 잘게 쪼갬 | 아이템 크기를 특별히 규정하지 않음 |
차트 | 번다운 차트 규정 | 차트 사용 규정 없음 |
WIP | WIP리밋을 간접적으로 | WIP리밋을 직접적으로 |
추정 | 추정을 하도록 규정 | 추정은 선택사항 |
아이템 추가 | 이터레이션이 진행 중일때는 아이템 추가 불가 | 수용 능력이 허용한다면 새로운 아이템 추가 가능 |
보드 소유 | 특정 팀이 소유 | 다수의 팀이나 개인들 간에 공유 |
역할 | 제품책임자, 팀, 스크럼마스터 규정 | 규정x |
보드 초기화 | 이터레이션 마다 스크럼 보드 초기화 | 칸반보드는 계속 유지 |
우선순위 | 우선순위 정의를 규정 | 우선순위 정의는 선택 사항 |
'개발 > QA' 카테고리의 다른 글
2. testing 기초 (0) | 2020.09.15 |
---|---|
1. SW는 무엇이고 testing이란 무엇인가 (0) | 2020.09.14 |
디버깅과 테스팅의 차이 (0) | 2020.09.11 |
15. 정적 테스팅 (Static Testing) (0) | 2020.07.11 |
14. 블랙박스 테스트 3 (0) | 2020.07.10 |