각 스프린트 시작시 조기 서브 태스킹

Agile / Scrum을 사용하는 새 팀에 합류했으며 개발 프로세스는 다음과 같습니다.

1) 개발자는 각 스프린트 전에 각 스토리를 검토하여 중요한 것을 놓치지 않도록합니다. 워크 플로에 공식적인 상태가 있습니다.

2) 스프린트 킥오프 동안 전체 팀은 각 스토리에 소요되는 스토리 포인트 수에 대한 추정 (포커 계획)을 수행합니다.

3) 마지막으로, 각 스프린트가 시작된 직후, 각 개발자는 할당 된 모든 스토리를 시간 추정치 (하위 스토리를 시작하기 전에 서브 태스킹이 아닌)를 가진 서브 태스크로 열심히 분류해야합니다.

마지막 단계의 주요 주장은 스토리를 구현하는 데 예상보다 시간이 오래 걸리고 스크럼 마스터에게 스프린트 마감 기한이 누락 될 수있는 잠재적 위험에 대해 경고하는 경우 발견하는 데 도움이된다는 것입니다.

그러나 나는 주로 다음과 같은 이유 때문에이 비생산적인 것을 발견합니다.

• 대략적인 견적을 제공하는 것이 목표라면 스토리 포인트 (2 단계)가 그 역할을합니다. 그렇지 않으면 왜 스토리 포인트를 신경 쓰지 않습니까? -초기에 서브 태스킹을 수행하십시오.
• 목표가 정확한 추정치를 제공하는 것이라면 이것은 휴먼 타스크 스위치가 해로운 것으로 간주 되는 것에 대한 명확한 예입니다 . 이는 무엇을해야하는지 이해하는 데 최대 50 %의 시간이 소요될 수있는 대규모 프로젝트에서 기존 팀에 합류하는 새로운 개발자의 경우에 특히 그렇습니다. 스토리 # 1, 스토리 # 2, # 3 등의 세부 정보를 가져와 많은 정보 이탈을 가져와야합니다.

나는 또한 그러한 관행이 "책에 의해"이루어 졌다는 말을 듣고 있으며, 이것에 대해 논의 할 의도조차 없습니다. 스크럼 성경에 명확하게 정의되어 있거나 추가 통찰력을 제공하는지 여부에 관계없이 누구나 그러한 관행에 대한 참조를 제공 할 수 있습니까?

이것은 스크럼 프로세스 중 일부를 실행하는 방식과 다르지 않습니다. 우리

1. "스토리 포인트"에서 백 로그 상단 부근의 스토리 추정
2. 스프린트를 "구성"할 것으로 생각되는 스토리 포인트를 기반으로 스토리 선택 / 설명
3. 스토리를보다 자세한 기술 작업으로 분류
4. 기술 작업을 예측하고 원래 스토리 포인트 추정치와 비교하십시오 (우리는 스토리 포인트가 일반적으로 동일한 개발 시간을 알고 있음)

그러나 당신이 알고 싶은 것은 우리가 두 번 추정하는 이유입니다!

• 우리가 무엇에 대한 예측을 할 수 있기를 좋아하기 때문에 우리는 (이야기 기준) 거친 추정치를 할 수 에있을 다음 어쩌면 그 이후도 하나 질주하고있다. 궁극적으로 경영진은 가능한 시간 척도에 대해 고객과 의사 소통 할 수 있어야하므로이 대략적인 척도 추정치가 없다면 장기 계획은 사실상 불가능합니다.
• 분명히, 이것은 우리가 현재 스프린트 이상의 것을 위해 대략적인 추정을한다는 것을 의미합니다. 다음 스프린트에 대한 백 로그 주문이 변경되지 않을 것이라는 보장이 없기 때문에 작업 중단과 정밀한 견적이 필요할 때까지 시간을 투자하고 싶지 않습니다.
• 우리는 모든 작업이 열거되고 스토리를보다 쉽게 ​​병렬로 처리 할 수 ​​있도록 작업을 분류합니다.
• 우리는 훨씬 더 부드러운 번 다운 그래프 (특히 큰 이야기를 실행 가능한 "기능"으로 분리하기 쉬운 방법이 없기 때문에)를 제공하기 때문에 정밀한 평가 (작업을 기반으로)를 수행합니다.
• 우리는 두 가지를 모두 수행하기 때문에 서로에 대한 위생 검사 역할을합니다. 야생의 불일치는 식별해야 할 어딘가에 실수가 필요하다는 것을 나타냅니다. 이것은 유용한 부산물이지만 "두 번"을 추정하는 이유 자체는 아닙니다.

귀하의 질문과 의견을 다시 읽어 보니 워크 플로와 귀하의 작업간에 약간의 차이가 있습니다.

• 우리는 팀으로서 고장 을 겪습니다. 오버 헤드가 클지라도 우리가 얻는 기술적 토론은 종종 매우 가치가 있으며 우리 이야기의 단점을 발견 할 수 있습니다. 우리는 경험, 지식 또는 능력의 불일치가있을 때,이 토론은 더 많은 사람들이 더 적은 사람들을 도울 수있는 곳이기도합니다 (신규 채용에 매우 유용함).
• 우리는 팀으로서 작업 수준에서 예측을합니다. "포커 계획"이 작동하는 이유 중 하나는 "군중의 지혜"현상 때문입니다. 주석에서 언급했듯이이 시점에서 작업을 추정하는 데 30 초 미만이 소요됩니다 따라서 오버 헤드는 무시할 수 있습니다.

팀이 작업 분석을 수행하는 이유와 작업 추정이 순조롭게 진행되는 것 같습니다. 스프린트 진행 상황을 모니터링하고 스크럼 마스터가 문제를 조기에 감지하고 해결할 수 있도록하는 것이 좋습니다. 이 정보를 원하는 경우에 당신은 이 고장 및 견적을 할 당신은 이 먼저 할 수 있습니다.

내 의견으로는 작업 전환이 여기에 문제가되지 않을 것이라고 생각합니다. 다른 작업을 분해하는 것이 실제로 하나의 기능 개발에서 다른 부분으로 전환하는 것이 작업 전환과 같은 의미에서 작업 전환이라고 생각하지 않습니다. . 나는 스프린트의 전반적인 "아키텍처"에 대한 이해를 얻는 것이 아마도 매우 유용한 것이라고 생각합니다.

그러나 나는 당신이 고려할 수있는 다른 문제가있을 수 있다고 생각합니다. 항상 당신이해야 애자와 마찬가지로 당신이 가지고있는 문제를 파악 하고 해결책을 제시 한 후 솔루션이 회고전에서 근무 여부를 결정 . 이것이 귀사와 팀에 적합한 민첩한 솔루션을 구축하는 핵심 요소입니다. 따라서 몇 가지 문제 가있을 수 있습니다.

• 개별적으로 고장을 겪고 있습니다. 따라서 주니어 / 익숙하지 않은 팀원들은 상급 팀원들로부터 어떻게 배우고 있습니까? 물론 모든 것을 스스로 배울 수는 있지만 멘토링을 받으면 더 빨리 배울 수 있습니다. 주니어 팀원들이 시간을 내서 문제를 해결하고 있습니까? 팀원들이 장기적으로 실수를하거나 실수를합니까? 팀으로 분류하면 여기에서 도움이 될 수 있습니다.
• 추정을 개별적으로 수행하고 있습니다. 첫 번째 포인트와 동일하게 적용되지만, 추정치보다 정확도가 떨어 집니까?
• 스프린트가 시작될 때 작업이 할당 된 것처럼 들리지만,이 경우 할당을 변경해야 할 때 비용이 얼마나 듭니까? 누군가가 뒤처 지거나 아프면 다른 사람이 자신의 작업을 집어 올리는 것이 얼마나 쉬운가? 그들은 과제 분류를 거쳐 원래의 양수인을 방해하지 않고 이해해야합니까? 팀으로 분류하고 평가하면 모든 사람이 모든 작업을 수행 할 수 있어야합니다!
• 당신의 이야기가 너무 큽니까? 분석 시간이 50 % 정도 걸리면 스토리가 관련이있는 것처럼 들립니다. 아마도 더 작게 만들 수 있습니까? 우리는 일주일 안에 일주일 이내에 이야기를 유지합니다.
• 작업이 너무 작습니까? 작업 목록을 만드는 데 오랜 시간을 보내고 있다면 너무 자세하게 설명하고 있습니까? 하루 1 시간에서 8 시간 사이의 작업을하는 경향이 있으므로 하루 종일 모든 사람이 다음 일일 스탠드 업에서 보고서를 작성하는 데 약간의 진전이 있습니다.

그것이 회사가 개발을 진행하고 토론을 종료하려는 방식이라면, 선택이 제한되거나 최소한 사람들을 화나게 할 위험이 있습니다.

애자일의 궁극적 인 목표는 가치있는 소프트웨어를 사용하는 것이므로 팀이 제공 할 수있는 능력 (제공 / 추정 된 포인트, 스프린트 버그, 테스트 횟수, 코드 적용 범위, 가동 시간, 매출 발생)을 측정하여 도움을 줄 수 있습니다. 도대체 무엇이). 모든 결과에 대비하십시오. 이러한 방식의 작업은 이해가되지 않더라도 효과가있을 수 있습니다. 당신이 옳다면 폐기물은 자명해질 것입니다.

공정을 위해 다음 공정을주의하십시오. 이로 인해 시간이 낭비되고 여전히 불량 제품이 제공됩니다. 좋은 민첩한 팀은 실험, 측정 및 학습합니다. 의견을 내리지 않고 행동을 바꾸는 가장 좋은 방법은 증거에 근거한 결정을하는 것입니다.

이것은 또한 내 의견입니다. 나는 당신이 스스로 시도하고 결과를 측정하는 것이 좋습니다-내가 한 일을보십시오 :)

스프린트 킥오프는 스프린트 계획 회의를 의미한다고 가정합니다. 스크럼 마스터가이 회의가 어떻게 진행되는지 잘못 해석했다고 생각합니다. 개발할 스토리를 결정할뿐만 아니라 팀에서 아무 것도 놓치지 않도록 준비된 정의 (일반적으로 INVEST 사용 )를 테스트하고 해당 스토리를 작업으로 세분화합니다. Mike Cohn (Scrum Alliance의 창립자 중 한 명) 을 인용합니다 .

스프린트 백로 그는 스프린트 계획의 다른 결과물입니다. 스프린트 백로 그는 팀이 제공하기로 한 제품 백 로그 항목의 목록과 해당 제품 백 로그 항목을 전달하는 데 필요한 작업 목록입니다. 스프린트 백 로그의 각 작업도 일반적으로 추정됩니다.

스토리를 분석하고 추정하는 것은 모두 스프린트 계획 세션의 일부입니다. 계획 세션이 끝난 후가 아니라 개별적으로가 아닙니다.

좀 더 통찰력을 제공하기 위해 스프린트 계획 회의에서의 워크 플로는 다음과 같습니다.

1. 우리는 제품 백 로그의 맨 위에서 스토리를 가져 와서 작업으로 나눕니다. 경험상 하나의 작업은 일반적으로 하루보다 작아야합니다.

2. 우리는 공제 된 작업을 고려하여 이야기를 추정합니다. 이야기가 크게 밝혀지면 우리는 이야기를 더 작은 이야기로 나눕니다.

3. 예상 총점에 도달 할 때까지 헹구고 반복하십시오

Cohn의 말과 달리 작업이 하루보다 작게 지정되어 있기 때문에 각 작업을 개별적으로 추정 할 필요가 없다는 것을 알았습니다. 작업이 하루 작업보다 작을 경우 특정 작업을 수행하는 사람이 여전히 작업 중이라고 말하므로 작업이 예상보다 오래 걸리는 경우 Daily Standup 동안 쉽게 알 수 있습니다.

스프린트 동안 팀은 스토리를 진행하며 결국 팀은 실제로 얼마나 많은 일을했는지 ​​반영해야합니다. 이것이 스크럼 회고 회의의 목적입니다. 테이블에 여전히 스토리가있는 경우 추정이 너무 낙관적임을 공제하고 다음 스프린트를 위해 조치를 취할 수 있습니다. 또는 발생한 일 등에 영향을 미치는 특정 사건이있을 수 있습니다. 시간이 지남에 따라 그 추정이 더 나아질 수 있습니다.

"책으로"-문제입니다. 폭포 작업을 할 때보 다 더 많은 과정에서 익사하고 있습니다.

애자일에는 '책'이 없으며 "모든 오버 헤드없이 작업을 수행하십시오"라는 민첩한 선언문 만 있습니다. 따라서 크기를 추정 한 다음 스토리를 다시 추정하기 위해 작업으로 분할하는 경우 이는보다 효율적으로 만들어야하는 무의미한 프로세스 오버 헤드입니다. 이것이 민첩한 것입니다. 스크럼과 다른 모든 것들은 민첩하게 시작하는 방법에 대한 출발점 지침입니다. 그렇게 할 때 이해가되지 않는 부분을 식별하거나 팀이 더 효과적으로 작업하는 데 도움이되지 않도록 변경해야합니다.

그러나 어떤 사람들은 규정 된 작업 방식이 돌로 작성되어야하며 어리석은 일이 있더라도 결코 벗어나지 않을 것이라고 생각합니다. 스크럼 회의 전에 스토리를 작업으로 분할하려고 시도합니다. 개발자가 각 스토리를 검토해야한다고 말하면, 검토의 일부로 동시에 분할을 수행 할 수있는 기회가 있습니다. 그런 다음 스크럼 회의에서 스토리를 구성하는 작업을 선언하고 (시간을 할당하지 마십시오!) 사람들이 포함 된이 추가 정보를 기반으로 스토리가 얼마나 큰 워크 패키지를 결정하게 할 수 있습니까? 정보에 근거한 의사 결정은 추측보다 훨씬 낫습니다. 그리고 의사 결정에 정보를 제공 할 때만 가능합니다.)

회의 후에도 작업에 시간을 할당 할 수 있습니다 (이 시점을 알 수 없지만 스프린트는 시간을 기준으로하지 않으며 스토리 포인트로 측정 된 "원하는 작업량"을 기반으로합니다. 이것은 시간이 아니라 스크럼에서 흔히 발생하는 문제입니다. 포인트는 시간을 의미하지는 않지만 완료해야합니다 (예 : 2 주당 20 포인트, 따라서 2 포인트 = 1 일의 작업). 스프린트에서 너무 많은 작업을 수행하지 않고 과도하게 작업을 수행하지 않고 실제로 수행 할 작업 수가 가장 적습니다. 가장 좋은 스프린트는 몇 가지 작업이 남아있는 것으로, 완벽하게 추정 된 결과를 보여줍니다. 마지막에 완료하는 것을 지연-생산적이지 않습니다).

따라서 애자일 선언문 의 사본 과 민첩한 버전 을 짧게 인쇄하십시오 . 민첩한 것보다 더 많은 일을하고있을 것입니다. 스크럼은 그런 경향이 있습니다. 이를 해결하는 유일한 방법은 팀과 교류하고 변화를위한 구매를 얻는 것입니다. 경영진이 팀의 업무 방식을 알려주지 말고 민첩하지 않으며 책에 쓰여질 것입니다.

각 스프린트 중 특정 시점에 제품 백 로그 개선 회의 가 있어야합니다 . 이 회의에서 제품 백 로그의 상단 부분이 충분히 분류되어 해당 부분의 항목이 다음 스프린트 백 로그에 추가 될 수 있도록합니다.

제품 백 로그 개선이 제대로 관리되면 Sprint Planning Meeting이보다 효율적일 수 있습니다. 이상적으로 는 스프린트가 시작된 후 개발자가 스토리를 "열심히 분류"할 필요가 없게된다 .

현실적으로 추정 하기 위해 충분히 분류 하기 전에 제품 백 로그 항목을 스프린트 백 로그에 추가하면 스프린트에 추가 할 항목에 대한 올바른 결정을 내리기가 어렵습니다.