다음 릴리스에서 수행 할 작업을 결정하고 각 사용자 스토리 (및 특정 스토리의 하위 태스크)에 대한 타이밍을 추정 할 때 그룹 또는 관리자만으로이 작업을 수행합니까?
팀 규모가 10 인 경우 이것이 실용적입니까?
얼마나 시간이 걸려요?
다음 릴리스에서 수행 할 작업을 결정하고 각 사용자 스토리 (및 특정 스토리의 하위 태스크)에 대한 타이밍을 추정 할 때 그룹 또는 관리자만으로이 작업을 수행합니까?
팀 규모가 10 인 경우 이것이 실용적입니까?
얼마나 시간이 걸려요?
답변:
우선 순위 결정은 코드의 이해 관계자이고 비즈니스 이해 관계자가 기능적 요구 사항으로서 비 기능적 요구 사항을 책임지는 선임 개발자를 포함하여 다양한 이해 관계자로부터 의견을 얻은 단일 제품 소유자가 수행해야합니다.
견적은 작업을 수행 할 사람이 수행해야하며, 전달해야하는 압력을받는 관리자는 절대 수행하지 않아야하지만, 6 명 이상의 사람들이이 문제를 논의하는 데 몇 시간을 소비 할 것이라는 본능은 정확합니다. 이상적인 세계에서는 팀을 세분화하여 단일 팀에 4 이상 7 이하가되도록해야합니다. 5 이상이 IMHO입니다.
어떤 이유로 든 이것이 불가능한 경우-불가능하다는 사실을 인정하기 전에 그 이유에 5 가지 이유를 적용 해야하는 경우, 팀을 대신하여 4-5 명으로 구성된 팀을 선택해야합니다.
제 생각에는 10 명으로 구성된 팀으로 계획을 발표해서는 안됩니다. 대부분의 토론에서 6-8 명의 사람들이 완전히 단절되고 지루함을 느끼는 거대한 회의가 생길 것입니다. 거기에 3-4 시간의 피로가 방에 함께 잠겨 있습니다. 그리고 10 명이 대화하면 대화가 너무 많다는 것을 고려하십시오. 그들이 말하지 않으면 귀중한 의견을 얻지 못할 수 있습니다.
우리는 조셉의 회사와 매우 비슷한 일을했습니다. 이전 릴리스에는 8 명의 엔지니어가 있었고 릴리스 계획에는 2 주가 걸렸습니다. 그리고 그것은 절대적으로 잔인했습니다. 매일 몇 시간 씩, 나는 우리 모두가 가능한 한 적게 말을 시작하여 회의가 더 빨리 끝날 것이라고 생각합니다.
이번 출시로 팀 규모가 두 배 이상 증가했습니다. 따라서 우리는 제품 영역을 영구적으로 소유 할 소규모 팀으로 헤어졌습니다. 소규모 팀은 각각 리드가있었습니다. 그런 다음 리드만으로 높은 수준의 릴리스 계획을 수행했습니다. 이제 방에 4 명의 개발자 만 있었기 때문에 더 빠르고 효율적으로 진행되었습니다. 이 기간 동안 우리는 어떤 팀이 어떤 이야기를하고 어떤 제품을 어떻게 나눌지를 확인했습니다. 또한 이것은 전체 제품의 큰 그림을 이끌어 냈습니다.
그런 다음 각 리드는 자신의 팀으로 돌아가서 해당 팀만이 담당 한 릴리스 부분을 넘어갔습니다. 이 기간 동안 우리는 몇 가지 세부 사항을 작성하고 스토리 포인트 값을 할당했습니다.
마지막으로 모든 것이 통합되었으며 팀의 모든 사람이 전체 팀과 함께 진행중인 작업을 알 수 있도록 마지막 연습 (토론보다 프레젠테이션)을 수행했습니다.
우리는이 방법으로 완전한 릴리스를 성공적으로 수행하지는 못했지만 릴리스 계획 전체가 이전보다 훨씬 매끄럽게 진행되었으며 훨씬 더 많은 이점을 얻었습니다. 핵심은 주어진 회의에서 3-4 명 이상의 개발자가 없었으며 모든 사람의 목소리가 여전히 들렸다는 것입니다.
가능하면 10 명의 개발자를 3 개의 그룹으로 나누는 것이 좋습니다. 전체 릴리스를 겹치지 않는 3 개의 영역으로 나눌 수 없다면 2 개의 그룹조차 하나의 큰 팀보다 낫습니다.
저는 실제로 여러 프로젝트 (및 여러 팀)의 리더이며 일부는 10+ 이상입니다. 내가 작업하는 거의 모든 프로젝트에서 릴리스 계획은 리드와 비즈니스 분석가가 수행합니다. 그러나 우리의 상황에서 BA는 관리자가 아니므로 관리자는 실제로 릴리스 계획에 참여하지 않습니다.
추정은 구현 팀이 수행하지만 두 부분이 별개이지만 매우 관련이 있습니다.
평가는 얼마나 많은 시간을 릴리스 계획 인 반면 작업이 완수하는 데 걸리는 경우 이러한 작업은 작업 할 예정 얻을.
계획은 비즈니스 관심사에 따라 수행되어야하고 추정은 기술적 인 관심사에 따라 수행되어야합니다. 따라서 추정과 계획의 붕괴.