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.
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/ .
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.
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ę…
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…
Nasza strona internetowa używa plików cookies (tzw. ciasteczka) w celach statystycznych, reklamowych oraz funkcjonalnych. Dzięki nim możemy indywidualnie dostosować stronę do twoich potrzeb. Każdy może zaakceptować pliki cookies albo ma możliwość wyłączenia ich w przeglądarce, dzięki czemu nie będą zbierane żadne informacje. Ustawienia ciasteczekAKCEPTUJ
Ochrona danych i polityka ciasteczek
Ochrona danych
Ta strona korzysta z plików cookie, aby poprawić wrażenia podczas przeglądania witryny. Z tych plików cookie pliki cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są one tak samo niezbędne do działania podstawowych funkcjonalności strony. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
