Kategoria: polish

bookmark_borderUser experience? Developer experience!

Posted on by kalkus
rusted tools

Zatrudniasz się jako programista. Dostajesz powolny komputer. Nie ma na nim oprogramowania, które pozwala na wydajną pracę. Sporo stron w internecie jest zablokowanych. Nie możesz wybrać sobie klawiatury ani myszy, krzesła też wszyscy mają takie same. Brzmi znajomo?

5S

Japonia posiada interesującą kulturę. Estetyka, porządek, pracowitość – to bez wątpienia ciekawy kraj. Jednym z jego wielkich sukcesów jest motoryzacja. Amerykański przemysł samochodowy – z legendarnym Detroit, z linią produkcyjną w fabrykach Forda – był dumą Stanów Zjednoczonych. Mimo wygranej wojny i lat doświadczeń, w latach 80 przegrał z Japońską motoryzacją, a System Produkcyjny Toyoty wszedł do podręczników organizacji i zarządzania.

Jednym z elementów Japońskiej kultury w tym obszarze jest 5S. Nie wchodząc w szczegóły, jest to organizacja miejsca pracy polegająca m.in. na:

  • usunięciu zbędnych przedmiotów
  • ograniczeniu zbędnego ruchu i wysiłku pracowników
  • utrzymaniu stanowisk pracy w czystości

Wdrożenie tych zasad pomaga stworzyć bezpieczne i efektywne miejsce pracy. Nie trzeba mówić, że pomaga to całej organizacji w utrzymaniu wydajności – co istotne, bez zwiększania wysiłku pracowników.

Alcoa

Alcoa to jeden z największych producentów aluminium na świecie. Ciekawą historię o firmie opisał Charles Duhigg w Sile nawyku. Otóż swego czasu pojawił się w Alcoa nowy CEO – Paul O’Neill. Po nominacji na stanowisko prezesa zaskoczył udziałowców, bo w swoim przemówieniu inauguracyjnym skupił się nie na wynikach, opłacalności biznesu, planach rozwoju, ale… na bezpieczeństwie pracowników. Było to jedyne, co poruszył. Zmniejszenie liczby wypadków przy pracy.

O’Neill zarządzał firmą od 1987 do 1999 roku. W tym czasie wartość rynkowa firmy wzrosła z 3 do ponad 27 miliardów dolarów, a dochód netto wzrósł z 200 milionów do prawie półtora miliarda.

Czy te pieniądze Alcoa traciła na wypadkach przy pracy?

Oczywiście, że nie. Traciła je z powodu złej, niedbałej, niechlujnej organizacji stanowisk pracy. Na tym, że były nieprzemyślane, nieergonomiczne i były takie od lat z powodu złych procesów oraz komunikacji. O’Neill wprowadził presję na ulepszenie organizacji produkcji, bezpieczeństwo stanowiska pracy było metryką doskonałości. Jak widać – skuteczną.

Ciągle im mało

Tak, wiem, jesteśmy roszczeniowi. Mamy game roomy, podnoszone biurka, dwa monitory i owocowe czwartki, ale ciągle nam mało – snujemy się po kolejnych firmach w poszukiwaniu Bóg jeden wie czego, ale pewnie pieniędzy, których ciągle nam mało.

Może tak jest.

Co jednak, jeśli nie?

Co jeśli jest jakaś głębsza przyczyna migracji koderów?

Stanowisko pracy programisty

W programowaniu duży nacisk kładzie się na optymalizację. Motywem przewodnim tej branży od lat jest efektywność. Nowe frameworki, które pozwolą zrobić to samo szybciej. Szybsze procesory, więcej pamięci, potężniejsze dyski. Algorytmy, które liczą sprawniej, lepiej niż starsze. Karty graficzne, które generują więcej klatek na sekundę. Branża technologiczna oparta jest o wiarę w to, że da się lepiej i szybciej, taniej i sprawniej.

Programista, kiedy siada do pracy, próbuje ją sobie zoptymalizować. Jeśli musi wykonywać powtarzalną czynność – napisze skrypt. Jeśli coś zajmuje dużo czasu – pomyśli jak zrobić to szybciej, innym sposobem.

Co więc może być bardziej irytującego dla programisty od sytuacji, w której coś spowalnia jego pracę, a jednocześnie nie da się obejść, usunąć, poprawić?

Tych mniejszych lub większych przeszkód na drodze do wydajności, w wielu miejscach pracy, jest zaskakująco dużo. Oto kilka przykładów:

  • komputer, na którym programujemy ma za mało pamięci / za wolny procesor / za mały dysk
  • internet w firmie działa powoli, np. przez proxy
  • oprogramowanie antywirusowe dramatycznie spowalnia komputer (choćby od czasu do czasu)
  • polityka firmy blokuje pewne strony (np. youtube, gdzie możemy znaleźć tutorial do rozwiązania problemu)
  • przyznanie praw dostępu przeciąga się w nieskończoność (np. by wykonać zadanie potrzebujemy dostępu do systemu x, ale musi je zaakceptować trzech managerów, a to trwa trzy tygodnie)
  • firma nie kupuje pewnych narzędzi albo robi to bardzo powoli (np. potrzeba jakiegoś narzędzia na za tydzień, ale akceptacja i zamówienie zajmuje trzy miesiące)
  • naprawa zepsutego sprzętu trwa bardzo długo (osobiście raz czekałem dwa tygodnie na naprawę mojego firmowego komputera)

Pamiętam pewnego managera, który dziwił się, jak to jest możliwe, że startupy są wydajniejsze? – przecież mają nieraz mniejsze budżety, czyli teoretycznie gorszych pracowników, a jednak dostarczają szybciej. Z mojej praktyki wynika, że to właśnie narzut organizacyjny zabija efektywność…

Skupienie

Poza czysto technicznym aspektem, jakim jest wydajność sprzętu i dostępność narzędzi warto jednak pamiętać również o ergonomii miejsca pracy programisty. W jej skład wchodzą zarówno wygodne, dostosowane do konkretnej osoby krzesło, czy klawiatura, jak i otoczenie.

W wielu firmach kupuje się kilkaset takich samych krzeseł, biurek, monitorów, klawiatur i przydziela każdemu nowemu programiście. To zrozumiałe. Stan tych narzędzi jest zresztą zazwyczaj bardzo dobry. Jest jednak część osób – może niskich, może otyłych, może wysokich albo czułych w jakimś sensie – którym taki standard będzie utrudniał życie. Będzie ich bolał kark albo nadgarstki, będą ich bolały oczy. Trudno wtedy o najważniejszą rzecz w pracy programisty – skupienie.

Programista, jeśli nie może się skupić, trwoni pieniądze firmy. Skupienie zaś nie jest tak łatwe jak przyjście do biura. Rozmowni koledzy, liczne spotkania w trakcie dnia, niewygodne krzesło, zapach ryby atakujący nas z biurowej kuchni… wszystko to może zburzyć delikatną materię flow.

DX

User experience stało się głośną ideą. Na tyle głośną, że specjaliści projektujący interfejsy wygodne dla użytkownika zagościli w wielu firmach tworzących oprogramowanie. Każdy dziś wie już, że ergonomia aplikacji jest ważna.

Analogicznie, należałoby stworzyć ideę DX – developer experience. Im gorszy, tym więcej pieniędzy utonie w projekcie, a to co powstanie może okazać się niewarte wysiłku. Im lepszy tym mniejsza rotacja w zespole, wydajność i motywacja programistów, mniej błędów, a więcej zysku.

Za zalążek DX uznać można słynny test Joela – listę punktów, jakie spełnia proces rozwoju oprogramowania. Im więcej, tym on dojrzalszy, ale również przyjemniejszy dla programistów uczestniczących w projekcie…

Starając się „dopieścić” koderów warto wyjść poza standardy. Nie muszą to być duże koszty. Zyski zaś i owszem. 

Na koniec przypomnijmy, że i Microsoft nigdy nie był obojętny na developerów…

bookmark_borderStek w czasach zarazy

Posted on by kalkus

Japonia to niezwykły kraj. Jego kultura jest znana, ceniona i bogata. Samurajowie, Godzilla, manga i anime, Hokusai, gejsze, origami i tak dalej…

Swoją drogą, Godzilla w oryginale brzmi Gōjira i to właśnie stąd wzięła swoją nazwę znana nam wszystkim… Jira.

Sztuka kulinarna stanowi potężny element kultury kraju kwitnącej wiśni. Jednym z charakterystycznych jej przejawów jest teppan-yaki. Jest to smażenie potraw na wielkiej stalowej, podgrzewanej od spodu płycie. Wygląda to mniej więcej tak:

Cóż jednak począć, gdy COVID-19 szaleje, restauracje zamknięto, a głód puka w ścianki żołądka od wewnątrz?

W Japonii, kraju nowoczesności, istnieje tylko jedno wyjście. Technologia!

bookmark_borderPrototyp, głupcze!

Posted on by kalkus

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?

Posted on by kalkus

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

Posted on by kalkus

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

Posted on by kalkus

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

Posted on by kalkus

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

Posted on by kalkus
czaszka scrum

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.

Więcej o metodyce Scrum w mojej książce – Programista. Przewodnik po zawodzie.

bookmark_borderMetoda Copy’ego Paste’a

Posted on by kalkus

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.