Scrum Daily Standup 회의에서 체크인과 관련이없는 토론을하는 것이 허용됩니까?

사람들이 저에게 명백한 질문에 빠지 길 바랍니다. 저는 매일 스크럼 회의를하는 여러 조직에서 근무했습니다. 일부 조직은 체크인에만 스크럼을 사용하는 것 ( "세 가지 질문"-어제 무엇을했는지, 오늘 무엇을하는지, 차단자가 있습니까?)에 대해 엄격하지만 다른 조직은 다른 조직을 가지고있는 경향이 있습니다 발표 또는 자세한 기술 토론.

나는 이 기사 와 같은 비 체크인 관련 토론을 허용하는 것이 실수 라는 주장을 들었습니다. 스크럼 회의는 스크럼 마스터의 일반적인 발표, 기술 토론 등을 위해 사용되어서는 안됩니다.

내가 본 가장 큰 피해는 회의가 필요 이상으로 오래 지속될 수 있다는 것입니다 (그리고 나와 관련이없는 세부 사항에 대해 토론하는 것이 성가시다).

전체 그룹과 관련이없고 "세 가지 질문"에 속하지 않은 토론은지지의 일부가되어서는 안된다는 것이 분명합니다. 그러나 전체 그룹과 관련된 다른 발표가 있고 어쨌든 논의해야하는 경우 별도의 회의 나 전자 메일이 아닌 해당 시점에 논의하는 것이 해롭습니까?

Daily Scrum의 목적은 개발 팀이 지난 24 시간을 검토하고 다음 24 시간 동안 계획을 업데이트하는 것입니다.

이 목표를 달성하고 15 분 안에 다룰 수있는 것은 Scrum Guide에 따라 Daily Scrum의 목적과 정확히 일치합니다. 더 긴 대화가 필요한 경우 대화 내용을 메모하고 Daily Scrum이 끝날 때 해당 주제에 관심이있는 소규모 그룹으로 나눕니다.

Daily Scrum이 아닌 것은 문제에 대한 해결책을 찾는 것입니다. 그런 다음에 ...

물론 허용되지만 중요한 사항에 먼저 초점을 맞추십시오. 우리가하는 5 인 개발 팀 꽤 공통 인 15 분에 남아있는 시간이 있다면 집단 (그들이 개발하는 동안 더 자주 동기화 때문에)를, 나는 별도의 통신 및 또는 공지 사항에 문제가 없습니다. 우리는 매일이 끝날 때까지 연기합니다.

스크럼 마스터로서 저는 팀이 어떻게 든 세 가지 주요 질문에 답변하도록합니다.

Daily Scrum은 개발 팀이 활동을 동기화하고 향후 24 시간 동안 계획을 작성하기위한 15 분 단위 시간 단위 이벤트입니다.

때로는 팀을 동기화하기 위해 짧은 기술 토론이 필요합니다. 스크럼 마스터로서 저는 15 분 타임 박스에 맞도록하고 스탠드 업 이후에 더 긴 토론을 마무리합니다.

개발 팀 또는 팀 구성원은 종종 일일 스크럼 직후에 만나서 스프린트의 나머지 작업에 대한 자세한 토론을 조정하거나 재 계획합니다.

비 스크럼과보다 민첩한 관점에서 바라본다. 팀에 효과가있는 것과 그렇지 않은 것에 집중하십시오. 팀이 변경 사항을보다 효과적으로 결정하고 더 높은 품질의 소프트웨어를 제작할 것이라고 생각되면 변경 사항을 결정하고 실험하도록하십시오.

팀 구성원은 스탠드 업의 요점을 명심해야합니다. 즉, 비공개로 유지되거나 제한된 범위 내에서 더 오래 걸릴 수있는 문제에 서로가 기여할 수 있도록해야합니다. 반면에 중요하고 팀 전체와 관련된 문제를 피하는 것이 매우 민첩하지는 않지만 Scrum 포켓북에 명시된 지침 기준에 맞지 않습니다. 시간을 절약하기위한 규칙 때문에 별도의 회의를 예약하는 것은 어리석은 일입니다.

화자가 그의 문제가 무엇인지 항상 분명하지는 않습니다. 그를 잠시 동안 졸졸 거리게하면 다른 사람이 자신이 고군분투하거나 막 다른 길을 따르고 있음을 분명히 할 수 있습니다. 양식에 너무 많은 관심을 기울이면 생산성이 저하되고 사람들이 실망 할 수 있습니다.

문화에 따라 스탠드 업은 엄격하거나 사회적 문제도 포함 할 수 있습니다. "좀비 스크럼"으로 간주되는 것은 생각이없는 모션 동작 이벤트가되어서는 안됩니다.

다양한 사람들이 스크럼이라고 강력하게 주장하는 것과 프로세스에 대한 사람들의 개념 사이에는 종종 이분법이 있습니다.

전달할 정보가 있다면, 궁극적으로 판단 요청입니다. 상당한 양의 토론이 발생할 가능성이 높으면 다른 시간으로 이동하는 것이 가장 좋습니다. 서버 다운 타임 등과 같은 것이 빠른 경우에는 수행 할 수 있습니다. 물론 스크럼 마스터는 15 분 (또는 무엇이든)이 지나면 오프라인으로 전환되도록 제안해야합니다.

어느 쪽이든, 나는 일반적인 스탠드 업 프로세스가 완료된 후 그것을 끝내는 경향이 있습니다.

"해로운가요?" 그러나 다른 답변은 주로 "회의의 목적입니까?"라고 답했습니다. 나는 이것이 다른 질문이라고 생각합니다. 다른 아젠다 항목을 회의에 몰래 넣을 때, 특히 습관적이게되면 정말 해로울 수 있습니다. 스탠드 업은 사람들이 많은 에너지를 가지고있는 아침에 매일, 대개 가장 생산적인 시간에 많은 시간이 걸립니다. 필요한만큼 오래, 더 이상 완전히 관련이없는 스탠드 업을 믿을 수 없다면 사람들로부터 바로 그 에너지를 흡수 할 수 있습니다.

사람들은 "보다 생산적인"무언가에 관여하기 때문에 늦게 나타나기 시작할 것입니다. 그들은 심지어 며칠 동안 나타나지 않을 것입니다. "모두"가 늦게 나타나거나 전혀 나타나지 않기 때문에 다른 사람들이 늦게 나타나거나 나타나지 않을 것입니다. 문제는 서로 복잡해지고 스탠드 업은 원래 목적에 유용하지 않습니다. 그것은 극단적으로 들리지만, 나는 그것이 일어나는 것을 보았습니다. 이렇게하면 일 이 매우 그것을 리드 위치에 대한주의.

내가 참여했던 대부분의 팀은 때때로 스탠드 업 직후 디자인 회의를 개최 할 것입니다. 드물게 사용하면 괜찮습니다. 그러나 솔직히 말해서 팀원에게 스탠드 업 팀원에게 곧 디자인 입력이 필요하다고 차단되면 더 나은 결과를 얻을 수 있습니다. 그날 오후 모임을 예약 할 예정입니다. 그것은 그들에게도 문제를 해결할 시간을주고, 점심 식사 후에 사람들은 약간의 침체에 빠지고 페이스의 변화를 원합니다. 또한, 그렇게하면 사람들이 스탠드 업 후에 "미니 미팅"을하는 최초의 경쟁자가되지 않기 때문에 떠나게됩니다.

물론, 나는 인터넷의 임의의 사람 (나조차조차)이 당신에게 말했기 때문에 맹목적으로 무언가를하거나 맹목적으로 행동하지 않는 것을 결코 옹호하지 않을 것입니다. 프로세스 및 도구에 대한 개인 및 상호 작용 스탠드 업 미팅에 추가 아젠다 항목을 추가하기로 결정한 경우, 이후 회고에서 구체적으로 제시하고 팀이이를 방해하는지 확인한 후 필요에 따라 조정하는 것이 좋습니다. 궁극적으로 각 팀은 서로 다른 수준의 안락함을 가지며 적절한 것에 대해 다른 아이디어를 갖습니다.

업데이트 : 분명히해야합니다 : 15 분은 모든 스탠드 업을 고려해야하는 최대 시간입니다. 아래 규칙에 따른 효율적인 스탠드 업은 일반적으로 최대 5 분을 넘지 않으며 해당 시간을 더 이상 증류 할 수 있다면 더 좋습니다. 다시 말하지만, 귀하가 관련 있다고 생각하는 대부분의 토론은 간단한 일일 체크인 프로세스 이외의 팀 구성원간에 쉽게 토론 할 수 있습니다.

경험상 친구들과 프로젝트를 진행하면서 꼼짝 못하고 전문적인 환경에서 연마했습니다.

• 어제

어제 프로젝트를 진행하기 위해 개인적으로 한 일과 관련이 있다면 다른 사람에게 영향을 미쳤습니다.

• 오늘

위와 같이 오늘

• 차단제

아무리 사소한 일이 있어도 알람을 발생시키고 알람을 발생시킬 수있는 모든 것

다른 것은 산만하다. 이것은 "진행"이 프로젝트 진행과 관련이있는 것 같다는 주제를 의미 할 수 있습니다. 꽤 가혹하지만 XP 목적으로 매우 효과적입니다.

스탠드 업 회의의 목적은 효과적인 의사 소통입니다. 맹목적인 규칙을 따르는 대신 목표를 정하십시오. 이 질문을 게시 했으므로 올바른 방향으로 가고 있습니다.

모든 우려 사항이 유효합니다. 문제가 발생하는지 예상 할 수는 있지만 시도해 보라고 제안하여 질문에 대답합니다.

다음을 피하십시오 :

1. 너무 긴 회의가 있습니다.
2. 너무 많은 사람들이 다른 곳에서 공지를받는 것을 선호합니다. 예정된 회의 중에하는 것은 유혹적이지만 남용하지 마십시오. 대부분의 사람들은 나쁜 회의를 싫어합니다.
3. 모든 사람에게 정보가 적용되는 것은 아닙니다. 경우에 따라 몇 가지 예외가 있습니다.
4. 모든 회의에는 필요가 아니라 습관적으로 발표가 있습니다. 직업이 되십시오.

교육을 받고 정보에 근거한 결정을 내리고 지나치게 적용하거나 규칙을 너무 글자 그대로 숨기지 마십시오.

대부분의 애자일 모델은 민첩한 프로세스에 익숙하지 않은 팀을위한 훌륭한 시작 구조를 제공합니다. 그렇다고 사용자 요구에 맞게 변경할 수는 없습니다. 이러한 공지 사항으로 의사 소통이 개선되지 않으면하지 마십시오. 단순 해 보이지만 ...