scrum events time boxing
스크럼 이벤트 소개 :
이전 튜토리얼에서 우리는 Scrum과 그것이 어떻게 구성되는지에 대해 논의했습니다.
그리고 우리의 이전 튜토리얼은 스크럼 아티팩트 상세히.
우리는 스크럼 팀을 구성하는 사람과 프로세스 전반에 걸쳐 어떤 다른 아티팩트가 개발되었는지 알고 있습니다. 우리는 지금 강력한 배경을 확립했습니다. 따라서 스크럼에 한발 더 나아가 스크럼 프로세스를 구성하는 주요 이벤트 / 행사에 대해 논의하겠습니다.
이 튜토리얼에서는 각 스크럼 이벤트가 의미하는 바, 필수 기능이 무엇인지, 세부적으로 구성하는 방법을 이해하려고 노력할 것입니다.
학습 내용 :
개요
스크럼 기반 프로젝트에서 작업하는 동안 스크럼 팀은 일련의 스크럼 의식을 거칩니다.
어떤 사람들은 스크럼 행사 또는 이벤트라고 부르고 다른 사람들은 의식이나 회의를 위해 그들을 부르기도합니다. 여기에서 사용되는 다른 용어에 관계없이 각 스크럼 이벤트의 목표는 동일하게 유지됩니다. 본질적으로 각 스크럼 이벤트는 Sprint 작업을 수행하고 모니터링하는 데 도움이됩니다.
스크럼 이벤트 유형
각 스크럼 행사는 스크럼 마스터가 전담 그룹을 위해 조직 한 대면 행사 / 모임입니다. 핵심 팀 외에도 일부 회의에는 이해 관계자, 배달 관리자 또는 고객 자신이 참여할 수 있습니다. 이러한 회의는 시간 제한이 있으므로 정해진 시간 내에 완료해야합니다.
각 회의의 목적은 참가자를 모아 당면한 작업에 대해 논의하게하는 것입니다. 모든 참가자의 기대는 집중, 참여 및 참여를 유지하는 것입니다.
이는 완료된 작업에 대한 피드백을 대화하고, 검토하고, 검색 할 수있는 기회로 간주됩니다. 일반 회의와 달리 스크럼 이벤트는 결과 지향적이고 시간 제한이 있으며 대상 청중을 기반으로하며 각 이벤트와 일치하는 특정 목표를 갖습니다.
타임 복싱이란 무엇입니까?
타임 박스는 모든 스크럼 이벤트에 첨부 된 핵심 기능 중 하나입니다. 참가자는 각 이벤트에 할당 된 시간을인지하고 존중해야합니다. 행사는 연장 할 수 없지만 회의의 목표가 이미 달성 된 경우 단축 할 수 있습니다.
모든 스크럼 이벤트의 촉진자이기도 한 스크럼 마스터는 모든 사람이 타임 복싱의 중요성을 이해하고 회의의 목표에 집중하여 최상의 결과를 도출하고 편차가있는 시간 결과에 집중하도록 상기시켜줍니다.
이벤트의 타임 박스를 이상적으로 연장해서는 안되지만 스크럼이 규칙에 관한 것이 아니라는 것을 알고 있으므로 모든 참가자가 동의하면 시간을 특정 길이로 연장 할 수 있습니다.
각 스크럼 이벤트의 시간 상자를 어떻게 결정합니까?
스크럼 이벤트의 타임 박스는 스프린트의 길이에 정비례합니다. 그러나이 규칙의 유일한 예외는 스프린트 길이에 관계없이 15 분의 고정 타임 박스가있는 Daily Standup입니다.
스프린트 길이에 따라 각 이벤트에 대한 표준 시간 프레임이 있습니다. 그러나 팀은 요구 사항에 따라 이러한 이벤트의 시간 프레임을 결정할 자유가 있습니다.
각 스크럼 이벤트에 대해 자세히 논의하여 이러한 개념을 더 많이 이해하겠습니다.
스프린트 계획
이 행사의 전제 조건으로 제품 소유자는 회의에 오기 전에 준비된 사용자 스토리의 안정적인 우선 순위 제품 백 로그를 보유해야합니다. 사용자 스토리는 팀이 이해할 수 있도록 잘 구성되고 명확해야합니다.
제품 소유자는 제품 백 로그를 개발하기 위해 이해 관계자, 고객, 디자이너 및 스크럼 마스터의 도움을 구할 수 있습니다.
사용자 스토리에 허용 기준이 있어야합니다. 팀은 수락 기준없이 사용자 스토리를 거부 할 권한이 있습니다.
목적
스프린트 계획은 스프린트를 시작하는 초기 의식입니다. Sprint 계획 회의의 목적은 Sprint 목표를 만들고 제품 백 로그에서 Sprint 백 로그까지 사용자 스토리를 선택하고 자세히 논의하는 것입니다.
팀은 제품 소유자 및 스크럼 마스터와 함께 회의실에 모여 제품 소유자가 다음 스프린트를 위해 선택해야하는 사용자 스토리를 제공합니다.
팀은 스토리에 대해 더 많이 알고 싶은만큼 많은 질문을 할 수 있으며 질문을 처리하는 것은 제품 소유자의 책임입니다. 팀은 완성도와 적합성에 대해 이야기에 도전 할 수도 있습니다.
스토리 내에서 추가 정보가 필요하거나 완료되지 않은 종속성이 있거나 불완전한 것으로 밝혀지면 팀은 해당 스토리를 거부 할 권한이 있습니다.
결국 의심이 사라졌고 팀은 스토리를 완성하기 위해 수행해야하는 작업의 정확한 양을 알고 있으며, 팀은 각 사용자 스토리에 스토리 포인트를 추정하여 제공합니다.
비슷한 방식으로 다른 이야기가 논의되고 추정됩니다. 이제 팀은 우선 순위가 지정된 제품 백 로그의 상단에서 Sprint Backlog로 스토리를 선택하여 과거 속도를 고려할 때 Sprint에서 커밋하고 완료 할 수 있다고 생각합니다.
속도는 평균 스프린트에서 완료 한 총 스토리 포인트 수에 따라 결정됩니다. 속도는 과거 스프린트를 기반으로 평균화하여 계산됩니다. 더 많은 스프린트를 완료할수록 팀의 속도가 더 안정적입니다.
많은 팀이 스토리 추정을 위해 계획 포커 카드를 사용합니다. 가장 일반적인 추정 기법은 피보나치 시리즈를 사용한 스토리 포인팅입니다. 피보나치 시리즈는 시리즈의 각 다음 숫자가 이전 두 숫자를 더하여 구성되는 일련의 숫자입니다.
피보나치 시리즈 – 1, 1, 2, 3, 5, 8, 13 등.
13 개의 스토리 포인트를 초과하여 추정 된 사용자 스토리는 단일 스프린트에서 완료 되기에는 매우 큰 것으로 간주되므로 개별적으로 추정 할 수있는 더 작은 논리적 사용자 스토리로 분해됩니다.
스프린트 계획 회의 중에 팀은 스프린트를 위해 선택된 사용자 스토리 아래에 작업을 생성합니다. 팀은 Sprint Planning 동안 모든 사용자 스토리를 작업 할 것으로 예상되지 않지만 시작하는 데 충분합니다. 나머지 작업은 스프린트 중에 수행 할 수 있습니다.
스프린트 계획 회의의 주요 결과는 팀이 완료하기로 약속 한 사용자 스토리로 구성된 스프린트 목표 및 스프린트 백 로그입니다.
사용자 스토리 외에도 Sprint 백 로그의 일부가 될 수있는 다른 유형의 항목이있을 수 있습니다.
- 스파이크
- 기술 부채
- 버그
스파이크 솔루션을 찾기위한 연구 과제, 즉 사용자 스토리 자체에 의해 유발되는 필요성입니다. 일부 이야기는 간단하지 않거나 기술적 능력이 없기 때문에 더 많은 분석과 연구가 필요합니다. 따라서 스파이크가 생성됩니다. 필요한 경우 POC도 포함될 수 있습니다.
기술 부채 기존 코드의 리팩토링입니다. 팀이 새로운 요구 사항을 수용하기 위해 이전에 개발 된 코드를 재 작업해야하는 경우가 많습니다.
버그 스크럼에서 일반적으로 허용 된 사용자 스토리에서 나오지만 현재 작업 항목과 관련된 누락되거나 새로운 요구 사항입니다. 요구 사항이 아니라면 실제로 이전 스프린트 중에 발견되었지만 수정되지 않았으며이 스프린트에서 우선 순위가 지정된 시스템의 버그 일 수 있습니다.
참석자
스크럼 팀의 모든 구성원은 스프린트 계획 회의의 일부입니다. 핵심 팀 이외의 누구도 회의에 초대되지 않습니다.
Sprint Planning 회의는 Scrum Master가 조직하고 진행하지만 제품 소유자가 쇼를 훔칩니다.
타임 박스
스프린트 계획 회의는 스프린트 2 주 동안 반나절 정도 걸릴 수 있습니다. 스프린트 계획 회의의 시간 상자는 스프린트 길이에 직접적으로 의존합니다. 짧은 스프린트의 경우 짧고 긴 스프린트의 경우 더 길다.
Sprint Planning 회의는 전체 스크럼 아키텍처에서 매우 중요한 역할을하며 개발중인 제품에 직접적인 영향을줍니다. 따라서 팀은 모든 사용자 스토리를 자세히 논의하는 데 필요하다고 생각하는만큼의 시간을 투자해야하며 자신에게 적합한 대체 시간 상자를 제안 할 수 있습니다.
타임 박스가 결정되고 합의되면 팀이 목표에 집중하고 동시에 시간을 추적하는 것은 스크럼 마스터의 책임입니다.
데일리 스탠드 업
목적
Daily Standup은 Sprint의 건강 상태를 전반적으로 보여줄 수있는 기회를 제공하는 회의입니다. 또한 다른 팀원들이 무엇을하고 있는지, 그리고 Sprint의 목표를 달성하는 데 무언가 중단이 있는지 논의하는 플랫폼이기도합니다.
매일 스탠드 업 회의 중에 모든 팀원은 작업중인 작업 항목에 대한 진행 상황을 공유합니다. 또한 진행을 방해하는 장애물이있는 경우 다른 팀원과 공유하고 도움을 구합니다.
매일 스탠드 업 회의에서 테이블 주위의 모든 팀원은 다음 세 가지 주요 질문에 하나씩 대답합니다.
‘지난 일일 스탠드 업 회의 이후 무엇을 했나요?’
“오늘은 무엇을 할 계획입니까?”
성능 테스트를위한로드 러너 도구
‘작업을 방해하는 것이 있습니까?’
다른 팀원은 누군가가 상태를 공유 할 때주의를 기울이고 필요한 경우 도움을 제공해야합니다. 마지막 팀원이 세 가지 질문에 모두 답하자마자 회의가 끝납니다.
Daily Standup 회의는 현재 작업중인 반복의 현재 및 전체 완료 상태에 대한 전체적인 그림을 제공합니다. 스크럼 마스터는 데일리 스탠드 업 회의를 집중하고 타임 박스를 유지하는 데 매우 중요한 역할을합니다. 그는 또한 팀이 사용자 스토리로 진행하는 것을 방해하는 장애물을 해결하는 책임도 있습니다.
스크럼 마스터는 또한 핵심 팀 외에 다른 사람이 질문을하고 상태를 제시하지 않도록해야합니다. 그는 필요한 경우 사용자 스토리에 대한 빠른 토론을 허용 할 수 있지만 항상 시간을 인식해야하며 언제든지 참여하여 팀원에게 오프라인으로 토론하도록 요청할 수 있습니다.
참석자
누구나 일일 스탠드 업 회의에 참석할 수 있습니다. 그러나 핵심 팀은 회의에 참석하여 작업 상태를 발표해야합니다.
스프린트 진행 상황에 대해 알고 자하는 팀 외부의 누구라도 데일리 스탠드 업 회의에 참석할 수 있지만 작업 상태를 발표하거나 개발 팀 구성원에게 작업에 대해 질문 할 수 없습니다.
핵심 팀 구성원 만 작업 진행 상황을 공유 할 수 있으며 다른 모든 사람은 조용히 경청해야합니다.
일일 스탠드 업 회의는 팀원이 한 명이라도 참석해야합니다.
팀은 일일 스탠드 업 회의를 자체적으로 진행하거나 스크럼 마스터에게이를 촉진하도록 요청할 수 있습니다.
타임 박스
이름에서 알 수 있듯이 매일 스탠드 업 미팅이 매일 열리 며 참가자들은 15 분의 짧은 미팅이므로서야합니다. 아이디어는 의제를 고수하고 초점을 벗어나지 않는 것이므로 회의가 짧게 유지됩니다. 회의를 유지하면 15 분이면 사람들이 쉽게 회의에 참여할 수 있습니다.
매일 스탠드 업 회의도 매일 같은 시간에 같은 장소에 보관되어 참가자 간의 혼란과 매일 회의실을 예약하는 오버 헤드를 줄입니다. 회의 중에는 노트북, 데스크톱 또는 휴대 전화를 사용하지 않는 것이 좋습니다.
팀은 Daily Standup 회의를 할시기를 결정하고이를 고수 할 수 있습니다. 그러나 정상적인 경향은 아침에 회의를 가장 먼저 유지하는 것입니다. 다른 시간대에서 작업하는 팀의 경우 모닝콜이 작동하지 않을 수 있으므로 오후 또는 자신에게 가장 적합한 통화를 할 수 있습니다.
스크럼 마스터는 시간이 허락되지만 어떤 비용으로도 회의를 연장 할 수없는 경우 회의가 끝날 때 중요한 뉴스 나 업데이트를 팀과 공유 할 수도 있습니다.
스프린트 검토
목적
Sprint Review Meeting은 완료된 작업을 시연하고 피드백 및 동의를 수집하는 것입니다. 어떤 곳에서는 Sprint Review 회의를 Sprint Demo라고도합니다. 스프린트 검토 회의는 일반적으로 스프린트가 끝나고 스프린트 회고 회의 전에 이루어집니다.
팀에서 선택한 대표가 현재 스프린트 작업 항목을 보여줍니다. 일반적으로 사용자 스토리를 작업하는 개발자는 작업을 시연하고 청중이 제기 한 질문에 응답합니다.
완료 정의를 기반으로 수행 된 사용자 스토리는 Sprint Review Meeting에서 데모를위한 유일한 후보입니다.
제품 소유자는 Sprint Review 회의에서 매우 중요한 역할을합니다. 그는 허용 기준에 따라 시연되는 각 사용자 스토리를 평가하고 스토리를 수락하거나 거부 할 책임이 있습니다.
승인 된 스토리는 잠재적으로 배송 가능한 결과물 인 Done Increment와 통합됩니다. 거부되거나 완료되지 않은 스토리는 제품 소유자의 부름입니다. 거부 된 스토리는 다음 스프린트의 일부가되거나 다시 우선 순위가 지정되는 제품 백 로그로 이동할 수 있습니다.
Sprint Review 회의의 주요 결과는 프로젝트 완료 날짜의 전체적인 그림입니다. 제품 소유자는 스토리를 수락 / 거부하고 수락 된 스토리는 전체적으로 Increment (이전 스프린트 동안 생성됨)와 통합되어 전체 제품을 완성하는 데있어 우리가 어디에 있는지 더 잘 보여줍니다.
Sprint Review 회의의 또 다른 주요 결과는 팀 구성원이 추정에 대해 알게 된 것입니다. 수락 된 사용자 스토리의 수는 스프린트에서 달성되는 스토리 포인트의 수를 결정합니다.
따라서 스프린트별로 점진적으로 스프린트하면 팀은 정확하게 추정하는 능력을 개발하고 달성 가능한 스토리 포인트에 대해 정보에 입각 한 결정을 내릴 수 있습니다.
그러한 회의는 불완전한 수락 기준 또는 새로운 요구 사항이 튀어 나온다는 사실을 밝혀주는 것으로 종종 관찰됩니다. 이 상황을 해결하는 가장 좋은 방법은 스토리를 닫고 스프린트 계획 회의에서 처음 합의 된 모든 수락 기준을 충족하는 경우 완료로 표시하는 것입니다.
새로운 요구 사항으로 간주되어야하는 이상 사항 및 제품 소유자는 향후 스프린트에 대한 요구 사항에 대한 책임이 있습니다.
참석자
Sprint 검토 회의에는 스크럼 마스터 및 제품 소유자를 포함한 팀 구성원이 참석합니다. Sprint Review 회의의 다른 참가자는 이해 관계자, 제공 관리자, 고객 / 최종 사용자 또는 Sprint Review에 참여하는 데 관심이있는 모든 사람입니다.
타임 박스
2 주간의 스프린트에 대한 이상적인 시나리오에서 우리는 스프린트 검토 회의에 약 2 시간을 보냅니다. 이것은 스프린트의 길이에 따라 다를 수 있습니다. 더 짧은 스프린트의 경우 더 짧은 스프린트 검토 및 더 긴 스프린트의 경우 더 긴 스프린트 검토.
다른 회의와 마찬가지로 스크럼 마스터는 회의의 추진력을 유지하고 활동 (스토리 시연, 질문에 답하기, 스토리 수락, 언급 된 피드백 등)이 규정 된 시간 범위 내에 맞는지 확인할 책임이 있습니다.
스프린트 회고전
목적
Sprint Retrospective는 Agile의 말을 구현하는 것입니다. 더 효과적인 방법에 대한 정기적 인 고찰 ’. Sprint Retrospective는 전체 팀이 스프린트가 어떻게 진행되었으며 프로세스를 즉석에서 수행하기 위해 수행해야하는 작업을 반영하고 숙고 할 수있는 기회를 제공합니다. Sprint Retrospective는 각 스프린트가 끝날 때 수행됩니다.
Sprint Retrospective 회의에서 전체 팀이 모여 방금 완료된 Sprint에 대해 논의합니다. 팀은 투명하고 정직한 의견을 제시해야하지만 비난 게임은 주변에 없습니다.
즉흥 연주 분야에서 한 발 앞서 나가고 멤버들 사이의 긴장감을 높여 팀을 유지하는 것이 아니라 회의의 목적을 기억하십시오.
여러분 에 팀은 다음 네 가지 기본 질문에 답해야합니다.
스크럼 마스터는 위의 스티커 메모에 표시된대로 각 사분면에 대한 점수를 팀원에게 작성하도록 요청합니다. 어떤 곳에서는 도구가 같은 목적으로 사용됩니다.
잘 됐어?
팀원들은 지난 스프린트에서 잘 된 것에 대해 하나 이상의 점수를 부여합니다. 이 섹션은 또한 다른 팀원들의 좋은 작업에 대해 감사하고 인정하는 기회로 삼을 수 있습니다.
무엇을 배웠습니까?
스크럼은 모든 스프린트에서 새로운 것을 배울 수있는 기회로 간주됩니다. 사분면의이 영역은 마지막 스프린트에서 얻은 주요 내용과 학습 내용을 논의하는 것입니다.
잘되지 않은 것은 무엇입니까?
이 섹션에서 팀은 마지막 스프린트 동안 직면 한 문제와 장애물에 대해 논의합니다. 회의의이 부분은 사람들이 다른 사람들을 불편하게 만들 수있는 문제를 제기 할 수 있기 때문에 가장 취약한 부분 인 경향이 있습니다.
필요한 경우 분위기를 진정시키고 사람들에게 인신 공격을 거치지 않고 건설적인 방식으로 문제를 제기하도록 가르치는 것은 스크럼 마스터의 책임입니다.
다른 팀원들 앞에서 문제를 마주하는 것이 불편한 멤버가 있다면 나중에 스크럼 마스터에게 가서 문제를 논의 할 수 있습니다.
더 잘할 수있는 것은 무엇입니까?
회의의이 부분은 모든 팀 구성원이 이전에 제기 된 모든 문제를 논의하고 해결 방법을 찾을 수있는 기회를 제공합니다. 팀원 모두가 당면한 문제에 대한 해결책을 제안 할 수 있습니다. 그런 다음 팀은 단결하여 가장 적합한 솔루션을 결정합니다.
팀은 또한 향후 스프린트를 위해 잘 진행된 섹션에서 논의 된 사항을 고수해야하며 앞으로 이러한 사항을 프로세스의 필수 부분으로 추가 할 수 있습니다.
Sprint Retrospective 회의의 결과는 다가오는 스프린트를위한 프로세스를 개선하기 위해 참가자가 동의 한 작업 항목 목록입니다.
참석자
스크럼 마스터 및 제품 소유자를 포함한 전체 스크럼 팀. 그러나 일일 스탠드 업 회의와 달리 스크럼 마스터 및 제품은 입력 및 회고 포인트를 제공하는데도 참여합니다.
Visual Studio 용 github 확장을 사용하는 방법
Daily Standup 회의와 마찬가지로 Sprint Retrospective 회의도 Scrum Master에 의해 진행됩니다. 스크럼 마스터는 자신을 포함한 팀의 모든 사람이 긍정적 인 것과 부정적인 것을 모두 열고 말할 수있는 기회를 제공합니다.
팀 외부의 참가자는 Sprint Retrospective Meeting에 초대되지 않습니다. Sprint Retrospective는 팀 구성원이 주저없이 문을 열고 마지막 스프린트 동안 직면 한 문제를 논의 할 수있는 약간의 개인적이고 감정적 인 환경으로 간주됩니다.
타임 박스
모든 스크럼 세레모니는 타임 박스이며 타임 박스는 스프린트의 길이에 따라 달라진다고합니다. 단, 2 주 동안 스프린트 동안 2 시간 동안 스프린트 회고 회의를 갖는 것이 이상적입니다.
그러나 Sprint Retrospective를 개선 사항에 대한 의사 소통, 회고 및 헌신의 기회로 본다면 회의가 중요한 관점과 통찰력을 잃지 않도록 충분한 시간을 제공하는 것이 매우 정당합니다.
따라서 회의 시간을 정하는 것은 좋지만 의사 소통과 진행을 희생하여 수행해서는 안됩니다. Scrum에서 또 다른 매우 중요한 이벤트는 백 로그 세분화입니다. 잠시 시간을내어 그것에 대해 조명 해 보겠습니다.
백 로그 개선
백 로그 그루밍이라고도하는 백 로그 구체화는 다음 스프린트의 일부가 될 수있는 제품 백 로그의 사용자 스토리를 논의하기위한 회의입니다. 백 로그 구체화 회의에서 전체 팀은 함께 앉아 사용자 스토리를 논의하여 입력을 제공합니다.
전반적인 아이디어는 다가오는 Sprint에 대한 제품 백 로그를 준비하고 사용자 스토리를 선택할 준비가되었는지 확인하는 것입니다. 백 로그 세분화 회의는 'n'스프린트에서 선택 될 항목을 준비하기 위해 'n-1'스프린트 중에 구성됩니다.
결론
이것으로 우리는 반드시 읽어야 할‘스크럼 이벤트’에 대한이 튜토리얼의 끝까지 왔습니다. 스크럼 이벤트는 스크럼 시리즈에서 가장 중요하고 중요한 주제입니다.
이 튜토리얼에서는 5 개의 스크럼 이벤트, 즉 스프린트, 스프린트 계획, 일일 스탠드 업, 스프린트 검토 및 스프린트 회고 . 일일 스탠드 업을 제외한 각 이벤트에는 스프린트 당 규칙적인 사이클이 있습니다. 즉, 모든 스프린트에서 한 번씩 수행됩니다.
이벤트는 스크럼 환경에서 작업이 어떻게 수행되는지에 대한 통찰력을 제공합니다. 모든 스크럼 이벤트는 개선, 적응 및 검사의 기회입니다.
다음은 현재 Sprint의 모든 결함을 논의하고 분류하는 공식 회의 인 '결함 심사'에 대한 자습서입니다.
추천 도서
- 스크럼 아티팩트 : 제품 백 로그, 스프린트 백 로그 및 제품 증분
- JIRA Scrum Board Tutorial : Sprint 관리를위한 Jira를 사용한 스크럼 처리
- 애자일 스크럼 온라인 퀴즈 : 애자일 스크럼에 대한 지식 테스트
- Agile Scrum 프로세스를 사용하여 단기간에 고 가치 소프트웨어 기능을 제공하는 방법
- 스크럼의 결함 심사 : 스크럼 설정에서 구성되는 방법
- Selenium 전문가를위한 파트 타임 프리랜서 채용 기회
- 스크럼 팀 역할 및 책임 : 스크럼 마스터 및 제품 소유자
- 직원 시간 추적을위한 10 가지 최고의 자유 시간 시계 소프트웨어