Programowanie jest pięknym zawodem. Jest stymulujące intelektualnie, pozwala na kreatywność, pomaga ludziom ułatwiając im życie i służy biznesowi redukując koszty. Czasami jednak ma smak goryczy.
W programowaniu jest duch wydajności. Od chwili, gdy na pierwszym komputerze udało się policzyć coś setki razy szybciej niż ręcznie, jesteśmy oczarowani możliwością uzyskania niespotykanej wcześniej efektywności. Pewnie dlatego programiści prześcigają się w tworzeniu narzędzi usprawniających pracę. Ergonomiczne edytory kodu, automatyczne testy pozwalające zwiększyć niezawodność oprogramowania, metodyki tworzenia programów sprawniej, szybciej, wydajniej.
Każdy programista, który kiedykolwiek pisał coś co dało się zoptymalizować zna to słodkie uczucie, gdy coś zadziała sprawniej. Swego czasu, gdy jeszcze studiowałem, pewien profesor zlecił nam napisanie programu kompresującego. Algorytm z tego co pamiętam był entropijny, czyli przypisywał słowom używanym w tekście najczęściej najkrótsze symbole, a tym mniej powszechnym dłuższe. Na początku program po prostu działał, jak zwykle w optymalizacji bywa – wolno. Potem trzeba było sprawić by działał szybko. Pamiętam, że chodziłem dzień lub dwa z problemem w głowie, aż w końcu zrozumiałem, że drzewo BST będzie odpowiednim narzędziem w tym przypadku (dekompresji tak konkretnie). Po zmianie program działał błyskawicznie. Satysfakcja była przeogromna.
Tak samo jest z programowaniem poza akademią. Kiedy widzimy sens w projekcie, w produkcie, gdy wiemy, że użytkownicy będą zadowoleni, że ułatwi to ludziom życie – jest pięknie. Praca nad czymś takim to czysta przyjemność.
Bywa jednak gorzko. Pracujemy, nieraz w dużej grupie, miesiącami, nad pewnym produktem, wkładamy w niego serce, pracę i czas, powołujemy go do życia, a potem z powodu jakiejś decyzji na szczeblach władzy dużej firmy projekt zostaje anulowany. Znam osobiście człowieka, który po takiej decyzji opuścił firmę. Ze swojego doświadczenia natomiast wiem, jak boli, gdy dopada nas tego rodzaju wydarzenie.
I o ile zdarza się to raz na kilka lat nie ma w tym większego problemu. Jednak jeśli powtarza się regularnie, jeżeli staje się normalnością, zaczyna rodzić cynizm. Jak przekonać programistę do zwiększania efektywności albo wzmożonej pracowitości, jeśli przez ostatnie kilka lat co drugi projekt w jakim uczestniczył został anulowany, a jego kod nigdy nie wszedł na produkcję? Nie wiem. Po prostu nie wiem. Sądzę, że taki pechowy programista zostaje na jakiś czas, być może na zawsze, zepsuty.
Jest taka mądra opowieść o testach i błędach. Jeśli bug jest wykryty chwilę po powstaniu, jego naprawienie kosztuje niewiele, jeśli tydzień, już więcej, a jeśli lata później, bardzo dużo. Podobnie jest z decyzjami projektowymi – błędne decyzje co do startu projektu albo jego kształtu kosztują ogromne pieniądze. Im mniej tych błędów tym również mniej frustracji wśród programistów w naszym przedsiębiorstwie, a więcej motywacji, efektywności i zysku. Dlatego warto prototypować i badać rynek. Przynajmniej jednak dobrze byłoby programistom wyjaśnić czemu ich praca poszła na śmietnik. Możliwe, że odrobinę zmniejszy to ich gorycz…
Estymacja się nie udała, deadline nas pokonał, nie wyrobimy się. Manager dorzuca ludzi do projektu, ale okazuje się to być gaszeniem pożaru benzyną. Poznajcie prawo Brooksa.
Fred Brooks jest jedną z najbardziej znanych postaci z dziedziny rozwoju oprogramowania. W Polsce nie wiedzieć czemu jest stosunkowo nieznany, a szkoda. Brooks zrobił w życiu dwie wielkie rzeczy – solidnie przyłożył się do rozwoju produktów IBM, w tym OS/360 oraz napisał książkę Mityczny osobomiesiąc. To właśnie z niej, a konkretniej z tytułowego eseju pochodzi prawo nazwane jego nazwiskiem – prawo Brooksa.
Prawo Brooksa mówi:
„dodawanie ludzi do opóźnionego projektu opóźnia go jeszcze bardziej”
Bardzo bym chciał, by świadomość tej reguły upowszechniła się nad Wisłą, bo oszczędziłoby to wielu programistom i menedżerom zbędnego stresu…
Dziewięć kobiet nie urodzi dziecka w miesiąc
W eseju opisującym prawo Brooksa, autor rozróżnia zadania na trzy rodzaje:
zadania idealnie podzielne
zadania niepodzielne
zadania podzielne, wymagające komunikacji
Zadania idealnie podzielne
Skręcanie długopisów lub zbieranie szparagów to przykłady zadań idealnie podzielnych. Dzielimy to, co jest do wykonania na części i przydzielamy różnym pracownikom. Nie istnieje potrzeba by się między sobą komunikowali. Chcąc wykonać pracę szybciej możemy wysłać na pole albo do skręcania więcej ludzi. Wyślemy dwukrotnie więcej, dwukrotnie szybciej skończą.
Zadania niepodzielne
Choćbyśmy do wymiany oleju w samochodzie przydzielili pięciu mechaników, to nie zrobią tego szybciej. Olej musi spłynąć, nowy musi być nalany. Nic nie da dodawanie ludzi.
Zadania podzielne, wymagające komunikacji
I tu właśnie dochodzimy do tworzenia programowania. Wykonanie nowej aplikacji wymaga koordynacji między członkami zespołu. Co więcej wymaga również wdrożenia nowych osób.
Poniższa grafika ilustruje, jak lawinowo rośnie potencjalna ilość interakcji w zespole w zależności od ilości członków. Każda interakcja, rozmowa, wymiana wiedzy między dwoma osobami kosztuje czas, czas tym cenniejszy im bardziej spóźniony jest projekt.
Nowi ludzie w projekcie
Najgorsze w prawie Brooksa jest to, że jest ono sprzeczne z intuicją. Wydaje się bowiem oczywiste, że jeśli jakieś zadanie będzie wykonywała większa ilość osób to muszą je skończyć szybciej. W końcu projekt to nie jedno, ale wiele zadań. Na tablicy „do zrobienia” są różne taski, więc wezmą je i zaczną działać. Co może pójść nie tak?
Wbrew pozorom – sporo.
Przychodzą nowe osoby. Konfigurują swoje komputery, instalują oprogramowanie, ściągają kod źródłowy. Niby coś robią, ale żadnego z tego widocznego efektu przez pierwsze godziny/dni. Wydaliśmy pieniądze, a nie zyskaliśmy jeszcze nic.
Wszystko jest technicznie gotowe, nowi mogą zacząć pracę. Muszą się jednak dowiedzieć, co mają do zrobienia. Organizuje się więc spotkania wyjaśniające naturę projektu. Teraz już nie tylko nowe osoby w projekcie nie posuwają pracy do przodu, ale też dotychczasowi członkowie zespołu przestali pracować nad tym co kluczowe.
Spotkania się zakończyły. Nowi mniej więcej wiedzą, co robić. Zaczynają pracę. Wydaje się, że postęp w końcu ruszy z kopyta. Tymczasem wszystkie okresowe spotkania w zespole zaczęły zajmować więcej czasu. Zakładając, że pracujemy w scrum – dłuższe stają się daily, refinementy, planowanie sprintu i retrospekcja.
Wszystko wydaje się iść do przodu, ale to, czego nie widać na pierwszy rzut oka, to nieustanne pytania nowych osób do starej części zespołu. Nie da się również zauważyć, że te pytania przerywając pracę rujnują ich skupienie. Czasami po kilku minutach rozmowy programista potrzebuje piętnastu minut lub pół godziny, by wrócić do produktywności sprzed rozproszenia. Co więcej programiści pracują przecież nad tymi samymi plikami w zespole. Kiedy było ich trzech nie wchodzili sobie za bardzo w drogę. Nagle okazuje się, że merge’owanie, scalanie plików po zmianach kolejnych trzech osób staje się zmorą i zajmuje dużo czasu. Wydajność wszystkich znacząco spadła, zadowolenie również, a postęp jest wolniejszy, niż się spodziewaliśmy. Dopadło nas prawo Brooksa.
To co, nic nie robić?
Co robić w przypadku opóźnionego projektu to oczywiście doskonałe pytanie, na które jak sądzę nie da się odpowiedzieć ogólnie. Nie byłbym na tyle ortodoksyjny, by stwierdzić, że na pewno nie można dodać kolejnej osoby do zespołu, ale sądzę, że warto się nad tym dobrze zastanowić, przemyśleć ile takich osób i na jak długo planujemy dokoptować, a także koniecznie trzeba porozmawiać z zespołem i zapytać, jak taki pomysł im się podoba.
W wielu przypadkach naprawdę nie ma sensu dodawać ludzi do spóźnionego projektu. Deadline i tak będzie przekroczony, praca zakończy się szybciej, niż gdyby nie dodawać nikogo, a koszt będzie niepotrzebnie zwiększony.
Co jednak bardziej istotne, czasami dodanie ludzi do zespołu może skończyć się autentyczną tragedią. Wtedy prawo Brooksa ujawnia się z całą jaskrawością. Jeśli termin jest naprawdę krótki, a ilosć osób już oscyluje wokół dziewięciu i chcemy dorzucić jeszcze czwórkę, może się okazać, że zespół się kompletnie komunikacyjnie zakorkuje i nie tylko nie dostarczy produktu na czas, ale dostarczy zdecydowanie później, niż byśmy się spodziewali i to absurdalnie większym kosztem.
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…
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!
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.
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.
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.
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…
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.
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?
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.
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.
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ć.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are as essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
