민첩한 방법론에서 스탠드 업의 목적과 지속 기간은 무엇입니까? [닫은]

저는 폭포 방법론에서 일했고 지금은 민첩한 방법론을 따르는 팀에 있습니다. 그들이 잘못하고있는 것 같습니다. 예를 들어, 매일 25 분 이상 지속되는 스탠드 업이 있습니다. 또한, 나는 다른 어떤 것보다 급여를 경영진에게 정당화하는 것처럼 느낍니다.

이런 느낌이 잘못 되었나요? 이것이 스탠드 업이 일반적으로 수행되는 방법입니까?

스크럼의 경우 Ken Schwaber와 Jeff Sutherland는 다음과 같이 설명합니다 .

일일 스크럼

Daily Scrum은 개발 팀이 활동을 동기화하고 향후 24 시간 동안 계획을 작성하기위한 15 분의 시간 단위 이벤트입니다. 이는 마지막 일일 스크럼 이후의 작업을 검사하고 다음 작업 전에 수행 할 수있는 작업을 예측하여 수행됩니다. Daily Scrum은 매일 같은 시간과 장소에서 개최되므로 복잡성을 줄입니다. 회의 중에 개발 팀원은 다음과 같이 설명합니다.

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

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

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

개발 팀은 일일 스크럼을 사용하여 스프린트 목표를 향한 진행 상황을 점검하고 스프린트 백 로그에서 작업 완료를 향한 진행 상황을 조사합니다. 일일 스크럼은 개발 팀이 스프린트 목표를 달성 할 확률을 최적화합니다. 개발 팀은 매일 스프린트 목표를 달성하고 스프린트가 끝날 때까지 예상 증가분을 만들기 위해 자체 구성 팀으로 협력하려는 방식을 이해해야합니다. 개발 팀 또는 팀 구성원은 종종 일일 스크럼 직후에 만나서 스프린트의 나머지 작업에 대해 자세한 토론을하거나 재조정합니다.

Scrum Master는 개발 팀이 회의를 갖도록하지만 개발 팀은 Daily Scrum을 수행 할 책임이 있습니다. Scrum Master는 개발 팀에게 Daily Scrum을 15 분 안에 보관하도록 지시합니다.

Scrum Master는 개발 팀 구성원 만 Daily Scrum에 참여하는 규칙을 시행합니다.

일일 스크럼은 의사 소통을 개선하고, 다른 회의를 제거하고, 제거를위한 개발의 장애를 식별하고, 신속한 의사 결정을 강조 표시하고 개발하며, 개발 팀의 지식 수준을 향상시킵니다. 이것은 주요 점검 및 조정 회의입니다.

다른 방법론은 다른 의식을 가질 수 있으며 다른 스크럼 팀조차도 다르게 수행하는 방식을 최적화 할 수 있습니다. 핵심 아이디어는 팀이 신속하게 제공 할 수 있도록 신속하게 모이는 것입니다. 관리 상태 보고서가 아니어야합니다. 그러나 더 쉽게 파괴되는 민첩한 아이디어 중 하나입니다.

TL; DR

적절한 규모의 스크럼 팀 내에서 제대로 실행되면 일일 순위는 15 분 이상 걸리지 않아야합니다. 시간이 더 걸리면 팀이 너무 크거나 프로세스 문제가있는 것입니다.

스탠드 업의 목적

일일 순위는 전체 팀을위한 헌신과 조정 회의입니다. 전체 팀이 장애, 수행 할 스토리 또는 수행 할 작업, 한 팀 구성원의 할 일 목록에서 다른 사람에게 가져올 준비가 된 작업을 인식하도록 설계되었습니다.

Scrum Master와 Product Owner가 스탠드 업에 적극적으로 참여하는 것이 중요하지만, 팀 중 하나에 보고 하는 경우 Scrum 프로세스가 제대로 중단 될 수 있습니다. Project Management Stack Exchange에 대한 관련 답변 은 하단 에 "프로젝트 냄새"10 점 목록이 있으며 일부는 귀하의 경우에 적용될 수 있습니다. 적용되지 않더라도 다음 스프린트 회고전에서 스탠드 업의 효과를 확실히 다시 평가해야합니다.

타임 박스 존중

“세 가지 질문”이 구체적인 형식으로 싫어하는 이유는 그들이 상태 풀림과 유사한 회의로 이어지는 경향이 있기 때문입니다. 그러나 Mike Cohn의 일일 스크럼에 대한 정식 설명을 가리 키지 않으면 나는 기각 될 것 입니다. 이 페이지는 부분적으로 말합니다 :

팀은 어제 각자의 성과와 오늘의 성과에 중점을 두어 수행 한 작업과 남은 작업을 잘 이해합니다. 일일 스크럼 회의는 상사가 일정이 미달 된 사람에 대한 정보를 수집하는 상태 업데이트 회의가 아닙니다. 그보다는 팀원들이 서로에게 약속을하는 회의입니다.

해당 페이지에는 더 자세한 내용과 구체적인 예가 있습니다. 그러나 질문의 ​​목적 상 다음과 같이 명시 적으로 언급되어 있습니다.

스크럼 일일 스탠드 업 미팅은 15 분으로 엄격하게 시간이 정해져 있습니다. 이렇게하면 토론이 활발하지만 관련성이 유지됩니다.

타임 박스는 스크럼의 기초입니다. 검사 및 적응주기의 결과로 스크럼 내의 대부분의 시간 상자를 팀에서 조정할 수 있지만 스탠드 업 길이를 연장하는 것은 좋지 않은 관행으로 간주됩니다. 프로세스 내에서 시간 복싱 원칙을 준수하지 않는 경우 일반적으로 매우 기발한 "프로젝트 냄새"입니다.

당신이 설명하는 것은 팀에게 '스탠드 업'이 실패 할 수있는 한 가지 방법입니다.

모든 사람들이 다른 사람들이하고있는 일을 이해하고, 어제 달성 한 것을 설명하고, 오늘 성취 할 것을 설명하고, 약속을 이행 할 수있는 능력에 영향을 줄 수있는 모든 것을 표시하기 때문에 최고의 순위는 짧습니다. 그런 다음 팀의 다른 구성원은 서로의 장애를 신속하게 해결하는 데 도움이 될 수 있지만 솔루션은 스탠드 밖에서 참여한다는 것을 나타낼 수 있습니다.

요컨대 팀을 묶는 접착제가되어야합니다.

더 좋은 소리는 상태 업데이트이며 배달 / 배달을 설명하기 위해 열리지 만 팀이 장애를 전달하고 제거하기 위해 서로를 지원하기 위해 스탠드 업 미팅을 사용하지 않기 때문에 팀이 제대로 작동하지 않습니다.

내가 본 두 가지 환경에서, 팀이 반복 약속을 이행 할 책임을 위임하지 않은 스크럼 마스터가 있었기 때문입니다. 어떤 경우에는 특히 반 생산적이며 팀 내에서 US / Them 태도를 생성했습니다.

스크럼 (Scrum)은 자체 구성 팀에 관한 것으로, 팀은 문제를 신속하게 해결하여 약속을 이행하기 위해 스스로 조직합니다.

모든 애자일 프로세스와 마찬가지로이 목적은 "가치가있는 것"입니다.

일일 스탠드 업은 일반적으로 팀 구성원 간의 의사 소통을 저해하는 방식으로 모든 팀이 현재 작업 세트와 관련하여 팀의 위치를 ​​이해할 수있는 메커니즘입니다. 따라서 모든 사람들이 "어제 x를하고 오늘은하기로하겠습니다"라고 말하는 5 분 스탠드 업은 괜찮습니다. 팀이 다음 작업을 결정하고 작업 보드를 업데이트하는 15 분입니다.

그러나 예를 들어 롤링 소셜 알림 시스템을 사용하는 등 다른 방식으로 이러한 내용을 전달하지 않는 한 전혀 필요하지 않습니다.

마찬가지로, 스탠드 업이 더 길고 더 많은 팀보고를 원한다면 그것도 괜찮습니다. 나는 그것에 의문을 제기 할 것이지만, 일부 팀은 작업을받는 데보다 직접적인 접근 방식을 선호한다는 것을 알고 있습니다. 애자일은 결국 모든 유형의 팀에 대처할 수 있습니다.

당신이 물어봐야 할 실제 질문은 당신이 그것으로부터 가치를 얻고 있는지 여부이며, 그렇지 않다면 가치를 얻기 위해 무엇을 바꿀 것입니까? 성스러운 스크럼 서에 규정 된대로 스탠드 업을하는 것은 민첩하지 않습니다. 팀원들에게 의미있는 의미의 스탠드 업을하는 것은 모두 더 잘 협력하는 것입니다.