Tradycyjnie projekt jest organizowany wokół zespołów komponentowych (tj. UX, Dev, Biznes, Tester itd.), każda wersja, która wymaga zakresu wiedzy o komponentach, będzie musiała angażować wiele zespołów komponentowych. Zazwyczaj różne zespoły mają różne zestawy priorytetów, co nieuchronnie prowadzi do wąskich gardeł w cyklu wydania produktu.
Według Wikipedii zespół międzyfunkcyjny to grupa ludzi o różnych specjalizacjach funkcjonalnych, pracujących w kierunku wspólnego celu. Jednym z najlepszych sposobów na poprawę jakości zespołu jest uczynienie go międzyfunkcyjnym. Zespół międzyfunkcyjny ma wszystkie niezbędne umiejętności, aby przekształcić pomysł w działający produkt.
“Zespół Zespoły międzyfunkcyjne mają wszystkie kompetencje potrzebne do wykonania pracy bez polegania na innych, którzy nie są częścią zespołu” — Przewodnik Scrum
W przeciwieństwie do podejścia zespołu komponentowego, zespoły międzyfunkcyjne są grupami składającymi się z ludzi z różnych obszarów funkcjonalnych firmy. — powinny być tworzone nie tylko z technicznych specjalistów (programistów Back-end, Front-end, inżynierów QA itd.), ale także z członków takich jak analitycy biznesowi, specjaliści ds. marketingu i UX lub ktokolwiek inny, kto aktywnie uczestniczy w projekcie.
Zespół samoorganizujący się jest zespołem, który ma autonomię w wyborze najlepszego sposobu realizacji swojej pracy, zamiast być kierowanym przez innych spoza zespołu. W przeciwieństwie do tradycyjnych zasad zarządzania, samoorganizujące się zespoły nie są kierowane i kontrolowane z góry; raczej ewoluują z członków zespołu aktywnie i wspólnie uczestniczących we wszystkich praktykach i wydarzeniach Scrum.
Zespół tradycyjny vs Zespół Agile
„Zespół Samoorganizujący się Zespół składa się z grupy pracowników wiedzy, którzy muszą zarządzać sobą. Muszą mieć autonomię” — Peter Drucker.
Przewodnik Scrum wskazuje: „Zespół Scrum składa się z Właściciela Produktu, Zespołu Deweloperskiego i Mistrza Scrum. Są to:
Zespoły Scrum są samoorganizujące się i międzyfunkcyjne” — Przewodnik Scrum:
Zespół komponentowy vs Zespół funkcjonalny
Tradycyjne podejście polega na podzieleniu produktu mniej więcej logicznie i sensownie na komponenty oraz przypisaniu do nich zespołów komponentowych. Jednak te komponenty są całkowicie nieistotne z punktu widzenia klienta.
Podejście zespołu funkcjonalnego jest obecnie niemal powszechnie akceptowanym sposobem organizacji zespołów, w przeciwieństwie do zespołu technologicznego, szczególnie w podejściu ciągłej dostawy, podkreśla funkcje (tj. pionowy przekrój systemu), które rozwiązują potrzeby użytkowników, co zazwyczaj może przyspieszyć dostarczanie wartości jakichkolwiek funkcji lub działającego oprogramowania oraz skrócić pętlę informacji zwrotnej od rzeczywistych użytkowników. Zespół funkcjonalny miałby wszystkie umiejętności potrzebne do wykonania niezbędnej pracy na poziomie zadań, aby wykonać zadanie. W szczególności, zakładając architekturę trójwarstwową, członkowie zespołu pracowaliby nad zadaniami związanymi z GUI, warstwą pośrednią i bazą danych tej historii.
Dużą wadą organizacji komponentowej jest oczywista: spowalnia przepływ wartości. Większość funkcji systemu tworzy zależności, które wymagają współpracy między zespołami komponentowymi w celu zbudowania, wdrożenia i ostatecznego wydania. Zespoły spędzają dużo czasu na omawianiu zależności między zespołami i testowaniu zachowań między komponentami, zamiast być w stanie dostarczyć wartość końcowemu użytkownikowi.
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文