스크럼 팀이 스프린트 약속을 얼마나 자주 충족시켜야합니까? [닫은]

10

약속은 약속이며, 우리 모두는 약속을 지킬 필요가 있다고 배웠습니다. 그러나 각 스프린트에 대한 헌신을 유지하는 것이 현실적입니까? 때로는 사람들이 아플 때도 있고 기술적 인 접근 방식이 틀린 것으로 판명되고 때로는 제품 소유자 또는 사용자와의 추가 토론 중에 기능이 원래 생각했던 것과 매우 달라야한다는 것을 이해하는 경우가 있습니다.

공식 스크럼 가이드는 이제 이러한 문제를 해결하기 위해 노력보다는 "예측"이라는 단어를 사용한다는 것을 알고 있습니다.

따라서 제 질문은 조직의 팀이 얼마나 자주 노력을 기울이고 있는지, 그리고이 접근 방식을 좋아하는지 또는 변경하고 싶은지입니다.

감사합니다.

scrum

— 유진
소스

meta.programmers.stackexchange.com/questions/6483/…

— gnat

1

내가 자주 궁금했던 질문과 두 가지 좋은 답변

— matt freake

1

당신이 경우 항상 당신의 약속을 충족, 당신은 아마 공격적인 충분히되지 않습니다. 스크럼의 목표 중 일부는 특정 작업이 실제 세계에서 소요되는 시간을 추정하는 데 모든 사람의 기술을 향상시키는 것이므로 시간이 지남에 따라 정확성이 향상 될 것입니다.

— keshlam

1

@keshlam 반드시 그럴 필요는 없습니다. 민첩한 운동에는 온전한 유독 한 본성을 인식하면서 전통적인 추정치를 지나서 적극적으로 움직이려고하는 온통 생각의 학교가 있습니다.

— Stefan Billiet

1

물론 @StefanBilliet ... 그러나 Scrum은 외부 세계가 우려하는 한 추정치를 동시에 스트레스 해소하려고했지만 팀이 언제 추가 작업을 수행 할 수 있을지에 대한 팀의 내부 감각을 향상시켰다.

— keshlam

21

팀이 얼마나 자주 약속을 지켜야하는지에 대한 질문은 아닙니다.
팀이 왜 약속을 충족시키는 데 문제가 있는지 조사하는 것이 더 중요합니다.

경건한 개입이라면 그것은 중요하지 않습니다. 그러나 기술적 인 접근 방식이 잘못되었거나 PO가 계속 마음을 바꾸거나 스프린트를 시작할 때 이야기가 명확하지 않기 때문에 드로잉 보드로 자주 돌아와야한다는 것을 알게되면 이유를 조사해야합니다.

스프린트 약속을 지키지 않는 것은 증상입니다. 근본 원인에 관심이 있어야합니다.

— 스테판 빌리 엣
소스

우리는 99.99 %의 사례에서 헌신을 달성하기 위해 노력해야합니까? 그것이 약속을 이행 할 것이라는 확신의 수준이라면, 우리는 보통 우리가 생산할 수있는 평균 작업의 절반 만 약속합니다. 그래서 나는 99.99 %가 아니라고 생각합니다. 그래서 무엇입니까? 50 ~ 70 %? 80 ~ 90 %?

— 유진

@Eugene 왜 숫자가 필요하고 누가 안심해야합니까? 스프린트 목표를 달성하지 못한 경우 당신을 처벌 할 사람이 있다는 생각이

— Stefan Billiet

전혀. 사실 내 조직에서는 아무도 약속을 이행했는지 여부를 신경 쓰지 않습니다. 현재 버그를 수정하고 테스트를 작성할 시간이 없기 때문에 테스트를 작성하지 않기 때문에 변경하려고합니다. 팀원들에게 정기적으로 약속을 이행 할 수 있도록 적은 노력을 기울 이도록 조언하고 싶습니다. 그러나 얼마나 덜? 헌신을 충족시키는 것이 삶이나 죽음의 문제라면, 외부의 어느 누구도 의지하지 않을 것이라고 예측 한 것보다 적은 노력을 기울일 것입니다.

— 유진

2

그 소리에 따르면 더 근본적인 문제가 있습니다. '완료'된 스토리 수에 대한 성능을 측정하려면 먼저 '완료'에 대한 팀 이해가 필요합니다.

— Michael Shaw

13

모든 것이 잘되면 팀이 스크럼 약속을 충족시키는 것이 정상적인 것입니다. 그들은 즉각적이고 자동으로 스프린트 약속을 이행하지 못하는 소규모의 합리적이고 일과 질병, 육아 응급 상황 등과 같은 장애에 대처할 수있을 정도로 시원하게 운영되어야합니다. 그것이 내 관점에서 볼 수 없다면 스프린트는 커밋되어 팀으로서 장기적으로 좋은 결과를 얻기에는 너무 뜨겁습니다.

스프린트가 지속적으로 전달에 실패하면 스크럼은 '문제'를 보이도록 약속 한 결과를 전달했습니다. 문제에는 제대로 정의 된 작업이 없거나 팀의 경험이 부족하거나 지속적으로 초과 배송을 시도하는 경영 문화가 포함되어 지속적으로 부족할 수 있습니다.

어느 쪽이든, 해결책은 개발자를 더 강하게 휘두르지 않고 근본 원인을 식별하고 해결하는 것입니다.

약속을 지키기 위해 항상 '가까운'팀은 더 심각한 방식으로 실패하고 있습니다. 충분한 테스트를 수행하고 있지 않은지 확인할 수 있습니다.

— 마이클 쇼
소스

4

나는 개인적으로 조직의 어느 누구도 당신의 약속을 지키는 것에 관심이 없다면, 당신은 약속에 대해 이야기하고 있지 않다고 믿습니다. 거래를하고 약속을하려면 두 명의 파트너가 필요합니다.

스프린트 커밋은 모든 "정상 변형"을 고려하여 유지할 수있는 것입니다. 기본 변형의 의미에 대해 더 자세히 알고 싶다면 민첩한 계획의 기본 사항에 대한 내 블로그 게시물을 읽을 수 있습니다 . 그리고 스테판이 언급 한 바와 같이 , 당신의 약속을 충족하지 못하는 것은 증상이 아닌 질병이다.

모든 스프린트 후에는 스프린트의 실제 속도를 검사하고 "평균 속도"를 그에 맞게 조정할 수 있습니다 ( 위에서 언급 한 게시물 에서 설명 ). 스프린트 후 속도가 계속 내려 가면 스프린트 후, 실제 근본 원인을 감지하는 데 도움이되는 패턴이 나타납니다. 계획되지 않은 작업이 너무 많을 수 있습니다 (예 : 소규모 긴급 작업, 작업중인 코드의 버그, 스프린트 중 승인 기준 변경 등). 이 데이터는 스크럼 마스터가 추적하여 어떤 패턴이 있는지 파악하는 데 도움이됩니다. 이를 통해 회고 중에 팀이 조치를 취할 수 있습니다.

— 탈붐
소스

2

저의 관점은 팀이 약속을하지 않는다는 것입니다. 그들은 예측조차하지 못하고 있습니다. 스프린트가 계획되기 전에 예측이 이루어집니다. 예측은 평균적으로 속도를 달성 할 것입니다. 즉, 때로는 속도보다 몇 점 더 많은 포인트를 수행하고 때로는 더 적게 수행합니다.

당신이 정기적으로 속도보다 적게하고 있다면, 그것을 반영하기 위해 속도가 떨어집니다. 따라서 예측도 떨어집니다. 스프린트 후에 스프린트를 할 수 있다고 말하는 것보다 과거 속도보다 더 많은 이야기를 계속한다면 실행 실패가 아니라 계획 실패입니다. 당신은 당신의 속도를 알고 있으므로, 당신이 달성 할 수있는 역사보다 더 많은 포인트를 가져 오지 말아야합니다.

스크럼을 사용한 세 조직 중 특정 질문에 대답하기 위해 시간이 지남에 따라 "커밋 누락"메트릭을 추적 한 사람은 한 명뿐입니다. 해당 회사의 팀은 일반적으로 시간의 약 85 %를 예측했습니다.

— 브라이언 오클리
소스

동의하다. 나는 스프린트 계획이 끝날 때마다 스프린트에 대한 모든 이야기를 완료하겠다는 약속을 요구 한 한 팀에있었습니다. 나는 "예"라고 말하는 습관에 빠져 계속 민첩했습니다. 아마 그렇게 느끼게 될 것 같아요.

— Rob

1

@RobY : 성숙한 팀에 헌신 할 여지가 있다고 생각합니다. 내 경험상 대부분의 민첩한 팀은 특별히 성숙하지 않았으며 약속을 요구하는 PO는 좋은 PO가 아닙니다. 나는 속도가 매우 완고한 한 팀에 있었고 필요할 때 실제 약속을하는 것이 매우 편안하다고 느꼈지만 다른 팀은 성숙하지 못했습니다.

— Bryan Oakley

나는 약간 퉁인 뺨을하고 있었다. 나는 일반적으로 당신이 저지를 수있는 핵심 이야기가 있지만, 속도에 가까워 질수록 다소 확실하지 않다는 데 동의합니다. 속도는 평균이므로 정의에 따라 때로는 끝날 때가 있습니다. BTW 같은 관리자가 배와 함께 우리를로드하거나 우리의 속도마다 3 배 다음 약속을 요구하는 것 ... 그래서 ...) (나는 주로 내가) 정말 잘 국가에게 그것을 생각하는 당신의 첫 번째 단락에 반응 한

— 롭

2

약속을 지키지 않으면 속도를 줄여야합니다. 항상 만나는 경우 때때로 실패 할 때까지 늘려야합니다.

문제는 얼마나 심각하게 실패 하는가입니다. 항상 가까워 야합니다. 약간 느슨하게하거나 조금만 실패해도됩니다. 즉, 건강 목표 어떤 분야, 실행 시간, 역도 등 당신의 속도 주위 정규 분포이어야한다 스프린트에서 수행 작업의 이상적 평균 시간입니다.

더 중요한 것은 속도의 장기 추세입니다. 매주 속도에 15 스토리 포인트를 추가하지만 이전 주에했던 것보다 10 개만 달성하면 실제로 나쁜 것입니까? 어떤 곳에서는이 "스트레치 목표"를 고려합니다.

— 썰매
소스

나는이 답변에 정말로 동의하지 않는다. 인간의 본성은 전달을 시도하는 것이며, 팀이 이야기를 포기하지 않고 전달하기 위해 '테스트'를 줄이겠다는 최저 금액을 베팅 할 수 있습니다. 당신이 항상 라인 가까이에 있다면, 당신은 철저히 테스트하지 않을 것이고, 다시 물릴 것입니다.

— Michael Shaw

징계, 전문적 자부심 및 확실한 " 완료된 정의 "가 필요한 @Ptolemy . 그것들은 당신이 똥을 운송하지 못하게해야합니다. 또한 모서리를 자른 경우 수행 한 것으로 계산해서는 안됩니다.

— Sled

스크럼의 테스트 부분보다 개발자 부분이 훨씬 명확합니다. 테스터가 핵심 기능을 테스트하는 데 초점을 맞추고 버그를 노출시키는 '임의의 이벤트'에 대한 시간이 없었기 때문에 알려진 결함이 없습니다.

— Michael Shaw

2

@Ptolemy : 테스트는 이야기의 일부이기 때문에 팀은 기술적으로 "컷 테스트"를 수행 할 수 없습니다. 그들이 자르면 코딩의 일부를 자르는 것과 다르지 않습니다. 코딩 된 기능의 일부를 생략하면 스토리를 완성하고 있습니까? 마찬가지로 테스트를 중단하면 스토리가 완료되지 않습니다.

— Bryan Oakley

나는 스크럼을 사용한 적이 없지만 약속을 해왔으며 일이 끝났는지 판단했습니다. 완료의 정의가 전적으로 객관적 이라면 , 즉 그룹이 약속을 충족시키기 위해 수행되어야하는지 여부에 비추어 정의를 해석 할 여지가 없다면 좋을 것이다 . 자연어가 무엇인지, 이것은 비현실적으로 보입니다. 약속에 대해 상당히 편안하고 객관적인 정의에 상당히 가깝다면 이것은 문제가되지 않습니다. 프톨레마이오스가 "인간의 본성이 전달하려고 노력하는 것"이라고 말하면, 나의 스키마에서 "사람들은 그 약속에 대해 충분하지 않다"는 것을 의미합니다.

— Steve Jessop 2016 년