일부 팀원은 스프린트 계획에 적극적으로 참여하지 않습니다

15

일부 팀원은 자신이 작업 할 가능성이 가장 높은 이야기가 논의 될 때까지 기다렸다가 참여해야합니다. 그렇지 않으면 그들은 단지 전화를 가지고 놀고 듣지 않습니다.

어떤면에서 나는이 입장을 이해한다. 왜 스프린트에서 또는 개발에 도움이되지 않는 기능에 대한 토론을 듣습니까?

우리는 어떻게해야한다고 생각합니까?

agile scrum

— 유진
소스

9

이 팀은 얼마나 큽니까?

— JeffO

8

@JeffO는 머리에 못을 박았다-이것은 대형 팀의 고전적인 문제입니다. 특 대형 팀 = 특화된 개인 당국 / 책임 = 특 대형 개인 참여. 적절한 규모의 팀이란 여러분이 이야기하는 모든 것이 방의 모든 사람에게 영향을 미친다는 것을 의미합니다. 또는 당신은 너무 많은 책임을지고 있습니다. 왜 도움이되지 않는 기능에 대한 토론에 귀를 기울입니까? 사일로 책임이없는 적절한 규모의 팀은 모든 사람이 모든 기능을 수행 할 가능성이 있어야합니다.

— 지미 호파

7

예외없이 전화가 꺼집니다. 간단한 회의 상식.

— user1019696

5

@ user1019696 공정하게, 나는 내 아이가 언제든지 그의 다리를 파열했다는 아내로부터 전화를받을 수 있습니다. "전화 끄기"와 "회의 중에 전화를 걸지 말아라"는 큰 차이가 있습니다. 단순히 무례하기 때문입니다. "

— Jimmy Hoffa

4

@jw 회사 비서가 있었을 때 당신이 시대에 대해 말하면서, 몇 년 동안 일한 회사에는 그런 사람이 없었습니다. 아무것도하지 않았습니다. 그리고 아니, 기다릴 수 없어. 특히 일을 위해서가 아니라 미안하지만 가족을 위해 일하십시오. 즉, 아마도 30 또는 40 회의 중 1 회의 중 중간에 전화를받을 수도 있습니다 (아마도 ??). 사람들이 얼간이를 피하기 위해 장애인을 제거하거나 제거해야하는 경우, 그 사람은 얼간이 일 수 있습니다.

— 지미 호파

32

코드 소유권을 중지하십시오. 팀의 모든 사람이 주어진 작업을 수행 할 가능성을 동일하게 만듭니다.

개발자가 특정 코드 영역에 익숙해지고 다른 사람들이 어깨 너머로 보지 않기 때문에 약간의 반동이있을 것입니다. 또한 경영진은 항상 학습 곡선이 있기 때문에 평소보다 오래 걸리는 작업에 문제가 있습니다.

그러나 그것은 모두에게 최선의 이익입니다. 필수적인 것은 양날의 칼입니다. 저녁, 주말, 휴일 또는 휴가를 보내기가 점점 어려워지기 시작합니다. 그리고 코드 소유권은 회사에 나쁜 영향을 미칩니다. 누군가가 떠날 때 약간의 지식 이전으로 절약 한 것보다 시간이 오래 걸리기 때문입니다.

— pdr
소스

4

+1 물론입니다. 코더가 조립 라인의 또 다른 부분이라고 생각하면 톱니 중 하나를 교체해야하기 때문에 프로젝트가 다시 시작되는 이유가 궁금 할 때 효율성에 대한 잘못된 인상이 있습니다.

— JeffO

3

@JeffO는 개발자가 다른 탄소 단위로 즉시 교체 할 수있는 기계의 동일한 부품으로 간주하면서 내 경험에있어서 소프트웨어 개발 회사 관리에서 거의 표준 인

— @JeffO

3

@jwenting은 아웃소싱에 완벽하게 적합합니다. 개발자가 왜 이런 태도를 지원하는지 모르겠습니다.

— GrandmasterB

1

@jwenting 그것이 민첩성의 요점입니다. 사물에 대한 이런 종류의 견해를 바꾸는 것.

— Euphoric

1

내 경험에서 @Euphoric 최종 결과는 반대로, 관리자는 사람들을 요구 사항과 같이 즉시 스왑 아웃 할 수있는 자산으로 더 많이보고 있습니다 ...

— jwenting

15

적절한 사람들을 회의에 초대합니까? 시스템을 하위 팀의 책임 영역으로 분할 한 경우 모든 하위 팀을 모든 회의에 초대해야하는 이유는 무엇입니까?
예를 들어 프런트 엔드 팀과 백엔드 팀이있는 경우 프런트 엔드 작업을위한 계획 세션을 프런트 엔드 팀 구성원에게 유지하십시오. 작업이 팀 경계를 넘을 경우 백엔드 팀의 담당자를 연락 담당자로 초대 할 수 있습니다 (그러나 자주 발생하는 경우 팀 간의 책임 분담을 다시 평가할 수 있음).
이상적으로 모든 사람이 모든 작업을 수행해야하지만 실제로는 시스템이 작고 단순하지 않으면 모든 사람이 시스템의 모든 부분을 철저히 알고 있지 않으면 실제로는 실용적이지 않습니다. 실제로 많은 시스템은 조직의 모든 구성원이 계획 세션 동안 유효한 입력을 제공 할 수있는 계획된 작업에 대한 충분한 지식을 가질 수있을 정도로 충분히 큽니다. 현실적이지 않습니다.

— wen
소스

12

그들의 무관심은 단지 증상 일뿐입니다. 문제는 모든 팀원에게 작업을 균등하게 분배하지 않는다는 것입니다. 이상적으로 모든 팀원은 특정 프로젝트 영역으로 제한되지 않은 새 티켓을 수령해야합니다.

— 톰 스콰 이어스
소스

3

이론적으로는 좋습니다. 실제로, 특히 대규모 프로젝트의 경우 시스템은 모든 팀원이 작업 할 때 생산성을 발휘할 수 있도록 시스템의 모든 부분에 대해 충분한 지식을 보유하는 것이 비현실적 일 수 있습니다.

— jwenting

@jwenting-이 팀은 다른 부분에서 작업하지 않아도 될 것 같습니다. 한 사람이 모든 것을 알 수는 없지만 가능한 한 적게 배워야한다는 의미는 아닙니다.

— JeffO

@JeffO 사실이지만, 그들이 모르는 분야에 대한 계획에 적극적으로 참여할 수는 없습니다. 듣고 배우지 만 입을 다물고 있어야합니다. 아마도 핸드폰을 사용해서 플래닝 보드의 사진을 찍을 수도 있습니다 :)

— jwenting

1

실제로 대규모 프로젝트에서 @jwenting하면 작업을 더 많이 배포해야합니다! 모든 사람이 동일한 지식을 가지고있는 것은 아니지만 특정 영역에서 작업 할 가능성도 동일합니다. 변명을 허용하면 팀원이 새로운 영역을 채택하지 않을 가능성이 높아집니다.

— Dave Hillier

5

동기 부여 문제처럼 들립니다. 일부 사람들이 작업중인 프로젝트에 관심을 가지지 않는 이유는 무엇입니까? 팀이 '주최자'와 '왼쪽 아웃'으로 나뉘어져 있기 때문일 수 있습니다.

따라서 계획 세션을 담당하는 1 ~ 2 명 대신 모든 사람을 참여 시키십시오. 모든 사람을 참여 시키십시오. 다른 사람이 각 세션을 담당하게하고, 바람직하게는 다른 사람이 세션 동안 담당하게하십시오. 모든 것을 회전시킵니다. 나는 모든 사람을 소란스럽게하고 조직하고 싶어하는 사람이 항상 있기 때문에 이것이 어려워 보일 수 있다는 것을 알고 있습니다.

아이디어는 다음과 같습니다. 계획 할 때 각 이야기를 담당 할 사람을 무작위로 선택하십시오. 무작위. 계획 수립을 담당 한 사람도 기록해 두십시오. 따라서 다음 스프린트는 그들이 예상 및 작업 분할에 대한 합의를 얻는 데 좋은 일을했는지 알 수 있습니다. 그것은 그들이주의를 기울이고 프로젝트에 참여할 이유를 줄 것입니다.

문제는 문제가 아니라 자신과 계획 세션이 이루어지는 방식이라는 점을 기억하십시오. 따라서 다른 사람이 스토리 계획을 인수 할 때는 공식적인 진행 방법이 있어야합니다. (즉, 앉아서 프록시로 조직을 계속 강요하지 마십시오)

— bj
소스

좋은 생각. 잘만되면 사람들은 이것을 시간 낭비로 보지 않을 것입니다.

— Eugene

1

스프린트 지속 시간은 얼마입니까?

스프린트 지속 시간이 길어질수록

스프린트에서 더 많은 계획을 세우면
더 긴 계획 회의
팀원들이 집중력을 유지하기가 더 어려워 짐 ...
팀원은 지루해

스프린트 지속 시간이 2 주 이상인 경우 더 짧은 스프린트 작업을 시도하십시오.

이해 관계자가 더 짧은 스프린트를하도록하는 것이 어려운 경우 공식적인 회의 중 일부를 건너 뛸 수 있습니다. 예를 들어 모든 스프린트 후가 아니라 2 개의 스프린트마다 스프린트 검토 만합니다.

— 피트
소스