SCRUM은 팀 구성원이 공유되는 환경을 어떻게 관리합니까?

글쎄, 질문 자체가 말했다. 내 직장에서도 그러한 경우가 발생하지만 많은 애자일 책은 같은 직장에서 일하는 것을 장려하고 현재 프로젝트에 집중하여 작업 속도가 빨라집니다.

어쩌면 나는 그 주제에 대해 알지 못했을 것입니다. 아마도 엄격하지는 않습니다. 그래서 그런 경우에 애자일이 제안하는 것을 알고 싶었습니다.

아무도?

스크럼 방법론에서는 추정에만 영향을 미칩니다.

각 프로젝트에 시간을 할당 한 것에 따라 그 사람에 초점 요소를 할당합니다.

따라서 프로젝트 A 와 프로젝트 B를 동일하게 작업하는 경우 프로젝트 A는 다음과 같이 리소스를 계산합니다.

프로젝트 A — 팀 포커스 요소 70 %
Sam-10 일, 100 % 할당 (포커스 팩터 후 7)
Joe-10 일, 100 % 할당 (포커스 팩터 후 7)
Me-10 일, 50 % 할당 (포커스 팩터 후 3.5) )
총계 : 25 일 * 70 % 초점 계수 = 17.5 예상 속도

또한 프로젝트 분할의 효율성이 저하되어 전체 팀에 대해 한 번이 아니라 풀 타임 팀 구성원과 파트 타임 팀 구성원에 대해 개별적으로 초점 계수를 계산할 수 있습니다 . 이 경우 프로젝트 포커스 팩터 50 %를 사용하고 25 % 또는 2.5 일 프로젝션 속도 에 50 % 의 개인 할당 을 곱합니다 .

이것이 실제로 얼마나 잘 작동하는지, 공유 자원이 각 프로젝트에 얼마나 많은 시간을 할애하는지, 그리고 Scrum이 다른 방식으로 당신을 위해 얼마나 잘 일하는지 미리 알 수있는 요인이 될 것입니다.

Scrum에서 경험 한 바에 따르면 프로젝트와 팀이 동일하고 헌신적 일 경우에만 속도를 예측할 수 있습니다. 이 중 하나가 바뀌면 이전 스프린트에서 속도 계산을 사용하여 추정을 수행 할 수 없습니다. 시도해 볼 수는 있지만 일반적으로 할 수있는 것보다 훨씬 많은 시간이 소요됩니다.

일반적으로 스프린트 전반에 걸쳐 LEAST 팀을 동일하고 헌신적으로 유지하려고 노력해야합니다.

내 생각에 이것은 모든 프로젝트에 매우 나쁜 영향을 미칠 것입니다. 추정이나 계획의 문제 만이 아닙니다. 예, 팀원이 3 개의 프로젝트에 할당되어 있고 각 프로젝트에 33 %의 할당이 있다면 필요한 모든 것을 알고 있지만 완료된 것은 아니라고 말할 수 있습니다.

컨텍스트 전환은 매우 비쌉니다. 또한 여러 병렬 프로젝트에 대한 전념을 유지하는 것은 불가능하므로 개발자가 단일 프로젝트에만 배정 된 경우 개발자 시간의 33 % 퍼센트가 33 %에서 멀어집니다.

이것이 완전히 실패하는 또 다른 장소는 의사 소통입니다. 현재 프로젝트 A에서 작업중인 팀 구성원이 프로젝트 A에서 작업했지만 현재 프로젝트 B에서 작업중인 팀 구성원과 무언가를 전달해야하는 경우 어떻게됩니까? 첫 번째는 정보가 필요하지만 두 번째는 완전히 다른 프로젝트에 집중되어 있고 프로젝트 A에 대한 질문은 그를 방해하기 때문에 두 가지 모두에 대한 장애입니다. 프로젝트 A의 스크럼 마스터는 개발자가 가능한 빨리 정보를 얻길 원하고 프로젝트 B의 스크럼 마스터는 팀 B가 프로젝트 B와 관련이없는 것에 방해받지 않기를 원합니다.이를 피하려면 모두 계획해야합니다 팀의 개발자는 같은 날에 같은 프로젝트를 수행해야합니다. 이는 전체 계획 프로세스와 완전히 피해야 할 문제에 큰 문제가됩니다.

또한 충돌하지 않도록 모든 회의를 계획해야합니다. 또한 회의는 실제로 낭비이며 프로세스를 계속 제어하려면 가능한 최소한의 회의가 있어야한다는 점을 이해해야합니다. 그러나 세 명의 프로젝트를 수행하는 팀원이있는 경우 개발자가 비즈니스 가치를 창출하지 않는 세 배 이상의 미팅 => 세 가지 프로젝트의 모든 미팅에 참여해야합니다.

결론은 민첩성이 폐기물 감소에 관한 것이며 (예 : 린 접근 방식에서 발생) 팀간에 팀 구성원을 공유하는 것은 폐기물 도입 및 생산성 감소 측면에서 최악의 실패 중 하나입니다. 단일 프로젝트에 대한 33 % 할당에 대한 비즈니스 가치 제공은 전체 시간 할당의 10-16 %에서 제공되는 비즈니스 가치와 같을 것입니다. 즉, 개발자는 프로젝트에 1/3의 시간을 할애 할뿐만 아니라 그 기간 동안 생산성은 1/3에서 1/2 사이가됩니다.

SCRUM은 공유 멤버없이 헌신적 인 팀을 구성하는 데 기반을두고 있으므로 다음과 같은 질문을 할 수도 있습니다.

우리는 true == false를 만들어야한다고 들었습니다 .x는 어떻게합니까?

스크럼이 아닌 경우 스크럼이라고 부르지 마십시오!

핵심 질문은 프로젝트에 대한 팀원의 헌신에 관한 것입니다. 이상적으로, 팀원은 프로젝트의 성공에 전적으로 헌신해야합니다. 이것은 그의 시간이 전적으로 프로젝트에 전념한다는 것을 의미하지는 않지만 프로젝트에서 작업 할 때 프로젝트에 필요한 모든 작업을 수행 할 수 있음을 의미합니다.

프로젝트에 시간 제로 만 근무하는 직원의 경우 종종 제한된 범위의 약속에만 관여합니다. 예를 들어 데이터베이스 최적화 만하는 사람이있을 수 있습니다.

이 경우, 그 사람을 팀원이 아닌 "자원"으로 취급하는 것이 가장 좋습니다. 팀은 특정 스프린트에서 원하는 리소스 양을 결정하고 스프린트를 위해 완료해야 할 매우 구체적인 작업 세트를 제공합니다. 때로는 팀에 해당 리소스를 담당하는 특정 팀원이있는 것이 가장 좋으며 매일 스크럼에서 해당 리소스에 대한 상태 업데이트 및 장애보고를 수행합니다.

스크럼의 핵심 측면 중 하나는 팀이 한 번에 하나의 프로젝트, 하나의 이야기, 하나의 작업에 집중하는 것입니다.

하나의 프로젝트에 리소스를 할당 할 수없는 상황에서 "Agile의 제안"을 물었습니다. 다음 중 하나를 시도해 볼 수 있습니다.

• 여러 프로젝트에 걸쳐 큰 칸반 보드를 유지하십시오. 프로젝트가 필요 해짐에 따라 사람들은 역량을 갖추게되면 주요 스토리를 끌어냅니다. 문제는 모든 프로젝트가 함께 관리되어 하나의 프로젝트에 대한 전반적인 예측 가능성이 감소한다는 것입니다. 즉, 개별 스토리 / 칸반 요소는 집중된 사람이나 팀에 의해 끌어 당겨 개발됩니다. (Kanban 보드에서 가져 오기 위해 소규모 4-5 명의 팀을 만들 수 있습니다.
• 커밋 된 리소스 만 할당하십시오. 프로젝트 전용 리소스 풀을 유지하십시오. 이들은 팀으로 보호되며 중단은 0에 가깝게 유지됩니다. 또한 백 로그가없고 프로젝트 / 제품 중심이없는 "신속한 대응 팀"을 유지하십시오. 중단이 발생하면 빠른 대응 팀이 중단을 처리합니다. 중단이 없으면 빌드 시스템 개선, 자동화 테스트 프레임 워크 추가 등에 중점을 둘 수 있습니다. 또한 코드 검토 / 디자인 검토 및 발생하는 까다로운 버그를 해결하는 데 도움을 줄 수 있습니다. 이 팀이 존재하지 않는 것처럼 개발을 관리하십시오. 그들이 할 수있는 일은 배달을 끌어내는 것입니다. 이 팀을 통해 사람들을 "신선하게 유지"시키십시오 (사람들은 빠른 대응 팀에있는 것을 좋아하거나 싫어하는 것 같습니다 ...)

도움이 되었기를 바랍니다!