속도를 사용하여 리소스 시간 할당

Question

속도 관련 : 속도를 기반으로 한 다음 스프린트에서 기술을 혼합 한 팀에 시간을 할당하려면 어떻게해야합니까?

팀은 프런트 엔드 및 백엔드 개발에 더욱 숙련 된 사람들과 다른 수준의 개발자가 있습니다.

각기 다른 스프린트는 각 그룹마다 서로 다른 양이 있습니다.

"팀이 스프린트 당 100 점을 얻었고 실제로 10 점의 백 엔드 작업과 90 점의 프런트 엔드 작업을 스프린트에 할당한다고 말하는 것은 이해가되지 않는 것 같습니다. 90 점의 속도를 가진 백엔드 사람들과 10 점의 속도를 가진 프론트 엔드 사람들.

나는 그 대답이 단순히 사람들의 힘을 무시하는 것이라고 상상할 수 없다. 하위 팀별로 속도를 분할해야합니까?

Answer 1

속도는 팀 측정이며 다른 팀간에 비교할 때 숫자는 일반적으로 의미가 없습니다. 당신이 그것을 개인적인 수준으로 분해한다면 똑같은 일이 일어납니다 : 한 개인의 속도는 다른 사람의 속도와 비교할 수 없습니다. 이 개념은 프로젝트의 한 스프린트를 다른 스프린트와 비교할 때만 유용하므로 프로젝트 중간 측정 메트릭을 변경하면 결과를 잘못 해석 할 수 있습니다.

당신은 생산적인 개인의 인력을 결정하려고합니까? 다른 팀원들에게 사람들이 훌륭한 일을하고 있다고 느끼면 다른 팀원들에게 질문하거나, 팀 노력에서 자신의 체중을 빼는 등의 다른 방법을 측정 할 수 있습니다.

Answer 2

기술 속도에 따라 다음 스프린트에서 시간을 할당받을 수 있는가?

전체 팀은 이야기의 스토리 포인트 수가 이야기에 대해 무엇인지에 관해 공통된 합의를합니다. 같은 팀이 프로젝트 기간 동안 이러한 스토리 포인트를 결정할 것이므로 팀의 속도는 더 많은 스프린트가 될수록 더 정확해야합니다.

예, 일부 개발자들은 다른 사람보다 느리게 수 있지만 팀이 일정하게 유지되는 경우, 속도 계산은 당신이 이야기가 전달 될 수있는 경우에 괜찮은 추정을 할 수 있도록,보다 정확한 얻을 것이다.

하위 팀으로 속도를 나눠서 이야기가 전달 될 때를 예측하지 못하면 의 속도 인이 중요한 요소입니다.

팀은 프런트 엔드 및 백 엔드 개발에서보다 숙련 된 사람과 개발자의 수준이 다릅니다.

스크럼 팀은 일반화 전문가 인 개발자 (예 : 소프트웨어 엔지니어, 테스터, 비즈니스 분석가 등 개발 팀의 개발자)로 구성되어야합니다. 각 팀 구성원은 백 엔드 및 프런트 엔드 개발 및 테스트를 수행 할 수 있어야하며, 실제로 스토리를 전달하는 데 필요한 모든 것이 있어야합니다. 예, 실제로 일부 팀 구성원은 전문가의 프론트 엔드 환경을 경험할 수 있지만 스프린트가 진행됨에 따라 모든 팀 구성원이 솔루션을 개발할 수 있도록 지식 공유가 이루어져야합니다 (예 : 쌍 프로그래밍, 멘토링, 문서화 (!)).

좋은 스크럼 마스터는 지식의 공유를 장려합니다, 당신은/약간의 프론트 엔드 개발자는 그 반대 우수한 백엔드 개발자 것을 찾을 수 있습니다!

이것은 기업이 고투하는 사일로 환경에서 개발자를 분리하는 개념이지만 성공적인 애자일/스크럼 팀에게는 필수적입니다.

Answer 3

스크럼 팀은 일반적으로 크기가 7 또는 8입니다. 2-3 명이 백엔드 작업을 잘 수행 할 수있는 전문가가 있으면 90 개의 스토리 포인트를 레코딩합니다. 그렇다면 위험과 너무 많은 의존성입니다. 스크럼 팀의 모든 사람들이 프론트 엔드뿐만 아니라 백엔드도 인식 할 수 있도록 지식을 공유하는 것이 좋습니다. 초기 단계에서 램프 업으로 25-30 %의 시간을 줄이고 스토리 포인트를 적게 설정하면 60이됩니다. 결국 팀이 상승 할 때 속도가 의미가 있습니다. Velocity는 스크럼 팀이 개별 전문 지식에 관계없이 달성 할 수있는 정도를 항상 의미합니다.

하지만 백 엔드 및 프런트 엔드 전문 지식을 구분하려면 두 개의 개별 스크럼 팀을 구성 할 수 있습니다. 그러면 속도가 적절 해집니다.