스토리 추정에 대한 나의 이해는 상상의 평범한 개발자, 즉 법의 "합리적인 방관자"개념과 비슷한 스토리의 크기를 추정해야한다는 것입니다. 즉, 스토리의 크기를 추정해야 한다고 가정 해서는 안됩니다 .
예를 들어 : 이전 직장에서 나는 가장 자신감있는 Ruby 개발자가있는 팀의 일원이었습니다. 팀원들은 "루비에서 X가 어떻게 작동하는지 모르겠 기 때문에 시간이 오래 걸릴 것입니다."와 같은 주장으로 루비 관련 이야기를 평소보다 더 크게 추정 할 것입니다.
이것에 대한 나의 주장은 스프린트 계획 이 팀의 역량이 작용하는 곳 이라는 사실에서 비롯된다. 즉 , 말을 올바른 포럼입니다 "작업의 대부분은 루비 기반으로하기 때문에 우리의 능력이 질주 약간 평소보다 낮은 것입니다, 우리는 하나의 강력한 루비 개발자가 있습니다." 추정 중에 이것을 인수 분해하면이 양상이 두 배가됩니다.
정답에 대한 권위있는 언급에 감사 드리지만 간단한 의견도 좋습니다.
답변:
스토리 포인트 는 상대적 추정치입니다. 따라서 두 배의 점수는 두 배의 노력 수준을 의미합니다. 상대적 추정치는 기술 수준의 변동이 적습니다. 문제는 1 포인트에 얼마나 많은 시간이 걸리지는 않지만 2 포인트는 2 배 더 많은 노력이 필요하다는 것입니다. 개별 생산성 수준을 가정하기 때문에 스토리 포인트 대신 이상적인 날 이 걸리면 기술 수준이 더 중요 할 수 있습니다 .
상대적 추정치가 더 강력합니다. 또한 스토리 포인트 평가는 개인이 수행하지 말아야하며 팀의 노력에 의한 결과입니다 . 덜 복잡한 이야기의 경우 일반적으로 빠른 동의가 있습니다. 더 어려운 이야기를 위해, 팀은 대부분의 회원들이 동의 할 결과를 얻게 될 것이며, 따라서 팀의 집단 기술 수준을 암시 적으로 고려합니다.
마지막으로, 스토리 평가는 팀 내의 과제가 반드시 결정되지 않은 순간에 수행됩니다. 이것은 개별 기술 수준을 고려하지 않는 또 하나의 주장입니다. 스프린트 계획의 경우 팀의 스토리 포인트 용량을 가져옵니다. 이는 실제 성능 수치를 기반으로 발전하여 팀의 글로벌 기술 수준에 맞게 자체 조정됩니다.
결론적으로, 개별 능력은 추정을 고려해서는 안됩니다. 그러나 집단적 추정과 상대적인 접근의 견고성으로 인해 그렇게 될지라도 그렇게 중요하지는 않습니다.
정식 답변은 개발자 당 견적을 변경해서는 안된다는 것입니다. 그것은 당신이 당신의 동료보다 스프린트 당 더 많은 포인트를 얻는다는 것을 의미하며, 포인트는 개발자가 아닌 팀의 속도를 측정하기 때문에 좋습니다. 비즈니스는 대략적인 납품 기대치를 달성하기 위해 팀이 얼마나 생산할 것인지 추정 할 수 있으며 모든 것이 훌륭합니다.
그러나 실제로 모든 종류의 문제가 발생합니다. 그 주에 휴가를 가면 어떻게 되나요? 재검토 시간이 다가오고 평균 급여의 110 %에 대해 평균 스토리 포인트가 200 % 생성되고 있음을 알게되면 어떻게됩니까? 비즈니스가 팀 속도를 사람으로 나눈 값이 실제로 정확한 근사치라고 생각하기 시작하면 어떻게됩니까? 비즈니스가 다른 기능보다 더 많은 버그를 생성한다는 사실을 알게되면 어떻게됩니까 (더 많은 기능을 생산하는 것을 무시 함)? 사람들이 그렇게 다양한 물기를 가질 때 "물린 크기"이야기는 무엇입니까?
내가 경력을 통해 찾은 것은 그것이 중요하지 않다는 것입니다. 프로세스는 당신을 위해 봉사하는 것이지 그 반대가 아닙니다. 조직이 개발자에게 과부하가 걸리는지 측정해야하는 경우 개발자 별 스토리 포인트가 좋은 솔루션입니다. 조직에서 팀 속도를 측정해야하는 경우, 개발자에 구애받지 않는 스토리 포인트가보다 명확한 그림을 제공합니다. 그러나 그것들은 항상 근사치이며 항상 학대 받고 잘못 해석 될 것입니다.
결국, 그들은 당신이에 적응해야하는 만들어 프로세스에 대한 포인트를 만들어하고 당신의 환경을 제공합니다.
TL; DR
우리는 항상 유능한 개발자 만 특정 스토리에 배정 될 것이라고 가정해야합니다 .역량 (또는 부족)은 모욕이 아닙니다. 그것은 뒤쳐지지 않거나 예외적으로 경험이없는 개발자의 기술에 대한 합리적인 척도입니다.
이것은 특정 회사의 접근 방식의 문제 일 수 있습니다. 회사가 특정 개발자에 맞게 견적을 조정하는 것을 보았습니다. 또한 무작위로 선정 된 3 명의 개발자가 작업에 대략 무작위로 개발자를 할당하기 전에 스토리를 추정하는 시스템을 시행 한 회사를 보았습니다.
모든 시스템이 작동하고 모든 시스템이 실패 할 수 있습니다. 문제는 어떤 시스템이 더 낫지는 않지만 회사가 어떤 결함을 다룰 수 있는지에 대한 문제입니다 .
원칙적으로 언어 / 프레임 워크 숙달을위한 학습 시간은 포함되지 않아야합니다. 사소한 접선 : 이상적인 세상에는 존재하지 않아도되지만 프로젝트 또는 스토리 별 장애물에 대한 학습 시간이 포함되어야합니다.
그렇게하는 데에는 많은 타당성이 있지만,이 방법은 일반적으로 워크로드 추정 의 의도 에 충실하기 때문에 더 나은 선택이라고 생각합니다 . 이것은 객관성이 아니라 내 의견의 문제 일 수 있습니다. 나는 확실히 말할 수 없다.
학습 시간은 개인 입니다. 특정 기술에 대한 작업이 필요한 특정 개발자에게 적용됩니다. 사용자 스토리는 애플리케이션 (및 사용하는 기술)의 범위에 있기 때문에 사용자 스토리의 워크로드를 평가할 때는 관련이 없습니다.
학습 시간은 일반적으로 누적되지 않습니다. 우리의 신인이 C #에 대해 거의 알지 못한다고 말하고, 작업을 수행하기 전에 환경을 파악하는 데 3 일이 더 필요하다고 추정합니다. 제가 일한 많은 회사에서 흔히 볼 수 있듯이, 현재 여러 사용자 사례를 개별적으로 평가할 것으로 예상되는 회의에 참여하고 있습니다. 예를 들어, 우리가 다루어야 할 세 가지 이야기가 있다고 가정 해 봅시다.
참고 :
학습 시간 이 쌓이는 경우가 있습니다 (예 : 세 가지 이야기가 매우 다른 주제에 있고 다른 기술이 필요한 경우).
그러나 이것이 사실인지 아닌지를 알기 위해서는 세 가지 이야기를 동시에 볼 필요가 있습니다.이 이야기 는 독립적 인 사용자 이야기 를 갖는 원칙을 천천히 위반하기 시작합니다 . 만약 우리가 다른 개발자들과 함께 별도의 회의에서 이러한 추정치를 다루었다면; 스토리 사이의 중복을 정확하게 측정 할 수 없습니다.
실제로 어떤 스토리가 완료되는지 (고객이 큰 견적을 거부 할 수 있음) 누가 해당 스토리에 배정 될지 보장 할 수 없기 때문에 특정 개발자가 특정 스토리에 배정되도록하는 것은 무의미합니다. 그것은 단지 물을 진흙으로 만듭니다.
대신, 우리는 신인이 이미 속도를 내렸다고 가정하고 (따라서 동료와 동등한 개발자 라고 가정) 워크로드의 추정치를 렌더링해야합니다 .
이러한 견적은 개발자에 구애받지 않으므로 스토리에 할당 된 개발자에 따라 견적의 정확성이 변동되지 않습니다.
참고
특정 개발자가 특정 이야기를 다루기 전에 공부하는 데 시간이 더 필요할 수 있음을 인정하는 것이 여전히 중요합니다. 그것은 여전히 매우 관련된 고려 사항입니다. 그러나이 고려 사항은 스토리에 첨부되어서는 안되며이 특정 개발자가이 특정 스토리에 할당 되는 것이 좋습니다.
그러나 처음 시작할 때 회사마다 다를 수 있습니다. 일부 회사는 학습 시간에 대해 불만을 품고 있지 않을 수도 있습니다 (예 : 개발자가 어쨌든 기술 사용을 배워야하는 경우). 다른 사람들은 고객에게 청구하는 데 영향을 미치기 때문에 이러한 견적의 정확성에 크게 의존 할 수 있습니다.
결국, 그것은 독을 선택하는 문제입니다. 이 방법들 중 어느 것도 다른 것보다 더 정확한 것은 아닙니다.
이것은 복잡한 주제이며 주제에 대한 논쟁이 자주 있습니다. 나는 이것에 대한 "정규적인"의견의 개념을 좋아하지 않습니다 : 가치에 대한 다양한 의견들이 있습니다. 그러나 접근 방식을 안내해야하는 지원 가치, 원칙 및 관행이 있습니다.
다음은 10 년 이상 스크럼 팀과 함께 일하는 본인의 의견에 근거한 것입니다. 그러나 그것은 단지 나의 의견입니다.
예측 방법으로서의 스토리 포인트 스토리 포인트의 원래 의도는 팀이 일정 기간 동안 완료 할 수있는 것을 예측하기 위해 노력을 추정 할 수있는 빠른 방법을 찾는 것이 었습니다. "휘도"중 일부는 포인트가 장기 범위 (예 : 릴리스)를 예측하는 데에만 사용되며 스프린트 레벨에서 용량을 결정하지는 않습니다. 또한 개념은 팀이 과거 값을 기준으로 "상대적 크기 조정"을 적용한다는 것입니다 (노력 X는 3 점인 노력 B와 유사합니다). 이를 통해 추정 프로세스 속도가 빨라지므로 팀은 향후 작업을 세부 작업 패키지로 분류하고 모든 작업에 시간을 적용 할 필요가 없습니다. 고성능 팀은 모든 기술 인력을 비슷한 기술 수준의 매우 유능한 구성원으로 키우려고 노력합니다. (이 개념은 포인트 # 4에서 더 자세히 살펴볼 것입니다.) 이것이 달성되면, 개별 기술 수준은 실제로 사이징의 변수가 아닙니다. 그러나 그 목표를 달성하기 위해서는 보통 오랜 시간과 노력이 필요합니다. 그래서 ... 도착하기 전에 어떻게해야합니까?
작업 시간은 스프린트 용량을 결정합니다. 포인트가 장기 예측에 사용된다고 언급 한 동일한 "조명"에 따르면 작업 시간은 포인트가 아닌 스프린트 용량을 결정하는 데 사용되도록 제안합니다. 제 생각에는 괜찮습니다. 그러나 코치 팀이 "고성능"을하도록 도와 주었을 때, 레벨 아웃 기술은 스토리 포인트 만 사용하여 스프린트에서 완료 할 수있는 것을 정확하게 결정할 수있는 곳까지 평균이 났다고 말할 것입니다. . 다시 말하지만, 그것은 우리가 노력하는 목표 일 수 있지만, 새로운 팀은 그 준비가되어 있지 않습니다. 따라서 한 번의 스프린트에서 작업 시간이 12 시간이고 2 시간이 25 시간 인 스토리가 있습니다. 그래서 당신은 무엇을합니까? 내가 "민첩한 순수 주의자"라고 부르는 일부 사람들은 스토리 크기 (단위 : 포인트)가 지속 시간에 무관심해야한다고 말합니다. 다른 사람들은 동의하지 않습니다. 항목 # 3의 논리를 읽고 당신의 생각을보십시오.
따라서 팀은 작업을 검토하고 노력 수준의 대리자가 될 요점에 동의해야합니다. 권리? 모든 기술이 동일하다고 가정하면 합의에 도달하기 쉽습니다. 그러나 종종 팀에는 Java 전문가 인 사람이 있으며 Java에는 능숙하지 않은 다른 사람이 있습니다 (아마도 C # 또는 .Net 또는 Cobol 사람이고 Java를 배우고 있음). 따라서 Bob의 작업 X는 매우 간단합니다. Jane에게는 더 어렵다.
애자일 팀은 공동 코드 소유권과 성장 / 확장 전문 지식을 홍보하려고합니다. 따라서 우리는 일반적으로 전문 지식을 기반으로 사람들에게 이야기를 할당하지 않습니다. 우리는 팀이 함께 이야기를하고 함께 배우는 것을 선호합니다. 이는 "Slow down to speed up"의 개념과 일치합니다. Jane에게 Java에 대한 경험을 제공하는 데 시간이 걸리면 처음에는 속도가 느려지지만 나중에는 더 유능한 Java 개발자가됩니다. 실제로 하나의 Java 전문가 만 있고 모든 사람이 자신의 전문 분야에서 작업하는 경우 여러 잠재적 "실패 지점"이있는 상황이 발생합니다. 작업의 90 %가 Java 인 경우 스프린트에서 어떤 일이 발생하지만 Bob (Java 전문가)이 아프거나 휴가 중입니까? 기술을 확장함으로써 잠재적 병목 현상을 제거하고 위험을 줄입니다. 그것을 염두에두고 : 팀이 스토리를 볼 때 사이징 할 때 몇 가지 개념을 염두에 두어야합니다. VUCK의 약어로이 점을 기억할 수 있습니다.
볼륨 : 일부 노력은 매우 간단하지만 많은 양의 반복 작업이 필요합니다. (단순하기 때문에 1 포인트라고 말한 50 + 테이블을 복사하고 다시 포맷 해야하는 사람이 있었지만 팀은 쉽게 볼 수 있지만 시간이 많이 걸리고 많은 테이블이 있음을 깨달았습니다. 작업량에 따라 포인트를 다시 조정해야했습니다.)
미지수는 : 때때로 우리는 우리가 무엇을 해야할지 생각하지만, 우리는 또한 일부 미지수를 식별 -이 대표 위험성을 . 그리고 이것은 다른 솔루션을 해결, 재 설계 또는 시도해야하는 예기치 않은 문제가 발생할 수 있음을 의미합니다.
복잡성 : 이것은 매우 명백합니다. 일부 솔루션은 기술적으로 복잡합니다. 우리는해야 할 일을 정확히 알고 있지만 기술 전문 지식이 필요합니다. 복잡성은 또한 어떤 위험을 암시하지 않습니까? 따라서 우리 모두가 동일한 기술을 보유하더라도 기술적 복잡성으로 인해 예기치 않은 문제가 발생할 수 있습니다. 그래서 우리는이 이야기를 더 크게 만들 수 있습니다.
지식 : 우리가 무엇을 해결하고 있는지 정말로 알고 있습니까? 때로는 고객이 원하는 솔루션에 대해 완전히 명확하지 않은 경우도 있습니다. 또는 아무도이 솔루션을 구현 한 적이 없으며 (이전에 사용한 적이없는 새로운 기술), 우리는 우리가 모르는 것을 모릅니다.
제 생각에는 이러한 모든 고려 사항은 실제로 연장 된 기간 동안의 대리입니다. 쉬운 이야기, 많은 양? 시간이 더 걸리거나 스토리를 분리해야합니다. 미지수? 위험, 연구, 실험이 추가되면 시간이 더 걸리거나 스토리를 분리해야합니다. 복잡한? 추가 위험, 버그 수정, 재 설계 등이 필요하므로 시간이 더 걸릴 수 있습니다. 필요한 지식이 있는지 모르십니까? 추가 위험이 있으며 실험해야 할 수도 있으므로 시간이 더 걸릴 수 있습니다 ...
어디로 가는지 봅니까? 이야기 포인트의 개념은 우리가 추정 할 때의 지속 시간에 대해 생각하는 것을 방해하지만, 반면에 우리는 4 시간 안에 완료 할 수있는 1 포인트 스토리와 단순하지만 1 시간짜리 스토리를 갖는 것은 비논리적입니다. 이주.
만약 Jane이 그 자바 노력에 자원하고 만약 Bob이 그렇게한다면 같은 노력의 기간을 2 배 또는 3 배로 만들 수 있다면 어떻게해야할까요? 시간이 지남에 따라 우리 팀은 노력하는 사람들을 위해 노력 수준 (LOE) / VUCK에 따라 사이징 이야기를 정했습니다. Guru 팀 Bob은 Jane에게 쉽지 않고 완료하는 데 1 주일이 걸리고 페어 코딩 및 코드 검토를 위해 Bob의 시간이 필요하다고 말하면 "1"이라고 말하는 것은 의미가 없습니다. 따라서 우리는 실제 LOE를 반영하기 위해 이러한 점들을 강화했습니다. 다음에 비슷한 이야기가 왔을 때 Jane의 8은 이전에 5가되었습니다. 결국 모든 사람들이 쉽지 않다는 데 동의했습니다. 3. 그 시점에서 우리는 팀으로 성장하고 있음을 알았습니다.
TLDR
아니요, 그러나 아마도 당신이 생각하는 이유가 아닙니다.
긴 버전
다른 많은 답변들은 스토리 포인트가 다른 작업과 관련하여 순수하게 계산되어야한다고 설명했습니다. 이것은 절대적으로 사실입니다. 스토리 포인트는 완료하는 데 필요한 시간이 아니라 작업량 을 추정하므로 개인을 기준으로 스토리 포인트를 제공하는 것은 의미가 없습니다.
예를 들어 (내가 좋아하는 것 중 하나), 당신의 작업 "Dig a hole"을 고려하십시오. 제거 할 지구의 양 또는 지구를 제거하는 데 걸리는 시간을 기준으로이를 추정 할 수 있습니다. 내 친구는 시간당 3 미터의 속도로 전체를 파고, 큰 기계 파는 사람이있어서 100을 관리 할 수 있습니다! 상수는 지구의 양뿐이므로 우리가 추정 단위로 사용하는 것입니다.
그러나 사용자 스토리를 추정 할 수있는 개발자 기능을 할인해야하는 두 번째 이유 (그리고 더 중요한 관점)는 거의 모든 사용자 스토리가 여러 사람에 의해 진행될 수 있다는 사실입니다.
UI를 수행하는 건축가, 개발자, 테스터, 아마도 두 번째 개발자가있을 수 있습니다. 사용자 스토리가 완료 (이상적으로 배포 및 완료)로 표시되기 전에 많은 다른 사람들이 이에 대해 작업했을 것입니다. 문제의 개발자를 기반으로 한 추정의 아이디어는 거의 의미가 없지만, 팀에서 얼마나 많은 노력을 기울일 것인지 정확하게 예측하는 유일한 방법은 팀의 속도를 측정하고 팀이 완료하는 작업을 추정하는 것입니다.
팀에는 "I"가 없으며 민첩한 계획에는 절대로 없습니다.