팀 규모가 10 명을 초과해도 계획을 함께 발표 할 수 있습니까?


9

다음 릴리스에서 수행 할 작업을 결정하고 각 사용자 스토리 (및 특정 스토리의 하위 태스크)에 대한 타이밍을 추정 할 때 그룹 또는 관리자만으로이 작업을 수행합니까?

팀 규모가 10 인 경우 이것이 실용적입니까?

얼마나 시간이 걸려요?


9
왜 팀이 그렇게 큰가요? 애자일하려는 경우 하나의 큰 팀 대신 두 개의 작은 팀이 있어야합니다. 왜 10 명이 한 팀인지 설명하십시오.
S.Lott

1
10 명의 프로그래머가 회의에 참석 한 이유는 IPO 또는 파산을 알리는 것입니다.
JeffO

아니요. 3 명 이상으로 작성된 소프트웨어는 절대 공개되지 않습니다. 카운터 예제에 대해 들으면 : 알파 또는 베타 버전입니다.
Landei

저는 우리가이 일을했던 약 15 명으로 구성된 팀에서 일했습니다. 가장 큰 단점은 회의 중 어느 시점에서든 약 10 명이 지루한 손에 앉아 있으며 매주 몇 시간 동안 발생한다는 것입니다. 그러나 때때로 팀을 분리하면 더 많은 문제와 잘못된 의사 소통이 발생할 수 있습니다. 이상적이지는 않지만 완료되었습니다.
MrFox

답변:


3

우선 순위 결정은 코드의 이해 관계자이고 비즈니스 이해 관계자가 기능적 요구 사항으로서 비 기능적 요구 사항을 책임지는 선임 개발자를 포함하여 다양한 이해 관계자로부터 의견을 얻은 단일 제품 소유자가 수행해야합니다.

견적은 작업을 수행 할 사람이 수행해야하며, 전달해야하는 압력을받는 관리자는 절대 수행하지 않아야하지만, 6 명 이상의 사람들이이 문제를 논의하는 데 몇 시간을 소비 할 것이라는 본능은 정확합니다. 이상적인 세계에서는 팀을 세분화하여 단일 팀에 4 이상 7 이하가되도록해야합니다. 5 이상이 IMHO입니다.

어떤 이유로 든 이것이 불가능한 경우-불가능하다는 사실을 인정하기 전에 그 이유에 5 가지 이유를 적용 해야하는 경우, 팀을 대신하여 4-5 명으로 구성된 팀을 선택해야합니다.


2

제 생각에는 10 명으로 구성된 팀으로 계획을 발표해서는 안됩니다. 대부분의 토론에서 6-8 명의 사람들이 완전히 단절되고 지루함을 느끼는 거대한 회의가 생길 것입니다. 거기에 3-4 시간의 피로가 방에 함께 잠겨 있습니다. 그리고 10 명이 대화하면 대화가 너무 많다는 것을 고려하십시오. 그들이 말하지 않으면 귀중한 의견을 얻지 못할 수 있습니다.

우리는 조셉의 회사와 매우 비슷한 일을했습니다. 이전 릴리스에는 8 명의 엔지니어가 있었고 릴리스 계획에는 2 주가 걸렸습니다. 그리고 그것은 절대적으로 잔인했습니다. 매일 몇 시간 씩, 나는 우리 모두가 가능한 한 적게 말을 시작하여 회의가 더 빨리 끝날 것이라고 생각합니다.

이번 출시로 팀 규모가 두 배 이상 증가했습니다. 따라서 우리는 제품 영역을 영구적으로 소유 할 소규모 팀으로 헤어졌습니다. 소규모 팀은 각각 리드가있었습니다. 그런 다음 리드만으로 높은 수준의 릴리스 계획을 수행했습니다. 이제 방에 4 명의 개발자 만 있었기 때문에 더 빠르고 효율적으로 진행되었습니다. 이 기간 동안 우리는 어떤 팀이 어떤 이야기를하고 어떤 제품을 어떻게 나눌지를 확인했습니다. 또한 이것은 전체 제품의 큰 그림을 이끌어 냈습니다.

그런 다음 각 리드는 자신의 팀으로 돌아가서 해당 팀만이 담당 한 릴리스 부분을 넘어갔습니다. 이 기간 동안 우리는 몇 가지 세부 사항을 작성하고 스토리 포인트 값을 할당했습니다.

마지막으로 모든 것이 통합되었으며 팀의 모든 사람이 전체 팀과 함께 진행중인 작업을 알 수 있도록 마지막 연습 (토론보다 프레젠테이션)을 수행했습니다.

우리는이 방법으로 완전한 릴리스를 성공적으로 수행하지는 못했지만 릴리스 계획 전체가 이전보다 훨씬 매끄럽게 진행되었으며 훨씬 더 많은 이점을 얻었습니다. 핵심은 주어진 회의에서 3-4 명 이상의 개발자가 없었으며 모든 사람의 목소리가 여전히 들렸다는 것입니다.

가능하면 10 명의 개발자를 3 개의 그룹으로 나누는 것이 좋습니다. 전체 릴리스를 겹치지 않는 3 개의 영역으로 나눌 수 없다면 2 개의 그룹조차 하나의 큰 팀보다 낫습니다.


2

저는 실제로 여러 프로젝트 (및 여러 팀)의 리더이며 일부는 10+ 이상입니다. 내가 작업하는 거의 모든 프로젝트에서 릴리스 계획은 리드와 비즈니스 분석가가 수행합니다. 그러나 우리의 상황에서 BA는 관리자가 아니므로 관리자는 실제로 릴리스 계획에 참여하지 않습니다.

추정은 구현 팀이 수행하지만 두 부분이 별개이지만 매우 관련이 있습니다.

평가는 얼마나 많은 시간을 릴리스 계획 인 반면 작업이 완수하는 데 걸리는 경우 이러한 작업은 작업 할 예정 얻을.

계획은 비즈니스 관심사에 따라 수행되어야하고 추정은 기술적 인 관심사에 따라 수행되어야합니다. 따라서 추정과 계획의 붕괴.


4
+1-계획은 리드와 비즈니스에 의해 수행되지만 실제 작업자 꿀벌에 의해 추정이 수행되어야합니다.
Jim In Texas

0

이 작업은 관리자가보다 효율적으로 수행합니다. 소규모 팀에서는 역할이 혼동되는 경향이 있습니다. 모두가 모든 것에 관여합니다. 그러나 팀이 성장함에 따라 관리가 어려워지고 역할을 명확하게 정의해야합니다.

내가 모든 것에 참여하고 싶은 욕구를 얻는 것만 큼 생산적이지는 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.