허용 기준: 사용자 스토리의 범위를 나타내는 세부 정보로, 팀과 제품 소유자가 완료 여부를 판단하는 데 도움이 됩니다.
기민한: 스크럼이 속하는 더 광범위한 아이디어 집합에 대해 만들어진 이름입니다. 애자일 가치와 원칙은 다음에 담겨 있습니다. 민첩한 선언.
건축가: 스크럼 팀에는 아키텍트 역할이 없으며, 대신 모든 팀원이 아키텍처를 개발할 책임이 있습니다.
번다운: (스프린트 버다운, 보고서 섹션의 제품 버다운 참조).
백로그 정리: ("스토리 타임" 참조. 정리 및 백로그 개선이라고도 함.)
백로그 항목: (제품 백로그 항목 참조)
치킨: (아키텍처) 팀에 속하지 않은 사람을 지칭하는 용어로, 이 용어는 일부 사람들에게 불쾌감을 주어 지금은 거의 사용되지 않습니다. 돼지 참조.
일일 스크럼: 매일 15분씩 진행되는 팀 회의를 통해 진행 상황을 공유하고, 문제점을 보고하며, 공약을 다집니다. 일일 스크럼에서 각 팀원은 다음 세 가지 질문에 답합니다.
- "지난 스크럼 회의(즉, 어제) 이후로 내가 무엇을 했는가?"
- "다음 스크럼 회의 전에 무엇을 해야 하나요? (즉, 오늘)"
- "내가 최대한 효율적으로 업무를 수행하는 것을 방해하는 것은 무엇인가?"
스크럼 마스터는 이러한 제약을 벗어나는 논의가 있을 경우 참여자들이 사이드바 회의를 소집하도록 합니다. 스크럼 관련 자료에서는 모든 팀원이 도착하자마자, 아침 일찍 사이드바 회의를 열 것을 권장합니다.
완료: "완료 완료"라고도 하는 이 용어는 잠재적으로 출시 가능한 것으로 간주되는 제품 증분을 설명하는 데 사용됩니다. 즉, 모든 설계, 코딩, 테스트 및 문서화가 완료되었고 증분이 시스템에 완전히 통합되었음을 의미합니다.
출현: 최상의 설계와 최상의 작업 방식은 미리 정의되는 것이 아니라 작업을 수행하면서 시간이 지남에 따라 나타난다는 원칙, 참고: 경험주의, 자기 조직화.
경험주의: "검사하고 적응"의 원칙은 팀이나 개인이 무언가를 시도하고 의식적인 반성과 변화를 통해 경험을 통해 배우는 것을 가능하게 합니다. 출현과 자기 조직화를 참조하세요.
서사시: 결국 더 작은 스토리들로 나뉘는 매우 큰 규모의 사용자 스토리. 에픽은 종종 완전히 구상되지 않은 새로운 아이디어를 위한 임시방편으로 사용됩니다. 우선순위가 높지 않다면 에픽을 갖는 것은 아무런 문제가 없습니다.
견적: 제품 백로그에 있는 스토리의 크기 측정에 대해 합의하는 과정입니다. 팀에서 주로 플래닝 포커를 활용하여 진행합니다.
피보나치 수열: 다음 숫자가 이전 두 숫자를 더해서 도출되는 숫자 시퀀스(1, 2, 3, 5, 8, 13, 20…)입니다. 이 시퀀스는 숫자가 커질수록 각 간격이 커지는 특징을 가지고 있습니다. 이 시퀀스는 종종 스토리 포인트에 사용되는데, 그 이유는 서사시를 다룰 때 추정치는 항상 덜 정확하기 때문입니다.
방법: "어떻게"는 제품 소유자의 경우와 달리 팀의 영역을 설명하는 데 사용되는 용어입니다. 또한 전술(즉, 전투에서 승리하는 방법)로도 설명할 수 있습니다.
방해: 팀의 잠재력을 발휘하지 못하게 하는 모든 것(예: 의자가 불편한 경우). 조직적인 문제라면 스크럼 마스터가 해결해야 할 책임입니다. 팀 내부적인 문제라면 스크럼 마스터가 직접 해결해야 합니다.
방해물 백로그: 팀의 생산성을 얼마나 심각하게 방해하는지에 따라 우선순위에 따라 보이는 장애물과 보이지 않는 장애물 목록을 나열한 것입니다.
돼지: (원래는) 팀원을 지칭하는 용어였지만, 이 용어는 일부 사람들에게 불쾌감을 주어 지금은 거의 사용되지 않습니다. 예를 들어 "치킨"과 같습니다.
계획 : 스프린트 계획을 참조하세요
포커 계획: 추정치를 스토리에 적용하는 데 사용되는 게임으로, 합의에 도달하기 위해 델파이 방법을 사용합니다.
프로세스 : 누군가가 일하는 방식과 같습니다. 누구에게나 프로세스가 있습니다. 이는 미리 정의되어 있거나, 경험적이거나, 혹은 그저 혼란스러울 수 있습니다.
제품 백로그: 작업이 필요한 스토리의 우선순위 목록입니다.
제품 백로그: 제품 백로그(또는 "백로그")는 시스템 요구사항으로, 우선순위가 매겨진 제품 백로그 항목 목록으로 표현됩니다. 여기에는 기능적 및 비기능적 고객 요구사항과 기술팀에서 생성한 요구사항이 모두 포함됩니다. 제품 백로그에는 여러 입력 항목이 있지만, 제품 백로그의 우선순위를 정하는 것은 전적으로 제품 소유자의 책임입니다. 스프린트 계획 회의에서 백로그 항목은 제품 소유자의 우선순위에 따라 제품 백로그에서 스프린트로 이동됩니다.
제품 백로그 항목: 백로그 목록에 있는 모든 항목으로, 여기에는 사용자 스토리, 에픽, 기술 부채를 처리하기 위한 기술 스토리 등이 포함됩니다.
제품 소유자: 제품에 대한 비전을 갖고 제품 백로그를 유지 관리, 우선순위 지정 및 업데이트할 책임을 지는 사람입니다. 스크럼에서 제품 소유자는 백로그 우선순위 지정 및 요구사항 관련 질문에 대한 고객의 의견을 대변할 최종 권한을 갖습니다. 이 사람은 언제든지 팀에 참여해야 하지만, 특히 스프린트 계획 회의와 스프린트 검토 회의에서는 더욱 그렇습니다.
제품 소유자로서의 과제:
- 팀을 "관리"하려는 유혹을 뿌리치세요. 팀은 당신이 기대하는 방식으로 스스로 조직화되지 않을 수 있습니다. 특히 일부 팀원이 팀이 스스로 해결해야 할 문제에 대해 당신의 개입을 요청하는 경우 더욱 그렇습니다.
- 스프린트가 진행 중인 경우 더 중요한 작업을 추가하려는 유혹을 참으세요.
- 스프린트 계획 회의에서 어려운 선택을 할 의지가 있음.
- 경쟁하는 이해관계자들의 이익을 균형 있게 조정합니다.
상대 추정: 백로그 항목의 크기를 절대 단위(예: 시간)가 아닌 상대적 크기 범위로 그룹화하여 조정합니다. 피보나치 및 티셔츠 사이즈를 참조하세요.
Release: 개발팀에서 잠재적으로 출시 가능한 제품을 고객이 일상적으로 사용할 수 있도록 전환하는 과정입니다. Release일반적으로 하나 이상의 스프린트를 통해 제품 가치가 배포 비용보다 더 클 때 발생합니다.
Release 번다운 차트: 출시 진행 상황을 보여주는 눈에 띄는 차트입니다.
회고: 팀과 스크럼 마스터가 프로세스를 되돌아보고 개선을 위한 의지를 다지는 세션입니다.
로마 투표: 엄지손가락 투표를 참조하세요.
스크럼 마스터 역할: 스크럼 마스터는 팀과 제품 소유자를 위한 촉진자입니다. 스크럼 마스터는 팀을 관리하는 것이 아니라, 다음과 같은 방식으로 팀과 제품 소유자 모두를 지원합니다.
- 개발팀과 제품 소유자 간의 장벽을 제거하여 제품 소유자가 직접 개발을 주도할 수 있도록 합니다.
- 스크럼을 통해 제품 소유자에게 투자 수익률(ROI)을 극대화하고 목표를 달성하는 방법을 교육합니다.
- 창의성과 역량 강화를 촉진하여 개발팀의 삶을 개선합니다.
- 가능한 모든 방법으로 개발팀의 생산성을 향상시킵니다.
- 각 기능 증분을 잠재적으로 배송할 수 있도록 엔지니어링 관행과 도구를 개선합니다.
- 팀의 진행 상황에 대한 정보를 최신 상태로 유지하고 모든 당사자가 볼 수 있도록 합니다.
출처: Scrum을 활용한 애자일 프로젝트 관리, 켄 슈와버
스크럼 회의: 스토리 타임, 계획, 검토, 회고, 일일 스크럼.
스크럼 역할: 세 가지뿐입니다: 제품 소유자, 스크럼 마스터, 팀원.
자기 조직화: 업무에 가장 가까이 있는 사람이 업무를 수행하는 방법을 가장 잘 알고 있으므로 명확한 목표와 경계를 설정하고 모든 전술 및 실행 결정을 그들에게 맡기는 원칙입니다. 참조: 출현주의, 경험주의.
스파이크: 일반적으로 단일 스토리에 대한 기술적인 짧고 시간이 제한된 조사 자료로, 팀이 스토리의 규모를 추산할 수 있을 만큼의 정보만 제공하기 위한 것입니다.
스프린트: 시간 제한이 있는 반복 작업입니다.
스프린트 백로그: 스프린트의 목표를 실현하기 위해 완료해야 하는 작업 세트와 선택된 제품 백로그 항목 세트로 표현되는 스프린트 작업을 정의합니다.
스프린트 번다운: 스프린트에서 남은 작업량을 매일 표시하는 눈에 띄는 차트입니다.
스프린트: 목표 또는 스프린트 테마. 단일 스프린트에서 작업의 주요 초점입니다.
스프린트 계획: 스프린트를 계획하고 약속에 대한 합의에 도달하기 위해 팀과 제품 소유자가 만나는 회의입니다.
스프린트 작업: 특정 스토리를 완성하는 데 도움이 되는 단일한 작은 작업 항목.
이야기: 일반적으로 템플릿 양식을 사용하는 백로그 항목: [사용자]로서 [기능]을 원하므로 [비즈니스 가치]를 위해 제품 백로그 항목을 참조하세요.
이해관계자: 때로는 다음 용어들이 동의어로 사용되기도 합니다. 다만 정의에 미묘한 차이가 있다는 점에 유의해야 합니다. 스토리, 사용자 스토리, 기술 사용자 스토리, 제품 백로그 항목, PBI, 제품 요구 사항.
스토리 포인트: 스토리의 크기에 적용되는 측정 단위, 참조: 피보나치 수열 티셔츠 크기(2의 거듭제곱)는 스토리 포인트를 할당하는 또 다른 방법입니다.
점심시간 백로그에 있는 항목을 논의하고, 개선하고, 추산하고, 백로그를 정리하고 우선순위를 정하는 정기적인 작업 세션입니다.
태스크: 스프린트 작업을 참조하세요.
작업 목록: 스프린트에 할당된 스토리 세트를 완료하는 데 필요한 작업입니다.
작업 게시판: 팀의 모든 스프린트 작업을 나타내는 카드와 스티키 노트가 있는 벽 차트입니다. 작업 노트는 진행 상황을 보여주기 위해 보드 전체로 이동합니다.
팀: 팀(또는 "스크럼 개발 팀")은 7명에서 2명 사이의 인원으로 구성되는 것이 가장 이상적이며, 업무에 전념하고, 제품을 제공하고, 전략적 관점에서 제품을 추진할 책임을 맡습니다.
소프트웨어 개발 프로젝트의 경우, 팀 구성원은 일반적으로 소프트웨어 엔지니어, 아키텍트, 프로그래머, 분석가, QA 전문가, 테스터, UI 디자이너 등으로 구성됩니다. 이를 "교차 기능 프로젝트 팀"이라고 부르기도 합니다. 애자일 방식은 이러한 교차 기능 팀 구성원의 참여를 장려합니다.
스프린트 동안 팀은 스프린트 목표를 달성하기 위해 스스로 조직화됩니다. 팀은 목표를 가장 잘 달성하는 방법을 스스로 선택하고 그에 대한 책임을 집니다. 스크럼 마스터는 팀이 제품 책임자로부터 고립되도록 보호하는 수호자 역할을 합니다. 스크럼은 또한 전체 팀을 하나의 팀룸에 모으는 것을 권장합니다.
팀원: 팀원은 스프린트 목표를 향해 스프린트 작업을 수행하는 모든 사람으로 정의됩니다. 스크럼 용어로, PO와 SM도 개발에 참여하는 경우 팀원이 될 수 있습니다.
엄지손가락 투표: 팀의 헌신이나 의사 결정에 대한 합의 정도 등을 파악하기 위한 빠른 펄스입니다. 엄지손가락을 위로 향하게 하면 일반적으로 동의, 예 또는 좋음을 의미하고, 엄지손가락을 아래로 향하게 하면 동의하지 않음, 아니오 또는 나쁨을 의미합니다. 아날로그 버전에서는 엄지손가락을 반원 위 아무 곳에나 두어 동의 정도를 다르게 나타낼 수 있습니다.
타임박싱: 모든 활동에 기간을 설정하고 정확히 그 기간 동안만 지속되도록 합니다(즉, 회의나 스프린트가 결코 길어지지 않습니다).
Velocity : 팀이 작업을 완료하는 속도로, 일반적으로 스토리 포인트로 측정됩니다. 스크럼에서 속도는 팀이 한 스프린트에서 처리할 수 있는 제품 백로그 작업량을 의미합니다. 이는 팀 구성과 스프린트 기간이 일정하다고 가정할 때 이전 스프린트를 확인하여 추정할 수 있습니다. 또한, 커밋먼트 기반 계획을 사용하여 스프린트별로 설정할 수도 있습니다.
속도가 확립되면 이를 활용하여 프로젝트를 계획하고 출시일과 제품 완료일을 예측할 수 있습니다.
백로그 항목 추정치를 의도적으로 대략적으로만 조정했을 때 속도 계산이 어떻게 의미가 있을까요? 대수의 법칙은 추정치의 대략적인 값을 평균화하는 경향이 있습니다.
비전 선언문: 제품이 누구를 위한 것인지, 왜 필요한지, 다른 유사 제품과 어떻게 차별화되는지 등을 포함한 제품에 대한 개략적인 설명입니다.
뭐: "무엇"은 제품 소유자의 영역을 설명하는 데 사용되는 용어로, 팀과 구분되는 개념입니다. (예: 방법) 전략(즉, 전투의 최적 순서)으로도 설명될 수 있습니다.
XP 연습: XP 방법론에서 가져온 페어 프로그래밍, 테스트 우선 또는 테스트 주도 개발(TDD) 및 지속적 리팩토링을 포함한 일련의 개발 관행을 통해 많은 스크럼 팀은 생산성과 팀 사기를 크게 향상시킨다는 것을 알게 되었습니다.
