매일 스크럼-개발자 당 3 가지 질문을하거나 티켓으로 이동 하시겠습니까?
우리는 약 5 명의 개발자로 구성된 소규모 팀입니다.
우리는 가상 스크럼 보드가있는 티켓 관리 시스템을 사용하고 있습니다.
스크럼 보드에는 여러 개의 열이 있습니다. 열의 항목은 우선 순위에 따라 정렬됩니다.
New | Consultation | Working | Waiting | Test & Review | Done
상담 = 외부인의 피드백 필요
Waiting = 누군가 또는 무언가를 기다리는 중
2 주 동안 스프린트를하는 동안 약 40-50 개의 활성 티켓이 있습니다.
표준 스크럼 데일리에서는 일반적으로 모든 개발자가 3 가지 질문에 답합니다.
어제 무엇을 했습니까?
오늘은 무엇을할까요?
내 장애는 무엇입니까?
어떻게 든 우리의 프로세스는 다릅니다.
우리는 열로 이동 한 다음 열의 각 티켓으로 이동합니다.
다음과 같은 몇 가지 이유 때문에 이렇게합니다.
- 이 프로세스는 자체적으로 개발되었지만 우리는 계획하지 않았습니다.
- 일부 개발자는 다른 사람들이 말하고 듣지 않을 때 "공간을 확보"합니다. 예, 일반적으로 매일 15 분 정도이므로이 시간 동안 청취가 가능할 것으로 예상 할 수 있습니다. 그러나 우리는 모두 집에서 일하기 때문에 누군가가 듣고 있는지 여부를 알 수 없습니다.
- 개발자가 3 개의 질문을 마치면 초점이 사라져 다른 질문의 말을 듣지 않을 수 있습니다.
- 개발자는 티켓에 표시되지만 작업중인 티켓을 찾기 위해 자신의 이름을 검색하는 데 약간의 시간이 걸립니다. 보기를 전환하는 방법이 있지만보기를 지속적으로 전환하면 모든 사람이 매우 빠르게 짜증이납니다.
- 개발자에게 가면 프레젠테이션을하면서 중요한 티켓을 간과 할 때가 있습니다.
칼럼을 지나면 티켓이 더 자연스러워지고 다음 티켓이 자신의 것이기 때문에 모든 사람이 더 적극적으로 듣는 것처럼 보입니다. 또한 우리는 중요한 세부 사항이나 티켓을 간과하지 않습니다. 대부분의 경우 개발자는 이러한 방식으로 세 가지 질문에 간접적으로 대답하지만 항상 그런 것은 아닙니다. 이 과정은 적어도 우리 환경에서 여전히 다소 우월하다고 느낍니다!
그래서 항상 3 개의 질문을해야합니까, 아니면 티켓으로 가야합니까?
아니면 어떤 접근 방식이 "더 나은"지 알 수있는 방법이 있습니까?
(이 사진이 내 질문을 이해하는 데 도움이 될 수 있습니다)
답변
그래서 항상 3 개의 질문을해야합니까, 아니면 티켓으로 가야합니까? 아니면 어떤 접근 방식이 "더 나은"지 알 수있는 방법이 있습니까?
2020 년 버전의 스크럼 가이드 에서는 세 가지 질문을 제거했지만 2017 년 버전의 가이드 에서는 다음과 같이 말합니다.
회의의 구조는 개발 팀에서 설정하며 스프린트 목표를 향한 진전에 초점을 맞추는 경우 다양한 방식으로 진행될 수 있습니다. 일부 개발 팀은 질문을 사용하고 일부는 더 많은 토론을 기반으로합니다.
그러니 가장 좋다고 생각하는 일을하거나 팀이 선호하는 것이 무엇인지 물어보고 더 유용하다고 생각하십시오.
세 가지 질문은 목표를 향한 노력을 조정하기 위해 다루어야 할 기본 사항에 대한 토론에 초점을 맞추기 때문에 매일 수행 할 수있는 방법의 예입니다. 티켓에 대해 논의하는 것이 더 나은 접근 방식이라고 생각되면 그렇게하십시오.
너무 많은 세부 사항에 빠져들지 않도록하고 (매일 이후에 항상 더 자세히 논의 할 수 있음) 시간 상자를 넘어서서 회의로 바뀌고 사람들에게 정신적으로 체크 아웃 할 수있는 더 많은 기회를 제공합니다.
TL; DR
개발자 또는 칼럼별로 보드를 걸어야합니까? 둘 다 아닙니다. 둘 다 안티 패턴입니다.
팀에서 상태 풀과 스탠드 업을 취급하지 말고, 확실히 전체 스프린트 계획 모든 작업의 상태의 미니 리뷰로 사용하지 마십시오. 스탠드 업의 범위를 현재의 작업으로 유지한다면 어떻게 "보드를 걸어야할지"(힌트 : 그렇게해서는 안되므로 하나가 없습니다)에 대한 질문은 사라집니다.
팀 조정에 다시 집중
귀하의 질문은 근본적으로 결함이있는 가정에서 시작됩니다. 모든 티켓에 대해 상태 보고서를 수행하는 것이 Scrum에서 유익하거나 바람직하다는 가정입니다. 팀이 오늘의 활동에 대한 적시 계획 및 조정을 수행하는 일일 스탠드 업 의 전체 요점 을 놓치고있는 한 정말 X / Y 문제 입니다.
"세 가지 질문"은 목적을위한 수단 일뿐입니다. 덜 성숙한 팀에서는 지침이나 요점을 가지고 있으면 팀 구성원이 작업 간의 종속성을 식별하는 데 도움이 될 수 있습니다. 그러나 의도는 상태 보고서를 제공하는 것이 아닙니다. 목표는 항상 팀이 현재 작업을 공동으로 계획하도록 돕는 것입니다. 예를 들면 :
Sandy : 어제는 중앙 위젯을 비대화하는 작업을했습니다. 오늘은 기본 톱니 바퀴를 축소해야하지만이를 수행하려면 Susan의 whatchamacallit이 필요합니다.
Susan : 어제 whatchamacallit을 마쳤으므로 Sandy를위한 준비가되었습니다. 오늘 저는 frobnosticator 작업을하고 싶었지만 MacGuffin 이야기가 끝날 때까지 꼼짝 않고 있습니다. 아직 작업중인 사람 있나요?
즉, "보드 위를 걷는"데 매일 스탠드 업을 사용하지 마십시오. 이를 사용하여 팀이 하루 일과를 스스로 구성 할 수 있습니다! 질문이 팀에서 도움이된다면 좋습니다. 그렇지 않다면 던지십시오.
마찬가지로, 이미 진행 중이거나 당일 계획된 작업 만 스탠드 업에서 논의해야합니다. 스프린트 백 로그 또는 보류 상태의 작업은 현재 작업의 종속성이거나 다른 작업에 대한 차단기이거나 누군가가 오늘 작업중인 작업으로 가져올 계획 인 경우에만 관련이 있습니다 .
정말로 스프린트 상태를 원한다면 완료 열과 번 다운 차트를 활용하여 스프린트 목표를 달성 할 수 있는지 확인하세요. 스프린트 목표의 상태에 문제가있는 경우 일일 스탠드 업 이외의 별도 회의가 필요하며 다음 스프린트 회고에서 전체 스크럼 팀의 관심이 가장 높습니다. 기껏해야 보드를 걷는 것은 비효율적 인 통신이나 누락 / 잘못된 정보 방사기를 은폐하는 임시 방편입니다. 최악의 경우 팀 구성원 간의 상호 작용보다 상태보고를 선호하여 팀이 적시 계획에 대해 협력하는 것을 적극적으로 방지 합니다.
세 가지 질문 접근 방식은 개인에 초점을 맞추고 있지만 이사회 접근 방식은 팀과 스프린트 목표에 초점을 맞추고 있습니다. (또는 적어도 보드의 오른쪽에있는 목표) 내 경험상 세 가지 질문의 함정은 개인이 자신이 일하고 있음을 증명해야한다고 느낄 때입니다. 그러나 티켓으로 가면 모든 사람과 이야기하지 않을 수도 있습니다.
위에서 언급했듯이 목표에 따라 더 좋습니다.
팀이 응집력 있고 보드가 목표에 이르는 경로를 반영한다면 반드시 보드를 사용하십시오. (더 나아가 보드를 명시 적으로 오른쪽에서 왼쪽으로 사용하는 것이 좋습니다. 작업을 완료하는 데 초점을 두는 것입니다.)
그러나 팀이 새롭거나 아직 함께 잘 작동하지 않거나 이사회가 실제로 목표를 나타내지 않는다면 세 가지 질문이 더 나은 방법 일 수 있습니다. 스프린트의 목표는 실제로 "이 새로운 팀을 젤로 만들어라"또는 "프랭키에 합류하여 그녀가 효과적 일 수 있도록"일 수 있습니다. 그럴 경우 모든 사람이 자신이하는 일과 효과가있는 것과 그렇지 않은 것에 대해 이야기 할 기회가 있는지 확인하고 싶을 것입니다.
아니면 어떤 접근 방식이 "더 나은"지 알 수있는 방법이 있습니까?
애자일 개발의 한 가지는 프로젝트 목표와 조직에 유연성을 제공한다는 것입니다. 데일리가 수행되는 방식에 대해 유연하게 할 수있는 한 가지는 반복적으로 개선하는 것입니다. 팀으로부터 피드백을 수집하고, 스프린트 회고전에서 일일 구조를 논의하고, 팀의 제안을 실험하는 것을 두려워하지 마십시오.
저는 현재 두 가지 접근 방식을 모두 가지고있는 팀에서 일하고 있습니다. 둘 다 매일 작업 지향적이고 매일 "세 가지 질문"이 있습니다. 첫 번째는 개발자들 사이에 매일 10 분씩 현재 보드에 대해 토론하고 기술적 관찰을위한 공간을 확보하는 것입니다. 두 번째는 더 넓은 팀과 함께 더 인간적인 일을하기 위해 "세 가지 질문"에 훨씬 더 집중하는 매일 15 분입니다.
우리는 개발자와 그들의 작업을 매일 진행했지만 초점, 시간 문제 및 관련 작업의 상태에 대한 일관된 이해 부족에 대해 언급 한 두 가지 이유로 프로세스를 스크랩하기로 결정했습니다. 그리고 그렇습니다. 개발자가 지속적으로 작업을 필터링하는 것은 우리에게도 번거로운 일이었습니다.
댓글을 달 수 없어서 2 센트를 추가했습니다.
내가 제안 할 수 있다면 "세 가지 질문" 은 "당신의 배꼽을 응시하는 것 " 일 수 있지만, 당신은 정말로 그들 모두가 "주위를 둘러 보길"원합니다.
가장 먼저 할 일은 "비즈니스에 유용한"방식으로 관련 작업을 함께 고려할 수 있도록 편리하게 작업 목록 을 그룹화 하는 방법을 찾는 것입니다. (또한 둘 이상의 그룹과 관련된 작업을 "태그"하는 기능적인 방법을 찾으십시오. 소프트웨어에서는 일반적으로 모든 것이 다른 모든 것과 관련이 있습니다.)
그런 다음 팀에게 각 그룹을 함께 고려 하고 상호 및 정보에 입각 한 합의에 의해 팀의 "하루에 대한 세 가지 질문"이 되어야하는 것을 선택 (!) 하도록 요청합니다.
한편으로 소프트웨어 개발자는 그날의 문제에 집중할 수있는 우수한 능력을 습득했습니다 . 말하자면, "그들은 깊이 잠수하는 방법을 정확히 알고 있습니다." 그러나 - 지금 개인적인 경험에서 말하기 - 너무 늦게 깨닫게 끔찍한 것을 당신이 알고하지 않았다 당신이 엉뚱한 이유로 잘못된 자리에 깊은 다이빙 그리고 당신은 단지 허리케인 바보 같은 짓을 받았습니다. "당신은 알고 있었지만 ..."
따라서 근본적인 문제는 분명합니다. 개발자는 항상 보트에 앉아 항상 마른 상태로 큰 그림을보고있는 "딥 다이버"이기 때문에? 상어를보고 계십니까? 그들이 수면에서 노를 젓는 동안, 다음에 어디에서 왜 다이빙해야하는지 알 수 있도록 도와 주나요? 당신이 될 것입니다.
이제-생각을 완성하기 위해-때때로 그 다이버들은 당신 이 알지 못했던 중요한 새로운 발견을 가지고 표면으로 돌아올 것입니다 . 항상 개발자 자신이 믹스에 "티켓"을 제공하도록하십시오.
다른 사람들이 언급했듯이 스크럼 가이드는 더 이상 세 가지 질문을 규정하지 않습니다. 그리고 솔직히 말해서 3 가지 질문에 기반한 대부분의 일일 스크럼은 이벤트의 목적과 모순됩니다. 스크럼 마스터가 오케스트레이션하고 팀 구성원이 0 % 자체 구성 인 지난 24 시간을보고해야 할 때. 스프린트의 상태를 진정으로 점검하고 스프린트 목표에 성공적으로 도달한다는 정신으로 하루를 계획하는 것은 아닙니다. 팀 구성원이 자신의 성공에 관심이있는 개발 팀의 내부 토론이어야합니다.