Przetestowałem programowanie ekstremalne z osobami nietechnicznymi. Dlaczego warto je stosować?

Najczęstszym problemem podczas pracy z jakim się spotykam, to brak specjalistycznej wiedzy na temat wykonywanego zadania, i nie mam na myśli wiedzy technicznej. Dla przykładu: mamy stworzyć kalkulator składek ZUS. Kto zna wszelkie niuanse na ten temat, niech pierwszy rzuci kamieniem. Brak wiedzy na temat problemu jaki mam rozwiązać, generuje ryzyko, że zadanie do nas wróci. Rozwiązaniem jest programowanie ekstremalne. Chcesz je wypróbować? Zobacz, jak ja to zrobiłem.

---

Mariusz Walczak. Tech lead w Softfin. Absolwent Warszawskiej Wyższej Szkoły Informatycznej. Pasjonat inżynierii oprogramowania, swoje aplikacje tworzy w PHP i językach opartych na ES6/7. Prywatnie miłośnik futrzanych czworonogów, oraz winiarstwa i nalewkarstwa.

---

Gdy przejdziemy przez wszystkie niuanse, jak liczyć składki ZUSowskie w przypadku umów łączonych, lub przy zatrudnieniu w więcej niż dwóch miejscach, na dwóch różnych typach umów, przykład umowa menedżerska i umowa o dzieło, to gwarantuje wam, że ryzyko popełnienia błędu wzrasta wykładniczo.

Niewielu z nas jest ekonomistami, specjalistami od wind, lub od zarządzania wspólnotami mieszkaniowymi, a zadania często mówią tyle, że musimy stworzyć algorytm wyliczania składek na ciepłą wodę w rozliczeniu rocznym, lub napisać najlepszy algorytm do obsługi wind. Każdy z nas miał styczność z tego typu problemami.

Programowanie ekstremalne

Pierwszym moim pomysłem na to jak radzić sobie z tego typu sytuacjami, to programowanie ekstremalne. W skrócie: siadam z kolegą przy jednym komputerze i poprzez dyskusję tworzymy kod. Sprawdza się to całkiem dobrze, lecz zazwyczaj przełożeni źle na to patrzą, bo widzą, jak jeden z bardzo drogich w utrzymaniu pracowników gada cały dzień, zamiast tworzyć kod. Choć przez jego gadanie zadanie zostanie szybciej wykonane, niż bez pomocy kolegi, to szefostwo i tak na takie podejście źle patrzy.

W takiej sytuacji zawsze przekonywałem szefostwo, że to efektywna metoda, opierając się na statystykach nakłaniałem do jej stosowania. Jeżeli dany deweloper wykonuje zadania w 5 dni i 20% tych zadań do niego wraca, to w przypadku pracy w parach, te same zadania zostaną wykonane w czasie około 2~3 dni i zwrotów będzie o połowę mniej. Czyli de facto dwóch programistów, czyli 4 osobo dni, wykonało pracę pięciodniową, wraz z obsługą błędów po.

Często praca w parach oszczędza jeszcze więcej czasu. Przykład z mojego życia: kolega walczył z zadaniem czwarty dzień, nie miał już bladego pojęcia co jest nie tak, a to było dopiero połowa jego prac wyliczonych na w sumie 8 dni. Usiedliśmy razem, jego problem udało nam się rozwiązać w 20 minut. Chłopakowi brakowało wiedzy backendowej, był frontendowcem z powołania i nie znał się na zakamarkach backendowych, ja natomiast lepiej poruszam się po zapleczu niż na froncie.

Korzystając z ekstremalnego programowania udało nam się w ciągu jednego dnia zamknąć pozostałe zadania. Czyli mój jeden dzień pracy z kolegą zaoszczędził 3 dni robocze, a gdybym usiadł z nim od razu, to wtedy okazałoby się, że oszczędność pracy wyniosłaby 5 dni roboczych. Skąd ten fenomen? Każdy z nas ma inne doświadczenia i inne przemyślenia, inaczej podchodzi do zadania patrzy na świat po prostu inaczej. To inaczej w trakcie dyskusji przewiduje znacznie więcej scenariuszy i problemów jakie możemy spotkać. Dodatkowo wiedza dwóch programistów jest znacznie większa niż jednego, jest mniejsze ryzyko, że będą musieli się czegoś douczać.

Oferty pracy z

Programowanie sterowane testami

Niestety nawet we dwójkę, nie zawsze dobrze nam szło, jeśli chodzi o poprawność wykonywania zadań. Powiem wprost: czasem problemy nas przerastały, w szczególności jeśli wchodziły w grę jakieś niuanse prawnicze, w zadaniach osoby zlecające często nie uwzględniały tego.

Rozszerzyliśmy moją metodę o sterowanie testami, czyli osoby zlecające zadania dawały nam dane wejściowe i mówiły co ma wyjść, czyli dawali nam testy akceptacyjne. My rozszerzaliśmy to o nasze testy, co prawda praca szła jeszcze szybciej niż w poprzednim przypadku i odsetek błędów był mniejszy, niemniej jednak wciąż to było dla mnie za mało.

Zauważyłem wąskie gardło w przepływie wiedzy, o tak zwanych haczykach. My nie mieliśmy o nich pojęcia a osoby, które miały zapominały nam o nich mówić, lub po prostu nie myślały o nich w danym momencie. To powodowało, że wykonanie zadania, a oczekiwania się rozjeżdżały bardzo mocno.

Jak wykonanie zadania jest odmienne od oczekiwań, wszyscy wiemy co następuje dalej, ludzie zaczynają się denerwować, dochodzi do spychania odpowiedzialności, wszyscy zaczynają się na siebie gniewać. W firmie panuje niezdrowa atmosfera, a w skrajnych przypadkach ktoś jest zwalniany.

Mój złoty środek

Przez przypadek wypracowałem podczas jednego zadania metodę, która okazała się złotym środkiem.

Studium przypadku.

Miałem zrobić bardzo skomplikowany system zarządzania personelem dla działu HR, było tam wiele elementów, których nie rozumiałem na początku i wiele haczyków. Zbliżał się termin, kiedy miałem oddać wersję alfa systemu, a tkwiłem w rozwiązywaniu zwracanych zadań, ciągle było coś nie tak.

Wtedy mój właściciel projektu posadził mnie przy jednym biurku z analitykiem z działu HR. Na początku było dziwnie, ale potem wypracowaliśmy mechanizm programowania ekstremalnego z jednym programistą.

Benefity dla mnie: miałem ciągły dostęp do wiedzy i dowiadywałem się o wszelkich algorytmach na bieżąco, plus o wszystkich haczykach. Program był na bieżąco testowany i sprawdzany pod każdym względem na bieżąco. Oddając kolejne moduły, oddawałem je w pełni przetestowane i już zaakceptowane.

Benefity dla analityka: miał kontrolę nad tworzoną aplikacją. Na bieżąco sprawdzał zgodność z przyjętymi algorytmami, oraz z metodami wyliczeń. Miał wpływ na każdy element systemu podczas jego tworzenia na bieżąco.

Benefity dla firmy: w naszym programie do zarządzania zadaniami zawrzało. Zadania powstawały ze szczątkowym opisem, bo nie było konieczności, aby był szczegółowy, bo przecież mam encyklopedię w tym temacie pod ręką i zawsze mogę szybko zaczerpnąć wiedzy.

Prace przeznaczone na 160 osobo/godzin we dwójkę zrobiliśmy w około 80 osobo/godzin. W tym przypadku mieliśmy dwukrotne oszczędności, ale to nie wszystko. Żadne z zadań nie wróciło na poprawki, a liczyłem, że przeznaczę na nie około 20%, czyli 32 roboczo/godziny. Z moich wyliczeń wyszło, że ta metoda zaoszczędziła 112 roboczo/godzin. Teraz przemnóżmy to przez przeciętną stawkę programisty w Warszawie, czyli około 75 zł za godzinę, wychodzi nam, że ten manewr dla firmy zarobił 8 400 zł.

Metodę ulepszyłem o testy. Testy przyspieszają pracę o około 17%~20% (sprawdzone doświadczalnie) i zmniejszają liczbę błędów o około 30% w przeciągu roku życia projektu, bo aplikacja pokryta w dużej mierze testami, nie pozwala na generowanie błędów interferencyjnych, czyli takich, w którym nowy kod źle interferuje z już istniejącym kodem tworząc bugi.

Dodałem testy akceptacyjne, dodatkowo każdy błąd zgłoszony podczas testów przez mojego eksperta był dorzucany do puli testów. Jak się okazało programowanie ekstremalne z ekspertem plus sterowane testami, sprawia, że nagle praca z takimi zadaniami to bajka.

Wprowadzając te zasady, zrobiłem test. Dostałem zadanie stworzenia kalkulatora składek ZUS, poprosiłem o eksperta, do pomocy zgłosiła się księgowa, zadanie było wyliczone wstępnie na 3 dni, czyli 24 roboczogodziny.

Do pracy przystąpiliśmy o 9 rano, omówiliśmy co i jak, napisaliśmy testy akceptacyjne oraz testy jednostkowe. Do godziny 9:45 mieliśmy już szkielet modułu oraz wszelkie testy. O godzinie 10:55 byłem już po wykonaniu zadania, gdzie mieliśmy obsłużone wszelkie niuanse i odstępstwa, z racji uzyskanego czasu stwierdziliśmy, że zrobimy panel administracyjny do tego w wersji uproszczonej, czyli bez przykładania większej uwagi do wyglądu, byleby jakoś wyglądało.

Otrzymałem od eksperta informacje, które dane są ważne, stworzyłem odpowiedni formularz oraz obsłużyłem go. W sumie to pracę skończyliśmy o 12:30. Z czego prócz algorytmu, który liczy składki ZUS, HR otrzymał możliwość zmiany zasada liczenia ZUSu zgodnie z ich wymogami. Cały moduł był pokryty w 100% testami i w zasadzie bronił się sam, jeśli chodzi o wszelkie zmiany. Dodatkowo żadne z zadań nie wróciło z błędami.

Podsumowanie przypadku

Moduł został rozszerzony o panel administracyjny, w którym HR sam może sobie zmieniać wysokości składek kiedy potrzebują. Całość zadania została oszacowana na 24 osobo/godziny, a wykonaliśmy ją w 3:30 w dwie osoby, czyli w 7 osobo/godzin, dodatkowo ryzyko, że ktoś coś namiesza przez przypadek w tym module jest niewielkie z powodu testów jednostkowych i akceptacyjnych. Moduł ukończyliśmy przepalając 29% czasu i oszczędzając 17 godzin, co w przeliczeniu na oszczędność dla firmy oznacza 1275 złotych, przy założeniu, że programista i ekspert zarabiają po 75 zł za godzinę. Oczywiście ta oszczędność może być inna w waszym przypadku, tu chodzi tylko o pokazanie skali zysku jaki firma może odnotować.

Po wielkim sukcesie z ZUSem, zostałem poproszony o napisanie rozszerzenie kosztów osobowych o PFRON, jak się domyślacie pierwsze co zrobiłem, to poprosiłem o eksperta.

Podsumowanie

W życiu programisty trafiają się zadania, które wymagają specjalistycznej wiedzy nietechnicznej. Wtedy spada na programistę trudne zadanie, bo musi on posiąść tą wiedzę i ją zaimplementować. To jest już pierwszy sygnał, że coś pójdzie nie tak, bo nikt nie jest wstanie stać się specjalistą w ciągu dnia, lub dwóch. Nawet pomoc drugiego programisty, może się okazać niewystarczająca, co więcej testy akceptacyjne, też nie rozwiążą wszystkich problemów. Istnieją haczyki i pułapki, o których my programiści nie wiemy, a w zadaniu najczęściej się o nich nie pamięta.

Na te problemy najlepiej sprawdza się programowanie sterowane testami, oraz programowanie ze specjalistą w tej dziedzinie. Mamy wtedy pewność, że zadanie na pewno zostanie napisane tak jak sobie tego zażyczyła dana osoba, więc ryzyko zwrotu już jest mniejsze. Wszelkie haczyki, oraz inne problemy zostaną na pewno przez naszego eksperta wyłapane. Co więcej jeżeli czegokolwiek my nie zaimplementujemy, bo nikt nam nie powiedział, to nasz ekspert będzie się tłumaczył nie my.

Jeśli chodzi o przedstawienie szefostwu powodu dlaczego warto to zrobić, bo możemy zaoszczędzić do 70% czasu jaki jest zarezerwowany do wykonania tego zadania, a im szybciej wykonamy zadanie tym jest ono tańsze dla naszego szefa. Dodatkowo pewność, że zadania są wykonywane prawidłowo i nie wracają, generuje dodatkowy zysk, bo koszt utrzymania systemu jest mniejszy.

Ostatecznym plusem jest to, że programista nie musi pochłaniać nowej wiedzy, która nie przyda mu się później, może skoncentrować się na swojej pracy i tworzyć naprawdę skomplikowane algorytmy, które będą działały tak, jak sobie wymarzyły to osoby zlecające zadania.

---

Zdjęcie główne artykułu pochodzi z pexels.com.