Kilka słów o Zespole Deweloperskim w Scrumie [agilestarter]

Zespół DeweloperskiZespół Deweloperski stanowi – obok roli Product Ownera oraz Scrum Mastera – główny trzon Zespołu Scrumowego. Co ważne, mówiąc o nim “deweloperski”, mam tu na myśli wszystkie role, które są konieczne, aby zespół na koniec Sprintu mógł pokazać działający kawałek produktu. Innymi słowy, nieważne czy jesteś programistą, testerem czy analitykiem biznesowym – w Scrumie każdą osobę, niezależnie od roli, nazywamy Deweloperem.

Takie nazewnictwo wzmacnia fakt, iż każda osoba ma wkład w rozwój produktu oraz zmniejsza antagonizmy, które potrafią zrodzić się pomiędzy rolami. Zestawienie wielu różnych ról w jednym miejscu może być nowością dla kogoś, kto pracował w organizacji o strukturze silosowej (pracownicy zorganizowani są wokół konkretnych działów – np. Dział Testów, Dział Analizy Biznesowej itd.), natomiast jest naturalnym i preferowanym sposobem komponowania zespołów w środowiskach zwinnych.

Nie dość, że osoby z różnymi kompetencjami tworzą jeden zespół, to na dodatek zespół taki powinien charakteryzować się zdolnością do samoorganizacji. W odróżnieniu od klasycznie prowadzonych zespołów (tzn. istnieje ktoś, kto mówi zespołowi jak powinien pracować), zespoły w Scrumie uczą się, jak samodzielnie podejmować decyzje, zarządzać i organizować swoją pracę. W praktyce oznacza to, że zespół sam odpowiada na pytanie “jak to zrobić”, otrzymując od Product Ownera wyłącznie informację mówiącą o tym, co ten chciałby uzyskać na koniec Sprintu.

Poniżej kilka przykładów, jak może wyglądać samoorganizacja w Zespole Deweloperskim:

  • zespół sam przeprowadza Daily Scrum – nie jest konieczna moderacja Scrum Mastera, zdarzenie może przybierać różną formę w zależności od potrzeb zespołu, nikt nie musi przypominać zespołowi o tym zdarzeniu,
  • podczas Planowania Sprintu nikt nie przypisuje zadań konkretnym osobom w zespole – Zespół Deweloperski dokonuje tego we własnym zakresie, biorąc pod uwagę swoje aktualne możliwości,
  • zespół samodzielnie pielęgnuje Product Backlog, rozumie dlaczego warto poświęcić czas na to zdarzenie, w zależności od kondycji Product Backlogu zmniejsza lub zwiększa ilość potrzebnych sesji per Sprint.

Warto zaznaczyć, iż samoorganizacja nie oznacza, że zespół funkcjonuje w próżni i nie dotyczą go żadne ograniczenia. Oznacza to raczej, że w obrębie określonych przez organizację ram, zespoły mogą podejmować pewne decyzje samodzielnie, nie naruszając przyjętych granic. Dla przykładu, firma może określić, że błędy produkcyjne muszą zostać obsłużone w czasie nie dłuższym niż 12h od zgłoszenia. Wybór sposobu, w jakim zespół podchodzi do rozwiązywania błędów (np. “jedna osoba od obsługi błędów ustalana na cały Sprint”, “codzienna rotacja” czy “osoba, która właśnie zakończyła zadanie ze Sprintu, rozwiązuje błąd o najwyższym priorytecie”) pozostaje po stronie zespołu. Kilka inspiracji związanych ze wzmacnianiem samoorganizacji zespołów, m.in. poprzez zwiększanie ich autonomii możecie znaleźć w artykule z przemyśleniami po lekturze “Drive” Dana Pinka.

Drugim istotnym atrybutem Zespołu Deweloperskiego jest jego interdyscyplinarność. Oznacza to, że zespół jest tak skonstruowany, że posiada wszelkie kompetencje potrzebne do wytworzenia działającego rozwiązania. Przykładowy zespół może się składać z kilku programistów, kilku testerów, administratora systemów oraz projektanta UX. Nie oznacza to jednak – wbrew powszechnie panującemu mitowi – że np. tester musi umieć programować, a projektant UX pisać testy automatyczne. Jeżeli zespół posiada wszystkie wymagane kompetencje, może niezależnie i bez zbędnych przestojów produkować funkcjonalności. Posiadanie wszystkich niezbędnych ról w zespole automatycznie zmniejsza też ilość zależności zewnętrznych, które niekorzystnie wpływają na przewidywalność zespołu.

Pomimo, iż chcemy mieć w zespole wszystkie potrzebne role, rozmiar zespołu w Scrumie nie jest nieograniczony. Scrum Guide określa go jako przedział: od 3 do 9 osób. Logika stojąca za tymi liczbami jest następująca – zespół z mniej niż trzema osobami może cierpieć na brak kompetencji, więcej niż 9 osób powoduje duży narzut komunikacyjny oraz zarządczy. W sieci dostępna jest masa artykułów dotyczących idealnego rozmiaru zespołu, w których autorzy próbują ustalić jedną, konkretną liczbę gwarantującą optymalną pracę. Inną, mniej “poważną” miarą wielkości zespołu jest popularna “Zasada 2 Pizz” Jeff’a Bezos’a, szefa Amazonu, który uważa, że jeśli nie nakarmisz zespołu dwoma pizzami, zespół jest za duży. Niezależnie od wiedzy dostępnej w książkach oraz internecie, sensowne wydaje się empiryczne podejście do ustalania rozmiaru zespołu, w zależności od zastanych okoliczności.

Bez względu na jego rozmiar, zespół jako całość – a nie pojedyncze osoby w zespole – jest odpowiedzialny za wykonaną pracę. Pomimo, iż niepowodzenia mogą mieć wiele źródeł (np. błędy w kodzie, nieszczelne testy, błędna analiza wymagań, błąd w konfiguracji środowiska produkcyjnego, “wrzutki” spoza Sprintu), to Zespół Deweloperski w całości jest odpowiedzialny za końcowy rezultat. Założenie takie wzmacnia zgranie zespołu oraz minimalizuje ryzyko “grania pod siebie” poprzez konkretne, wyspecjalizowane role w zespole.

Warto na koniec wspomnieć także o braku stałych podzespołów w ramach Zespołu Deweloperskiego. Szczególnie w organizacjach, które stosunkowo niedawno rozpoczęły proces transformacji w kierunki zwiększonej zwinności, może pojawić się pokusa tworzenia podzespołów. Przykładowo – może zostać zaproponowana propozycja stworzenia podzespołu programistów oraz podzespołu testerów. Ten pozornie logiczny podział kompetencyjny zwyczajowo źle wpływa na przepustowość oraz przewidywalność procesu deweloperskiego oraz zachęca do ograniczenia odpowiedzialności za efekt pracy Zespołu Scrumowego (np. “ja swój kawałek zrobiłem”). Zwykle tego typu podejście jest próbą zachowania starych przyzwyczajeń lub to po prostu zwykły brak wiedzy, która pozwoliłaby podjąć lepsze decyzje, dotyczące tworzenia i utrzymywania zespołów scrumowych.

Źródło zdjęcia: Bramley Phoenix 2XV v York 3XV 16112013-28.jpg via photopin (license)

Komentarze do wpisu: “Kilka słów o Zespole Deweloperskim w Scrumie [agilestarter]

  1. Back to basics ważna sprawa 🙂

    Jeśli jesteśmy przy kompozycji zespołu ciekawi mnie, jak inni podchodzą do przykładowej, ale dosyć często spotykanej, sytuacji: 7 osobowy zespół, który jest interdyscyplinarny i posiada kompetencje niezbędne do dostarczenia przyrostu. Wśród nich są 2 osoby, które są specjalistami w swojej działce, mają obłożenie pracą na poziomie 50%, tj. UX Designer, Ops.

    W szczególności chodzi mi o adresowanie takich kwestii jak:
    – poczucie przynależności do zesp0łu (w konsekwencji wpływ na zaangażowanie),
    – radzenie sobie z poczuciem, że nie jest w pełni wykorzystywany czyiś* potencjał,
    – linia obrony przed zarzutami, że to jest zbyt kosztowne rozwiązanie.

    *http://sjp.pwn.pl/szukaj/czyiś.html

    • Jacek Wieczorek

      Cześć Bartek, dzięki za Twój komentarz.

      Spotkałem się z podaną przez Ciebie konfiguracja na przykładzie roli UX w różnych firmach, chociaż oczywiście pod “UX” można podstawić dowolną inną rolę.

      Jeśli chodzi o przynależność do zespołu, to dużo zależy od tego, czy wspomniane przez Ciebie poczucie zespołowości jest wspierane, czy też nie. Kilka przykładów wspierania:

      – równorzędne traktowanie roli UX oraz pozostałych ról na poziomie komunikacji oraz zachowań, np. włączenie do oficjalnego aliasu mailowego zespołu, branie zdania UX pod uwagę w kwestiach nie tylko związanych z UX, unikanie konstrukcji “my” i “wy” w komunikacji
      – siedzenie w jednej przestrzeni, codziennie część dnia lub w wybrane dni cały dzień; powoduje to, że ZAWSZE jest wolne biurko dla UX w pokoju zespołu i unikamy tej niezręcznej sytuacji, gdy osoba przychodzi i nie ma gdzie usiąść
      – branie udziału we wspólnych rytuałach, np. wspólne śniadania czy wspólne granie w Counter Strike co piątek o 17:00
      – udział w wyjściach integracyjnych
      – układanie zdarzeń w zespole tak, aby nie nakładały się czasowo ze zdarzeniami z drugiego zespołu, który jest wspierany przez UX, np. Sprint Review czy Planning w takich dniach/godzinach, aby UX mógł uczestniczyć

      Co do radzenia sobie z poczuciem, że nie do końca wykorzystujemy czyiś potencjał, to zakładam, że chodzi o poczucie, że gdybyśmy mieli dodatkowe 50% UX (oprócz tych które już mamy), to mogli byśmy dostarczyć więcej wartości. Zapewne taki układ wynika z jakiś ograniczeń (np. brak budżetu po stronie klienta, problemy z rekrutacją odpowiedniej liczby osób, nie wystarczająca ilość pracy UX w konkretnym produkcie). Jeśli nie są to sytuacje, na które mamy niewielki wpływ, to próbowałbym pokazać, co tracimy oraz co moglibyśmy zyskać, gdyby zaangażować UX w większym stopniu. W praktyce realizacja może polegać na przedstawieniu klientowi/osobie decyzyjnej faktów (najlepiej w postaci liczb), które są argumentacją naszej propozycji, np. gdybyśmy mogli zaangażować UX na 100% moglibyśmy popracować nad obniżeniem współczynnika porzuceń koszyka w sklepie internetowym, który przekłada się na mniejszy obrót.

      Nawiązuje to do Twojego trzeciego pytania – moim zdaniem ostatecznie wszystko rozbija się o zyski i koszty. Nie zaadresowanie  problemów UX to często też koszt, tylko mniej widoczny lub zupełnie ukryty. Tak jak wspomniałem wcześniej, to kwestia argumentacji i odpowiednio dobranych przykładów. Moje obserwacje są takie, że temat UX nadal jest świeży (co ciekawe, nie tylko w PL), co powoduje, że trzeba włożyć dużo pracy w ewangelizację.

      Powodzenia!

  2. Dzięki Jacek.

    pisząc „radzenie sobie z poczuciem, że nie jest w pełni wykorzystywany czyiś potencjał” miałem na myśli co innego. Już doprecyzowuję.
    Chodziło mi o poczucie osoby, która jest w zespole i której to potencjał nie jest w pełni wykorzystany, ponieważ nie ma takiej możliwości.

    Przykład. Grafik jest częścią zespołu i pracuje z nim na codzień. Przy czym zajmuje tylko maksymalnie 50% jego dostępności. To oznacza, że Grafik ma dużo wolnego czasu. Jednocześnie trudno zaplanować jego pracę, w końcu projekt wybrał Scruma po to, aby radzić sobie z niepewnością na codzień.

    Poprzez radzenie sobie z taką sytuacją ciekawią mnie rozwiązania inne niż ulokowanie go w 2 zespołach na 50%, ponieważ to oznacza context-switching.

    Ma to sens?

  3. Kolejny fajny wpis u Was – dzięki 🙂

    Chciałbym poznać Wasze podejście w kontekście silosów w zespołach budujących oprogramowanie na urządzenia mobilne. Mam wrażenie, że w takiej konfiguracji podział pracy następuje w sposób naturalny, bo mamy Deweloperów na platformy Android, iOS, a czasem nawet i Windows Phone (niebawem Windows 10).

    W tej sytuacji silosy tworzą się same, bowiem Deweloperzy zajmują się jedynie „swoimi” zadaniami.

    Spotkaliście się może z takim wyzwaniem? Jak w tej sytuacji wzmacniać odpowiedzialność Zespołu za wszystkie zadania w Sprincie?

  4. Jacek Wieczorek

    Dzięki! Nawiązując do Twojego pytania – jeśli chodzi o wzmacnianie odpowiedzialności za wszystkie zadania, bazując na tym co zrozumiałem, to przychodzą mi do głowy poniższe pomysły:

    – jako, że jestem przeciwnikiem podejścia “jestem deweloperem, więc nie testuję, bo nie mam mindsetu testerskiego”, pomyślałbym o wzajemnym wspieraniu się chociażby w obszarze testowania aplikacji,

    – idąc dalej wiem, że nie jest niczym zaskakującym, że ktoś kto ma doświadczenie w pisaniu aplikacji na platformę Android, zaczyna uczyć się pisać kod na iOS; staje się w ten sposób wszechstronnym deweloperem mobilnym, który nie tylko może wspomóc testy, ale też napisać kod na więcej niż jednej platformie,

    – pytanie też, jak wygląda sprawa backendu: czy korzystacie z zewnętrznego API utrzymywanego przez innego dostawcę, czy piszecie to samodzielnie? zadania backendowe, jeżeli pisane w jednej technologii (np. Python czy Java) również mogą być czymś, co mogłoby budować odpowiedzialność zespołu chociażby na poziomie warstwy technologicznej, a to już coś!

    – jeśli chodzi o zdarzenia scrumowe, to wyobrażam sobie, że pierwsza część Planowania Sprintu mogła by być interesująca dla całego zespołu (niezależnie od technologi), natomiast druga część – ta bardziej zależna od technologi, mogłaby być realizowana oddzielnie,

    – sensowne wydaje mi się też wspólne Sprint Review, zakładając, że produkt niezależnie od platformy ma sporą część wspólną niezależnie od platformy technologicznej,

    – wszelkiego rodzaju warsztaty i burze mózgów dotyczące produktu od strony biznesowej realizowałbym całym zespołem.

    Co myślisz?

  5. Cześć Jacku.

    Ze Scrum-em mam już doczynienia parę lat i chcę podzielić się dla mnie najtrudniejszą kwestią jeśli chodzi o Zespół Deweloperski – jak pogodzić sprint planning oraz cel sprintu, gdy w zespole są jednocześnie role typu Designer (Graphic / UI / UX) oraz Programmer.

    Już wyjaśnię, gdzie jest największy problem, nie sądzę, żeby był on bardzo nietypowy. Myślę, że większość zespołów może się z nim borykać. Weźmy na początek planowanie sprintu, w którym biorą wszyscy członkowie zespołu, więc zarówno designerzy jak i programiści. Zastanawiając się nad estymatami (czy podczas backlog refinementu, czy podczas planningu) programiści mówią, że nie mogą dać wiarygodnej estymaty, dopóki nie będą mieli bardziej szczegółowej specyfikacji niż tylko historyjka. Potrzebują wiedzieć ile dany ficzer będzie miał stanów, screenów, popupów i generalnie use-case’ów. Czyli inaczej mówiąc, będą mogli podjąć zadanie programistyczne dopiero wtedy, gdy grafiki, UX i UI będą zaprojektowane.
    Powoduje to sytuację, że do tej pory prowadziłem tak jakby dwa nurty – jeden dla designerów, których celem było wytworzenie materiału dla programistów na następny sprint, a w tym samym czasie programiści programowali to, co deisgnerzy wytworzyli sprint wcześniej. Prowadziło to do tego, że sensowniej było rozbić pracę tych dwóch zespołów i stworzyć dwa osobne zespoły, żeby każdy mógł realizować swoje cele. Bo przecież w scrumie, cały zespół ma pracować nad wspólnym przyrostem.
    Żeby utrzymać komunikację między tymi zespołami, raz lub w razy w tygodniu mieliśmy wspólne daily scrumy, żeby móc wymienić się informacjami na temat postępów prac, sprawdzić czy nie pojawiają się nowe zależności, które mogą wpływać na pracę jednego lub drugiego teamu.

    Chciałbym poznać twoje zdanie na możliwe rozwiązania tego problemu oraz być może jakieś przykłady z życia wzięte 🙂

    Pozdrawiam i gratuluję super roboty!


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x