blog.testowka.pl

Niekoniecznie kros-funkcjonalny zespół

opublikowany przez 02, Sty, 2012, w kategoriach Agile, Scrum, Testowanie

Problemy z kros-funkcjonalnością zaczyna się już na etapie definicji zespołu kros-funkcjonalnego. Niestety zadając pytanie o to na czym polega kros-funkcjonalność bardzo często słyszę niepoprawne odpowiedzi.

Zespół jako całość ma posiadać kompetencje do tego by regularnie dostarczać oprogramowanie gotowe do wydania na produkcję – to jest wystarczająca definicja kros-funkcjonalności.

Ciężko jest mówić o kros-funkcjonalnych zespołach, opartych na ścisłej współpracy ich członków, dostarczających działające i przetestowane oprogramowanie na zakończenie każdej iteracji, gdy na przykład testerzy pracują w oddzielnym zespole niż programiści, często siedząc w osobnym pokoju, budynku, mieście, kraju, kontynencie – jak wtedy powiedzieć, że po zakończeniu każdej iteracji mamy działający produkt. „Scrumowy zespół testowy” to nie zespół Scrumowy.

Jeśli trzeba oprogramowanie testować (a gdzie nie trzeba?) to w skład zespołu powinni wchodzić testerzy. Jeśli do konfiguracji i wydania oprogramowania potrzebna jest praca administratora to taki administrator lub developer z odpowiednimi umiejętnościami powinien się w tym zespole znajdować. Warto wspomnieć jeszcze o tym, że taki zespół nie powinien być zbyt duży. Podział na zespoły funkcjonalne powoduje utworzenie silosów, pomiędzy którymi znajduje się ściana przez, którą jedni i drudzy przerzucają problemy na innych zamiast skupiać się na dostarczaniu wartości. Pisałem już wcześniej o probelmach komunikacyjnych, które także dotyczą takich wyspecjalizowanych zespołów zamkniętych w swoich silosach.

Niestety z powyższym wiąże się kilka problemów – np. problem ze znalezieniem odpowiednio wykwalifikowanych osób – często trzeba po prostu członków zespołu kros-funkcjonalnego szkolić od podstaw. Wszelkie protezy typu „Scrumowy Zespół Testowy” wspomniany powyżej nie będę działać tak wydajnie jak dobrze zmotywowane zespoły kros-funkcjonalne, Problem z silosami wynika też często z zaszłości historycznych – wcześniej organizacja musiała mieć określoną strukturę, posiadać poszczególne specjalistyczne działy i kierowników tych działów – niestety dla takich specjalistycznych kierowników w Agile raczej miejsca nie ma. Oczywiście mogą się oni przekwalifikować np. na Scrum Masterów, albo po prostu członków zespołu – niemniej jednak wraz z tym utracą „władzę” i większość mocy decyzyjnej – byćmoże stąd wynika częsty opór przed wdrożeniami Agile.

Powyższy post jest rozwinięciem kolejnej części prezentacji na temat przyczyn niepowodzeń wdrożeń Agile w organizacjach, którą od czasu do czasu wygłaszam przy różnych okazjach. Wkrótce pojawią się kolejne części opisujące kolejne problemy. Prezentacja oraz notka powstały na podstawie obserwacji moich i moich koleżanek i kolegów zajmujących się na co dzień wdrożeniami Agile, a także wielu godzin rozmów z różnymi ludźmi na tematy mniej lub bardziej związane z wdrożeniami Agile. Cały cykl możecie znaleźć tutaj.


3 Comments for this entry

  • bartek

    Podzielę się sytuacją z życia: w firmie w której pracuję (serwis internetowy) zespół ma kompetencje wystarczające do dostarczania oprogramowania, niemalże co tydzień, na środowisko testowe. Wgranie na środowisko produkcyjne wymaga zaangażowania administratora, który nie jest w zespole (jest w silosie). Mimo takiej konfiguracji mechanizm działa sprawnie. Wydaje się, że jest to możliwe m.in. dzięki dobremu workflow tasków administracyjnych i organizacji pracy (oczywiście nie działałoby to bez odpowiednich kompetencji programistów i administratorów).

  • spandor

    @Bartek, z tego co piszesz to u Was chyba jeszcze nie jest najgorzej. Gorzej byłoby jakby admin z produkcji, dostawał paczkę do promocji od admina który zarządza środowiskiem testowym. Powszechnym problemem jest również dość mocne oddzielanie dev back-endu od dev front-endu. Na końcu jest klops 🙂

  • marta

    Także z życia: pracuję obecnie w takim kros-funkcjonalnym zespole, gdzie sami zarządzamy swoimi zadaniami, a nasz manager wkracza do akcji jedynie w momentach ‚kryzysowych’, które z resztą nie zdarzają się zbyt często. Według mnie taka postawa menedżerska wymaga pewnej dojrzałości i ‚okrzepnięcia’ w agile’u, zdarzyło mi się pracować z osobami na średnim szczeblu kierownictwa, dla których transformacja do tak rozumianego zarządzania zespołem byłaby niemożliwa. Wiąże się to właśnie z poczuciem stracenia kontroli i znaczenia dla zespołu, a skutkuje niechęcią do choćby rozmów o zmianie podejścia do wytwarzania oprogramowania.

Skomentuj