스크럼 스탠드 업에서 어제 수행 된 내용에 대한 토론이 보드상의 작업 또는 모든 작업으로 제한되어야합니까?

나는 매일 스탠드 업에서 스크럼 규칙 이 팀이 어제 무엇을하고 있는지, 오늘 무엇을하고 있는지, 무엇을 막고 있는지에 대해서만 이야기해야한다는 것을 알고 있습니다. 다른 건 없어 그러나 문제는 때때로 개발자가 업무와 관련이없는 일을하면서 스탠드 업에서 이야기하는 것입니다. 그들이 어제 한 일입니다!

내 경험상, 보드상의 작업에 대해 이야기하고, 스탠드 업에 집중하고, 모든 사람이 자신의 작업에 계속 집중하고, 평가를 검토하고, 매일 기록을 추적하는 것이 더 효과적이라는 것을 알았습니다.

토론을 칠판의 과제로 제한하는 것이 유효합니까?

agile scrum meetings

— 샤딘
소스

개발자가 하루 종일 업무를 수행하지 않으면 언급하지 않으면 보이지 않는 문제가 될 수 있습니까?

— RemcoGerlich

모두 30 초 전에 자신이 한 일에 대해 이야기합니다. 얼마나 더 집중하고 싶습니까? 추정을 검토 하지 않습니다 . 다음 사람 (검토 자 또는 테스터)에게 전달할 때 작업을 추적합니다.

— gnasher729

답변:

일일 스탠드 업에 대한 Scrum Guide의 내용에 따라 다음 세 가지 질문이 있습니다.

어제 개발 팀이 스프린트 목표를 달성하는 데 도움이 된 것은 무엇입니까?

개발 팀이 스프린트 목표를 달성하도록 돕기 위해 오늘 무엇을해야합니까?

본인 또는 개발 팀이 스프린트 목표를 달성하지 못하게하는 장애가 있습니까?

모든 질문은 게시판에있는 작업이 아니라 스프린트 목표에 중점을 둡니다. 다시 한 번 스크럼 가이드에 따라 스프린트 목표는 스프린트 계획에서 작성되며 , "제품 백 로그의 구현을 통해 스프린트 내에서 달성 될 목표를 정의하고, 개발 팀에게이를 구축하는 이유에 대한 지침을 제공합니다. 증가".

개발 팀이하는 모든 일은 이상적으로 팀이 스프린트 목표를 향한 진전을 돕도록해야합니다. 이것은 계획되지 않은 활동으로, 보드에서 수행되지 않았거나, 고려 및 추정되었을 수 있지만 보드의 항목보다 낮은 수준의 작업 일 수 있습니다.

팀원들이 어제했던 모든 일에 대해 이야기하게하겠습니다. 팀이 스프린트 목표를 달성하는 데 도움이되지 않는 것에 대해 이야기하고 있다면, 특히 스프린트 목표를 완수하기 위해 팀을 더 가까이 옮길 수있는 다른 일이 있었을 경우 누군가가이를 제기해야합니다.

한 개인이 여러 Scrum 팀을 지원하는 경우가 있습니다. 회의에서 그들은 어제 수행 한 모든 것에 대해 이야기하지 말고 현재 스탠드 업중인 팀을 지원하기 위해 한 일에 대해 이야기해서는 안됩니다.

스프린트 회고는 팀이 문제에 대해 이야기 할 수있는 좋은 시간입니다. 고려해야 할 많은 질문이 있습니다.

스프린트 목표와 관련된 항목에 대해 팀원이 부족합니까?
계획되지 않은 작업이 너무 많습니까?
계획되지 않은 작업은 어디에서 왔으며 누가 승인합니까?
사람들이 왜 칠판에없는 일을하고 있습니까?
당신이하는 일을 더 쉽게 보드의 항목에 묶기 위해 보드에 더 자세한 내용을 보여 주어야합니까?

— 토마스 오웬스
소스

"스프린트 목표"의 문제점은 너무 모호하고 소원합니다. 실제로 스프린트 목표 == 보드의 작업을 완료합니다. 만약 당신이 작업 한 것이 거기에 있지 않거나 아니면 작업하지 말아야합니다

— Ewan

@Ewan 고객이 전화를 걸어 라이브 소프트웨어가 고장 났으며 로그 및 버그 보고서를 받았습니다. 지금 보드에 있지 않더라도 해당 보고서를 즉시 심사하는 데 시간이 걸리는 것이 중요합니다. 그것은 범위 내로 가져 오거나 백 로그에 올릴 수 있지만 어제 내가 한 일이며 점심 후에야 밥에게 그의 문제를 도울 수 없었던 이유 일 수 있습니다. 나는 그 일을 맹목적으로해서는 안되지만,이 스프린트에 빠지지 않는 한 아무도 보드에 올려 놓지 않을 것입니다. 다른 예도 생각할 수 있습니다.

— Thomas Owens

당신은 티켓 "트리거 라이브 버그"를 보드에 추가하고 완료로 표시해야합니다. 그런 다음 스프린트가 끝나면 확실하게 말할 수 있습니다. '이 스프린트는 X 시간 동안 사용자 오류를 보았습니다. 그래서 우리는 늦었습니다. 우리는 헬프 데스크를 더 잘 훈련해야합니다. 그렇지 않으면 스프린트가 완료되지 않고 PM은 팀의 변명을 받았습니다. '오 이번 주에 볼 버그가 많았습니다! 어깨를 으 ''

— Ewan

@ Ewan 나는 그것이 매우 불필요하다고 생각합니다. 나는 티켓을 쓰는 데 하루를 보내고 싶지 않습니다. 프로세스를 통해 작업을 완료하고 95 분 대신 분류하는 데 90 분이 걸리고 심사 한 후 티켓을 바보로 분류 한 티켓을 넣을 수 있어야합니다. 특히 여러 티켓을 심사해야하는 경우. 회고에서 논의하기 위해 티켓이 필요하지 않습니다. 전자 도구를 사용하는 경우 스프린트에서 팀이 수정 한 티켓을 찾아 심사 할 것이 많지 않은지 확인할 수 있습니다.

— 토마스 오웬스

scrummaster / pm / company까지보고 수준 하루 동안의 모든 작업을 처리하기 위해 하나의 "트리거 버그"티켓을 작성할 수 있습니다. 그러나 중요한 것은 당신이 인쇄물의 일부로 그것을 기록한다는 것입니다. 다른 통계에 의해서도 영향을받는다고 가정하지

— Ewan

아니요, 어제 무엇을했는지 이야기해야합니다.

보드에없는 경우 다음 중 하나를 수행해야합니다.

보드 위에 올려 놓고
그만해
또는 팀을 변경하십시오.

계획되지 않은 긴급 작업의 경우 가장 일반적인 것은 카드를 작성하여 보드에 붙이는 것입니다. 이를 통해 스프린트 종료시 속도를 측정하고 스프린트 목표를 달성하지 못한 이유를 설명 할 수 있습니다.

스프린트에없는 것을 다루는 팀원은 민첩한 입양이 실패한 주요 이유 중 하나라고 생각합니다. 가장 일반적으로 이것은 다른 프로젝트에서 실제 문제를 해결하기 위해 전환 된 개발자입니다.

스프린트에서 또 다른 성가신 것은 "PM이 다른 프로젝트를위한 회의에 대해 이야기하는 것"입니다. 내 생각에 PM은 스크럼 팀의 일부가 아니며, '제품 소유자'스크럼 역할을 수행하므로 진행 상황을보고하지 않고 질문에 대답합니다.

— 이완
소스

계획되지 않은 작업과 같은 것이 있습니다-누군가를 차단하거나 보드에있는 다른 작업을 수행하기 위해 수행해야하지만 보드에는 없습니다. 종종 보드에 올려 놓는 것이 더 빠를 수도 있습니다. 이를 처리하는 방법을 논의하는 것은 팀의 책임입니다. 현재 팀에는 프로덕션 또는 QA 환경에 배포되는 규칙 또는 2 시간이 걸리는 규칙이 있습니다. 때때로 논의해야 할 짧은 과제가 있지만, 기준에 맞지 않기 때문에 이사회를 만들지는 않습니다.

— Thomas Owens

@Ewan, 당신은 그것을 확장 할 수 있습니까? 스프린트에없는 경우 누가 라이브 버그 수정을 처리합니까? 프로젝트 소유자는 어떻게 동시에 프로젝트 관리자가 될 수 있습니까? (나는 어느 것이거나 두 역할을 모두 저글링하고 있음을 의미합니다)

— Dennis

명확성을 위해 편집 됨

— Ewan

@Dennis : 프로젝트 관리자는 스크럼 역할이 아닙니다.

— RemcoGerlich

@ 이완, 감사합니다. 이것은 대답에 필수적이지는 않지만 "PM이 다른 프로젝트를위한 회의에 대해 이야기하고 있습니다"라고 궁금합니다. 어떻게 작동합니까? PM은 프로젝트 X에 대해 회의에 참석하지만 Y에 대해 이야기합니까? 이것을 시각화하는 데 어려움을 겪고 있습니다. 이것이 어떻게 / 왜 가능합니까? 당신은 그들이 들어와 본질적으로 험담하거나 주제를 떠나기 시작했거나, 즉각 회의 특정 목표 / 필요에 대해 이야기해야하는 더 깊은 이유가 있습니까? 나는 "이걸 듣기 좋았지 만 나는 프로젝트 Y의 일부가 아니다. 거기에 지식 / 경험이 없다면, X로 돌아갈 수 있을까?"

— Dennis