bookmark_borderPrototyp, głupcze!

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

Rękodzieło

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

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

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

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

I często wychodzi ładnie.

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

I czasami wychodzi ładnie.

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

Agile w dwójnasób

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

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

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

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

Wyróżniłbym dwa modele tworzenia produktu:

  • kreatywny
  • konserwatywny

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

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

Prototyp

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

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

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

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

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

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

bookmark_borderTypowy scrum

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


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

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

Wyceniamy zadanie.

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

Zadanie jest front-endowe, ale nie ma designu.

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

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

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

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

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

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

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

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

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


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

bookmark_borderScrum zabija

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

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

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

Przed

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

walka dobra ze złem scrum

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

Transformacja

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

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

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

Efekty

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

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

Estymacja

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

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

Wykres spalania i planowanie sprintu

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

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

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

Bezmyślna zmienność

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

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

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

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

Trudne początki

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

Spotkania

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

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

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

O spotkaniach można by pisać wiele:

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

Rezultaty

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

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

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

bookmark_borderDaily na 9

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

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

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

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

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

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

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

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

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

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

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

bookmark_borderProject managerowie go nienawidzą! Programista z korpo odkrył jeden prosty trik jak wysadzić projekt w powietrze przy użyciu Jiry.

Za górami, za lasami, za siedmioma routerami, był sobie projekt. Był dobry. Deadline był odległy, a budżet zatwierdzony. Zespół liczny, doświadczony. Pomysł na produkt miał ręce i nogi.

Co mogło pójść nie tak?

Zabraliśmy się do pracy. Spotkania, telekonferencje, ustalenia. Planowanie za planowaniem, meeting za meetingiem, sprint za sprintem. Szybko okazało się, że głównodowodzący projektem ma osobowość radiowego spikera. Człowiek ten uwielbiał rozmawiać, mówić, przemawiać i omawiać. Nie ma w tym nic złego. Dobrze jest być towarzyskim. Projekt był rozproszony geograficznie, więc siedziało się na słuchawce godzinami, ale jeśli trzeba coś omówić, to przecież naturalne.

Po rozmowie wypadałoby zacząć pracę, a ustalenia spisać. Nasz lider jednak lubił jedynie mówić. Zadania, jakie dla nas tworzył składały się zwykle z jednozdaniowego opisu staniowącego tytuł.

Projekt trwał i trwał, postępy nie były imponujące. Nadszedł sezon urlopowy. Nasz lider również postanowił udać się na zasłużony wypoczynek. Dwutygodniowy. Przed opuszczeniem biura zorganizował – a jakże! – spotkanie, na którym omówił zadania, jakie przed nami stały. Wydawało nam się, że zrozumieliśmy jego intencję. Dla uspokojenia przekazał nam kontakt do dwóch osób, które miałyby rozwiać nasze wątpliwości w razie, gdyby takowe zaistniały.

Przyszedł kolejny tydzień. Zajrzeliśmy do notatek, zajrzeliśmy do zadania (z jednozdaniowym opisem). Po kilkunastu minutach pojawiły się wątpliwości. Po godzinie rozmawialiśmy z pierwszą osobą, jaka miała nas wspomóc. Okazało się, że zrozumiała naszego lidera inaczej, niż my. Zaniepokoiło nas to. Zadzwoniliśmy do kolejnej. I ona zrozumiała inaczej. Tyle tylko, że nie inaczej niż my, ale również inaczej niż pierwsza osoba. Mieliśmy trzy interpretacje i dwa tygodnie bez autora.

Puenta okazała się zaskakująca. Gdy lider wrócił z urlopu i zaczęliśmy drążyć, jak konkretnie mamy wykonać zadanie i na czym ma ono polegać, po kikudziesięciu minutach kluczenia przyznał, że nie wie.

To najjaskrawszy, z jakim miałem do czynienia, przykład jednego z grzechów programistów – pobieżnego opisywania tasków. Oczywiście nie można być pedantem i opisywać ich przesadnie szczegółowo, ale pewien sensowny poziom detalu i dbałości jest wymagany, by projekt nie eksplodował spotkaniami.

Zastanówmy się. Bierzemy do ręki, na warsztat nowe zadanie. Czytamy opis i połowy z niego nie rozumiemy. Co robimy? Idziemy do autora. Jeśli autor jest z biznesu, to pewnie jest na spotkaniu i nie idziemy, a wysyłamy mail. Czekamy albo bierzemy inne zadanie. Jeśli inne są równie dobrze opisane, to piszemy kilkanaście maili zanim uda nam się zabrać do roboty. Jeśli natomiast autor jest programistą z zespołu to idziemy do niego i… odrywamy go od pracy w skupieniu, przychodząc z naszym  pytaniem.

W obu scenariuszach tracimy czas. Wszyscy. Czas i efektywność.

Opis zadań powinien być precyzyjny, napisany prostym językiem i wystarczająco dokładny, żeby zrozumiała go osoba, która nie posiada naszej wiedzy, a wiedzę wspólną dla członków zespołu. Nie możemy wychodzić z założenia, że jak nie wie to dopyta. To nieefektywne, szkodliwe, złe. To tworzy kulturę rozproszeń, chodzenia od biurka do biurka w nieustającym rytuale dopytywania, ustalania, marudzenia jeden drugiemu. Programista powinien móc jak najdłużej pracować w skupieniu. Tylko tak tworzy się sprawnie dobrej jakości oprograowanie.

Opisuj taski. Opisuj je dobrze. Jeśli nie umiesz ich dobrze opisać, to może nie wiesz w ogóle co jest do zrobienia?

bookmark_borderModyfikowany agile

Nie zliczę, ile to już razy, przez wszystkie przypadki słyszałem odmienianie w ostatnich latach słowo Agile. Jesteśmy Agile, działamy zwinnie, wdrażamy Agile.

Przypomina to kuchenne dywagacje o siłowni. Tak, chodzę na siłkę, tak robię masę, jasne crossfit, cardio, aero, suple.

Tylko muskulatury nie widać. 

I tak samo efektów tej zwinności nie widać. Jak był chaos tak chaos jest, jak estymacje nie szły tak nie idą. A przede wszystkim jak był sztywny scope tak jest i jak deadline’y straszyły tak straszą. Dług techniczny jest zaciągany. Wdrożenia są bolesne. No, ale jesteśmy Agile.

Tylko, czy jesteśmy?

Chyba najgorsze co w Agile nie wyszło, to twierdzenie, że możemy go modyfikować. Tak oto, wracając do analogii siłowni, robimy masę, ale… Nie dbamy o dietę, bo lubimy jeść. Nie robimy ćwiczeń na nogi, bo w piątek idziemy na imprezę. Nie chodzimy na siłkę jak nas głowa boli, bo jeszcze nam żyłka pęknie.

I tak chodzimy przez dwa lata, a zamiast kaloryfera dalej bojler.

Czy można być zwinnym przy sztywnym scope? Czy można wdrażać co sprint jeśli nie ma do tego struktury organizacyjnej? Czy bez pokazywania klientowi co sprint przyrostu można budować lepsze oprogramowanie? Czy w ogóle można być zwinnym jak nie ma jeszcze klienta?

Może tak, może nie.

Na pewno jednak jeśli posuwamy z zasad Agile połowę, nie będzie benefitów, a problemy. Warto by być odpowiedzialnym developerem i nie ulegać zbyt łatwo pokusie zjedzenia ciastka będąc na diecie. Jak wiemy nie można go zjeść i nadal mieć.