blog.testowka.pl

Wskroś funkcjonalność zespołu

opublikowany przez 04, Gru, 2012, w kategoriach Agile, Scrum, Zarządzanie

O  kros-funkcjonalności zespołów już kiedyś pisałem niemniej jednak warto ten temat poszerzyć. Wiemy już wszyscy, że zespół kros-funkcjonalny to taki, który posiada wszystkie umiejętności, które są potrzebne, by co iterację dostarczać potencjalnie gotowy do wydania inkrement i przeważnie nie potrzebuje do tego pomocy z zewnątrz. Ale co to tak właściwie znaczy? Jakie są te wszystkie umiejętności?

Zespół kros-funkcjonalny powinien posiadać kompetencje techniczne pozwalające na dostarczanie produktu. Powinien zatem mieć kogoś o umiejętnościach analitycznych, kto przeanalizuje wymagania i sprawdzi ich kompletność. Powinien mieć kogoś o umiejętnościach projektowania architektury, kto zaprojektuje dane rozwiązanie. Powinien mieć kogoś, kto wydevelopuje to rozwiązanie. Powinien w skład takiego zespołu wchodzić ktoś, kto sprawdzi czy wytworzona funkcjonalność nie zawiera błędów i czy została poprawnie zintegrowana z resztą systemu. Oczywiście może to być jedna osoba, która posiada kompetencje we wszystkich powyższych zakresach. Może to być kilka osób posiadających po kilka umiejętności, będących lepszymi w jednym z zakresów odpowiedzialności takiego zespołu a słabszymi w innych.

Nie ma problemu – zbudowanie takiego zespołu nie jest jakoś specjalnie trudne. Wystarczy w organizacji, która decyduje się na wprowadzenie kros-funkcjonalnych zespołów pozbierać ludzi z różnych działów i posadzić razem by nauczyli się pracować wspólnie. Oczywiście uformowanie się zespołu zajmie trochę czasu i pewnie po drodze pojawi się mnóstwo problemów do rozwiązania ale w większości przypadków powinno się udać.

Czy powyższe wystarczy by osiągnąć kros-funkcjonalność? Czy taki zespół będzie w stanie dostarczać inkrementy? Moim zdaniem nie zawsze – pytanie czym jest ten inkrement? Pytanie czym jest nasz produkt? Inkrement musi być w pełni działający i potencjalnie gotowy do wydania, co oznacza, że musi być zintegrowany. Problemu nie ma gdy nad produktem pracuje jeden czy dwa zespoły – integracja zachodzi w sposób ciągły i można poukładać pracę w taki sposób by zespoły nie wchodziły sobie w drogę. Sytuacja komplikuje się, gdy nad produktem pracuje znacznie więcej osób. Integracja staje się poważnym problemem i często nawet pomimo Continuous Integration zajmuje dużo czasu i powoduje wiele błędów. Oczywiście wszystko opiera się o komunikację pomiędzy tymi zespołami, oraz ustalenie wspólnych celów i klarowne rozpropagowanie wizji produktu jako całość a nie tylko poszczególne komponenty.

Idąc dalej tą drogą należało by usunąć bariery komunikacyjne pomiędzy zespołami i rozproszyć wiedzę. Colective Code Ownership jest pierwszym krokiem w tym kierunku. Aby zespół był wskroś-funkcjonalny i mógł dostarczać w pełni zintegrowany produkt co iterację potrzebne jest coś więcej niż tylko kros-funkcjonalność na poziomie umiejętności i kompetencji. Potrzebna jest również kros-funkcjonalność na poziomie znajomości budowanego produktu.

Problemem może okazać się tu zbytnia złożoność i skomplikowanie architektury produktu. Niestety z wielu różnych ewolucyjnych powodów większość produktów IT rośnie w zastraszającym tempie bez konkretnej wizji i pomysłu na architekturę, która pozwalała by na uniezależnienie od siebie poszczególnych komponentów. W takiej sytuacji powołanie zespołu, który poza kros-funkcjonalnością na poziomie umiejętności byłby również kros-funkcjonalny pod względem wiedzy na temat całego produktu jest wręcz niemożliwe. Niemniej jednak nie znaczy to, że nie można próbować. Rozproszenie wiedzy na temat całego produktu pomiędzy zespołami w efekcie może zaowocować stworzeniem spójnej wizji architektury stosowanych rozwiązań – co w efekcie sprawi, że refaktoryzacja będzie przebiegała w określonym kierunku.

Nawet jeśli jesteśmy w stanie powołać zespół/zespoły, które będę wskroś-funkcjonalne w obydwu wspomnianych powyżej wymiarach to jeszcze nie koniec zapewnienia kros funkcjonalności. Dopiero teraz zabawa się zaczyna. Dla takiego zespołu musimy w specjalny sposób formułować wymagania – „w specjalny sposób” czyli tak jak się powinno było to robić od początku. Wymagania muszą przecinać wszystkie warstwy i komponenty naszego systemu. Tworzenie wymagań z perspektywy użytkownika np. w formie User Stories powinno tutaj wystarczyć.

Ci z Was, którzy pracują nad „małymi” produktami wytwarzanymi przez małą ilość zespołów zapewne nie odczuwają opisanych powyżej problemów, natomiast pozostali zapewne teraz zastanawiają się jak wiele wspaniałych możliwości daje posiadanie w pełni wskroś-funkcjonalnych zespołów.


Skomentuj