"너무 많은"디자인을 수행하지 않고 Sprint Planning 동안 유효한 시간 추정치를 어떻게 제공합니까?

우리 팀은 Scrum에 익숙해 져 있지만 대부분의 사람들은 민첩하지 않은 "의사"민첩한 방법론에 더 익숙합니다. 우리에게 가장 큰 장애물은 백 로그 항목을 작업으로 나누고 시간을 추정하는 효율적인 스프린트 계획 회의를 운영하는 것입니다. (VS2010 스크럼 템플릿의 용어를 사용하고 있습니다. 어딘가에 잘못된 단어를 사용하면 사과드립니다.)

작업 시간이 얼마나 걸리는지 파악하려고 할 때 코드 레이아웃 (테이블 레이아웃, 인터페이스 등)에서 기능을 디자인하는 데 걸리는 시간을 파악하기 위해 종종 .

나는 이것이 이런 종류의 디자인을하기에 적절한 장소가 아니라고 확신합니다. 스프린트 동안 이러한 디자인 회의를위한 작업을 예약해야합니다. 그러나 우리는 작업에 대한 의미있는 견적을 도출하는 방법을 알아내는 데 어려움을 겪고 있습니다.

실용적인 습관 / 기술 등이 있습니까? 기능을 구현할 계획을 모른 채 기능 소요 시간에 대한 판단 요청을 한 적이 있습니까? 설계가 완료된 후 시간 추정치가 크게 변경 될 경우 어떻게 미리 Sprint 백 로그의 예산을 적절하게 조정할 수 있습니까?

편집하다:

명확히하기 위해 일부 의견 / 답변이 매우 유효하지만 잘못된 질문을 처리한다고 생각합니다.

우리는 우리가하고있는 일이 옳지 않다는 것을 알고 있으며,이 디자인의 스프린트에 시간을 투자해야한다는 것을 알고 있습니다. 개념적으로 모든 개발자는이를 이해합니다. 또한 잡초로 나가기 시작하면 스크럼 경험이있는 팀원을 데려와 추적 할 수 있습니다.

문제는 이 설계 프로세스를 거치지 않으면서도 구체적인 시간 추정치를 제공하기가 어렵다는 것입니다. "우리가 이런 식으로 디자인하면 8 시간이 걸리지 만, 다른 방법으로 끝내야한다면 약 32 시간이 걸리지 만, 쓰기를 시작하면 나쁘지 않을 것입니다. ... ".

또한 작업 속도가 빨라지면이 프로세스가 더 좋아질 것이라고 가정하지만, 우리가 사용하는 많은 기술과 건축 패턴은 우리에게 새로운 것입니다. 그러나 잠재적으로 매우 잘못된 추정치 가이 과정을 적응시키는 데 자연스러운 부분이라면 다음과 같이 받아 들일 수 있습니다. :)

1. 이러한 디자인 토론이있는 반복적 인 "손질"미팅을 예약하십시오. 내가있는 팀은 계획 전날 스프린트 당 한 번씩 있습니다. 그 목표는 팀이 전체 스토리의 시간 추정에 동의 할 수 있도록 디자인을 충분히 정리하는 것입니다. 이 회의에서 작업 분류를 고려하여 계획을 세우는 것이 얼마나 많은 양을 선택해야하는지 연습 할 수 있습니다. 다시 말해 실제 작업을 시작하기 전에 스프린트에서 디자인을 수행해야합니다.

2. 사용을 고려 계획 포커 작업을 추정하기 위해, 즉 점 "노력"의 / 단위가 아닌 사람이 일을. 또한 가능한 한 많은 이야기를 나누십시오. 이야기가 길거나 복잡할수록 추정치의 정확성이 떨어집니다.

3. 계획에서 스크럼 마스터는 "해결"에 너무 많은 논의를 중단함으로써 계획을 제대로 진행해야합니다. 이 시점에서 팀 구성원은 추정치에 대해 신속하게 합의해야하며 일반적으로 상한 / 최악의 사례 번호를 제공합니다. 계획보다 시간이 오래 걸리고 스토리가 여러 스프린트로 롤오버되어 스케줄이 미끄러지는 것을 처리하는 것보다 계획보다 태스크가 더 쉬운 경우 더 많은 작업을 선택하는 것이 훨씬 쉽습니다.

4. 스프린트의 끝에서 회고에서 추정치가 어떻게 전개되었는지에 대해 이야기하십시오. 특히 현저하게 떨어져있는 것이 있다면. 팀은 이야기가 진행된 방식과 예상했던 방식에서 무엇을 배웠습니까? 스크럼 마스터는 설계 / 추정 프로세스에서 수행 할 수있는 실행 가능한 변경에 계속 집중해야합니다.

문제는 당신이 시간을 추정하려고한다는 것입니다. 하지마

복잡성을 추정하십시오. 요구 사항 (필요하면 사용자 스토리)을보고 팀이 다른 요구 사항이나 사용자 스토리가 얼마나 복잡한 지에 비해이를 빌드하고 테스트하는 방법을 파악하는 것이 얼마나 복잡하다고 생각하는지 평가하십시오. 때때로 당신은 틀릴 지 모르지만, 종종 무언가가 어려울 것이라는 좋은 아이디어를 얻게 될 것입니다. 또한 복잡도가 비슷한 항목은 완료하는 데 동일한 노력을 기울이는 경향이 있습니다.

따라서 복잡도 순위는 제품 백 로그의 사용자 스토리와 관련된 "스토리 포인트"가됩니다. 스프린트 몇 개를 수행 한 후 스프린트에서 몇 개의 스토리 포인트를 통과 할 수 있는지에 대한 아이디어를 얻을 수 있습니다. 이 시점에서 각 항목의 소요 시간을 훨씬 더 잘 알 수 있습니다.

Mike Cohn의 User Stories Applied를 적극 권장 합니다.

귀하의 질문은 특히 계획에서 디자인을 피하는 것에 관한 것임을 알고 있습니다. 그러나 이것은 일종의 XY 문제 입니다.

나는 당신이 있었던 곳입니다. 점진적 개선을 제공 할 수있는 무언가를 제공하는 대신 이러한 중간 상태를 뛰어 넘는 데 도움을 드리고자합니다.

다음은 우리 팀이 작업 계획 및 실행과 관련하여 구체적으로 수행하는 세 가지 사항입니다. 이를 통해 설계 스 래싱을 피하고 부정확 한 시간 견적을 피할 수있었습니다.

자동 수락 기준

우리의 이야기는 그들의 자동 수락 기준 의 수에 의해 지적됩니다 . 즉, 스토리가 완료되었음을 확인하기 위해 자동화 된 테스트를 작성하면 어떻게 될까요?

예를 들어 "사용자가 iOS 6 이상을 실행하는 iPad에서 '재생'을 클릭하면 비디오가 재생되기 시작합니다." 실제로이 테스트를 자동화하는 것은 어려울 수 있지만 이야기의 수용 기준 (AC)이며 한 가지 점에 영향을줍니다.

피보나치 스케일을 사용하며 항상 반올림합니다. 따라서 스토리에 자동 수락 기준이 4 개있는 경우 5 포인트 스토리입니다.

우리의 최대 스토리 포인트 크기는 8 포인트이지만 거의 없습니다. 스토리에 자동화 가능한 수락 기준이 5 개 이상인 경우이를 분리 할 수있는 방법을 찾습니다.

손질

월요일에 시작 회의가 있지만 손질 회의는 팀 계획이 이루어지는 곳입니다. 정리하기 전에 팀 구성원은 결과를 설명하고 자동 수락 기준을 찔러 이야기를 미리 정리 합니다.

정리는 팀의 전문 지식을 통해 사전 정리 된 스토리에 대해 설명하고, 지정되지 않은 요구 사항을 정리하고, 스토리를 정리하는 등의 작업을 수행합니다.

우리는 때때로 승인 기준 외에 작업을 나열하지만,이 시간은 추정되지 않습니다. 우리는 시간을 추정하지 않습니다. 작업은 기준을 지원하기 위해 수행해야하는 작업에 대한 진술 일뿐입니다.

진행중인 작업 제한

전통적인 스크럼 은 작업 시간 을 스프린트 기간 으로 제한하려고 시도합니다 . 우리는 이것이 인위적으로 스프린트 마감일을 맞추기 위해 서두르고 스프린트가 금요일에 끝나기 때문에 주말을 죽이는 것을 발견했습니다.

또 다른 방법은 주어진 시간 에 진행중인 작업 을 제한하는 것입니다 . 우리는 후자로 이주했으며 훨씬 더 행복했습니다.

스토리가 백 로그에서 진행중인 작업으로 이동하면 여러 상태 중 하나 인 것으로 특성화됩니다.

• 보류 중-팀 외부 활동을 기다리고 있기 때문에 팀 작업을 수행 할 수 없습니다.
• 개발 중-승인 기준을 달성하기 위해 노력
• 테스트 필요-우리는 AC를 만났으며 다른 사람의 검증을 기다립니다.
• 테스트에서-이야기는 AC에 대해 평가되고, 버그는 해결됩니다.
• 배포 준비 완료-다음 번에 기회가 생겼습니다.

그런 다음 각 주에있는 스토리 수를 사용하여 팀의 초점을 맞 춥니 다. 예를 들어, 개발자가 새로운 이야기를들을 수 있지만 Test에 많은 이야기가있는 경우 기존 이야기를 도와주는 것이 좋습니다.

먼저, 그러한 상황에서는 정확한 추정이 불가능하다는 것을 인식하십시오. 잘못되면 스트레스를받지 마십시오. 그러나 계획을 세우기 위해서는 여전히 대략적인 아이디어 가 필요하며 완전한 불확실성을 설명하는 유일한 방법은 추정치에 더 많은 스토리 포인트를 추가하는 것입니다. 5 또는 13인지 모르는 경우 13을 사용하십시오.

스토리를 최대한 작게 나누는 것도 도움이됩니다. 우리는 종종 기능을 수행하는 방법에 대한 더 나은 아이디어를 얻기 위해 충분한 노력을 기울일 목적으로 연구 / 디자인 이야기를하고 기능 이야기 자체가 후속 스프린트로 진행됩니다. 왜 이것이 효과가 있는지 생각하십시오. 어떤 일이 어려울 지 모를지라도 보통 과거 경험에서 발견하는 데 시간이 얼마나 걸릴지 상당히 정확하게 알고 있습니다.

여기서 할 수있는 일이 두 가지 있습니다.

먼저 토론을 모니터하고 "이봐, 다시 디자인하고있다"고 말하는 스크럼 마스터가 있습니다. 생각보다 어려워서 사람들을 매일 매일 로테이션하고 처음에는 누구나 스크럼 마스터가되어 누구나 파이프 라인을 만들 수 있습니다.

둘째, 스프린트 계획 중에 디자인하는 경우 작업 기간 동안 전화를 걸 수있을만큼 충분히 알지 못하거나 더 재미있어서 디자인하고 있는지 여부를 구분할 수 있어야합니다.

다시 한 번 스크럼 마스터는 여기서 시작하여 일정을 잡을만큼 충분히 알 때까지 항목을 다시 보류 시키거나 디자인을 중단하고 원래 질문에 응답하도록하는 데 시간이 얼마나 걸리는지 알려야합니다.

따라서 스프린트 계획을 수행하는 경우 비즈니스 스폰서를 통해 백 로그를 검토하고 먼저보고 싶은 항목의 우선 순위를 정하는 것이 좋습니다. 그렇게하면 세션이 진행되는 동안 디자인이 어렵다는 것을 알게 될 것입니다. 왜냐하면 그들은 불안해하고 결국오고 싶지 않기 때문입니다.

우리는 스프린트 계획 중에 이야기 '감기'를 추정하는 것에 기초하여 약간의 토론을하면서 운영해 왔습니다. 합리적으로 좁은 초점을 가진 팀을 구성 했음에도 불구하고 추정치는 실제로 매우 부정확합니다. 주로 실제로 발생해야 할 일에 대한 모든 아이디어와 실제에 대해 전혀 알지 못하는 많은 문서화되지 않은 주석 처리되지 않은 레거시 코드가 존재하기 때문입니다. 원본이 작성된 이후 크게 변경된 직원.

우리가 지금 시도하는 것은 각 이야기를 조사하는 계획을 세우기 전에 시간을 보내는 것입니다. 여기서는 오직 한 명의 개발자 만이 하나의 이야기를 조사 할 것입니다 ... 우리는 이것이 조사한 개발자가 다음에 대한 명확한 설명과 통찰력을 제공 할 수 있기를 희망합니다. 추정을 도와주세요. 지금까지 이것은 시도 된 경우에 도움이되었습니다.

나는 추가 조사가 실제로 비용을 정당화하기에 충분히 정확한 추정치를 만든다는 것을 확신하지는 못했지만 몇 가지 스프린트를 위해 시도 할 것입니다.