시간 추정치가 스크럼의 약속과 같습니까?

추정치가 약속이 아니라면 제품 소유자로서 얼마나 오래 걸리는지 모르면서 프로젝트를 전달할 수 있습니까?

예상 시간을 약속으로 처리하면 Scrum 팀이 더 효율적으로 작동합니까?

이야기에서 얼마나 많은 연구 (준비, 문제를 이해하기위한 노력)가 올바른 견적을 도출하기에 충분합니까?

작업을 추정 한 후에 발생하는 예기치 않은 기술 문제 (초기 추정값을 실제로 망칠 수있는 문제)는 어떻습니까?

석재 에는 추정이 새겨 져 있지 않습니다 . 그들은 팀이 과제 / 이야기를 완성하는 데 필요한 노력에 대해 할 수 있는 최선의 추측 입니다.

"나는 참고로 아웃 시간 내 프로젝트를 제공 할 수있는 방법 제품 소유자?으로"귀하의 질문에 대한 대답에서, 대답은 당신이 있다는 것입니다 그리고해야 할 참조 (즉, 당신은 같은 시간이 됩니다 특정 날짜에 출시). 당신이 가지고 있지 않은 것은 배달 될 정확한 범위입니다.

내가 말한 것은 개발을 추진하는 데 사용하는 모든 방법론에 해당합니다. Scrum과 다른 방법론 (예 : Waterfall)의 차이점은 Scrum에서이 사실을 인정하고 설명한다는 것입니다. PO로서 수행 할 작업은 범위의 우선 순위를 정하고 팀이 주어진 시점에 다음과 같은지 확인하는 것입니다.

1. 가장 중요하고 (읽기 : 가치있는) 전달되지 않은 기능 (작업, 요구 사항, 사용자 스토리)에 대한 작업
2. 현재 작업하고있는 것보다 더 중요한 모든 기능을 성공적으로 완료했습니다 (완료된 정의 : 모든 완성 된 스토리는 테스트, 수락, 버그가 없으며 기능이 완료 됨).

이를 통해 특정 시점 에서 최신 빌드가 배송 할 수있는 최고의 제품이라는 것을 알기 때문에 모자를 떨어 뜨려 배송하거나 배송 할 수 있습니다. 즉, 최초 출시 약정 일에 최상의 제품을 제공하게됩니다.

물론 이것이 팀에게 개발을 요청한 모든 스토리로 구성 될 것이라고 약속하지는 않지만 나머지 불완전한 스토리는 물론 가장 나중에 전달할 수있는 가장 중요한 스토리라는 것을 알고 있습니다.

또한 팀의 추정치가 점점 향상되어 릴리스가 끝날 때 범위가 무엇인지 조기에 알 수 있습니다. 몇 주 후에 중요하지 않은 몇 가지 추가 기능을 사용하여 우수한 제품을 제 시간에 배송 할 수 있습니다 (물론 언제쯤 될지 예상 할 수 있습니다).

필요한 연구의 양에 관해서는 여기에 수익을 줄이는 법이 있습니다. 당신이 당신의 이야기를 충분히 작게 나누면, 약간의 연구는 당신에게 충분히 가까운 추정치를 제공해야합니다. 당신이 그들을 잘못했다면 다음 스프린트에서 수정하고 견적이 더 나을 것입니다. 3-4 스프린트에서 평균적으로 마감 기한까지 얼마나 많은 스코프를 전달할 수 있는지 (또는 스코프를 완료하는 데 걸리는 시간)에 대해 잘 알고 있어야합니다.

Scrum에서 스토리 포인트를 추정 할 때 실제로 기능을 작성할 수있을만큼 충분히 알고 있어야합니다. 애자일 개발 방법론의 요점은 완전히 정확한 것으로 예상되지는 않지만 개발 시간이 얼마나 걸리는지 정확하게 예측할 수 없다는 것을 인식하고 있다는 것입니다.

배송에 전념 하는 단계 는 제품 백 로그의 스토리를 스프린트로 수락하는 단계입니다. 스프린트 내에서 이러한 이야기를 전달할 것을 약속합니다.

이 약속을 지키면 약속을 지키지 않는 것 같으면 추가 시간을 할애 할 수 있습니다. 실제로 일부 이야기는 생각보다 오래 걸리고 다른 이야기는 생각보다 시간이 덜 걸립니다.

팀이 충분히 추정하면, 그들은 더 잘할 것입니다.

당신은 또한보고 싶을 수도 있습니다 ...

Clean Coder (도서) –이 책에는 "The Language Of Commitment"라는 장과 추정에 관한 장이 있습니다.

Kanban -Kanban은 풀 스타일의 실행 개발에 가깝습니다. 두 가지 아이디어를 모두 사용하는 "Scrumban"이라는 Scrum과 Kanban의 조합도 있습니다.

아니.

스프린트에서 완료된 각 작업에 대한 모든 추정값의 합계를 속도 라고 합니다 . 속도는 "스프린트 당 완료된 포인트 수"로 정의됩니다. 여기서 '포인트'는 팀이 추정하는 단위입니다.

따라서 속도는 팀이 동일한 방법을 사용하고 팀이 안정적이라고 가정 할 때 다음 스프린트에서 팀이 생산할 수있는 양을 알려줍니다.

이것이 무작위 약속을하지 않고도 팀이 제공 할 수있는 것을 확실히 확신 할 수있는 방법입니다.

노력의 견적은 예측을위한 도구입니다. 예측은 약속이나 보증이 아닙니다. 새로운 지식을 설명하기 위해 예측은 지속적으로 재평가되며 낙관적 및 비관적 변형과 같은 가능한 대안을 포함해야합니다.

우리는 민첩하게 기대하고 있습니다. 약속은 예측보다 조직 계획에 더 큰 가치를 더하지 않습니다.

Mike Cohn의 민첩한 추정 및 계획을 적극 권장합니다.

추정치가 약속이 아니라면 제품 소유자로서 얼마나 오래 걸리는지 모르면서 프로젝트를 전달할 수 있습니까?

하나의 큰 견적으로 작업하지는 않지만 스토리 수준에서 많은 작은 견적으로 작업합니다. 스토리 레벨에서 많은 추정 오류가 평균화됩니다. 내용과 날짜를 모두 약속 할 수는 없습니다. 그러나 백 로그의 맨 위가 릴리스에 포함될 것이라고 확신 할 수 있습니다 (또는 전체 백 로그를 전달할 수있는 정확한 날짜는 고정되어 있지는 않습니다).

예상 시간을 약속으로 처리하면 Scrum 팀이 더 효율적으로 작동합니까?

아닙니다. 이는 예측 결과를 모래 배지하고 속도 / 번 다운 차트를 쓸모없는 데이터로 전환하여 팀이 개선하지 못하게합니다.

이야기에서 얼마나 많은 연구 (준비, 문제를 이해하기위한 노력)가 올바른 견적을 도출하기에 충분합니까?

정밀도에 얼마나 관심이 있는지에 달려 있습니다. 모든 견적을 신중하게 준비하는 데 몇 주를 소비하거나 빠른 선의의 견적 및 희망 오류를 평균화 할 수 있습니다. 첫 번째 방법은 실패를 설정하는 것입니다. 이전에 수행하지 않은 작업을 추정하는 것은 실제로 어렵고 소프트웨어 엔지니어링은 이전에 수행하지 않은 작업에 관한 것입니다.

개인적으로, 나는 매우 정확한 추정치를 얻는 데 많은 이점이 있다고 생각하지 않습니다. 내가하려고하는 것은 추정이 충분히 정확한지 확인하는 것입니다. 즉, 이야기가 예상과 크게 다르지 않게 할 수있는 것을 놓친 것은 없습니다. (다음 요점 참조).

작업을 추정 한 후에 발생하는 예기치 않은 기술 문제 (초기 추정값을 실제로 망칠 수있는 문제)는 어떻습니까?

작은 반복. 주문 잔고. 작은 이야기. 위험한 것은 당신이 모르는 것입니다. 문제에 대한 전문 지식이 부족하면 추정치가 낮아 지지만 전문 지식을 습득 (정교화)하거나 '충분한'추정치로 조정하면 위험 관리에 관한 것입니다.

추정치가 약속이 아니라면 제품 소유자로서 얼마나 오래 걸리는지 모르면서 프로젝트를 전달할 수 있습니까?

이것은 Scrum에 대한 가장 큰 오해 중 하나입니다. "프로젝트에 시간이 얼마나 걸립니까?" 특정 시점에서 완료하기 위해 프로젝트에 수반되는 내용을 정의 할 수 있다고 가정합니다. 그러나 Scrum에 대한 전체 아이디어는 프로젝트에서 작업하면서 프로젝트에 대해 배운 것들이 프로젝트의 정의를 변경한다는 것을 인정한다는 것입니다.

프로젝트를 정의하는 가장 일반적인 방법은 기능을 나열하는 것입니다. 일반적으로 모든 기능이 구현되면 프로젝트가 완료됩니다. 그러나 프로젝트를 진행할 때 처음에 식별 된 5 가지 기능이 필요하지 않다는 것을 알고 있지만 처음 6 개월 동안 사람들이 실제로 포함시켜야 할 7 가지 기능이 있다면 어떻게 될까요? 시간이 얼마나 걸리는가에 대한 질문과 관련이 있습니까?

또 다른 요소는 학습 한 내용이 특정 기능을 구현하는 방법에 대한 이해를 변화시키고 각 기능을 구현할수록 견적이 변경 될 것이라는 점입니다. 개인적으로, 나는 "작은", "작은", "중간", "큰"및 "거대한"또는 "에픽"과 같은 서술적인 추정을 사용하여 구현의 지평에 접근하지 않는 모든 것에 대한 수치 추정치를 거부 할 것입니다. 그러면 추정 할 수있는 것보다 더 큰 정확도를 암시하지 않습니다.

솔직히 말해서 "얼마나 오래 걸립니까?", "어떻게하면 무엇이 될까요?" 회계사와 전통적인 비즈니스 사람들은 이것을 싫어하기 때문에 일부 조직에서는 폭포에서 멀어지기가 매우 어렵습니다.

또한 소금과 함께 속도와 메트릭에 대해 많은 이야기를 해야하는 이유입니다. 소프트웨어 프로젝트에는 일종의 Heisenberg의 불확실성 원리가 내장되어 있으며, 너무 많은 시간을 미세 조정 측정을하면 극도로 정밀한 넌센스가됩니다.

따라서 아닙니다. 견적은 약속이 아닙니다. 추정치입니다. "약속"은 팀이 특정 스프린트에서 특정 수의 기능 또는 스토리를 완성하기 위해 수행하는 약속입니다.

스프린트에 딱 맞는 기능 (또는 스토리)의 수를 팀이 파악할 수있을 정도로 정확해야합니다. 팀은 실제 작업이 일반적으로 예상보다 2 배 많은 것으로 밝혀 지더라도 스프린트에 얼마나 많은 작업을 수행 할 수 있는지 예측할 수 있기 때문에 추정의 정확성보다 더 중요한 것은 일관성입니다. 지속적으로 꺼져있는 한 계획을 세울 수 있습니다.