Przewodnik po Scrumie | 16. Skalowanie Scrum

Opublikowany: 2022-05-16

Zespół Scrumowy powinien składać się maksymalnie z dziesięciu osób. Ale co zrobić, gdy nad jednym projektem musi pracować większa grupa specjalistów? Lub jeśli organizacja zdecyduje się na zwinny sposób zarządzania? Aby rozwiązać ten problem, programiści Scrum zaproponowali [email protected] Jest to bezskalowa architektura do organizowania całych zespołów zgodnie z zasadami Scrum.

Skalowanie Scrum – spis treści:

  1. Wstęp
  2. [e-mail chroniony]
  3. Scrum Scrumów
  4. Dalsze problemy ze skalowaniem i [ochroną poczty e-mail]
  5. Streszczenie

Wstęp

Gdy tylko organizacja się rozrasta, pojawiają się nowe rodzaje problemów. Na przykład spadek efektywności pracowników spowodowany złożoną strukturą wewnętrzną, trudnym podejmowaniem decyzji lub wyznaczaniem kierunków. Firmy działające sprawnie na poziomie małych zespołów projektowych często szukają możliwości zwiększenia skali.

Wiele przedsiębiorstw radzi sobie dobrze bez skalowania Scruma. Nawet jeśli wiele Zespołów Scrumowych działa jednocześnie, nie potrzebują koordynacji, ponieważ grupy działają niezależnie. Nie oznacza to jednak, że jest to Scrum wielozespołowy. Potrzeba skalowania pojawia się tylko wtedy, gdy większość organizacji pracuje nad jednym produktem i może skutecznie zsynchronizować wiele zespołów Scrumowych.

Większość organizacji, które stosują zwinne metody zarządzania na dużą skalę, wybiera model SAFE lub Scaled Agile Framework. Dziś jednak nie skupimy się na SAFE , ale omówimy inny model o nazwie [email protected] , ponieważ według 15. raportu State of Agile z 2021 r., jest to drugi najlepszy wybór wśród firm, które wybierają agile.

[e-mail chroniony]

W 1996 roku twórcy Scrum, Jeff Sutherland i Ken Schwaber, pracowali nad dużym projektem. Kiedy to robili, mieli problemy z utrzymaniem synchronizacji mniejszych zespołów pracujących w Scrumie. Wymyślili sposób na skalowanie, który w końcu nazwali [ochrona poczty e-mail]

Analogicznie do oficjalnego Scrum Guide był przewodnik [email protected] , który definiuje ten sposób skalowania pracy jako:

Struktura, w której sieci Zespołów Scrumowych działają zgodnie z Przewodnikiem Scrumowym, aby rozwiązywać złożone problemy adaptacyjne i kreatywnie dostarczać produkty o jak największej wartości.

Podstawowym założeniem [email protected] jest prostota i wydajność. Dlatego jego działanie opiera się na architekturze bezskalowej. Innymi słowy, używa Scrum do skalowania Scrum. W ten sposób zespół scrumowy złożony z osób pełniących rolę Product Ownera, Scrum Mastera lub Developera staje się Scrum of Scrums: zespołem składającym się z zespołów.

Scrum Scrumów

Scrum of Scrums to zespół scrumowy, w którym ludzie pełnią tradycyjne role Scrumowe. Ponieważ jednak zadaniem Scrum of Scrums jest integracja wyników pracy kilku Zespołów Scrumowych, potrzebne są dodatkowe stanowiska:

  • Product Owner Team – grupa Product Ownerów, którzy spotykają się, aby uzgodnić priorytety i stworzyć spójną wizję produktu
  • Główny Właściciel Produktu – Właściciel Produktu Zespołu Scrumowego lub osoba zajmująca się wyłącznie Scrumem Scrum
  • Scrum of Scrums Master – osoba, która nadzoruje skuteczność Scrum of Scrums.

Spotykają się na tych samych wydarzeniach Scrum i używają podobnych artefaktów.

Scaling Scrum

Dalsze problemy ze skalowaniem i [ochroną poczty e-mail]

Bezskalowa architektura [email protected] oznacza , że ​​umożliwia skalowanie więcej niż jeden raz. Jeśli organizacja potrzebuje koordynować zespoły na jeszcze większą skalę, może skonfigurować Scrum of Scrums.

Jednak skalowanie Scrum, jak każda inna metodologia zarządzania, ma swoje wady i w tym przypadku są one podobne do tych z podstawowych Zespołów Scrumowych, tyle że proporcjonalnie większe. Dlatego zalecamy wypracowanie szczegółów współpracy w ramach każdego Zespołu Scrumowego przed rozpoczęciem Scruma na większą skalę. Sugerujemy skalowanie Scrum doświadczonym zespołom, które dobrze znają i rozumieją wartości i zasady działania Scrum.

scaling

Skalowanie Scrum – podsumowanie

Skalowanie Scrum nie jest dziecinnie proste. Wymaga to od Zespołów Scrumowych umiejętnego stosowania zasad Scrum i synchronizowania zadań z innymi Zespołami Scrumowymi. Dlatego podstawowe pytanie, na które należy odpowiedzieć, brzmi: czy potrzebne jest skalowanie? To, że w organizacji jest wiele Zespołów Scrumowych, nie oznacza automatycznie, że ich koordynacja przyniesie lepsze rezultaty.

Jeśli organizacja zdecyduje się na rozszerzenie Scrum, zyskuje architekturę bez skalowania, którą można z powodzeniem dalej rozszerzać. Każdej augmentacji towarzyszy jednak wzrost poziomu złożoności, z jakim muszą sobie radzić Zespół Właściciela Produktu, Główny Właściciel Produktu oraz Scrum of Scrums Master.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Twitterze, LinkedIn, Instagramie, YouTube, Pintereście.

Scrum Guide | 16. Scaling Scrum caroline becker avatar 1background

Autor: Caroline Becker

Jako Project Manager Caroline jest ekspertem w znajdowaniu nowych metod projektowania najlepszych przepływów pracy i optymalizacji procesów. Jej zdolności organizacyjne i umiejętność pracy pod presją czasu sprawiają, że jest najlepszą osobą do realizacji skomplikowanych projektów.

Zobacz wszystkie posty

Przewodnik po Scrumie:

  1. Słowniczek podstawowych pojęć, ról i pojęć
  2. Co to jest Scrum?
  3. Wartości Scrum
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Zespół Scrumowy - co to jest i jak działa?
  6. Kim jest Product Owner?
  7. Najczęstsze błędy Product Ownera
  8. Kim jest Scrum Master?
  9. Charakterystyka dobrego Scrum Mastera
  10. Najczęstsze błędy Scrum Mastera
  11. Jakie statystyki i metryki powinien śledzić Scrum Master?
  12. Współpraca Product Ownera ze Scrum Masterem
  13. Zespół Deweloperski w Scrum
  14. Najczęstsze błędy programistów
  15. Artefakty Scrum
  16. Skalowanie Scrum
  17. Backlog Sprintu
  18. Czym jest Backlog Produktu?
  19. Czym są historie użytkowników?
  20. Tworzenie najlepszej historii użytkownika z INVEST
  21. Najczęstsze błędy User Story
  22. Kryteria akceptacji historii użytkownika
  23. Szacowanie i punkty fabularne w Scrumie
  24. Poker Planowania
  25. Drużynowa gra szacowania
  26. Definiowanie przyrostu
  27. Wydarzenia scrumowe
  28. Czym jest Sprint w Scrumie?
  29. Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
  30. Co to jest wykres spalania?
  31. Jak stworzyć i zinterpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Velocity in Scrum - Szybkość Zespołu Deweloperskiego
  35. Codzienny Scrum
  36. Planowanie sprintu
  37. Przegląd sprintu
  38. Czym jest retrospektywa sprintu?
  39. Typowe błędy podczas Retrospektywy Sprintu
  40. Pielęgnacja Backlogu Produktu