Scrum에서 두 개의 서로 다른 프로젝트 간 개발자 시간을 조정하는 방법은 무엇입니까?

저는 새로 설립 된 팀의 스크럼 마스터가되어 소프트웨어를 만들고 다른 배포 된 응용 프로그램을 유지 관리해야합니다. 따라서 기본적으로 각 팀 구성원에게는 개발 및 운영 작업이 있습니다.

지난 몇 주 동안 그들이 어떻게 작동하는지 관찰 해 보았고 팀이 이러한 작업을 조정하는 데 어려움을 겪고 있음을 알았습니다. 개발자가 코딩에 집중할 때 프로덕션에서 제기 된 문제를 해결하기 위해 중단되어 이전 작업에 다시 집중하기가 어렵습니다.

운영 작업에 개발자 시간의 %를 할당하려고 시도했지만 분명히 문제가 해결되지는 않습니다. 이전에이 상황을 경험 한 스크럼 마스터의 의견을 듣고 싶습니다. 어떻게 관리했으며 권장 사항은 무엇입니까?

이 문제는 스크럼만큼 오래되었습니다. 해결책이 있지만 마음에 들지 않습니다.

• 백 로그에 새로운 작업을 넣습니다.
• 개발자를 방해하지 마십시오.
• 다음 스프린트를 기다립니다.

개발팀을 둘 이상의 스크럼에 배치하거나, ​​두 개의 개별 백 로그를 갖거나 스프린트에 시간의 일부만 할당하면 스크럼이 달성하려는 작업, 즉 완료된 작업의 일관된 흐름에 대해 모든 작업이 수행됩니다.

이러한 유형의 작업을 시도하면 기본적으로 모든 수행 문제와 함께 '카오스'또는 'JFDI'개발 방법론으로 돌아갑니다.

• 개발자는 한 번에 10 가지 작업을 수행 할 수 있습니다. 아무도 그들이 무엇을하고 있는지, 언제 끝날지 아무도 모릅니다.
• 다른 프로젝트가 동시에 진행되고 있기 때문에 프로젝트를 완료하기 위해 알 수없는 시간입니다.
• 프로젝트 우선 순위에 대한 일관된 견해가 없습니다. 다른 관리자는 개발자를 애완 동물 프로젝트로 전환합니다.

물론이 조언에 대한 일반적인 답변은 "하지만 나는 할 수 없습니다! 비즈니스는 가능한 빨리 생산 버그를 수정해야합니다!"

그러나 그것은 사실이 아닙니다.

실제로 비즈니스에 영향을 미치는 많은 실제 버그가 있다면 전문성을 확보하고 테스트를 개선해야합니다. 모든 버그가 해결 될 때까지 버그 및 자동화 된 테스트를 수행하십시오. QA 팀을 고용하고 모든 새로운 릴리스에서 지옥을 테스트하십시오.

더 가능성이 높은 것은 다음 중 하나입니다.

• 버그는 운영상의 문제이며 디스크 공간 부족, DR 없음, 백업 없음, 장애 조치 없음 등입니다. OPS 팀에 문의하십시오.

• 버그는 사용자가 시스템이 어떻게 작동해야하는지 이해하지 못하는 것입니다. 헬프 데스크를 확보하고 사용자를 교육하고 문서를 작성하십시오.

• 롤백의 두려움. 새로운 기능을 시작했으며 문제가 발생했습니다. 수정을 서두르지 마십시오. 이전 버전으로 롤백하고 버그를 백 로그에 넣습니다.

그냥 상자 밖에서 생각하려고합니다.

제품 소유자가 원하는 방식으로 작업을 수행하지 못할 수도 있습니다. 개발자 지원이 필요한 고객과의 회의 등 한 순간에 한 명의 개발자를 스프린트에서 꺼내야하는 심각한 오류가 여전히있을 수 있습니다.

이것을 예상하고 유리하게 사용하십시오.

현실적이 되려면 5 명 이상의 팀이 필요합니다.

그러나 스프린트마다 개발자 한 명을 꺼내는 것이 어떻습니까 (개발자 사이에서 회전 할 때마다 각자 차례가됩니다).

수정을 위해 전체 개발자를 사용하기에 충분한 오류가 없을 가능성이 높으므로 수행 할 수있는 다른 문제 나 작업이 있습니다.

• 성능 병목 현상 또는 확장 성 문제를 식별하기위한 테스트 실행
• 빌드 시스템 유지 보수
• 고객과의 만남
• 새로운 프레임 워크 / 라이브러리 연구
• 사용하고 싶은 언어 기능 탐색
• 보안 문제에 대한 읽기
• 데이터베이스 유지 보수
• 서버 유지 보수

팀 속도가 올라가고, 스트레스가 줄어든다. 경영진과의 갈등이 줄어든다. 실제로 지식을 향상시킬 시간이있다.

내가 사용한 진정한 필수 프로덕션 문제에 대한 개발자의 노력을 관리하는 효과적인 솔루션은 "배트맨 접근 방식"입니다.

새로운 기능을 개발하는 동안 생산 지원 책임의 고가의 측면은 컨텍스트 전환이므로이를 제한해야합니다.

팀의 구매를 통해 팀 구성원의 목록을 작성하고이를 순환하여 매일 새 직원이 스탠드 업 미팅에서 "배트맨"으로 선언되고 해당 날의 필수 생산 문제에 응답합니다. 팀의 나머지 부분은 상황 전환없이 개발에 계속 집중할 수 있으며 모든 사람이 지원의 고통을 공평하게 공유합니다. 팀이 5 명인 경우 주 1 일 개발자가 중단 될 수 있으며 4 일의 중단없이 예측 가능한 개발 시간이 있습니다.

이는 팀간에 지식 / 경험을 공유 할 수있는 이점이 있으므로 특정 문제를 해결하고 단일 실패 지점 및 지원 문제를 공정하게 구분할 책임이있는 사람이 없습니다.