Jak myśleć zwinnie? Zmiany w podejściu do efektywnego wytwarzania oprogramowania

„Nie liczy się to, co robisz, ale jak to robisz” – John Wooden

Zwinne wytwarzanie oprogramowania można opisać niezliczonymi przymiotnikami. Przyjazne klientowi, elastyczne, transparentne, nastawione na rezultat… Ale żeby takie było, musi być przede wszystkim efektywne.

Efektywność to kamień węgielny agile, bo daje programistom pracującym zwinnie bezdyskusyjną przewagę nad kolegami pracującymi w bardziej tradycyjnych metodykach. To zwykle ta ponadprzeciętna efektywność staje się kartą przetargową i przekonuje klientów do współpracy ze zwinnym software housem.

Metodyka agile składa się z dziesiątek drobnych nawyków, które razem pozwalają na płynne i harmonijne działanie zespołu programistycznego. Na pierwszy rzut oka wydaje się, że to właśnie te nawyki czynią zwinne podejście tak efektywnym. W rzeczywistości jest jednak coś jeszcze ważniejszego.

Wszystkie produktywne nawyki zwinnych programistów wynikają z określonego sposobu myślenia, z nastawienia, które domyślnie pozwala pracować efektywnie. Niektóre cechy tego nastawienia mogą początkowo wydawać się sprzeczne ze zdrowym rozsądkiem - nie daj się zwieść. Śmiemy twierdzić, że zwinny sposób myślenia to jedno z najbardziej sensownych i efektywnych podejść do pracy (a do wytwarzania oprogramowania w szczególności), jakie ludzkość dotąd wymyśliła.

Chcesz się dowiedzieć, co znaczy myśleć zwinnie? Poniżej opisujemy najważniejsze cechy zwinnego nastawienia. Od wielu lat wplatamy je we własny sposób pracy, żeby mieć pewność, że budujemy dobrej jakości oprogramowanie efektywnie.

Co więcej, te zasady nastawienia nie dotyczą wyłącznie wytwarzania oprogramowania. Wprowadzenie ich do dowolnego projektu czy biznesu przyniesie zauważalny wzrost efektywności - zwłaszcza w dłuższej perspektywie.

Elastyczność i efektywność idą w parze

Powszechnie uważa się, że aby być efektywnym, trzeba trzymać się z góry ustalonego planu z jak najmniejszą liczbą modyfikacji. To tylko częściowo prawda.

Oczywiście, jeśli masz zaplanowany każdy krok i po prostu skreślasz kolejne pozycje z listy zadań bez zastanawiania się nad nimi, przejdziesz przez tę listę wystarczająco szybko. To będzie efektywne i możesz mieć poczucie, że wiele osiągasz, po prostu trzymając się sztywnego planu. W niektórych rodzajach pracy to rzeczywiście może być najlepsza droga do pewnych celów.

Ale… co, jeśli po przejściu wszystkich kroków z listy zorientujesz się, że tak naprawdę nie tą listą trzeba było się kierować? Że zamiast dotrzeć tam, gdzie chciałeś, dotarłeś gdzieś obok - ale niewystarczająco blisko? Najpewniej będziesz musiał przejrzeć część wykonanych działań i zrobić je od nowa. Cofnąć się o kilka kroków i skorygować kurs. A to już nie brzmi tak efektywnie.

W wytwarzaniu oprogramowania aż nazbyt często zdarza się, że początkowa lista zadań ewoluuje w miarę odhaczania jej pozycji. Innymi słowy: realna droga do produktu końcowego może wyglądać różnie na różnych etapach projektu. I tu z pomocą przychodzi zwinne myślenie.

Zwinne nastawienie zakłada, że za kilka tygodni sytuacja będzie prawdopodobnie wyglądać zupełnie inaczej niż dziś. Dlatego zwinne zespoły tworzą na początku nowego projektu strukturę pracy, ale potem kładą ogromny nacisk na bieżące monitorowanie postępów i jak najczęstsze zbieranie informacji zwrotnej o swojej pracy. Dzięki temu mogą korygować kolejne kroki i realizować projekty efektywniej.

Elastyczność całego planu pracy często rozciąga się na elastyczny grafik każdej osoby. Wiele badań pokazuje, że pracownicy (w tym programiści), którzy sami planują swoją pracę, są bardziej produktywni, mają większą satysfakcję z pracy i dostarczają lepszej jakości efekty.

Dobre praktyki ułatwiające elastyczność pracy

– Monitoruj projekt na bieżąco, żeby wiedzieć, co trzeba zrobić w danym momencie, zamiast opierać się na planie sprzed dnia.
– Spotykaj się z zespołem codziennie i zostaw czas na omówienie bieżących celów i problemów.
– Dbaj o kulturę transparentności w miejscu pracy, żeby pracownicy czuli się na tyle bezpiecznie, by mówić prawdę o tym, jak idzie projekt. Więcej o znaczeniu zaufania i transparentności poniżej.

Budowanie relacji zawodowych na zaufaniu

Jak napisał Paul Blair na blogu Stack Builders, „wytwarzanie oprogramowania opiera się na zaufaniu”. Jako zwinny software house nie moglibyśmy zgodzić się bardziej.

Zgodnie z artykułem Stephena M. R. Coveya i Douglasa R. Conantaistnieje bezpośredni związek między poziomem zaufania w organizacji a tempem, w jakim rzeczy się dzieją. Gdy zaufanie spada, nieuchronnie spada też efektywność. Łatwo to pokazać na przykładach:

Kiedy liderka zespołu nie ufa swoim ludziom w szacowaniu projektu, za każdym razem czuje się zmuszona sama weryfikować estymaty. Kiedy product owner nie wierzy, że zespół dowiezie na czas, wkłada dodatkowy wysiłek w mikrozarządzanie ich harmonogramem. W obu sytuacjach brak zaufania prowadzi do marnowania czasu i zasobów, bo ludzie wykonują zbędne czynności.

Oznacza to, jak ujmują to Covey i Conant, że „[zaufanie w firmie] nie jest miłym dodatkiem; to konieczność”. Przynajmniej jeśli chcesz prowadzić efektywnie działający biznes.

Zaufanie w organizacji jest mocno powiązane z transparentnością. Zwykle im bardziej komuś ufasz, tym łatwiej być wobec tej osoby transparentnym i szczerym. Działa to jednak także w drugą stronę: jeśli od początku udostępniasz całą pracę partnerom biznesowym lub pracownikom, dostaniesz w zamian więcej zaufania.

W efektywnym zwinnym wytwarzaniu oprogramowaniaznaczenie zaufania i transparentności jest dwojakie. Po pierwsze, chcesz być całkowicie transparentny wobec klienta(product ownera) w kwestii tego, jak planujesz poprowadzić projekt. Nie ma miejsca na ukrywanie stosowanych rozwiązań ani zamiatanie pod dywan nieoczekiwanych komplikacji - i tak wyjdą prędzej czy później. Znacznie lepiej działa budowanie wzajemnego zaufania przez utrzymywanie dostępnej dokumentacji projektu , do której każdy może sięgnąć, oraz przez otwarte komunikowanie zarówno sukcesów, jak i przeszkód w projekcie. Przekonaliśmy się, że to najlepszy (i najprostszy) sposób, by współpraca była jak najbardziej efektywna.

Drugim ważnym aspektem zaufania w zwinnym wytwarzaniu oprogramowania jest utrzymywanie zaufania jako wysokiej wartości w kulturze firmy. Udowodniono, że „pracownicy, którzy czują, że się im ufa, częściej zachowują się w sposób wspierający cele organizacji”. I wydaje się to całkiem naturalne - członkowie zespołu, którzy czują się pewnie, biorąc odpowiedzialność za swoją pracę, dadzą oczywiście lepsze efekty niż ktoś stale kontrolowany.

Budowanie kultury zaufania powinno być jednym z najwyższych priorytetów każdego menedżera, lidera zespołu czy CEO. Przyjmując styl zarządzania oparty na wysokim zaangażowaniu (w opozycji do stylu nastawionego na kontrolę), mogą pozwolić programistom, projektantom i innym pracownikom pokazać, na co ich stać. Znów - da się to osiągnąć tylko wtedy, gdy czują, że się im ufa.

Wysoki poziom zaufania wzmacnia też ducha współpracy w zespole - więcej o tym w kolejnym akapicie.

Dobre praktyki budowania zaufania w organizacji

– Prowadź porządną dokumentację projektów. Zapisywanie wszystkich ustaleń i wyników spotkań tworzy punkt odniesienia dla wszystkich zaangażowanych. Oszczędza też konfliktów o to, „co zostało powiedziane wcześniej, ale czego nikt już nie pamięta”.
– Bądź otwarty na rozmowę o problemach i możliwych opóźnieniach w projektach - także z klientami. Informowanie o przeszkodach daje wszystkim sygnał, czego się spodziewać, i oszczędza sporo napięcia.
– Daj klientowi możliwość śledzenia postępów projektu i dziel się informacjami z pracownikami. Udostępniając informacje publicznie, wysyłasz wszystkim niewerbalny komunikat, że nikt tu niczego nie ukrywa.

Współpraca ponad rywalizację - znaczenie ducha zespołu

„Respondenci wysoko cenią pracę w środowisku opartym na współpracy, w którym czują, że ich głos jest słyszany i mogą decydować o swojej pracy”. – GitLab 2018 Global Developer Report

Być może słyszałeś o pisanej zbiorowo książce Tribal Leadership– przeglądzie pięciu różnych etapów kultury organizacyjnej. Zdaniem autorów firmy, które ewoluują do 4., a zwłaszcza 5. etapu kultury pracy, cenią współpracę znacznie bardziej niż rywalizację jako ogólne podejście do celów. To także organizacje zdolne wywrzeć naprawdę szeroki - a nawet globalny - wpływ.

Duch rywalizacji zaprowadzi firmę programistyczną tylko do pewnego miejsca - a widać to szczególnie, gdy pracujesz zwinnie. Jeśli ktoś chce, by zwinne wytwarzanie oprogramowania było maksymalnie efektywne, musi zapewnić bezpieczną przestrzeń do współpracy. Zespół może osiągnąć więcej niż grupa pojedynczych osób.

Dlaczego wspominamy o „bezpieczeństwie”? Bo jeśli ludzie mają otwarcie współpracować, muszą czuć, że nie muszą ze sobą rywalizować, żeby „przetrwać”. Na przykład: jeśli programistka ma poprosić o pomoc (a to ważna część współpracy), musi pozwolić sobie na bycie wrażliwą. Musi mieć pewność, że sięgnięcie po pomoc nie zagrozi jej pozycji w zespole - ani w oczach szefa.

Ten aspekt leży w dużej mierze po stronie zarządu - to on musi stworzyć warunki, w których pracownicy nie czują potrzeby ciągłego udowadniania swojej wartości i walki o uznanie zarządu czy menedżerów. Jak ujmuje to David Mizne: „liderzy firmy muszą tworzyć kontekst dla zachowań, zamiast mikrozarządzać ludźmi”.

Choć brzmi to jak banał - żeby efektywnie współpracować, programiści muszą móc być sobą w pracy. Przy jak najmniejszej presji będą w stanie nie tylko dostarczać najlepsze efekty, ale też iść razem z kolegami ku wspólnemu celowi. Zwinne wytwarzanie oprogramowania sprzyja takiemu duchowi współpracy przez wplatanie w pracę różnych rodzajów spotkań, zachęcanie do transparentności i otwartą komunikację o tym, nad czym każdy pracuje (i z czym się zmaga).

Dużą częścią tego jest też otwartość na informację zwrotną od użytkowników i product ownerów oraz gotowość do ulepszania produktu. Powtarzalny cykl „zaprojektuj - zbuduj - zbierz feedback - popraw” to sedno iteracji i jeden z najważniejszych filarów agile. A żeby ten cykl się kręcił, od programistów wymagane są też pewien poziom bezpieczeństwa, otwartość i gotowość przyjmowania krytyki.

Dobre praktyki wnoszące ducha współpracy do zespołu

– Organizuj spotkania, na których każdy może powiedzieć innym, nad czym pracuje (np. codzienne stand-upy)
– Jeśli zarządzasz zespołem, nie oceniaj pracowników po wynikach, lecz po zaangażowaniu. W wytwarzaniu oprogramowania efekty bywają arbitralne i nie odzwierciedlają włożonego wysiłku.
– Spraw, by ludzie pracowali nad zadaniami wspólnie - świetnym pomysłem jest wprowadzenie wzajemnych code review wśród programistów. Dzięki temu ludzie czują się odpowiedzialni za ten sam kawałek pracy, a współpraca staje się naturalna.

Skupienie na jednej rzeczy naraz

Projekty programistyczne są zawsze złożone i zespołowi bardzo łatwo zgubić się w niekończącym się wątku zadań, researchu, kodowania… Ale, jak można się domyślić, gubienie się nie jest zbyt efektywnym sposobem budowania oprogramowania. Umiejętność (i chęć!) skupienia się na jednej rzeczy naraz to znacznie lepsza droga.

Wielozadaniowość w pracy przez długi czas była chwaloną umiejętnością. Ludzie wpisywali ją nawet w sekcje kompetencji miękkich w CV. Od kilku lat nauka pokazuje jednak, że wielozadaniowość jest dla człowieka czymś nienaturalnym. Oto kilka negatywnych sposobów, w jakie robienie wielu rzeczy naraz wpływa na pracowników i ich ogólną produktywność.

• Za każdym razem, gdy przełączasz się z jednego zadania na drugie, tracisz czas i obniżasz możliwości swojego mózgu. Samo dostosowanie się do nowego kontekstu i nowej czynności pochłania sporo mocy przerobowej.
• Twoja zdolność koncentracji spada, bo stale rozprasza Cię coś nowego.
• Przy wielozadaniowości mózg jest narażony na nadmiar bodźców i zakłócenia, które z dużym prawdopodobieństwem odbiją się na pamięci i sprawią, że zapomnisz o szczegółach. „Badanie z 2009 roku przeprowadzone przez Clifforda Nassa, Ph.D., i innych na Uniwersytecie Stanforda pokazuje, że uczestnicy, którzy najczęściej robią wiele rzeczy naraz, są rozpraszani przez nieistotne informacje przechowywane w ich pamięci krótkotrwałej”.
• Prawdopodobnie zmierzysz się z wysokim poziomem stresu, co rzecz jasna obniża Twoją wydajność - zwłaszcza gdy stres się przedłuża.

Wnioski z psychologii i neuronauki są jednoznaczne: kto chce pracować efektywnie, musi przestać dążyć do wielozadaniowości i nauczyć się skupiać na jednej rzeczy naraz. Po pierwsze, wymaga to chęci i porzucenia przekonania, że można (albo trzeba) robić wiele rzeczy jednocześnie. Po drugie, wymaga systematycznego podejścia - zwłaszcza w zawodach o dużej złożoności, takich jak wytwarzanie oprogramowania.

W zwinnym wytwarzaniu oprogramowania wszystko zaczyna się od podziału projektu na kamienie milowe, potem epiki, a ostatecznie konkretne zadania. Przypisanie każdego zadania do konkretnego programisty (i utrzymywanie transparentnego backlogu) usuwa niejasność, kto co robi w złożonym projekcie zespołowym. Dodatkowo jasno zdefiniowane zadania zachęcają pracowników do pracy nad jedną rzeczą aż do jej ukończenia - i dopiero potem przejścia do kolejnej.

Usystematyzowanie zakresu pracy dzięki zwinnemu podejściu sprawia, że nawet bardzo złożony projekt jest pod kontrolą. Każdy programista wie, co robi i w jakiej kolejności - to oszczędza mu koordynowania własnych zadań W TRAKCIE ich wykonywania. To właśnie możliwość skupienia się na jednej rzeczy naraz naprawdę czyni zwinne wytwarzanie oprogramowania efektywnym.

Dobre praktyki wzmacniające koncentrację

– Podziel projekt na uchwytne kawałki pracy: kamienie milowe, potem epiki, potem zadania. Korzystaj z list kontrolnych. Usystematyzuj pracę. Dzięki temu programiści nie ugrzęzną w złożoności swojej pracy.
– Prowadź codzienne stand-upy: pozwalają wszystkim skupić się na tym, co trzeba zrobić w ciągu najbliższych 24 godzin, bez rozpraszania się rzeczami, które mogą poczekać.
– Zadbaj o to, by Ty i Twój zespół robili wystarczająco dużo przerw w pracy. Dzięki temu utrzymasz mózg w dobrej kondycji i poprawisz swoją koncentrację w ogóle.

Jeśli chcesz się dowiedzieć, jak wdrażamy zwinne nastawienie w Ideamotive, wypatruj naszego whitepapera, który właśnie przygotowujemy. Poproś o egzemplarz zaraz po publikacji, wypełniając nasz formularz kontaktowy.