Niska wydajność procesu wytwarzania oprogramowania. Czy powodem może być nieefektywny sposób uczenia się developerów?
Zastanawiałaś/eś się kiedyś, w których momentach Twój zespół projektowy uczy się i w jaki sposób wpływa to na wydajność procesu wytwórczego oprogramowania? Czy problemy w szacowaniu story pointów i opóźnienia w realizacji celu sprintu mogą być wynikiem nieskutecznej nauki? Transfer wiedzy i proces uczenia się to elementy często pomijane w zarządzaniu projektami software’owymi, tymczasem mają one realny wpływ na jakość i szybkość tworzenia oprogramowania. W tekście przedstawiamy metody i narzędzia, które pomogą w sposób planowy uczyć się wartościowych rzeczy i odrzucać wszystko, co nie przynosi korzyści i działa kontr produktywnie.
Wolisz oglądać niż czytać?
Jaką wiedzą zarządzamy w projektach? Zwinność, zmiana i uczenie się
W zespołach zwinnych nieodłącznym elementem jest zmiana, a każda zmiana wymaga nauczenia się czegoś nowego. Co za tym idzie, w projektach uczymy się nieustannie – wdrażając nowe narzędzia czy optymalizując proces wytwarzania oprogramowania.
Zarządzanie wiedzą najczęściej kojarzy się z obszarem merytorycznym, czyli warsztatami i szkoleniami, w które inwestujemy, żeby nasi developerzy programowali lepiej. Oczywiście zespół to również testerzy, analitycy czy scrum masterzy i o ich rozwój należy dbać w takim samym stopniu. Mamy nadzieję, że każdy o tym pamięta 😉
Inne obszary zarządzania wiedzą:
- Wiedza domenowa – jako że oprogramowanie tworzymy dla klientów z różnych branż, zespół musi zaczerpnąć wiedzy w dziedzinie, w której to oprogramowanie będzie działać.
- Wiedza procesowa – nikt nie rodzi się specjalistą w metodykach wytwarzania oprogramowania, więc niezależnie, czy realizujemy projekt zwinnie czy tradycyjnie, musimy się tego nauczyć.
- Wiedza z zakresu kultury organizacyjnej i relacji panujących w firmie – najmniej doceniany obszar, a mogący narobić wiele problemów. Brak wiedzy organizacyjnej często przekłada się na konflikty i nieporozumienia w projekcie, które opóźniają (i uprzykrzają!) pracę.
W jaki sposób uczymy się i dlaczego jest to ważne?
Człowiek nie jest prostą istotą, dlatego i nasze procesy uczenia się bywają skomplikowane. Najważniejsza informacja, którą należy przyswoić na początek – uczymy się w różny sposób. Teorii na ten temat jest mnóstwo, ale przedstawimy tę, którą sami wykorzystujemy w naszych projektach: teorię Honeya i Mumforda. Jej ogromną zaletą jest stosunkowo niski próg wejścia, a co za tym idzie, osoby zarządzające mogą szybko wyłapać i określić style uczenia się w swoich zespołach.
4 style uczenia się według teorii Honeya i Mumforda:
- Aktywista – osoba, która chce doświadczać jak najwięcej i uczyć się w praktyce (dyskusje w grupach, burze mózgów, próby i błędy).
- Obserwator – osoba czerpiąca wiedzę z obserwowania innych (analiza indywidualna, mniejsze grupy, działanie na przykładach).
- Teoretyk – osoba z zamiłowaniem do statystyk, liczb, faktów, modeli, historii. Najpierw musi zgłębić sporo wiedzy teoretycznej, dopiero potem zaczyna działać.
- Pragmatyk – szuka optymalnego rozwiązania i jak najszybszej drogi do zastosowania teorii w praktyce (case study, analizy przypadków).
Przedstawmy to na przykładzie: w firmie pojawia się nowy ekspres do kawy. Aktywista klika wszystko i próbuje zaparzyć swoje ulubione espresso metodą prób i błędów. Obserwator przepuszcza w kolejce kilka innych osób i próbuje podpatrzeć ich działanie. Teoretyk sięga po instrukcję, a pragmatyk po prostu chce jak najszybciej wykonać zadanie. Może np. jednocześnie googlać filmik instruktażowy, rozpytując wszystkich dookoła o wskazówki.
Warto mieć świadomość, jak poszczególni członkowie zespołu uczą się, żeby – jako osoba zarządzająca – móc zarówno pomagać w rozwoju, jak i wpływać na efektywność zespołu w procesie wytwarzania oprogramowania. Łącząc pracowników z różnych stylów nauki, możemy uniknąć negatywnych aspektów działania, np. u teoretyka zbyt powolnego wdrażania wiedzy w praktykę, a u aktywisty zbyt pochopnego działania na oślep.
Kiedy w procesie wytwarzania oprogramowania mamy do czynienia z uczeniem się?
Podzielmy sobie proces wytwórczy oprogramowania na trzy fazy i przyjrzyjmy się, jakie momenty sprzyjają nauce i transferowi wiedzy. Poniższe porady, narzędzia i metody sprawdzą się nie tylko w projektach zwinnych, chociaż część z nich dotyczy np. ceremonii scrumowych.
Faza początkowa tworzenia oprogramowania
Początek projektu to moment, kiedy każdy jeszcze rwie się do pracy i najłatwiej popełnić błędy. Początkowa faza software developmentu wymaga ogromnego transferu wiedzy, szczególnie wiedzy domenowej. Musimy nauczyć się i zrozumieć, czym jest np. udzielanie leasingu czy kredytowanie (wszystko zależy od branży).
Narzędzia i metody pomagające przyswoić wiedzę domenową:
- Dokumentacja udostępniona przez klienta (rozwiązanie dla teoretyków);
- Wizyta studyjna: zespół realizujący projekt software’owy odwiedza miejsce pracy klienta i poznaje ludzi, którzy będą korzystać z tworzonego oprogramowania. Pomaga to zyskać pełen obraz rozwiązania, otworzyć się na nowe pomysły, uwzględnić w projekcie elementy, na które początkowo nie zwrócilibyśmy uwagi (obserwator, aktywista).
- Event storming: sesja/burza mózgów, gdzie zarówno developerzy, klienci i eksperci domenowi przyglądają się procesowi przeznaczonemu do digitalizacji, omawiając go na bardzo różnych poziomach. Aktywny sposób zdobywania wiedzy (pytania i rozmowy), często w ruchu, wykorzystując pomoce wizualne (trafia do wszystkich stylów uczenia się).
Ponadto, początkowa faza projektu to odpowiedni moment na przećwiczenie całego procesu wytwarzania oprogramowania. Możemy zarządzić dwa dni na naukę pracy w Scrumie, bo każda firma ma swoje indywidualne przyzwyczajenia, które wymagają przedstawienia i zrozumienia przez cały zespół.
W tym czasie uczymy się także kultury organizacyjnej – ta część kick off meetingu najczęściej realizowana jest poprzez rozmowę lub one pager podsumowujący kulturę pracy. My jednak polecamy metodę Kontraktu 5R, podczas którego cały zespół określa 5 wymiarów pracy:
- Kierunek – definiujemy cel pracy i upewniamy się, że wszyscy rozumiemy go tak samo;
- Ramy organizacyjne – ustalamy fakty dotyczące tego, w jaki sposób pracujemy (np. daily jest zawsze o godzinie 9:00);
- Role projektowe – zespół przedstawia się nie tylko formalnie (np. jestem java developerem), ale też nieformalnie, np. ktoś określa, że jest dobrym mediatorem;
- Reguły – przedstawiamy pożądane w projekcie działania (np. czas pracy jest raportowany w Jirze);
- Relacje – ustalamy wszystkie miękkie aspekty współpracy, które są dla zespołu ważne (np. nie opowiadamy sobie dowcipów o charakterze politycznym).
Z taką wiedzą możemy przejść do kolejnego etapu wytwarzania oprogramowania.
Faza realizacji oprogramowania
W fazie początkowej wiedza, którą zdobywamy jest stosunkowo szeroka, teraz przychodzi czas zagłębić się w szczegóły i przejść na operacyjny tryb pracy.
W tej fazie rekomendujemy wykorzystanie narzędzi takich jak (niektóre mają nazwy własne, ponieważ wdrożyliśmy je na własny użytek 😉):
- Domain storytelling. Warsztaty, w których bierze udział zarówno zespół projektowy, jak i eksperci domenowi oraz moderator. Eksperci dziedzinowi przedstawiają procesy oraz domenę biznesową, używając nomenklatury pojęć biznesowych. Natomiast zespół wytwórczy zadaje pytania, nie posługując się językiem technicznym. Moderator przedstawia story opowiadane przez ekspertów biznesowych za pomocą piktogramów, rozrysowując cały proces, żeby po warsztatach każdy wyszedł z wiedzą domenową. Jest to pierwszy krok do stworzenia user stories.
- User story mapping (po domain storytelling). Metoda, która pozwoli zebrać wymagania, zagregować wszystkie user stories i ułożyć je w logiczną całość. Podstawa do stworzenia backlogu projektu, czyli zakresu prac niezbędnych do realizacji oprogramowania.
- Programowanie w parach. Metoda pogłębiania wiedzy z perspektywy zespołu, który wytwarza oprogramowanie. Dwie osoby jednocześnie pracują nad jednym zadaniem: jedna programuje, druga jest wsparciem (np. podpowiada, jak zoptymalizować kod lub jako osoba bardziej doświadczona w projekcie odpowiada za początkowy transfer wiedzy).
- Czas wyznaczony na edukację. Poszerzanie warsztatu pracy dowolnego członka w zespole projektowym poprzez z góry ustaloną liczbę dni (np. 5 na kwartał), które należy w całości wykorzystać na zgłębienie jakiegoś elementu/problemu w projekcie lub zewnętrzne szkolenia.
- Wycieczki po systemie. Sposób na zarządzanie wiedzą, szczególnie w bardzo rozbudowanych projektach software developmentu. Jeżeli zespół buduje jakieś rozwiązanie, osoby, które opiekują się danym obszarem/funkcjonalnością, nagrywają cykliczne warsztaty, oprowadzając wirtualne po danej funkcjonalności. Nagrania można wykorzystać za każdym razem, kiedy osoba z innego obszaru, czy ktoś nowy w projekcie, chce przyswoić sobie akurat dany kawałek realizacji. Jest to gotowy transfer wiedzy, szybszy i efektywniejszy, niż gdyby jedna osoba wprowadzała wszystkich z osobna.
- Retrospektywa. Kawałek retrospektywy przeznaczamy na edukację lub organizujemy oddzielne spotkania (1-2 razy w tygodniu), podczas których scrum master spotyka się z zespołem projektowym, aby omówić jedno wybrane zagadnienie, np. sposób wyceny user stories (szczególnie, jeżeli zespół sam zgłasza niepewność/problem).
Faza końcowa wytwarzania oprogramowania
Sesja lessons learned to moment podsumowania i wyciągnięcia wniosków z projektu. Narzędzia, które przydadzą się w tej fazie do wzmocnienia procesu uczenia się, to m.in.:
- Start-Stop-Continue: zbieramy się z zespołem projektowym i na start: wypisujemy rzeczy, których nie robiliśmy, ale z perspektywy czasu fajnie byłoby je wdrożyć w kolejnych realizacjach. Stop: wskazujemy rzeczy, które wykonywaliśmy, ale dochodzimy do wniosku, że następnym razem powinniśmy z nich zrezygnować. Continue: podkreślamy aspekty, które robiliśmy i się sprawdziły.
- Metoda Plus Delta: podobne rozwiązanie, gdzie wypisujemy rzeczy dobre i działające oraz rzeczy, które się nie sprawdziły w procesie wytwarzania oprogramowania.
- Timeline: budujemy oś czasu i na niej wypisujemy kamienie milowe projektu. Omawiamy poszczególne wydarzenia i wyciągamy wnioski (znowu, co było dobre, a co nas ograniczało/stopowało).
Oczywiście metodyki można ze sobą łączyć. Ważne, aby taka sesja lessons learned zakończyła się podsumowaniem i wnioskami, które przełożą się na kolejne projekty.
Problem uciekającej wiedzy, czyli zmiany w zespole
Zmiany w zespole są nieuniknione, dlatego musimy nauczyć się, jak skutecznie przekazywać wiedzę nowym osobom. Onboarding może odbywać się z pomocą dokumentacji czy nagrań (dobre dla teoretyków czy obserwatorów), ale także za pomocą wcześniej już wspomnianej metody programowania w parach (aktywiści i pragmatycy).
W naszej firmie wprowadziliśmy także rolę Buddy’ego, w którego wciela się doświadczona osoba, mająca za zadanie zaopiekować się nowym członkiem zespołu projektowego. Pomaga w rzeczach związanych z organizacją, jak i wdraża w projekt.
Jeżeli natomiast sięgamy po instruktaż, szkolenie czy przekazywanie wiedzy przez jedną osobę, to warto pamiętać, że według Richarda Mayera człowiek jest w stanie utrzymać uwagę wyłącznie przez około 12 minut. Dlatego transfer wiedzy powinien odbywać się w 15 min. slotach, w skondensowanej i przemyślanej postaci.
Wspierać można się także metodą TWI (ang. Program Training WIthin Industry), czyli sposobem przekazywania wiedzy pod postacią trzech etapów: uczymy tego, co robimy, jak to robimy i dlaczego to robimy. Na końcu dana osoba zawsze powinna powtórzyć, jak zrozumiała przekazywany fragment wiedzy.
Problem uciekającej wiedzy – narzędzia:
- Dokumentacja – zapanowanie nad dokumentacją projektową bywa trudne, ale powinniśmy skupić się na tworzeniu przejrzystej i stale aktualizowanej dokumentacji (najlepiej dodać ten wymóg do definition of done, aby z każdym przyrostem developerskim na bieżąco uzupełniać dokumentację).
- Brak silosowania wiedzy – w zespole projektowym powinny znaleźć się osoby odpowiedzialne za dany obszar, ale jednocześnie należy unikać sytuacji, gdzie w projekcie jest tylko jedna osoba posiadająca dany zakres wiedzy. Zawsze powinien być ktoś na zastępstwo, chociażby na okres urlopowy.
- Wiedza pokrewna – Ważne, aby budować kulturę przekazywania i dzielenia się wiedzą ze swoich obszarów wewnątrz zespołów. Istotna powinna być nie tylko corowa wiedza, ale także wiedza z obszarów wspomagających i z dziedzin pokrewnych. Zrozumienie ról i obszarów pomiędzy poszczególnymi członkami zespołu poprawia współpracę i komunikację, co przekłada się na szybszy i bardziej wydajny proces wytwarzania oprogramowania.
Ceremonie scrumowe, wspierające proces uczenia
- Daily – podnosimy poziom wiedzy i kompetencji w zakresie wystąpień publicznych (nie jest to wiedza czysto projektowa, ale przydaje się np. w kontaktach z klientem).
- Refinement – pokazujemy perspektywy różnych osób w zespole (programisty, testera i analityka). Żadna rola nie powinna być pomijana – w sytuacji, w której tak się dzieje, często wymagania nie są dostarczane w takim tempie, jak się zobowiązaliśmy (np. nie jesteśmy w stanie przewidzieć, że testowanie zajmie dużo więcej czasu niż zakładaliśmy w oparciu wyłącznie o własną perspektywę).
- Review – to nie demo! Na review uczymy się produktu i tego, co ma się dalej z nim zadziać. Widząc, co zostało wytworzone, możemy podjąć decyzję, w jakim kierunku produkt będzie się rozwijał.
- Retro – uczymy się kultury feedbacku, ale też wychodzimy z konkretnymi action points do zrobienia (coś dla aktywistów), które będą realizowane w kolejnym sprincie. Dodatkowo na retro, podczas analizy przyczyn źródłowych, uczymy się narzędzi wspomagających kreatywność (np. Diagram Ishikawy, Macierz O’connora) i nic nie stoi na przeszkodzie, żeby korzystać z nich także w trakcie codziennej pracy. W końcu tworzenie oprogramowania jest pracą kreatywną 😊
Masz jakiekolwiek wątpliwości, czy poprawnie wykorzystujesz narzędzia oraz praktyki wspierające uczenie się w swoim procesie wytwarzania oprogramowania? Skontaktuj się z nami!