{"id":593,"date":"2022-01-26T01:46:08","date_gmt":"2022-01-26T01:46:08","guid":{"rendered":"https:\/\/www.cybermedian.com\/pl\/?p=593"},"modified":"2025-02-14T16:38:50","modified_gmt":"2025-02-14T08:38:50","slug":"cross-functional-vs-self-organizing-vs-feature-vs-component-teams-in-agile","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/pl\/cross-functional-vs-self-organizing-vs-feature-vs-component-teams-in-agile\/","title":{"rendered":"Zespo\u0142y mi\u0119dzyfunkcyjne vs Zespo\u0142y samoorganizuj\u0105ce si\u0119 vs Zespo\u0142y funkcjonalne vs Zespo\u0142y komponentowe w Agile"},"content":{"rendered":"
\n
\n
\n

Tradycyjnie projekt jest organizowany wok\u00f3\u0142 zespo\u0142\u00f3w komponentowych<\/strong> (tj. UX, Dev, Biznes, Tester itd.), ka\u017cda wersja, kt\u00f3ra wymaga zakresu wiedzy o komponentach, b\u0119dzie musia\u0142a anga\u017cowa\u0107 wiele zespo\u0142\u00f3w komponentowych. Zazwyczaj r\u00f3\u017cne zespo\u0142y maj\u0105 r\u00f3\u017cne zestawy priorytet\u00f3w, co nieuchronnie prowadzi do w\u0105skich garde\u0142 w cyklu wydania produktu.<\/p>\n

Wed\u0142ug Wikipedii zesp\u00f3\u0142 mi\u0119dzyfunkcyjny to grupa ludzi o r\u00f3\u017cnych specjalizacjach funkcjonalnych, pracuj\u0105cych w kierunku wsp\u00f3lnego celu. Jednym z najlepszych sposob\u00f3w na popraw\u0119 jako\u015bci zespo\u0142u jest uczynienie go mi\u0119dzyfunkcyjnym. Zesp\u00f3\u0142 mi\u0119dzyfunkcyjny ma wszystkie niezb\u0119dne umiej\u0119tno\u015bci, aby przekszta\u0142ci\u0107 pomys\u0142 w dzia\u0142aj\u0105cy produkt.<\/p>\n

\u201cZesp\u00f3\u0142 <\/em>Zespo\u0142y mi\u0119dzyfunkcyjne<\/em><\/strong> maj\u0105 wszystkie kompetencje potrzebne do wykonania pracy bez polegania na innych, kt\u00f3rzy nie s\u0105 cz\u0119\u015bci\u0105 zespo\u0142u<\/em>\u201d\u200a\u2014\u200aPrzewodnik Scrum<\/p>\n

W przeciwie\u0144stwie do podej\u015bcia zespo\u0142u komponentowego, zespo\u0142y mi\u0119dzyfunkcyjne<\/strong> s\u0105 grupami sk\u0142adaj\u0105cymi si\u0119 z ludzi z r\u00f3\u017cnych obszar\u00f3w funkcjonalnych firmy.\u200a\u2014\u200apowinny by\u0107 tworzone nie tylko z technicznych specjalist\u00f3w (programist\u00f3w Back-end, Front-end, in\u017cynier\u00f3w QA itd.), ale tak\u017ce z cz\u0142onk\u00f3w takich jak analitycy biznesowi, specjali\u015bci ds. marketingu i UX lub ktokolwiek inny, kto aktywnie uczestniczy w projekcie.<\/p>\n

<\/figure>\n

Zesp\u00f3\u0142 samoorganizuj\u0105cy si\u0119<\/strong> jest zespo\u0142em, kt\u00f3ry ma autonomi\u0119 w wyborze najlepszego sposobu realizacji swojej pracy, zamiast by\u0107 kierowanym przez innych spoza zespo\u0142u. W przeciwie\u0144stwie do tradycyjnych zasad zarz\u0105dzania, samoorganizuj\u0105ce si\u0119 zespo\u0142y nie s\u0105 kierowane i kontrolowane z g\u00f3ry; raczej ewoluuj\u0105 z cz\u0142onk\u00f3w zespo\u0142u aktywnie i wsp\u00f3lnie uczestnicz\u0105cych we wszystkich praktykach i wydarzeniach Scrum.<\/p>\n

<\/figure>\n

Zesp\u00f3\u0142 tradycyjny vs Zesp\u00f3\u0142 Agile<\/p>\n

\u201eZesp\u00f3\u0142 <\/em>Samoorganizuj\u0105cy si\u0119 Zesp\u00f3\u0142<\/em><\/strong> sk\u0142ada si\u0119 z grupy pracownik\u00f3w wiedzy, kt\u00f3rzy musz\u0105 zarz\u0105dza\u0107 sob\u0105. Musz\u0105 mie\u0107 autonomi\u0119\u201d\u200a\u2014\u200a<\/em>Peter Drucker.<\/p>\n

Przewodnik Scrum wskazuje: \u201eZesp\u00f3\u0142 Scrum sk\u0142ada si\u0119 z W\u0142a\u015bciciela Produktu, Zespo\u0142u Deweloperskiego i Mistrza Scrum. S\u0105 to:<\/p>\n

Zespo\u0142y Scrum<\/strong> s\u0105 samoorganizuj\u0105ce si\u0119<\/strong> i mi\u0119dzyfunkcyjne<\/strong>\u201d\u200a\u2014\u200a<\/em>Przewodnik Scrum:<\/p>\n

Zesp\u00f3\u0142 komponentowy vs Zesp\u00f3\u0142 funkcjonalny<\/h3>\n

Tradycyjne podej\u015bcie polega na podzieleniu produktu mniej wi\u0119cej logicznie i sensownie na komponenty oraz przypisaniu do nich zespo\u0142\u00f3w komponentowych. Jednak te komponenty s\u0105 ca\u0142kowicie nieistotne z punktu widzenia klienta.<\/p>\n

Podej\u015bcie zespo\u0142u funkcjonalnego jest obecnie niemal powszechnie akceptowanym sposobem organizacji zespo\u0142\u00f3w, w przeciwie\u0144stwie do zespo\u0142u technologicznego, szczeg\u00f3lnie w podej\u015bciu ci\u0105g\u0142ej dostawy, podkre\u015bla funkcje (tj. pionowy przekr\u00f3j systemu), kt\u00f3re rozwi\u0105zuj\u0105 potrzeby u\u017cytkownik\u00f3w, co zazwyczaj mo\u017ce przyspieszy\u0107 dostarczanie warto\u015bci jakichkolwiek funkcji lub dzia\u0142aj\u0105cego oprogramowania oraz skr\u00f3ci\u0107 p\u0119tl\u0119 informacji zwrotnej od rzeczywistych u\u017cytkownik\u00f3w. Zesp\u00f3\u0142 funkcjonalny mia\u0142by wszystkie umiej\u0119tno\u015bci potrzebne do wykonania niezb\u0119dnej pracy na poziomie zada\u0144, aby wykona\u0107 zadanie. W szczeg\u00f3lno\u015bci, zak\u0142adaj\u0105c architektur\u0119 tr\u00f3jwarstwow\u0105, cz\u0142onkowie zespo\u0142u pracowaliby nad zadaniami zwi\u0105zanymi z GUI, warstw\u0105 po\u015bredni\u0105 i baz\u0105 danych tej historii.<\/p>\n

<\/figure>\n

Du\u017c\u0105 wad\u0105 organizacji komponentowej jest oczywista: spowalnia przep\u0142yw warto\u015bci. Wi\u0119kszo\u015b\u0107 funkcji systemu tworzy zale\u017cno\u015bci, kt\u00f3re wymagaj\u0105 wsp\u00f3\u0142pracy mi\u0119dzy zespo\u0142ami komponentowymi w celu zbudowania, wdro\u017cenia i ostatecznego wydania. Zespo\u0142y sp\u0119dzaj\u0105 du\u017co czasu na omawianiu zale\u017cno\u015bci mi\u0119dzy zespo\u0142ami i testowaniu zachowa\u0144 mi\u0119dzy komponentami, zamiast by\u0107 w stanie dostarczy\u0107 warto\u015b\u0107 ko\u0144cowemu u\u017cytkownikowi.<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n