나는 스프린트 계획에서 일주일 동안의 스프린트를 위해 5 시간 이상 걸렸다. 너무 많은 것 같습니다.

우리는 대부분의 팀원이 선임하지 않기 때문에 스프린트 계획에서 세부 사항을 논의합니다. 그렇지 않으면 구현하는 동안 실수가 발생하고 스프린트 동안 다시 디자인됩니다.

우리는 이것을 어떻게 처리합니까?

일주일에 2 시간 정도만 걸기 위해 계획하는 동안 얼마나 자세하게 논의해야합니까?

1 주일 동안 스프린트 계획에서 5 시간 스프린트는 오랜 시간이 걸린 것 같습니다. 스크럼 가이드는 스프린트 계획을 1 개월 스프린트에 대해 8 시간으로 타임 박스하고 "스프린트가 짧을수록 이벤트는 일반적으로 짧습니다"라고 말합니다. 비율을 고려하면 1 주 스프린트 동안 2 시간의 스프린트 계획이 좋은 목표 일 수 있지만 고정 된 타임 박스는 없습니다.

그렇다면 긴 스프린트 계획을 어떻게 해결할 수 있습니까?

스크럼 마스터로서 다음 단계를 수행합니다.

먼저 제품 소유자와 협력하여 제품 백 로그가 제대로 주문되었는지 확인합니다. Scrum 팀이 올바른 작업을 정의, 개선 및 준비하는 데 에너지를 집중할 수 있도록 가장 중요한 작업 및 종속성이 제품 백 로그의 맨 위에 오도록하려면 백 로그 개선 및 스프린트 계획을 효과적으로 수행하는 것이 필수적입니다.

둘째, 팀이 백 로그 개선에 충분한 시간을 보내고 있는지 확인합니다. 스크럼 안내서에 따르면 개선 활동은 일반적으로 개발 팀 역량의 10 %를 넘지 않습니다. 예를 들어, 표준 40 시간을 일하는 4 명의 개발 팀은 약 16 시간의 백 로그 개선을 계획해야합니다. 이것은 개별적으로, 소그룹으로 또는 팀으로 수행 될 수 있습니다. 팀에 대한 백 로그 개선 세션을 계획 한 다음 조사, 조사 또는 계획을 수행하는 것이 가장 효과적이라는 것을 알았습니다.

셋째, 팀이 스프린트 계획에서 모든 세부 사항을 알 필요는 없음을 인식해야합니다. 스프린트 계획의 목표는 스프린트 목표를 달성하기위한 계획을 세우는 것입니다. Sprint Planning 세션에서 큰 디자인을 미리 시도하지 마십시오. Sprint Planning 세션 이외의 다른 작업에 대한 의존성, 종속성 및 목표 및 사용 시간을 이해하고 올바른 사람들과 함께 작업을 전달하는 데 필요한 설계, 구현 및 테스트를 수행하십시오.

더 많은 단계가이 단계에서 벗어날 수 있지만 이것은 좋은 출발점이 될 것입니다.

들었어요 너무 길다! 바라건대, 당신의 팀은 회고에서 이것을 논의하고 있습니다. 우리는 혼합 된 결과로 몇 가지 실험을 시도했습니다.

1. 모든 사람이 단일 티켓에서 고급 설계를 수행하고 수정을 위해 테이블 ​​주위에 왼쪽 또는 오른쪽으로 전달한 다음 각 티켓에 대한 계획을 그룹 검토합니다. 모두가 이것을 좋아하지는 않았지만, 그것은 우리 후배들에게 시도해 보도록 강요했습니다. 팀원 중 일부는 다른 사람들이 생각을하도록 지시하고 지시를 따르기 만하면 매우 행복합니다. 따라서 우리의 실험은 모든 사람들이 그들의 지식 격차에 맞서도록 강요하여 후배들에게 성장에 대한 도전을 제공했습니다. 부정적인 측면에서 모든 사람이 현장에 배치되는 것을 좋아하는 것은 아니며 회의 시간을 반드시 단축시킬 필요는 없습니다. 다음!

2. 페어링 된 디자인이 시도되었습니다. 2 ~ 3 명의 그룹은 티켓을 작업으로 분류합니다. 팀 전체가 결과 계획을 검토 할 것입니다. 속도는 훨씬 빨랐지만 일부 미니 포드에는 한 사람이 타는 것과 같은 문제가 있었고 다른 한 사람은 디자인 작업을 수행했습니다.

3. 작업 분석을 건너 뜁니다. 우리는 우리의 이야기 포인트가 평균화되었다고 결정했기 때문에 모든 팀에 모든 것을 참여 시키려고 노력하는 데 시간을 낭비했습니다. 그 결과 계획 회의가 훨씬 단축되었지만 디자인 작업은 티켓을 시작할 때 우리 쌍이해야 할 일이었습니다. 후배가 티켓을 가지고 있다면,이 단계를 지나는 데 도움이 필요할 것으로 기대하십시오. 이것을 시도하면, 스프린트에서 편안하게 될 때까지 더 적은 이야기를 받아 들였다. 또한, 팀원이 무언가를 모르는 경우 도움을 요청하는 것이 "안전"한지 확인하십시오.

결국, 그것은 팀 성숙에 달려 있습니다. 사람들은 서로의 능력과 선호도를 이해하고 팀원들이 필요할 때 의견을 요청할 것이라는 확신을 가져야합니다. 없는 경우 먼저 수정하십시오. 그러면 비효율적 인 회의 문제를 해결하는 것이 더 쉬워집니다.

@ Thomas-Owens에서받은 답변을 좋아하지만 항목을 하나 더 추가 할 것입니다. 애자일 구현의 일부로 페어 프로그래밍을 고려해 보셨습니까?

페어 프로그래밍은 (1) 일부 주니어 프로그래머에게 더 나은 코드를 작성하는 방법을 가르치고 (2) 페어 프로그래밍을하는 데 도움이되므로 스프린트 계획에 항상 모든 단일 디자인 기능을 배치 할 필요는 없습니다. 페어가 함께 작동하면 추가 된 페어 프로그래밍 이점으로 일부 설계 결정을 "자발적으로"만들 수 있습니다.

주니어 프로그래머가 더 빨리 배우도록 도울 수 있고 Sprint Planning에서 다루지 않은 디자인 항목이 두 사람에 의해 결정될 것임을 알고 있다면, 지출 시간을 줄일 수없는 이유가 없습니다 미래 스프린트 계획

나는 스크럼 애호가가 아니며 대략 1 년의 실제 경험이 있습니다. 따라서 다음은 소금 한알로 읽습니다.

나는 당신이 쓰는 것에 몇 가지 붉은 깃발을 보았습니다.

스프린트 계획 5 시간

일주일 스프린트를하기에는 너무 길다.

스프린트 계획의 목표는 AFAIR입니다

• 팀이 현재 우선 순위를 알고
• 다가오는 스프린트를위한 전투 계획을 개발합니다.

이 작업을 효과적으로 수행하려면 각 측면에서를 이해해야합니다 Product Backlog items.

Product Backlog items백 로그 를 이해하려면 모양이 양호해야합니다.

구체적인 계획 단계에서는 Product Backlog items로 변환됩니다 Sprint Backlog items.

가능한 원인 중 하나는 이러한 항목이 충분히 명확하지 않고 정제되지 않았기 때문입니다.

또 다른 가능한 원인은 항목이 너무 복잡하고 해석이 너무 많기 때문입니다.

스프린트 계획에서 매우 상세하게 논의

위에서 언급했듯이, 항목이 더 구체적 일 때 토론 단계가 더 짧아집니다.

반면 스프린트 계획은 모든 참가자의 전문적인 행동을 기대합니다. 여기에는 자전거 흘림 토론을 피하는 것이 포함됩니다 .

아마도 상황은 분명하지만 누군가 자전거 세상 토론을 시작합니다 .

자세히 : 구현 세부 사항 에 대한 논의를 피 하십시오 . 모든 아이디어는 특정 시점에 코드로 끝나지 만 간단한 배열이 트릭을 수행하는지 여부 또는 링크 된 목록을 사용하는 것이 더 나은지 여부는 스프린트 계획의 요점이 아닙니다.

대부분의 팀원은 선임자가 아니므로

스크럼에서 선배 와 후배 는 구별되지 않습니다 . 둘 다 개발자 일뿐입니다. 그리고 이것은 좋은 출발점이며, 당신의 토론이 월급이 아닌 더 나은 논증에 의해 뒷받침되는 실행 가능한 솔루션에 집중하는 데 도움이됩니다.

스프린트 동안 구현 및 재 설계의 실수

요구 사항 수집에 근본적인 문제가있는 것으로 보이며 매우 모호한 제품 백 로그가 뒤 따릅니다.

위에서 말했듯이 : Product Backlog모양이 좋으면 요점을 놓치기가 어렵습니다.

나는 다음과 같은 상황을 상상할 수 없다 :

»사용자로서 소수의 고객을보고 싶습니다!«

»오, 200 만 명의 고객을 모두 의미하지는 않았 습니까?«

OTOH :이 맥락에서 재 설계 는 무엇을 의미합니까? 개발자가 느리게 수행하는 알고리즘을 선택한 경우 다음 목표는 분명합니다. 더 나은 수행 알고리즘을 선택하십시오. 그러나 이것은 "재 설계"가 아니라 최적화입니다.

주요 질문에 :

이것을 다루는 방법?

언급하는 것은 사소한 일이지만 어쨌든 그렇게합니다. 여러분이 인간을 다루고 있다는 것을 잊지 마십시오 .

Rashomon 과 같은 공통 개념을 공유 할 수있는 서로 다른 마음의 그룹을 갖는 것은 매우 어렵습니다 . 이를 효과적으로 처리하기 위해 가능한 한 많은 의사 소통에 중복성 을 사용하십시오. 모든 사람이 주어진 항목의 주제를 얻는 지 여부에 대해 질문하십시오.

포커를 계획하고 있다면 좋은 지표가 될 수 있습니다. 낮음은 복잡성이 낮다는 것은 이해하기 쉽고 놓치기 어렵다는 것을 의미합니다.

반복의 부작용 중 하나는 팀이 기능과 숨겨진 복잡성을 이해하기 때문에 특정 작업의 수가 증가한다는 것입니다. 그런 다음 항목을 복잡성이 낮은 몇 개의 덜 복잡한 항목으로 나눌 수 있습니다.

일주일에 2 시간 정도 걸을 계획을 세우는 동안 얼마나 자세하게 논의해야합니까?

Salomonic answer : 가능한 한 적게 필요한만큼, 더 많지는 않습니다.

tl; dr

• 오해를 피하기 위해 쉬운 언어를 선택하십시오 ( 간단한 영어 사용 또는 ELI5)

• 요구 사항 수집 개선

• 백 로그 개선

• 팀원의 능력뿐만 아니라 개인의 능력에 대한 팀원의 신뢰도를 높입니다.

• 자전거 타기 피하기

• 개인 규율 향상

• 모든 항목에 대해 고정 된 타임 박스를 사용하여 논의 할 수 있습니다.

• 의 위치를 scrum master효과적으로 조절하십시오.

2 주 스프린트로 총 3 시간의 정리를 수행하여 계획 회의 시간을 크게 단축하는 데 성공했습니다. 그루밍을 4 개의 세션으로 나눕니다. 우리는 월요일에 30 분 손질을하고 매주 수요일에 1 시간 손질을합니다. 스프린트는 월요일에 시작하여 금요일에 끝납니다. 결과적으로 우리는 손질 모임에서 좋은 정보를 얻습니다. 우리의 최고 기록은 스프린트 중 하나에서 30 분 길이의 계획 회의였습니다. 대부분 1 시간에서 1 시간 30 분 이상 걸리지 않습니다. 어쨌든 아직 박스에 넣었지만 계획은 매우 일찍 이루어졌습니다.