Ilu programistów Javy trzeba, aby odtworzyć dzieła Szekspira?

Powyższe pytanie jest odniesieniem do znanego twierdzenia o małpach mających w losowy sposób napisać dzieła Szekspira ("infinite monkey theorem"). Eksperyment ten opisuje ciekawy paradoks, wg którego jednostki niekompetentne i nieszkolone w danej dziedzinie (np. małpy, nieobeznane z literaturą), mogłyby przy wielkiej ilości szczęścia, napisać chociażby dzieła Szekspira.

 

Gdzie związek z IT? W podobny sposób można by się zastanowić ilu programistów Javy potrzeba, aby ukończyć projekt, który wymaga znacznie szerszych kompetencji niż jedynie znajomość Javy i umiejętność programowania. Możemy zakładać, że projekt zostanie ukończony, ale czy będzie to wydajne?

Autor: Maciej Kochan, Lead Integration Developer, ProData Consult

Choć problem ten brzmi dość absurdalnie, doświadczenie pokazuje, że występuje on w praktyce. W zespołach projektowych istnieje pokusa zatrudnienia samych programistów, wychodząc z (niekoniecznie prawdziwych) założeń, takich jak:

  • Programiści to inteligentni ludzie, poradzą sobie nawet z zadaniami niekoniecznie programistycznymi
  • Łatwiej zatrudnić kolejnego programistę niż otworzyć nową rekrutację na inną, często pojedynczą rolę. Mamy już dla programistów pytania rekrutacyjne i testy, aktywne ogłoszenia, opisy stanowisk, aprobaty managementu itd.
  • Łatwiej douczyć programistę na np. Scrum Mastera niż Scrum Mastera na programistę
  • W naszym projekcie Scrum Master czy Produkt Owner będzie miał za mało pracy, aby uzasadnić pełny etat
  • W kryzysowych sytuacjach mamy więcej rąk do pisania kodu i naprawy błędów

 

Tak powstają zespoły złożone z samych programistów, gdzie niektórzy z nich z „doskoku” pełnią też inne, niezbędne w projekcie role. Ktoś jest „programistą Devopsem”, kto inny „programistą Project Managerem”, a jeszcze kto inny „programistą Scrum Masterem”.

O co tu chodzi?

W tym tekście chciałbym napisać o transformacji w naszym zespole, który zaczynał jako właśnie zespól samych programistów. Istotą zmian było dodanie wyspecjalizowanych ról takich jak Scrum Master, Product Owner i Analityk biznesowy. Proces zmian był szybki, trwał kilka miesięcy, co pozwala na porównanie jak pracowali ci sami programiści Javy, na podobnych zadaniach, ale wsparci nowym procesem i wymienionymi powyżej rolami.

Maciej_Kochan_20211019_163009

Początki

Nasz projekt zaczynał się prosto, zadania były konkretnie określone, a wyzwania przed nami były głównie techniczne. Z czasem wymagania ewoluowały, zakres projektu znacznie się rozszerzył, ilość zależności zewnętrznych i potrzeby koordynacji z innymi wzrosły co najmniej o rząd wielkości. To sprowokowało rozmowę z klientem o dalszym kierunku rozwoju projektu i zespołu, gdyż programiści mieli coraz mniej czasu na programowanie, a klienci nie mieli dobrego wglądu w postępy pracy.

Należy podkreślić wagę otwartości klienta, czyli de facto „właściciela” projektu. Założenie klienta było takie, że współpracuje z konsultantami, rozumiejącymi cel i zagadnienie na tyle dobrze, że to oni stoją w pozycji do zasugerowania najodpowiedniejszych środków do jego realizacji, w tym składu i kompetencji zespołu.

Na podstawie porozumienia z klientem, do istniejącego zespołu wyłącznie Javowców dołączył Scrum Master, Product Owner oraz Analityk biznesowy.

Co się zmieniło w codziennej pracy?

Metodologia pracy - po przyjściu doświadczonego Scrum Mastera, zaczęliśmy stosować sumiennie miary takie jak capacity, velocity, predictability, scope change. Scrum Master nakłonił nas do omawiania anomalii w powyższych miarach (np. ogromny scope change w sprincie, w którym poblokowaliśmy się na większości zadań w ciągu pierwszych dwóch dni), i zespołowych burz mózgów o tym jak takich anomalii unikać. Pojawiły się cele sprintu oraz łatwo przyswajalne wizualizacje postępu dla klientów, takie jak burndown charty dla sprintów jak i dla całego backlogu. Eventy scrumowe nabrały struktury i regularności. Scrum Master stał się też osobą gotową w każdej chwili i wielokrotnie tłumaczyć otoczeniu różnice między planem a zobowiązaniem, story pointami a pieniędzmi wydanymi z budżetu itp. Zespół developerski mógł cieszyć się dzięki temu ochroną przed dużą częścią „rozpraszaczy” zewnętrznych, powodujących wcześniej kosztowne zmiany kontekstu w codziennej pracy.

Backlog - programiści, przyjmowani do projektów na podstawie swoich kompetencji programistycznych, niekoniecznie muszą mieć umiejętności czy chęci do zarządzania backlogiem. Z tego powodu backlog był u nas groomowany z doskoku i porządkowany jedynie na tyle aby się w nim nie pogubić. Był on jednak słabo zrefinowany, a poszczególne stories bywały opisane skrótowo lub wcale. Aspektem, na który nie zwracaliśmy też uwagi, był fakt, że backlog był bardzo techniczny, i nieczytelny dla odbiorców produktu. Wprowadzenie Product Ownera, dysponującego po pierwsze doświadczeniem, a po drugie czasem na opiekę nad backlogiem, pomogło na te problemy oraz odciążyło programistów od ich prób zarządzania backlogiem. Product Owner stał się jednocześnie źródłem informacji o postępach prac dla interesariuszy na zewnątrz zespołu.

Zakres projektu i roadmapa - obecność Product Ownera bardzo pomogła przy trzymaniu ręki na pulsie i określaniu co już jest zrobione, co jeszcze pozostaje do zrobienia, kiedy planujemy to zrobić, i kogo musimy zawczasu zaangażować. W naszym projekcie takiej koordynacji jest dużo. Jeśli obciążyć tymi zadaniami developera, to de facto przestaje on być developerem, gdyż nie starczy mu czasu na inne obowiązki. Jeśli zaś rozdzielimy zadania zarządzania skomplikowanym projektem na kilku developerów, to wycinki projektu mogą poruszać się w różnym tempie, a o niektórych możemy przez rozmycie odpowiedzialności zapomnieć. Przypomina to budowanie fragmentów torów kolejowych przez wiele ekip –istnieje ryzyko, że nie spotkają się one w jednym miejscu.

Maciej_Kochan-hands_20211019_162954

Analiza biznesowa i dokumentacja - prowadzimy projekt w iteracjach. Są one z jednej strony podobne, z drugiej strony nigdy nie takie same, a każda z nich wymaga analizy i przygotowania. Powtarzalność wpływa na to, że analityk wykonujący te czynności co sprint, jest w stanie poprzez sam efekt rutyny i wprawy pracować sprawniej niż developer który robi te zadania jedynie czasami. Być może truizmem jest też podkreślenie lepszej efektywności analityka w dziedzinie analizy, ze względu na jego predyspozycje i doświadczenie. Dzięki temu od czasu wprowadzenia do projektu analityka, zadania trafiały na refinement opisane, z przynajmniej częściową dokumentacją dla zespołu developerskiego, a nawet dla końcowego klienta. Nietrudno sobie wyobrazić zachwyt programistów, którym nie groziło pisanie dokumentacji od zera, a jedynie uzupełnienie jej technicznych aspektów.

Dane testowe – częścią analizy i rozmów z klientami było omówienie use case’ów, scenariuszy testowych i danych testowych. W praktyce mogło to oznaczać np. pozyskanie danych wejściowych i wyjściowych z otaczających nas systemów, oraz zamieszczenie ich do repozytorium projektu, zanim jeszcze programiści rozpoczynali prace. Wpływ na wydajność programistów jest tu ogromny. Rozpoczynając prace nad danym story, scenariusze biznesowe i testowe były rozpoznane, wraz z dostępnymi przykładami spodziewanych komunikatów. Obecność przykładowych danych pośrednio dokumentowała zachowanie systemu, a bezpośrednio stanowiła wkład do testów jednostkowych i integracyjnych. W modelu bez analityka, programista musiał często przerywać prace nad funkcjonalnością, aby zrobić szczątkową analizę biznesową fragmentu, który dotyczył jego story, pozyskać dane do testów, skontaktować się z ludźmi, którzy dany system znali, aby potwierdzić pożądane zachowanie, itd. Operując na przykładzie - story, które wcześniej potrafiło wymagać od programisty dwóch dni pracy i trzech dni czekania, zdarzało się po zmianach ukończyć w jeden dzień.

Wnioski

<   Skutek zmian można chyba najkrócej podsumować stwierdzając, że każdy mógł się zająć pracą, w której jest dobry - programiści mogli zająć się programowaniem, analityk analizą, Product Owner backlogiem, a Scrum Master procesami agile’owymi.    >

 

Wnioskiem z naszej transformacji jest to, że specjalizacja i dopasowanie zadań do kompetencji, sprzyjają wydajności pracy, jakości wyników i zadowoleniu z pracy. Z jednej strony można powiedzieć, że nie odkrywamy takim stwierdzeniem Ameryki. Interesujące może być jednak to, że rzadko jest okazja w ramach tego samego projektu i otoczenia, przy luźno rozumianym ceteris paribus porównać różne podejścia, i już na przestrzeni kilku miesięcy zaobserwować pozytywne efekty zmian.

 

Ze strony klienta otrzymywaliśmy również potwierdzenia, że zespół stał się lepiej odbierany na zewnątrz, oraz bardziej autonomiczny. Potrafimy sami określić sobie plan, zidentyfikować i rozwiązać zależności, oraz przeprowadzić implementację – coś, co dla zespołu złożonego jedynie z programistów było trudne.

Maciej_Kochan-portrait2_20211019_163029

O autorze:

Maciej Kochan

 

Lead Integration Developer w ProData Consult. Z firmą związany od ponad 2 lat. Jest absolwentem Warszawskiej Wyższej Szkoły Informatyki. Studiował także Ekonomię na Uniwersytecie Warszawskim. Wcześniej przez długi czas pracował dla marki CitiBank Handlowy.

Chcesz pracować jako niezależny konsultant IT?

Daj się połączyć z najlepszymi projektami na rynku!