스크럼 가이드 | 35. 일일 스크럼
게시 됨: 2022-07-08Daily Scrum은 15분 이상 지속되지 않으며 불필요한 복잡성을 줄이기 위해 항상 같은 장소와 시간에 개최됩니다. 제품에 대해 함께 작업하는 모든 개발자와 선택적으로 스크럼 마스터가 참석합니다. 이 스크럼 이벤트의 주요 목적은 그날 집중할 작업을 계획하는 것입니다.
일일 스크럼 – 목차:
- 소개
- 데일리 스크럼 공식
- Daily Scrum과 5W 방식의 문제점
- 지원 질문
- 5 왜
- 요약
소개
일일 스크럼은 스크럼 이벤트 중 가장 짧고 자주 발생하며, 이에 대한 개요는 별도의 기사에서 확인할 수 있습니다. Daily Scrum에 참여하는 개발자의 임무는 향후 24시간 동안의 작업 목표를 빠르게 설정하는 것입니다. 이런 식으로 그들 각자는 다른 사람들이 무엇을 하고 있고 공통 스프린트 목표를 위해 어떻게 노력하고 있는지 알 수 있습니다.
데일리 스크럼 공식
올바른 일일 스크럼 공식은 없습니다. 각 개발 팀은 자신에게 적합한 회의 형식을 개발합니다. 그러나 보다 쉽게 수행할 수 있도록 하는 일반적인 프레임워크 가 있습니다.
잘 수행된 일일 스크럼에서는 각 참가자가 다음 두 가지 질문 에 답할 수 있어야 합니다.
- 오늘 내가 수행할 가장 중요한 작업은 무엇입니까?
- 이 작업을 수행하는 데 장애물은 무엇입니까?
그러나 그들에게 직접 묻는 것은 필수 공식이 아닙니다. 회의의 축을 정의하는 샘플 질문입니다. Daily Scrum은 개발 팀의 의사 소통을 개선하고 작업의 우선 순위를 지정하며 병목 현상의 위험을 줄이기 위한 것입니다.
Daily Scrum은 다른 Agile 방식의 Daily Standup과 동일한 이벤트입니다. 공식 스크럼 가이드에서는 개발자가 이 짧은 이벤트 동안 서 있을 것을 요구하지 않지만 종종 이와 매우 유사하게 실행됩니다. 매우 자주 참가자는 비공식 그룹에서 이야기하는 동안 단순히 서 있습니다.
하루 15분은 일상적인 작업을 논의하는 데 많은 시간으로 보일 수 있지만 실제로는 이러한 회의가 개발 팀의 효율성을 위해 가장 좋습니다. 목표와 약속에 대한 정기적인 업데이트를 통해 모든 개발자는 우선 순위 작업에 집중하고 개별 결과보다 원활한 팀 진행을 우선시합니다.
Daily Scrum과 5W 방식의 문제점
Daily Scrum의 문제점 중 하나는 개발자가 회의 시간을 지연시킨다는 것입니다. 이 경우 데일리 스크럼의 핵심은 아니지만 팀에 중요한 문제가 되는 문제(물리적이든 가상이든)를 게시판에 기록하는 정책을 도입하는 것이 좋습니다. 이런 식으로 낮 동안의 비공식 토론에서 논의하기 위해 남겨진 문제로 돌아갈 수 있을 것입니다. 또한 필요한 경우 Sprint Retrospective 동안 별도의 기사에서 더 자세히 설명합니다.
일일 스크럼에서 자주 발생하는 또 다른 문제는 전날의 작업을 요약하는 회의로 전환하는 것입니다. 그런 다음 개발자는 이미 달성한 결과를 논의하는 데 집중합니다. 이것은 좋은 습관이 아닙니다. 확실히, 스프린트 목표로 이어지는 작업의 상태에 대한 개발자의 현재 방향은 매우 중요합니다. 그러나 이미 완료된 작업에 일일 스크럼을 사용하는 것이 효율성을 높이는 것은 아닙니다.
지원 질문
팀이 Daily Scrum의 혜택을 받지 못하는 경우 Scrum Master는 다음 질문에 대한 답변을 위해 회의를 관찰하여 개발자가 문제를 식별하는 데 도움을 줄 수 있습니다.
5 왜
문제의 초기 식별 후 문제의 원인을 결정하는 효과적인 기술은 Sakichi Toyoda가 5 Whys 또는 5W라고도 하는 5 Why 방법 이 될 수 있습니다. 여기에는 여러 "왜?"라는 질문이 포함됩니다. 연속으로 질문. 이를 통해 문제의 더 깊은 원인을 진단할 수 있으므로 보다 쉽게 해결할 수 있습니다.
예를 들어, 표의 마지막 항목을 살펴보겠습니다. 문제는 개발 팀의 문제 해결 의지 영역에서 발생합니다. 다섯 가지 질문은 다음과 같습니다.
1 x 왜?
Q: 왜 개발자들은 발생하는 문제를 해결하는 다른 방법을 제공하지 않습니까?
A: 개발자 Harry가 항상 하나의 솔루션을 가장 먼저 제안하기 때문입니다.
2 x 왜?
Q: 개발자 Harry가 항상 먼저 하나의 솔루션을 제안하는 이유는 무엇입니까?
A: 아무도 말하고 있지 않기 때문입니다.
3 x 왜?
Q: 왜 다른 사람은 말하지 않습니까?
A: 다른 개발자들은 더 나은 솔루션을 찾고 싶지 않기 때문입니다.
4 x 왜?
Q: 왜 다른 개발자들은 더 나은 솔루션을 찾고 싶어하지 않습니까?
A: 솔루션을 찾는 데 집중해야 하고 Harry의 솔루션이 충분히 훌륭하다고 생각하는 것이 더 쉽기 때문입니다.
5 x 왜?
Q: 왜 그들은 Harry의 솔루션이 충분하다고 생각했습니까?
A: 대안을 제시해도 보상을 받지 못하기 때문에 회의 초반에 오늘의 계획을 논의하고 시작하려고 합니다.
이 경우 데일리 스크럼의 순서를 바꿔서 이 문제부터 시작하면 문제 해결 의지가 부족한 문제를 해결할 수 있다. 또는 주어진 스프린트에서 팀이 수락한 가장 많은 수의 솔루션 작성자에 대한 상징적 보상을 도입하는 것과 같이 최상의 솔루션에 대한 보상 시스템을 고안합니다.
요약
일일 스크럼은 개발 팀의 일상 업무에서 핵심적인 부분입니다. 그러나 각 팀은 이 회의를 위한 최적의 공식을 스스로 해결해야 합니다. 잘 수행된 일일 스크럼은 스프린트 목표를 달성하기 위한 하위 목표의 지속적인 설정을 허용합니다. 또한 통신 문제를 신속하게 진단하고 개발자 간의 협력을 향상시킬 수 있습니다.
콘텐츠가 마음에 들면 Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest에서 바쁜 꿀벌 커뮤니티에 가입하세요.
저자: 캐롤라인 베커
프로젝트 관리자인 Caroline은 최고의 워크플로를 설계하고 프로세스를 최적화하기 위한 새로운 방법을 찾는 데 전문가입니다. 그녀의 조직적 기술과 시간 압박 속에서 일하는 능력은 그녀를 복잡한 프로젝트를 현실로 만드는 최고의 사람으로 만듭니다.
스크럼 가이드:
- 기본 용어, 역할 및 개념의 용어집
- 스크럼이란?
- 스크럼 값
- 회사에서 스크럼을 구현하는 방법은 무엇입니까?
- 스크럼 팀 - 무엇이며 어떻게 작동합니까?
- 제품 소유자는 누구입니까?
- 제품 소유자의 가장 일반적인 실수
- 스크럼 마스터는 누구인가?
- 좋은 스크럼 마스터의 특징
- 스크럼 마스터의 가장 흔한 실수
- 스크럼 마스터가 추적해야 하는 통계 및 메트릭은 무엇입니까?
- 제품 소유자와 스크럼 마스터 간의 협력
- 스크럼 개발팀
- 개발자의 가장 흔한 실수
- 스크럼 아티팩트
- 스케일링 스크럼
- 스프린트 백로그
- 제품 백로그란 무엇입니까?
- 사용자 스토리란 무엇입니까?
- INVEST로 최고의 사용자 스토리 만들기
- 가장 흔한 사용자 스토리 실수
- 사용자 스토리 수락 기준
- 스크럼의 추정 및 스토리 포인트
- 계획 포커
- 팀 평가 게임
- 증분 정의
- 스크럼 이벤트
- 스크럼에서 스프린트란?
- 스크럼 팀 약속 - 제품 목표, 스프린트 목표 및 완료의 정의
- 번다운 차트란 무엇입니까?
- 번다운 차트를 만들고 해석하는 방법은 무엇입니까?
- 번다운 차트의 장점과 단점
- 스크럼과 스크럼반의 칸반 보드
- 스크럼의 속도 - 개발 팀의 속도
- 일일 스크럼
- 스프린트 계획
- 스프린트 리뷰
- 스프린트 회고란 무엇입니까?
- 스프린트 회고 중 일반적인 실수
- 제품 백로그 육성