전문가 팀을위한 스크럼

스크럼은 일반 회원이있는 팀, 즉 최소한 2 명이 같은 작업을 수행 할 수있는 팀에 가장 적합합니다. 저의 주요 관심사는 전문가들로 구성된 팀을 위해 스크럼 (보관 대상, 제거 대상, 개선 대상)을 조정할 수있는 훌륭한 솔루션을 찾는 것 입니다.

실제 개발자가 아닌 5 명의 개발자로 구성된 팀이 있다고 가정 해 보겠습니다.

1. C에 능숙한 수학자;
2. 하나의 DB 개발자;
3. 하나의 웹 개발자;
4. 하나의 UX / GUI 개발자;
5. 한 소프트웨어 아키텍트;

여기, 모두 전문가이며 아무도 다른 사람을 대신 할 수 없습니다 (나는 그러한 팀을 구축 할 위험에 관심이 없으며 스크럼에 집중하고 싶습니다). 따라서 스크럼 컨텍스트에서 내 생각은 다음과 같습니다.

1. 쓸모없는 봄 계획 : 실제로, 수학자가 특정 과제가 2 포인트의 가치가 있다고 말하면 아무도 그에 대해 투표 할 수 없습니다.
2. 쓸모없는 팀 속도 메트릭 : 모든 사람이 자신의 작업에 여러 포인트를 할당 할 수 있으므로 컴퓨팅 속도는 의미가 없습니다.
3. 일일 스크럼 회의를 매주 (더 긴) 스크럼 회의로 교체 : 팀의 각 구성원이 자신의 작업을 수행 할 때 매일 팀 스크럼 회의는 "팀 정신"을 유지하는 데 매우 중요합니다. 그러나 매일 스크럼 회의는 약 15 분 동안 지속됩니다. 이것은 다른 사람들이하고있는 일과 행동을 이해하기에 충분하지 않습니다. 더욱이, 수학자는 대부분 같은 시간에 대답 할 것입니다 : "나는 여전히 % & Lo (+? $$ + &)를하고 있습니다."주간 회의는 더 많은 시간을 줄 것입니다. "초기"스크럼 회의와 "주간"스크럼 회의 사이에 동일한 회의 시간을 유지하려면 매주 스크럼 회의가 지속되어야합니다 (주 5 일 스프린트, 스프린트 회의는 4 시간, 일일 회의는 15 분 지속). (4 * 60 + 20 * 15) / 4 =>

아니면 여전히 스크럼을 사용할 수 있습니까? 다른 민첩한 기술을 사용해야합니까?

스크럼은 은색 총알이 아닙니다. 모든 프로젝트가 성공하기 위해 Scrum을 사용할 필요는 없습니다. 그러나 당신이 묘사하는 상황은 린 / 칸반에 아주 적합합니다. 확인하시기 바랍니다.

칸반은 기본적으로 몇 가지 일만하도록 요구하지만 그중 어느 것도 당신이 묘사하는 팀과 충돌하지 않습니다.

• Kanban 보드와 같은 가치의 흐름을 시각화하십시오. Scrum 보드는 Kanban 보드의 특정 응용 프로그램입니다. 전문화가 가능하도록 조정할 수 있습니다.
• WIP (Work In Progress)를 제한하여 팀에 할당 된 작업량이 작업 흐름을 지속적으로 유지하기에 충분합니다. 즉, 스트림의 시작 (디자인) 또는 끝 (배포)에 "차단" .

Kanban에 대한 참조를 확인하십시오.

• 칸반 랜드에서 하루
• 프라이밍 칸반 (무료 전자 책)

애자일이 제공하는 것을 보지 않고 스크럼 / 애자일의 역학에 너무 집중하고 있습니다. 당신은 수학 녀석이 2 점을 추정하면 아무도 그가 틀렸다고 말할 수 없다고 말합니다. 이것이 목표가 아닙니다. 목표는 다가오는 스프린트에 대해 달성 가능한 목표 세트에 동의하는 것입니다. 이 작업의 전문가로서 그는 얼마나 오래 걸릴지 가장 잘 알 것입니다.

"그가 거짓말을하거나 잘못 이해하면 어떨까요?" 당신은 말합니다. 내 경험상 사람들은 정확한 추측을하기 위해 총에 맞을까 봐 두려워서 더 많은 것을 추정하고 있습니다. 그런 다음 추정 대상인 사람들은 모든 것을 균형있게 유지하는 안전 마진을 추가하고 이상한 게으른 사람은 예상을 초과하여 서두를 필요가 없습니다. 세 가지 중 첫 번째는 속도 추적에서 선택되고 두 번째는 잘못 들리는 동안 작동하고 세 번째는 스크럼 외부에서 처리해야하는 항목입니다.

일일 회의는 여전히 혜택을 제공합니다. 각 전문가 인 경우에도 팀 구성원간에 종속성이 있습니다. UI 녀석이 서버 녀석에서 알림 버그 수정을 기다리고있을 수 있습니다. 서버 사람이 계산을 잘못한 이유를 파악하기 위해 수학 사람을 기다리고있을 수 있습니다. 또한 그들의 일이 당신에게 어떤 영향을 미치는지에 관한 것이 아닙니다. "이유 X"로 인해 팀원이 지속적으로 지연되고 있지만 향후 "이유 X"발생을 완화하는 데 시간이 걸리지 않은 경우, 이는 도전이 될 수 있습니다.

당신이 설명한 것과 같은 자격을 가진 전문가가 있다면, 각자가 자신의 업무를 수행하고 있고 다른 사람들과 의사 소통 할 필요가 거의 없다는 가정은 IMHO 잘못입니다. 사실, 새로운 기능 ( "사용자 스토리")을 실현하려면 종종

• 데이터베이스를 변경
• GUI 또는 웹 인터페이스 추가 또는 변경
• 이것을 올바른 비즈니스 논리와 결합하십시오 (어쩌면 "수학자"가 온 곳)
• 모든 변경 사항이 함께 작동하는지 확인하십시오

따라서 모든 사람들이 다른 응용 프로그램 / 사용자 스토리에서 작업하여 모든 응용 프로그램 계층에 필요한 모든 변경 사항을 직접 적용 할 수있는 일반 팀과 같이 훨씬 더 많은 의사 소통을해야한다고 생각합니다. 따라서 위에 나열된 Scrum의 모든 팀 활동은 해당 팀에 적합합니다.

스크럼은 여전히 ​​귀하의 상황에 적합하지만 다른 프레임 워크도 마찬가지입니다.

새로운 기능을 제공하려면 이러한 기술의 전부 또는 다수가 필요할 것입니다. 팀이 서로에게 영향을 미치는 결정을 내리고 협력하려면 의사 소통이 필요합니다. 스크럼 회의 사이의 시간이 길수록 부정적인 계획이 더 길어질 수 있습니다. 팀은 매일 회의를 통해 이러한 상황을 신속하게 해결하고 새로운 계획을 수립 할 수 있습니다.

나는 또한 당신이 제기하는 몇 가지 특정 주제를 다루고 싶습니다 :

교차 기능 팀 스프린트 목표 및 / 또는 제품 백 로그 항목을 제공하는 데 필요한 모든 기술을 갖춘 팀은 교차 기능 으로 간주됩니다. 이것은 모든 직업에 2 명이 있다는 것을 의미 하지는 않습니다 .

사이징 솔루션이나 솔루션의 일부가 아니라 비즈니스 문제 나 규모를 사이징하고 있음을 기억하는 것이 중요합니다. 예를 들어, 전자 상거래 사이트에 소셜 미디어 / 트위터 통합은 UX, UI 디자인, 프로그래밍, 데이터베이스 및 Twitter API에 대한 지식이 필요한 문제입니다. 팀은 팀으로서이 기능을 제공하기 때문에 팀 단위로 크기를 조정해야합니다. 이 크기는 100 % 정확하지는 않지만 상대적 크기 조정을 기반으로 한 예측이 더 정확하다는 것을 알 수 있습니다. 이는 일부는 높고 일부는 낮으며 함께 계산 된 예측이 예상 지속 시간보다 더 정확함을 의미합니다.

쓸모없는 봄 계획 스프린트 계획은 제작해야 할 사항을 결정하고 시작 방법에 대한 계획을 세우기 위해 스크럼 팀 (개발 팀 + 제품 소유자 + 스크럼 마스터)으로서 협력 할 때입니다. 일부 팀은 선택한 제품 백 로그 항목을 작업으로 나누고 다른 팀은 통과해야하는 테스트 (XP 생각)와 같은 자체 진행 방식을 제시합니다.

이것은 양방향 협업입니다. 팀에 PBI 세트를 할당하고 "go"라고 말하는 것이 독재자의 역할입니다. 팀은 스프린트 시간을 최대화하기 위해 제품 소유자와 협상 중입니다.

쓸모없는 팀 속도 메트릭 팀이 아키텍처 / 시스템을 절단 한 비즈니스의 문제와 요구를 사이징하고 팀에서 일정 기간 (스프린트)으로 제공 한 팀 수를 알려주는 과거 경험을 통해 팀 예측을 제공 할 수 있습니다. 잔고의 나머지.

다시 말하지만, 두 개의 스프린트는 동일하지 않으며 사용하는 제품 백 로그 항목의 샘플 세트가 작을수록 추정 오차가 덜 분산됩니다. 주식 시장처럼 생각하십시오. 항상 올라 왔지만 그렇다고해서 몇 년이 지났다는 의미는 아닙니다. 총계에서 돈을 벌 수는 있지만 주어진 달, 분기, 연도에는 잘못 추측 할 수 있습니다.

일일 스크럼 회의를 주간 (더 긴) 스크럼 회의로 교체 매일 스크럼 은 팀에 24 시간의 피드백주기와 다음 24 시간 계획을 제공 할 수있는 기회를 제공합니다. 더 이상 아무것도 없습니다. "3 가지 질문"은 이러한 노력을 촉진하는 데 도움이됩니다.

5 일 동안 피드백이 없으면 작업이 충분하지 않다고 생각합니다. 이것은 단순히 제 의견이지만 코치와 팀원으로서의 경험을 바탕으로합니다. 팀은 더 자주 말하고, 계획하고, 노력을 통합해야합니다.

결론 스크럼은 학습과 학습의 균형을 맞추기위한 것입니다 (실제 학습이 이루어지는 곳). 시간이 지남에 따라 프로세스와 도구를 실험하고 Scrum을 사용하여 영향을 검사하십시오. 매일 스크럼으로 이동하여 팀이 올바른 기능을 제공하는 데 도움이되는지 또는 손상하는지 확인하십시오. 그것은 당신을 위해 일할 수 있습니다.