bookmark_borderGry do nauki CSS

Nauka zajmuje w programowaniu szczególne miejsce. Rzadko która branża tak szybko ewoluuje i wymaga nieustannej edukacji, jak rozwój oprogramowania. Dlatego każdy sposób na szybszą naukę jest dla programisty na wagę złota.

CSS jest jedną z podstawowych technologii w przyborniku front-end developera. Również full-stack powinien ją dobrze znać. Bywa z tym różnie. Praktyka często jest przyswojona, ale pełne zrozumienie teorii jest zaskakująco rzadkie. Jeśli nie wierzycie, poproście programist(k)ę z zespołu o wymienienie choćby rodzajów pozycjonowania w CSS. „Frameworkowcy” mogą mieć z tym trudności.

CSS w każdym razie znać warto, a im lepiej się go zrozumie tym płynniej będzie nam szła praca.

Codepip games

Z pomocą przychodzi nam zestaw gier edukacyjnych https://codepip.com/.

Większość z nich jest płatna, ale nasłynniejsza bodajże, Flexbox – żabka (https://flexboxfroggy.com/) jest darmowa. Również inna, służąca do nauki grid CSS jest bezpłatna.

O ile przeglądanie dokumentacji może nas zanudzić, to uwierzcie, że ustawianie żabek na jeziorku jest całkiem relaksujące, a przy tym edukujące.

CSS Diner

Inna urocza gra, służąca do nauki CSS, ale już nie fragmentu, a całości, to CSS diner – http://flukeout.github.io/ .

Flexbox Defense

Kolejna, również ucząca flexboxa, to http://www.flexboxdefense.com/ .

Różnych podobnych, interaktywnych pomocy naukowych do nauki CSS znajdziemy w internecie sporo. Warto im się przyjrzeć i urozmaicić sobie naukę.

bookmark_borderPrototyp, głupcze!

Tworzenie oprogramowania jest jednym z najbardziej złożonych przedsięwzięć, jakich podejmuje się nasza cywilizacja. Nie dotyczy to co prawda każdego projektu, istnieją rzeczy proste, trywialne, ale nawet za nimi ciągnie się ogon bibliotek, systemów operacyjnych, procesorów i całej koncepcji programowania, wraz z algorytmami, maszyną turinga i językami formalnymi. Są jednak również projekty same w sobie niezwykle skomplikowane – systemy tradingowe, symulacje fizyczne, oprogramowanie symulujące zwijanie białek…

Rękodzieło

Mimo całej tej złożoności, jest w programowaniu duch rękodzieła.

Pracujemy nieraz nad arcydziełami koronkowej abstrakcyjnej twórczości, rozpiętymi na setki tysięcy linii kodu w sposób jakbyśmy toczyli wazę za czasów dynastii Han.

Poniżej przykładowa waza. Piękna rzecz, ale od czasu panowania dynastii Han, 206 BC–220 AD, trochę czasu minęło…

Co złego w toczeniu wazy? Niby nic. Tyle, że w przypadku wazy można, jak sądzę, nadać jej jakiś początkowy kształt, a potem malować kolejne fragmenty nieco improwizując. Tutaj smok, tam feniks, jakiś ornamencik.

I często wychodzi ładnie.

Gorzej jednak, kiedy przełożymy to na programowanie. Robimy jakieś MVC, tam dwa przyciski, tu jakiś dropdown, pod spodem kontrolerek i repozytorium i jakoś to będzie.

I czasami wychodzi ładnie.

Warto by jednak było, zanim zaczniemy implementować, lepić, klecić i klepać, zastanowić się, co tak w zasadzie system ma robić. Bo co waza ma robić, to wiadomo, a czy będzie miała dwa smoki i i trzy feniksy, czy też pięć ornamentów i jednego smoka, to już detal, o ile się je ładnie namaluje. Trochę też krócej się tworzy taką wazę. Gorzej jednak, jak w trakcie lepienia naszej wazy-MVC przychodzi klient i mówi, że chce czajnik. I jeszcze raz za dwa tygodnie i dodaje, że elektryczny…

Agile w dwójnasób

Wydawać by się mogło, że brak planu na początku projektu może wynikać z dominacji Agile na rynku. Promuje ona tworzenie jak gdyby ad hoc, w krótkich odcinkach czasu. Sądzę jednak, że brak planu to coś naturalnego, amatorskiego. Tak projekty tworzą studenci. Siadają do kompilatora i próbują. Próbują, piszą, nie planują. Miło jest coś zacząć, dać się pochłonąć entuzjazmowi. Mniej sympatycznie jest tworzyć plan, analizować, przewidywać problemy, a potem tego planu się trzymać.

Jest taka słynna grafika w świecie Agile. Ilustruje tworzenie MVP na przykładzie budowania samochodu. Znalazłem swego czasu ciekawszą:

Przez pewien czas sądziłem, że w istocie jedynie dolny rysunek ukazuje właściwą drogę, a tradycyjny przykład z hulajnogą, rowerem, motocyklem i samochodem jest błędny.

Tymczasem oba są poprawne. W zależności jednak od sytuacji.

Wyróżniłbym dwa modele tworzenia produktu:

  • kreatywny
  • konserwatywny

Produkt tworzony kreatywnie może wyewoluować w dowolnym kierunku. Przykładowo – projektujemy pierwszy smartphone. Nie wiemy jak ma wyglądać. Produkt może ewoluować znacząco, a feedback od klienta jest kluczowy i ma prawo kompletnie zmienić produkt.

Produkt tworzony konserwatywnie jest czymś, co już istnieje na rynku i nie planujemy go rewolucjonizować (albo czymś coś wręcz wiemy jak ma wyglądać, bo wynika z regulacji rynku, ustawy itp.). Chcąc zbudować nowy model samochodu nie ma sensu tworzyć hulajnogi. Możemy poeksperymentować z nadwoziem, wyposażeniem, ale nie z samą koncepcją auta.

Prototyp

Wydawać by się mogło, że prototypowanie jest czymś oczywistym. Pisarze tworzą pierwsze szkice, które potem udoskonalają, ubierają w szczegóły, a czasami zupełnie przerabiają. Malarze zwykle zaczynają obraz od zarysowania głównych jego elementów, również tworząc na początku coś w rodzaju prototypu. Projekty samochodów zawsze zaczynają się od produkowanych w jednym, czy kilku egzemplarzach wersji demo. Tymczasem w oprogramowaniu bywa różnie.

Widziałem projekty, gdzie nigdy niczego nie prototypowano. Proces tworzenia oparty był o pełną implementację w każdym sprincie. Zupełnie bezrefleksyjnie marnotrawiono czas, choć można było narysować na kartce propozycje rozwiązań i dojść do konsensusu miesiące szybciej.

Moim zdaniem każda aplikacja, która posiada interfejs graficzny (co stanowi sporą część, jeśli nie większość rynku) MUSI zacząć się od designu, następnie przejść w „klikalny” prototyp, by w końcu zostać w pełni zaimplementowana.

Stworzenie designu ułatwia zrozumienie produktu i zadawanie właściwych pytań. Większość osób jest wzrokowcami i potrzeba im wizualnej reprezentacji tego, nad czym mają podjąć pracę.

Prototyp z kolei pozwala dostarczyć klientowi coś namacalnego w czasie o wiele szybszym od pełnej implementacji. Rozwiązuje to frustrację biznesu związaną z czekaniem na pierwszy rezultat. Nic pewnie nie irytuje bardziej, niż słuchanie przez dwa miesiące technicznych sprawozdań bez możliwości ujrzenia wyniku pracy, jeśli zainwestowało się kilkadziesiąt lub kilaset tysięcy złotych w rozwój produktu.

W wielu firmach specialiści od UI i UX są bagatelizowani lub w ogóle się ich nie zatrudnia. To błąd. To gigantyczne przeoczenie. Ich praca to nie tylko rysowanie okienek – ich wysiłek ułatwia wszystkim zrozumienie produktu oraz pracę nad nim. Projekty zaczynajmy od szkicu, designu, przechodźmy do prototypu, a kończmy na implementacji!

bookmark_borderDlaczego programiści nie lubią szacować czasu wykonania zadania?

Do zadania tytułowego pytania i próby udzielenia na nie odpowiedzi skłonił mnie ten artykuł: https://wedlugplanu.pl/zarzadzanie-projektami/noestimate-manifest-wycen/ , w którym autor odnosi się do idei #noestimate, czyli postulatu porzucenia wyceny zadań, Dla wielu osób zabrzmi to pewnie, jak zgrzyt paznokci na tablicy i wierutna bzdura, ale prawdę mówiąc coś jest moim zdaniem na rzeczy.

Programiści oczywiście wiedzą, czemu nie lubią wyceniać zadań. Wydaje mi się jednak, że osoby z biznesu mogą nie do końca rozumieć tę awersję do deklarowania szacowanego czasu wykonania pracy…

Wstyd i poczucie winy

Zacząłbym od tego, że spora część programistów jest dobrymi, pracowitymi ludźmi. Taka osoba nie lubi rzucać słów na wiatr. Jeśli mówi, że coś zajmie tydzień, a okazuje się, że nie da się go wykonać, odczuwa negatywne emocje. Wstyd, poczucie braku wymaganych umiejętności, wrażenie, że się kogoś zawiodło. Rozwiązania w tej sytuacji są dwa – odmowa udzielania kolejnych wycen lub ich zawyżanie.

Zadanie niemożliwe

Fundamentalny problem polega na tym, że w wielu przypadkach prawidłowe wykonanie wyceny, oszacowanie czasu wykonania zadania jest po prostu niemożliwe.

Kiedy ktoś zapyta nas, ile czasu zajmie nam przygotowanie kotleta schabowego, jesteśmy w stanie odpowiedzieć w miarę konkretnie. Zakładamy przy tym, że mamy wszystkie składniki i nic się nie wydarzy oraz że już kiedyś to robiliśmy.

Zwróćmy uwagę na te założenia. Zastanówmy się, co się dzieje, gdy nie są spełnione.

Zaczynamy pracę nad schabowym. Oszacowaliśmy ją na 30 minut. Otwieramy lodówkę i okazuje się, że mięso jest zepsute. Idziemy więc do mięsnego. Po 45 minutach wracamy z mięsem. Mówimy sobie – powinniśmy o tym pomyśleć. Nauczeni na błędzie rozglądamy się po kuchni i zastanawiamy się, co jest nam niezbędne. Tłuszcz, patelnia, kuchenka, panierka, tłuczek, deska, jajka. Wydaje się, że wszystko mamy. Zaczynamy raz jeszcze. I nagle okazuje się, że mimo dobrego terminu przydatności do spożycia wszystkie cztery jajka, jakie mieliśmy w domu są zepsute. Oczywiście powinniśmy mieć ich więcej, może dwie paczki, myślimy. Idziemy do sklepu i kupujemy jajka. „Zmarnowaliśmy” kolejne 30 minut, a jeszcze nie zaczęliśmy smażyć mięsa…

Mamy nowe jajka. Mamy mięso. Mamy wszystko. Ubiliśmy mięso tłuczkiem, obtoczyliśmy w panierce. Zaczynamy smażyć. I nie wierzymy własnym oczom. Wyłączono prąd.

Na szczęście tylko na 15 minut. W końcu udało się coś ugotować. Z początkowych 30 minut zrobiło się jednak… ponad dwie godziny.

Rzetelna wycena

Zakładając, że chcielibyśmy wykonać rzetelną wycenę musielibyśmy mieć:

  • kompletną specyfikację zadania, bez żadnych niespodzianek i improwizacji
  • doświadczenie w wykonywaniu analogicznych zadań
  • znamy narzędzia i zależności oraz system
  • wszystkie nasze zależności już istnieją i są niezawodne

Doświadczenie uczy, że nie tylko nie wszystko powyższe udaje się spełnić, lecz zwykle wręcz nic. Co więcej zrealizowanie tak rzetelnej wyceny zajmuje ogrom czasu i jest po prostu dysfunkcjonalne.

Współczynnik fi

Patrząc na powyższe problemy próbujemy zatem wycenę zawyżyć. Niektórzy mnożą przez dwa, inni przez współczynnik fi, czy inne pi albo stałą Plancka. Nic to nie daje, bo jak nieskończoność mnożona przez stałą daje nieskończoność, tak iloraz – czy choćby iloczyn – niepewności przez dowolną liczbę również równa się niepewności.

Czy jest na tym bożym świecie zadanie estymowalne?

Rozkładając już ręce w żałosnym geście zadajemy sobie powyższe pytanie. I w zasadzie odpowiedź brzmi: tak. Owszem, w wielu scenariuszach da się sensownie wyceniać. Kiedy robimy kolejną stronę wizytówkę w tej samej technologii, kiedy po edycji produktu tworzymy feature edycji kategorii w tym samym projekcie itp.

Niestety jednak sposobu wyceny projektów nowych, nowych feature’ów, implementacji w nieznanych frameworkach, wykonywanych przez nowo powstałe zepoły – nie ma. Po prostu nie ma.

Po co zatem szacować?

Na koniec odniosę się znów do wspomnianego na początku artykułu. Wyjaśnia on dobrze do czego – mimo ich pozornego braku logiki i ich niedokładności – potrzebne są wyceny. Warto rzucić okiem: https://wedlugplanu.pl/zarzadzanie-projektami/noestimate-manifest-wycen/

W wielkim jednak skrócie, by nie powtarzać niepotrzebnie argumentów, potrzebne są do planowania biznesu, budżetowania i alokacji zasobów. Możemy się w wycenie pomylić, choćby i dwukrotnie, ważne tylko, by nie o rząd wielkości, by z dwóch godzin nie zrobiło się godzin dwieście. Warto o tym pamiętać zarówno będą programistą, jak i zarządzając projektem.

bookmark_borderGreenfield seniorów

Masz do wydania milion dolarów i pomysł na produkt. Co robisz?

Rekrutujesz najlepszych ludzi i wierzysz, że ich doświadczenie sprawi, że powstały zespół efektywnie wytworzy oprogramowanie wysokiej jakości, prawda?

Tymczasem…

Przychodzisz po trzech miesiącach i widzisz, że:

  • pierwszy miesiąc minął na dyskusjach o strategii branchowania, architekturze testów, deploymentu, aplikacji, wyborze chmury, stosu technologicznego, narzędzi CI/CD, wyborze lintera i standardzie formatowania kodu oraz kilku innych podobnych tematach
  • półtora miesiąca zajęła implementacja infrastruktury w chmurze, automatycznych deploymentów, architektury aplikacji oraz refinement tasków
  • ostatnie dwa tygodnie dostarczyły nagłówek i stopkę oraz logowanie i rejestrację użytkownika

Czujesz jak nadciśnienie tętnicze napiera na ścianki twoich tętnic, twoje nerki aż swędzą od produkcji adrenaliny, a szkliwo zębów trzeszczy od napięcia nerwowego. Dowiadujesz się jednak również, że:

  • Maciej odchodzi, bo nie zgadza się z Piotrem w sprawie wybranej infrastruktury aplikacji
  • Bartek od dwóch tygodni prawie się nie odzywał i nikt do końca nie wie, co robi, ale podobno konfiguruje chmurę
  • Połowę kodu napisał Piotrek
  • Wojtka nikt nie lubi, bo nie przepuszcza pull requestów i każe poprawiać
  • Marek chce być team leaderem mimo, że ustaliliście, że nie będzie team leadera

Wracasz do domu, otwierasz 18 letniego Glenfiddicha i z każdym łykem coraz bardziej utwierdzasz się w przekonaniu, że IT to bagno.

Co poszło nie tak?

Oczywiście opisana sytuacja jest przerysowana, wiele w niej jednak prawdy. Problemy są dwa – greenfield i seniority.

Greenfield to projekt nowy, świeży, dziewiczy – taki, który buduje się od zera, mając swobodę wyboru technologii, praktyk, architektury, praktycznie wszystkiego. Jest to marzenie wielu programistów zamkniętych w klatkach utrzymania starych systemów legacy.  

Wysokie seniority jest dobre, wartościowe, bezcenne omal, jednakże we wszystkim potrzebny jest balans, a także dobro nigdy nie jest czyste – zawsze ma w sobie jakąś skazę. Skazą senior developera jest ego. Wielu doświadczonych programistów popada w przeświadczenie, że tyle już widzieli i zęby na tym fachu zjedli, że sądzą, iż mają rację. Prawda jest jednak taka, że każdy się czasami myli, a także, że wiele światopoglądów w IT nie ma znaczenia – lub ma, ale zysk jest mniejszy, niż koszt braku decyzji.

Zebranie wielu seniorów w projekcie typu greenfield jest ryzykownym przedsięwzięciem. Możliwość wyboru technologii i architektury w nieunikniony sposób tworzy kocioł dyskusji w pierwszej fazie projektu. Im więcej seniorów, tym bardziej zażarta ta dyskusja będzie. Juniorzy lub midowie raczej się dostosują – seniorzy zwykle będą uparcie bronić swojej racji i doświadczenia. To oczywiście zrozumiałe, ale w przypadku takiego rodzaju projektu – zgubne.

Dodatkowym źródłem problemu jest „samoorganizujący się zespół”. Gdy brak namaszczonego lidera, pojawia się walka o władzę. Kiedy brak potulnych owiec w stadzie, bo wybraliśmy same stare wygi – mamy problem.

W opinii autora greenfield seniorów to synonim porażki. Kompletując zespół do projektu tworzonego od zera warto go zbalansować i nie ulegać pokusie wyboru jedynie najlepszych. Dobrym pomysłem jest również selekcja oficjalnego lidera – przyspieszy to budowanie się struktury hierarchicznej, zmniejszy walkę o władzę i nada jasno zdefiniowane odpowiedzialności członkom zespołu.

bookmark_borderNienawidzę programistów, tych książąt, nierobów

Pandemia COVID-19 odsłoniła zarówno piękne, szlachetne, jak i ponure cechy rodzaju ludzkiego. W dobrych czasach łatwo być miłym. Stąd przecież mądre powiedzenie, że przyjaciół poznaje się w biedzie. Wrógów również w biedzie się poznaje.

Od kilku już lat dało się słyszeć głosy krytyki wobec programistów w Polsce. Słynny już artykuł „IT arystokracja” wszedł do słownika frazeologicznego naszego pokolenia. Przyprawiono w nim programistom gębę rozwydrzonych dzieciaków klikających w komputer i zarabiających piętnaście tysięcy na rękę. Nomen omen – programista15k stał się równie nośnym hasztagiem, co IT arystokracja hasłem.

Póki bezrobocie malało, a gospodarka rosła, było to jeszcze do przełknięcia dla większości osób spoza branży. Obecnie jednak, gdy wykluczenie z rynku wielu branż zasiało panikę, a na horyzoncie tli się gospodarcza pożoga – łaska dla IT się skończyła.

W coraz większej ilości miejsc czytam zjadliwe komentarze:

  • wam to łatwo mówić, bo sobie pracujecie zdalnie
  • w końcu się skończy eldorado dla programistów
  • teraz i wam się dostanie, książęta z IT
  • wywalą was to się przekwalifikujecie na magazynierów i zobaczycie jak życie wygląda
  • w kryzysie widać kto nic nie robi i jest zbędny
  • skoczą się konsole i piłkarzyki

Gorycz wykrzywia usta, bo nie czuję, by programiści otrzymywali swoje wynagrodzenia bezprawnie, żeby te pieniądze gwałtem, przemocą wyciągali od Bogu ducha winnych ludzi. Większość z nas ciężko pracowała przez ostatnie lata, uczyła się wytrwale nieraz przez dekady i wnosi solidny wkład w gospodarkę. Dzięki nam powstają systemy automatyzujące produkcję, ułatwiające pracę, dające rozrywkę. Posady w IT nie są państwowymi synekurami, ale miejscami, gdzie weryfikuje się umiejętności pracowników, nieraz bezlitośnie, w trwających godzinami testach. Programisci mojego pokolenia nie mieli nawet od kogo nauczyć się zawodu, bo ich ojcowie i matki programistami nie byli. Większość z nas to prawdziwi self-made mani.

Wielką szkodą jest, że społeczeństwo widzi w nas często jedynie rezultat naszych działań – mieszkanie, samochód, czy człowieka przed komputerem. Bardzo bym chciał, żeby dostrzeżono też lata studiów, dekady pasji i zaangażowania, skrzywione kręgosłupy, zaczerwienione oczy, młodość przed kompilatorami, wyrzeczenia, trud tej pracy łączącej w sobie wymagania wielu dziedzin (kreatywność, sumienność, matematyczny rygor, lingwistyczne zacięcie). I żeby nie zignorowano wpływu IT na jakość życia – tego, że dzięki programistom nie trzeba już stać w kolejce na poczcie po odbiór listu, w kolejce do okienka w banku, by wysłać przelew, że można rozmawiać z rodziną w UK na Skype, obejrzeć serial na żądanie, a nie w danej godzinie, słuchać dowolnej omal piosenki bez polowania na album w sklepie muzycznym i jechać przed siebie bez postoju i zaglądania w mapę oraz pytania przechodniów o drogę…

bookmark_borderTypowy scrum

Poprzedni artykuł o scrum sprowokował liczne komentarze i dyskusje. Spora ich część okazała się błyskotliwa, a inne były intelektualnie pobudzające. Prywatnie, w rozmowach ze znajomymi, miałem okazję dowiedzieć się jeszcze więcej o tym, jak implementacja scrum wygląda w miejscach ich pracy. Pewna osoba, pragnąca pozostać anonimowa, zauroczyła mnie swoimi obserwacjami, którymi – po drobnej korekcie, a za zgodą autorki – dzielę się poniżej…


Za siedmioma serwerami, za siedmioma routerami, pod niebem bezcloudnym była sobie firma. A scrum wyglądał tam tak…

Jesteśmy na planowaniu sprintu. Jednocześnie jest to trochę refinement, bo na refinemencie nie zdążyliśmy wszystkiego omówić.

Wyceniamy zadanie.

Opis zadania to 8 (osiem) słów.

Zadanie jest front-endowe, ale nie ma designu.

Nie rozumiesz co w zasadzie trzeba zrobić, ale nie zapytasz, bo macie do wyceny 9 zadań w pół godziny. Raz zapytałeś i wszyscy cię nienawidzili, bo zjedli lunch godzinę później. Zresztą jesteś back-endowcem. I tak nie będziesz tego zadania robił.

Próbujesz trafić w środek, żeby cię nie zapytali dlaczego tak mało/dużo. Trójka i piątka, to jedyne bezpieczne typy. Zazwyczaj trójka. Bardziej optymistycznie. Sprawia wrażenie, że jesteś doświadczony i szybko robisz taski. A jak front-end to już na pewno trójka.

Marcin ma taką magiczna umiejętność, że potrafi zasnąć w 10 sekund i wybudzić się w 2, gdy nadchodzi głosowanie albo pada jego imię.  Połowa zespołu mu zazdrości.

Osób w zespole jest 20. Zwykle dwie, trzy osoby nie mają krzesła. Pomaga to zwalczyć senność spowodowaną brakiem tlenu w salce.

Nikt nie ma ochoty wykonać planowania poprawnie, bo brak powietrza i nadchodzący lunch stanowią silne bodźce popychające zespół do pośpiechu.

Product owner wymyśla cel sprintu ad hoc. Po minucie zastanowienia tworzy konkatenację tytułów trzech najważniejszych zadań.

Wychodzisz ze spotkania, jesz obiad, a potem dodajesz zadanie do sprintu, bo okazało się, że jakoś nam wszystkim umknęło.

Scrum master jest wściekły, bo wykres spalania znów nie wygląda jak w książkach.

Do końca dnia próbujesz się dowiedzieć o co chodzi w zadaniu, które zacząłeś. Nie udało ci się napisać ani linijki kodu, ale powoli już się do tego przyzwyczajasz. Wychodząc z pracy myślisz o jutrzejszym refinemencie.


Życzę wam i sobie, byśmy nigdy się w takiej sytuacji nie znaleźli…

bookmark_borderScrum zabija

Z nadejściem Agile wiązały się duże nadzieje. Wszelkie szkolenia i manifesty obiecywały przysłowiowe złote góry. Waterfall miał być zły, dostarczać biznesowi coś, czego już nie chciał albo nigdy nie chciał, zaś metodyki zwinne wprowadzały nas w świat, w którym klienci są zadowoleni, a produkt powstaje przyrostowo…

W większości przypadków obietnice Agile okazały się kłamstwem.

Widziałem projekty. Wielkie projekty. Małe projekty. Długie i krótkie. Zabite przez Scrum.

Przed

Jak wspomniałem, w narracji Agile pojawia się omal zawsze manicheizm, czyli walka dobra ze złem. Dobry Agile przybywa nas zbawić od złego Waterfalla. Tyle tylko, że w projektach, w których pracowałem ja i moi współpracownicy nie było mitycznego Waterfalla. Zamiast niego były jakieś nieustrukturyzowane próby zarządzania projektami. Bez nazwy, bez dziesięciu przykazań jak działać, za to z doświadczeniem i mądrością organizacji, które te projekty organizowały. Co ciekawe te metodyki ad hoc działały. Nie były sformalizowane, ale przynosiły wartość przedsiębiorstwom.

walka dobra ze złem scrum

W żadnym „pre-Agile’owym” projekcie, o którym słyszałem nie była problemem nadmierna analiza, czy kurczowe trzymanie się planu, jakie rzekomo miało miejsce w Waterfallu. Być może obserwowałem już inny świat, niż twórcy metodyk zwinnych, może był to jakiś złoty środek, moment przejściowy – tego nie wiem.

Transformacja

Początek implementacji Agile w kraju, w mojej percepcji, zaczął się od szkoleń. Robiły wrażenie. Na warsztatach wszystko się udawało, teoria brzmiała rozsądnie. Wszyscy przecież chcieliśmy zadowolić klientów i dostarczać wartość biznesową od pierwszwego sprintu. To szlachetne pobudki.

Wykresy wyglądały ciekawie i idea oglądania postępu pracy w czasie rzeczywistym była kusząca – technokratyczna i nowoczesna. Estymacja nie czasu, a złożoności wydawała się odsuwać od nas odwieczną czarę goryczy – podawania czasu, jaki zajmie nam wykonanie zadania. Byliśmy dość entuzjastyczni.

Dodam, że w lokalnej, polskiej specyfice Agile oznaczał omal zawsze Scrum. Moje uwagi krytyczne dotyczą głównie, jeśli nie wyłącznie tej metodologii.

Efekty

Dość szybko okazało się, że Agile jest trochę jak komunizm – idee brzmią pięknie, ale w praktyce już tak cudownie nie jest. Co więcej zarzuty, że Scrum nie przynosi korzyści bywają również krytykowane na sposób sowiecki – „to nie był prawdziwy scrum”.

By nie pozostać gołosłownym, co do problemów, przejdę przez kolejne dysfunkcjonalne elementy…

Estymacja

Estymacja oderwana od czasu i ograniczona do liczb z ciągu Fibonacciego stała się rytuałem nużącym i w istocie bezużytecznym. W większości zespołów, z którymi pracowałem można było bez zastanowienia „wycenić” zadanie. W jednym z nich w zasadzie wyceny sprowadzały się do 3 i 5. Mimo tego poświęcało się zawsze mnóstwo czasu na wyjaśnianie natury zadań.

We wszystkich zespołach wyceny różnicowały się szybko do 3-5-8. Osiem zwykle zaś było rozbijane na mniejsze zadania. De facto zadania były małe albo duże, lub też za duże – i wtedy przekształcane w małe albo duże. Mnóstwo na to czasu zwykle było marnotrawione, a trafność estymacji „pojemności” sprintu i tak znikoma.

Wykres spalania i planowanie sprintu

Wykres spalania to chyba najbardziej zabawna rzecz w Scrumie. Prawdę mówiąc w żadnym zespole nie widziałem jeszcze, by wykres choć odrobinę przypominał to, jak wyglądać powinien. Albo nic nie jest „spalane” przez tydzień, a potem nagle spada. Albo rośnie, bo nowe zadania są dodawane do sprintu. Albo znów jest stałą, bo praca jest wykonywana, ale zadania nie są zamykane z powodu blokad.

Oczywiście powodem niewydolności jest binarność statusu zadań. Zadania nie mają natury „do zrobienia” albo „zrobione”. Jeśli w życiu zaplanujemy sobie w przyszłym roku kupić mieszkanie, stracić 10 kilo, zrobić kurs Vue.js i kupić psa, to o ile to ostatnie może odbyć się szybko, to kolejne zadania będą na rocznym wykresie nieustannie linią prostą – aż do momentu zakończenia. Co przecież przeczy celowi samego wykresu – ilustracji postępu.

Planowanie sprintu też z kolei nigdy się nie udaje. Jest to pochodna wadliwych estymat, ale też złożoności procesu wytwarzania oprogramowania, którą próbuje się kolanem dopchnąć i ukryć. Jacek robi średnio 12 story pointów na sprint, Marek 10, Łukasz 5, a Maks 6. Jacek poszedł na urlop na 2 tygodnie. Wszyscy zrobiliby 33. Zakładamy, że odpadnie 8.25, bo przecież nie będziemy wyliczać velocity każdemu z osobna. I co? 3.75, czyli małe zadanie nie zmieści się w sprincie, choć pozornie powinno. Nie mówiąc już o tym, że Łukasz jest praktykantem i bez Jacka robi 3 zamiast 5 story pointów, a Maks 4 zamiast 6, bo jest juniorem i też Jacka potrzebuje. Sprint nie dojedzie.

Bezmyślna zmienność

Klient powinien móc zmienić kierunek, w którym idzie projekt, jeśli istotne parametry biznesowe uległy zmianie. To bez wątpienia zaleta metodyk zwinnych, ich duża przewaga. Jednakże w wielu przypadkach pojawia się bezmyślna zmienność. Zamiast rozpocząć od prototypu, od rysunku, zaczyna się od pełnej implementacji, mając świadomość, że wszystko może być następnie zmienione, bo działamy zwinnie.

W jednym z projektów Agile coach tłumacząc ideę zwinności narysował zespołowi kolejno hulajnogę, skuter, motor i samochód. Narysował, popatrzył i powiedział – oto zwinność, oto iteracyjny rozwój. Cóż jednak, gdy od początku wiemy, że chcemy zbudować samochód? Czy naprawdę budowa hulajnogi na początku pomaga nam w budowie auta później? Czy nie jest wręcz przeciwnie? Czy nie będziemy próbowali wykorzystać amortyzatorów z motocykla do projektu samochodu, narażając użytkowników na niebezpieczeństwo?

Crisp's Blog » Making sense of MVP (Minimum Viable Product ...

Nie muszę chyba dodawać, że powoduje to marnotrawstwo zasobów i frustrację programistów, których praca jest wyrzucana do kosza przez kolejne miesiące i pory roku…

Trudne początki

Założenie, że będziemy dostarczać wartość biznesową od pierwszego sprintu jest całkowicie idealistyczne. Zawsze, ale to zawsze konieczne jest przygotowanie choćby pobieżnego planu, wykonanie pewnych czynności wstępnych i początkowa organizacja. Szczególnie naiwne jest twierdzenie, że da się „dostarczać od razu” w dzisiejszych czasach, gdy często konfiguracja infrastruktury na chmurze, konteneryzacja i projekt architektury średniej wielkości projektu może zająć tygodnie.

Spotkania

Czasami trzeba się spotkać. Przeważnie jednak trzeba się raczej skupić i zastanowić, niż spotkać. Spotkania są moim zdaniem przekleństwem Scrum. Widziałem spotkania, na których dwadzieścia osób obserwowało jedną, która wpisywała do Jiry zadanie. Widziałem spotkania, na których połowa zespołu milczała. Widziałem takie, gdzie dwadzieścia procent gapiło się w telefony.

Spotkania mają to do siebie, że często nie dotyczą bezpośrednio uczestników. Pojawia się wtedy nuda. Nuda oraz marnotrawstwo czasu. Dlaczego pracownik, który na spotkaniach spędza 20% swojego czasu, a z tego połowa jest marnowana, ma być efektywny po spotkaniu? Skoro nie szanuje się jego czasu, to czy nie zabija się jego nawyku szanowania czasu pracodawcy, klienta?

Oczywiście rozwiązaniem powyższego jest tworzenie spotkań w małych grupach. Ma to jednak miejsce rzadko i naturalna jest tendencja do gromadzenia dużej ilości osób.

O spotkaniach można by pisać wiele:

  • zabijają produktywność programistów wyrywając ich ze skupienia,
  • często stają się bezproduktywną dyskusją o niczym, o ile nie ma agendy i dobrego prowadzącego,
  • organizowane za wcześnie, za późno, zbyt długie, w okolicach obiadu – potrafią uczestnikom odebrać sen, radość i entuzjazm
  • zbyt częste – rujnują poczucie produktywności, sensu pracy, irytują

Rezultaty

Wbrew początkowemu entuzjazmowi na własne i cudze oczy przekonałem się, że implementacja Scrum w wielu, chyba nawet w większości przypadków, nie podniosła efektywności zespołów i zadowolenia klientów, a chaos przypudrowany rytuałami, spadek wydajności i opóźnienie w dostarczaniu produktów.

Nie chciałbym sprawić wrażenia, że odrzucam ideę zwinności, która nadal wydaje się bardzo sensowna i kusząca. Jednakże Scrum wydaje się zabijać – zabijać entuzjazm, zabijać zespoły, projekty. Moje przelotne doświadczenia z Kanban pokazują, że Scrum może być ślepą uliczką, a jednocześnie warto nie obrażać się na metodyki zwinne.

bookmark_borderMetoda Copy’ego Paste’a

Swego czasu znajomy programista wystosował do przełożonego nietypową prośbę. Zażyczył sobie pedałów wytnij-kopiuj-wklej. Argumentował, że jego praca bardzo przyspieszy.

Pomysł sam w sobie niegłupi. Szczególnie, gdyby połaczyć go ze skrzynią biegów schowka i zmieniać nią obiekty. Był to oczywiście jego szyderczy żart, ale rzeczywistość już tak śmieszna nie jest, bo wczoraj zmarł Larry Tesler.

Kto?

Twórca metody kopiuj-wklej!

Urodził się w 1945 i studiował na uniwersytecie Stanforda. Podczas pracy w PARC w Xerox w latach 70 pracował nad systemem do obróbki dokumentów – Gypsy. Wtedy i tam właśnie narodziła się idea wytnij-kopiuj-wklej, którą potem zaniósł do Apple, w którym pracował przez kolejne lata.

Nie wiem, jak wy, ale ja od dziś Metodę Copy’ego Paste’a nazywał będę Metodą Teslera.

bookmark_borderDaily na 9

Owocowe czwartki, game roomy, ubezpieczenia medyczne, elastyczne godziny pracy. Wszystko, byle tylko zwabić dewelopera do firmy. Żeby go zatrzymać, tego wybrednego, rozpieszczonego przez rynek pracy programistę.

Software house to nie Żabka na Bałutach i głodni, jak mawiał Himilsbach: bajkowego nastroju, klienci nie ustawiają się w kolejce od rana. Można zatem rozpocząć pracę wcześniej lub później. Ważne, by osoby pracujące razem mogły się porozumieć, spotkać, wymienić myśli. Benefit jest ważny, bo chronotyp jest ponoć jak wzrost – bez łamania kości nie da się go zmienić.

Czymże jest ten chronotyp? Jest byciem nocnym Markiem albo rannym ptaszkiem. Jest preferencją organizmu do wstawania rano lub do późnej, wieczornej aktywności. Podobno w tradycyjnie żyjących plemionach rozkłada się on tak, że około 25% populacji lubi nocny tryb życia, 25% poranny, a reszta coś pomiędzy. Miałoby to służyć przetrwaniu grupy, bo w każdym momencie nocy i dnia jest ktoś kto czuwa

Mamy więc Janusza, który wstaje z kurami i Mariusza, co zasypia z sowami. Teoretycznie obaj mają elastyczne godziny pracy i muszą się spotkać od czasu do czasu na callu.

I tu – cały na biało – wchodzi scrum master i ogłasza daily na 9.

Janusz spoko, przychodzi na 7, zje śniadanie, zrobi kupę, poogląda koty w internecie i jest gotowy i świeży na spowiedź z wczorajszych tasków.

Mariusz natomiast każdego dnia roboczego wstaje niewyspany, bo najchętniej przyszedłby na 12, a spać wcześniej nie może. Rośnie mu frustracja, spada IQ, wysypia się tylko w weekendy i wakacje. Każdy poranek spieszy się zaspany na to przeklęte daily. I w dodatku zespół patrzy na niego krzywo. Leń, spóźnia się, marudny, czarna owca, baran czarny.

Tymczasem badania sugerują, że nocne Marki są bardziej inteligentne, a nie leniwe: https://www.psychologytoday.com/us/blog/the-scientific-fundamentalist/201005/why-night-owls-are-more-intelligent-morning-larks

Ta drobna z pozoru kwestia organizacyjna, czyli daily o 9 rano, czyni z marszu nieefektywnym część zespołu. Jak dużą część to już zależy od szczęścia lub nieszczęścia, ale statystycznie około jednej czwartej. Nic nie stoi na przeszkodzie, by daily odbywać na koniec dnia lub w jego środku. Jest to zwyczajnie nawyk, rytuał, który się rozprzestrzenił i jest w nieprzemyślany sposób powielany.

Reasumując: podczas organizowania zespołu scrumowego warto zwrócić uwagę na preferencję jego członków co do godzin, w jakich spotkania mają się odbywać. Dotyczy to również spotkań w godzinach około-obiadowych, gdy część osób może po prostu umierać z głodu z powodu kilkugodzinnych dyskusji.

Zbyt poranne daily może obniżyć wydajność zespołu, o ile znajdują się w nim nocne Marki. Warto o tym pamiętać.