Getting Things Programmed najlepszą książką informatyczną w 2017r.

Wiadomość z ostatniej chwili!

Dziękuję za wyróżnienie! Przyznam, że najwartościowszą rzeczą, która przyszła razem z tą nowiną były dwie rzetelne recenzje od Kapituły Konkursu. Uwzględnię je w drugim wydaniu, o które Wydawnictwo ostatnio się dopytuje.

Co z tym analitykiem?

Kiedyś napisałem na gorąco o kilku sprawach, o których powinien wiedzieć analityk. Już po siedmiu latach mam kolejną refleksję o roli analityka :)

Jak wiadomo konsultanci nigdy nie mówią wprost, zacznijmy zatem od pewnej historii...

Jak urządzić mieszkanie?

Sęk w tym, że nie bardzo wiem jak. Moje kawalerskie kwatery przypominały koszary. Z tego względu dla uwicia rodzinnego gniazda postanowiłem skorzystać z profesjonalnej pomocy.

Projekt wykonawczy - bo o tym mowa - został wyceniony przez architektów na 6,1k. OK, pomyślałem, jeśli ma być dobrze i full profeska, to niech będzie.

Akcja rozpoczęła się od inwentaryzacji, a efektem - jak mnie pouczono - miał być PROJEKT WYKONAWCZY. Kompleksowa dokumentacja dla wykonawcy wykończenia, dzięki któremu będzie on mógł "zrobić" mieszkanie kropka w kropkę w zgodzie z zamysłem architektów.

-- Czyli moja ekpia będzie wszystko wiedziała co i jak z tego projektu?
-- Tak! - zdecydowanie potwierdzili architekci - Nie będą musieli zadawać żadnych pytań.

Skąd ja to znam - przemknęło mi przez głowę.

-- Więcej wiary! - skrytykowałem się w myślach - przecież budowle wznosi się od tysięcy lat. Architekci nie są w ciemię bici i wyłożyłem pierwszą ratę - 3,3k.

Co z tą fugą?

Projekt rzeczywiście robił wrażenie: gruby z zewnątrz, a w środku wszystko szczegółowo rozrysowane. Nawet rozłożenie płytek w łazienkach zostało precyzyjnie zaplanowane tak, że odniosłem wrażenie, iż sam bym sobie wykończył to mieszkanie, posługując się rzeczonym projektem. Bez słowa wyłożyłem drugą ratę - 2,8k.

Któregoś dnia zadzwonił do mnie Pan Czarek - główny specmajster z ekipy wykonawczej.

--Panie Michale, fugi się nie schodzą...

Fugi nie schodziły w dolnej łazience. Rząd płytek drewnianych jakoś nie chciał spasować się z płytkami ceramicznymi. Ale łaj?

Wnikliwa analiza w składzie: ja, ekipa i architekt zaowocowała oczywistą odpowiedzią - do projektu wkradł się błąd. Płytki drewniane miały wysokość nie 30cm lecz 31,5cm !

Jak to możliwe - zachodziłem w głowę. W projekcie za prawie 7 klocków takie rzeczy? Architektom trzeba oddać jedno, że sytuację uratowali - i tym razem i w kolejnych przypadkach.

Panie Michale, nie jesteśmy idiotami

-- Panie Michale, nie jesteśmy idiotami - zaczął majster Czarek. -- Przecież ja wiem, jak położyć płytki. No, ale kazał Pan robić wg projektu, a ja z projektem nie będę się kłócił. Po co oni tu piszą, że "drzwi mają być z podcięciem wentylacyjnym? Przecież wiadomo, że mają być podcięte. Po co piszą, że kibel ma być wiszący? Przecież jak go Pan przywiezie, to się okaże czy wiszący, czy stojący.

Tu Pan Czarek pokazał mi, jak wyobraża sobie projekt wykonawczy.

-- A gdzie reszta szczegółów? - zapytałem zdziwiony.
-- Resztę, to sobie dogadamy.

Coś tu poszło nie tak

Mieszkanie zostało wykończone jak trzeba. Siedziałem zadumany na schodach, trzymając w ręku PROJEKT WYKONAWCZY - plik kartek, za który zapłaciłem 6,6k. Coś tu jednak poszło nie tak.

Nie kwestionuję ceny za pracę architektów, wiadomo, że robota kosztuje. Kwestionuję cel, do którego wspólnie się skomitowaliśmy. Nie chciałem płacić za projekt, bo te rysunki nie mają dla mnie żadnej wartości. Chciałem zapłacić za doprowadzenie mieszkania do takiego stanu, jaki spodobał mi się na rysunkach. O to mi chodziło!

A co z tym analitykiem?

Analityk w zespole, analityk jako PO, analityk jako Proxy PO...itd. Każda z tych konfiguracji ma sens. Tyle, że analityku! Twoim celem nie jest wysmażenie BPMNów, UMLi, czy cholera wie czego tam jeszcze. Twoim celem jest dostarczenie tego, czego chce klient. Wespół z innymi wykonawcami na przykład z zespołem deweloperskim. Nie bez powodu na rynku pojawiły się biura architektoniczne mające własne ekipy.

Zauważ, że w opisanym przykładzie nie można mieć żalu ani do architektów, ani do ekipy. Problem leżał w tym, że setup organizacyjny pracy był niewłaściwy. Architekci poprzez zakontraktowanie PROJEKTU mieli inny cel niż ekpia.

Chociaż sam prowadziłem wiele szkoleń z UML, jestem raczej niechętny tego rodzaju formalnym notacjom. Ich intencja jest szczytna, ale prowokują one sytuacje, w których to chęć stworzenia poprawnego modelu zastępuje cele klienta. O wiele bardziej przemawiają do mnie nieformalne notacje "free form diagrams" prezentowane chociażby przez Simona Browna w "Software Architecture for Developers".

O tym, że, mało który deweloper używa UMLa zgodnie ze specyfikacją, nawet nie wspominam.

Prosto ze spożywczaka ważna lekcja analizy

Proponuję ćwiczenie w terenie: odwiedź 5 małych sklepów spożywczych i obserwuj, jakie pytanie zadaje klientowi sprzedawca tuż po podaniu żądanego towaru.

Już?

Prawdopodobnie zauważysz, że zadawane jest jedno z dwóch pytań:

• Czy to wszystko?
  
• Co jeszcze? (w zlokalizowanej wersji na mojej dzielni brzmi to: Co wincyj??)
  

Gdybyś dodatkowo zliczał liczbę zakupionych produktów w zależności od zadawanego pytania, przekonałbyś się, że Ci którzy pytają Co jeszcze? sprzedają więcej.

How it works?

Co jeszcze? jest pytaniem otwierającym proces i skłania klienta do zastanowienia się nad tym, czego jeszcze może potrzebować ze sklepu.

Czy to wszystko? zamyka proces i skłania klienta do skupienia się na tym, czy produkty na ladzie są wystarczające do jego potrzeb?

Tym czasem w trakcie analizy...

Pytaj Czy to wszystko?, gdy formułujesz kryteria akceptacyjne. Chcesz przecież mieć możliwie mały zbiór kryteriów, który spełnia potrzeby interesariusza.

Pytaj Czy to wszystko?, gdy rozmawiasz z interesariuszem, który ma tendencję do dygresji. Od takiej osoby łatwo uzyskasz scenariusze alternatywne przypadku użycia, ale ze scenariuszem podstawowym może być kłopot. Zatem możliwie często staraj się domykać proces za pomocą pytania czy to wszystko?

Pytaj Co jeszcze?, gdy chcesz doprecyzować scenariusz podstawowy przypadku użycia. Wtedy przydaje się "pociągnięcie" procesu do końca za pomocą pytania co jeszcze?

Co wincyj?

Wincyj znajdzieta w mojej ksiunżce "Jak rozmawiać z klientem, który nie wie, czego chce" w rozdziale "7. Sztuka konwersacji z klientem".

Poproszę kartę PayBack!

Poproszę kartę PayBack! - z niezachwianą pewnością w głosie wypaliła dziś do mnie obsługa stacji BP.

Najpierw poczułem lekki niepokój - Rany, nie mam karty PayBack!, następnie poczucie winy, bo przecież nie mam karty PayBack, a Pani prosi i na końcu złość odbijająca się w mojej głowie głośnym WFT.

Szczęśliwie miałem jeszcze przed sobą chwilę jazdy, żeby zastanowić się na spokojnie, co tam się właściwie wydarzyło.

Poproszę kartę PayBack! - to hakerskie zdanie, które zawiera w sobie ukryte założenie, że kartę PayBack posiadam. Aplikowanie klientowi takiego pytania wywołuje w nim - tak jak we mnie - wrażenie, że skoro akurat nie ma tej karty, to jest to nie w porządku i powinien ją czym prędzej założyć u życzliwiej - a jakże! - obsługi stacji benzynowej. W dodatku jest to polecenie do wykonania, a nie pytanie, co tylko potęguje nerw klienta.

Od razu przypomniałem sobie sytuację sprzed kilku lat, gdy dostałem telefon od jednego z ubezpieczycieli, a tam głos w słuchawce Dzień dobry! Czy zależy Panu na bezpieczeństwie Pańskiej rodziny i umówi się Pan ze mną na rozmowę w sprawie ubezpieczenia na życie?.

Było to diabelstwo level wyżej. Gdyż w jednym pytaniu zamkniętym - na tak || nie upakowane zostały dwa pytania. Pierwsze, na które oczywiście się zgodzę. Drugie zaś to właściwa intencja manipulanta z drugiej strony kabla. Hack polegał na tym, że odpowiadając automatycznie na całe pytanie, niechcący można zgodzić się na spotkanie, a gdy to już się stanie manipulant skorzysta z zasady konsekwencji i zaciągnie Cię do oddziału ubezpieczyciela.

Wróciłem na tę stację.
- Przepraszam, dlaczego powiedziała Pani do mnie "Poproszę kartę PayBack" zamiast najpierw zapytać "Czy ma Pan kartę PayBack?
- Tak nam każą mówić. Nie wolno nam inaczej zwracać się do klientów.
No brawo za szczerość.

I tu dochodzimy już do poważnych spraw - do zasad. Na stronie BP można znaleźć ichni Kodeks Postepowania, w którym stoi jak byk:

No, więc uwaga ludkowie od trenowania i pisania skryptów dla obsługi stacji benzynowych: strzelanie w klienta manipulacyjnymi komunikatami to rażący brak szacunku dla klienta i niezwykle mierne standardy etyczne. Czuć, że coś się rozjeżdża między deklaracją wartości a ich praktycznym stosowaniem. Bob Dudley nie jest z tego dumny. Słowo daję, że przy następnej prośbie o kartę PayBack kasier/ka usłyszy - Czy przestał/a już Pani/Pan obnażać przed nieznajomymi?.

Z podobnym numerem spotkasz się w Castoramie Poproszę kod pocztowy! - pyta kasjer z pewnością w głosie. Nie podawaj kodu, nie bierz udziału w badaniach marketingowych, za które Ci nie płacą :).

Dosypywanie pieniędzy - podstawowy problem zwinności

Przypomnij sobie (bądź wyobraź) urządzanie swojej własnej kuchni...
Właśnie zamontowali piękne białe blaty i trzeba wypełnić otwór na zlewozmywak. Stoisz więc przed dylematem:

• zlewozmywak z blachy kwasoodpornej za ok. 300zł - w pełni funkcjonalny, no ale kolorem odbiega od białego blatu
  
• biały zlewozmywak porcelanowy za ok. 1 500zł - pięć razy droższy, ale biały, doskonale pasujący do blatu
  

Teraz zaczyna się liczenie budżetu i załóżmy, że na porcelanę sporo brakuje. Można oczywiście wstrzymać się z decyzją na bliżej nieokreślony czas. Jednak w tym okresie kuchnia będzie nie w pełni funkcjonalna. No, a przecież nie o to chodzi. Decydujesz się więc na zlew z blachy kwasoodpornej z nadzieją, że w przyszłości wymienisz go na porcelanowy.

To jest właśnie cecha zwinności: podejmowanie decyzji w aktualnej sytuacji i w aktualnych ograniczeniach. Podejmowanie ich tak, aby maksymalizować wartość z wykonanej pracy oraz minimalizować straty i nieużytki.

Tylko, że w organizacjach taka sytuacja to rzadkość

W organizacjach, gdy brakuje pieniędzy na prace, to się ich często dosypuje (podkreślam: "często" nie "zawsze" i nie "w każdym bez wyjątku" lecz w "bardzo wielu przypadkach")

A następnie:

• Zespół pracuje nad sprintem i nagle wpada jakiś ubermanager z innej galaktyki z superpilną wrzutką. Product Ownerze, robimy? No, robimy. Przecież to superpilne, a ubermanager przyszedł z workiem pieniędzy
  
• Zespół regularnie nie dowozi sprintu. I co? I nic, biznes poczeka i dosypie trochę kasy.
  
• Od roku żaden sprint nie ma sensownego celu. Luzik, mamy już zaklepane mendeje na kolejny kwartał.
  
• Zespół jest maksymalnie zdemotywowany. Chce pracować, chce być zwinny, chce mieć FOCUS, chce OPENESS i inne też chce. Ale co z tego, jeśli cokolwiek nie zrobi i tak się nic nie stanie?
  

Tymczasem w małej firmie na dorobku

W małej firmie na dorobku, Scrum wygląda nieco inaczej. Zarządzanie małą firmą na dorobku przypomina podtapianie się. Miesiąc w miesiąc zastanawiasz się, czy masz na wypłaty (dla pracowników, z wypłatami dla siebie to różnie bywa). I wtedy musisz podejmować decyzje i respektować ograniczenia, bo od tego zależy Twoje być albo nie być.

Konkludując: Chcesz, aby zespół pracował zwinnie? Nie dosypuj pieniędzy!

Byte My Code 7. października

No więc, co robisz 7. października? Pytam, bo właśnie zostałem partnerem konferencji Byte My Code

Spotkaj się z Mistrzami Java: Wrocław, 7 października!

Nowa Javowa konferencja pod szyldem UBS odbędzie się we Wrocławiu już7 października. UBS Polska zaprosił do Wrocławia Mistrzów Java i Java RockStars, którzy podzielą się wiedzą związaną z najgorętszymi nowinkami ze świata języka Java - a jak wiadomo, w tej dziedzinie dzieje się teraz wiele! Kto stanie na scenie Byte My Code u boku dwóch #JavaChampions?

Java Champions pojawią się we Wrocławiu już 7 października

Na scenie Byte My Code zobaczymy m.in. dwóch Java Champions: Josha Long i Kirka Pepperdine. Mikrofon wezmą do ręki też Łukasz Szydło, Sebastian Malaca, Michał Kordasa i inni mistrzowie programowania. Prelegenci mają bogate doświadczenie w takich zagadnieniach jak:

• Java
  
• Spring
  
• mikroserwisy
  
• architektura aplikacji
  
• automatyzacja
  
• Agile
  
• Domain-Driven Design
  
• testowanie oprogramowania
  
• Groovy
  
• JVM
  

Między innymi tych tematów możecie spodziewać się podczas Byte My Code. Obserwujcie stronę konferencji oraz wydarzenie na Facebooku, by być na bieżąco z aktualnościami.

Spotkanie Mistrzów tylko dla 250 osób

Pierwsza edycja Byte My Code przewidziana jest na 250 uczestników. Nie czekaj i zarezerwuj swój bilet: https://bytemycode.pl - chętnych na spotkanie Java Champions nie brakuje!

Koniec z przytulaniem drzew

Taka sytuacja...oderwany od przyjemnego kodzenia, wbijasz na retro, a tu radosny ScrumMaster rzuca Ci przed nos plik łososiowych karteczek, długopis z biedronką, a potem całkiem poważnie pyta: Jaki kolor miał ten sprint?

No i już wiadomo, że ScrumMaster właśnie wrócił z nowej ekstraedżajlowej konferencji (no, wiadomo, że tam się kręcą sami ScrumMasterzy), gdzie zasilił się nowoczesnymi technikami na retrospektywy.

Ostatecznie dostajesz do wyboru: przytulanie drzew albo poszukiwanie wewnętrznego dziecka...

A gdyby tak zostawić te drzewa w spokoju i zająć się czymś ciekawszym np. architekturą?

Na przykład w ten sposób.

Przed retrospektywą

1. Deweloperzy z Zespołu czytają rozdział "From Mud To Structure" z Pattern-Oriented Software Architecture, 4th Volume.
   
2. Product Owner czyta rozdział "Warehouse Management Process Control" z tej samej książki i opcjonalnie rozdział dla deweloperów.
   

W trakcie retrospektywy

1. Temat do dyskusji: w jaki sposób idee w tekście mają przełożenie na architekturę systemu, nad którym pracujecie
   
2. ScrumMaster dba o timeboxing i o to, aby pojawiające się pomysły zostały konkretnie nazwane
   
3. ScrumMaster dba, aby konsekwencje biznesowe poszczególnych pomysłów były zrozumiałe dla ProductOwnera
   
4. Pomysły spisujecie na osobnych kartkach (nie muszą być kolorowe ;) )
   

Na zakończenie retrospektywy

Grupujecie pomysły według dwóch skal:

• mały/duży wpływ na rozwiązanie problemów w Waszym systemie
  
• mała/duża trudność we wdrożeniu w życie
  

Jako action point proponuję wybrać ten pomysł, który ma możliwie duży skutek oraz możliwie małą trudność we wdrożeniu.

Twórz wartość, zamiast ją kupować

Tym razem o finansach - tak dla odmiany.

Jakieś dziesięć lat temu wkręciłem się w temat zarządzania finansami osobistymi, oszczędzania, inwestowania, itd.
Straciłem trochę pieniędzy i o to przedstawiam mój własny, krwią i łzami nawożony wniosek: Twórz wartość zamiast ją kupować.

Z książek czy kursów na temat finansów poznałem strategie inwestowania o różnych poziomach zarąbistości.
Wszystkie one mają jedną rzecz wspólną - KUPUJ!

Każą kupować obligacje, akcje, fundusze, kruszce, ziemię, monety, ubezpieczenia, obrazy, wino albo zwierzaki, a od czasu do czasu wrzucić coś na lokatę. Ostatecznie chodzi o kupowanie z nadzieją na wzrost wartości, który jak wiem z własnego doświadczenia, bywa, że nie nadchodzi.

A teraz będzie jeb z dzidy i mój kontrprzykład. Napisałem parę książek.
Do tej pory czytelnicy kupili ich 5905 (papierowe, ebooki i wypożyczenia). Moje łączne koszty na ich przygotowanie to ok. 2300zł, które poszło na obrazki do książek i na okładki. Z oczywistych względów nie wyceniam poświęconego czasu.

Biorąc do obliczeń wyłącznie honorarium autorskie, mój "wynik inwestycyjny" wynosi 751%. Jeśli dodatkowo dodałbym do zysku wartość usług, które sprzedałem za pomocą tych książek, trzeba by zacząć dopisywać kolejne zera. W dodatku ta liczba może tylko wzrosnąć.

Który doradca inwestycyjny tyle gwarantuje?

Programista to wymarzony zawód, który pozwala na niczym nieograniczone tworzenie wartości. Twórz ją!

Dzielenie User Stories z życia wzięte

Żona zakontraktowała ze mną poprawę sytuacji wieszaków na ubrania w garderobie.
Garderoba jest tak wygospodarowana za pomocą ścianek kartonowo-gipsowych z powierzchni mieszkania,
że znajduje się pod dość spadzistą częścią połaci dachu.

Konsekwencja tego była taka,
jedyne wieszaki na ubrania jakie miały tam rację bytu ,to takie samodzielnie stojące w liczbie dwa.

Zgodnie z zasadą safe-to-fail experiments zacząłem od najtańszych. I gdy połamał się czwarty, czy piąty,
a sumaryczny koszt wieszaków zbliżał się niebezpiecznie do 1kPLN otrzymałem, wspomniane zlecenie mojej PO.

Na naradę strategiczną zaprosiłem sąsiada, który rychło przekonał mnie do wykonania pracy samodzielnie.

No i się zaczęło:

• nie ma gdzie się rozeprzeć drążkami
  
• prócz ciężaru ubrań na drążek będzie działać jeszcze szarpanie na boki, gdy ktoś nagle zapragnie
  wyciągnąć ubranie z samego końca składu - czyli karton-gipis nie wytrzyma szarpania
  
• i inne mniej poważne rozważania budowlane
  

Ostateczny plan działań rysował się następująco:

• usunąć listwę przypodłogową
  
• na ścianę nakleić sklejkę 18mm, dodatkowo poprawić wkrętami, sklejka ma być oparta o podłogę
  
• wieszak będzie przytwierdzony do sklejki i do podłogi
  

Raźno wziąłem się do pracy, a pomocny sąsiad zorganizował potrzebną sklejkę. Wyglądało to tak:

Jak to bywa, okazało się, że brakuje części, narzędzi i że praca zajmie kilka popołudni, zamiast jednego. Pokój przylegający do garderoby zaczął przypominać pobojowisko:

W tym momencie moja żona powiedziała STOP (nie jest to cytat dokładny). Okazało się, że bałagan w trakcie prac jest istotnym wymaganiem niefunkcjonalnym, które może położyć całe przedsięwzięcie.

A co na to agile?

Kocham wytwarzanie oprogramowania między innymi dlatego, że pomaga załatwiać ważkie sprawy codziennego życia. Takie jak chociażby montaż wieszaka w garderobie.

Optymalizuj proces wytwórczy "pod klienta"

Pierwsza zmiana w trybie pracy polegała na tym, by każdego wieczora po zakończeniu prac garderoba była gotowa do użytku, a pokój uprzątnięty. Mniej więcej tak:

Z mojej perspektywy taki tryb pracy wymagał więcej wysiłku i trwał dłużej, a zatem był droższy. Najchętniej przeniósłbym żonę z dzieciakami na kilka dni do teściowej, a sam ogarnął temat w trzy pacierze.

Z drugiej strony obecność rodziny dawała pewne korzyści:

• informacje od żony: czy za wysoko, czy za nisko, czy wystarczająco miejsca do poruszania się
  
• dzieciaki przeprowadzające testy obciążeniowe
  

Nieustanna obecność klienta pozwoliła mi podnieść jakość produktu (w oczach tego klienta, rzecz jasna) i uniknąć poprawek na samym końcu, a w skrajnym przypadku całkowitego demontażu niefunkcjonalnego wieszaka.

A zatem w kontekście całości przedsięwzięcia (łącznie z odbiorem produktu i sprzedażą) było szybciej i taniej. Ode mnie zaś wymagało to takiego sposobu pracy, aby był on całkowicie zrozumiały dla klientki.

Jak to zapisać w backlogu?

Ten bardzo naturalny sposób pracy nie został wymyślony - został zaobserwowany. Zespołom trudno wpaść w ten tryb, no bo jak to zapisać w backlogu?

Jedną z najistotniejszych rzeczy w zwinności jest rozwijanie produktu w taki sposób, aby klient mógł obserwować postęp prac i nie musiał mieć do tego żadnej magicznej wiedzy.

Zapisywanie tegoż jest ważne, ale wtórne. Jeśli pracowałbyś w ten sposób, a w backlogu umieszczał wpisy postaci:

• Montaż wieszaka w garderobie - etap 1
  
• Montaż wieszaka w garderobie - etap 2
  
• Montaż wieszaka w garderobie - etap 3
  
• Montaż wieszaka w garderobie - etap 4
  

to będzie OK. Może jakiś neofita zwymyśla Cię na forum. Ale Twój klient będzie wiedział o co chodzi, bo będzie widział co się dzieje, więc będzie miał wpływ na to, co wytwarzasz i będzie wiedział za co płaci. I to jest zwinność.

Czytelny backlog - większa przejrzystość

Sąsiedzi odnotowali dwie rzeczy: moją absencję na placu zabaw oraz hałasy dobiegające z naszego mieszkania. Dopytywali więc żonę, co się dzieje.

Mogła odpowiedzieć:

-Michał robi wieszak w garderobie i jest na etapie drugim.

Ale czy to by ich zadowoliło? Czy hałasy nie były zbyt niepokojące? Powstał więc problem z przejrzystością mojej pracy.

Dla jej poprawienia mógłbym nieco przeformułować wykonywane zadania:

• Jako Żona chcę zobaczyć różnicę między wieszakami stojącymi, a tym co robisz, żeby zrozumieć czy mi odpowiada pomysł
  
• Jako Żona chcę powiesić chociaż puste wieszaki, żeby przekonać się jak tego można używać
  
• Jako Żona chcę powiesić kilka lżejszych ubrań, żeby zobaczyć czy wygodnie się tego używa
  
• Jako Żona chcę samodzielnie powiesić mniej używane ubrania, żeby zobaczyć czy mam wystarczającą ilość miejsca do poruszania się w garderobie
  
• Jako Żona chcę powiesić tyle ubrań ile wlezie, żeby zweryfikować wytrzymałość wieszaka
  

Zauważ, jak bardzo przeformułowanie zadań poprawia przejrzystość prac nad wieszakiem. Zwłaszcza z perspektywy mojej żony oraz pośrednich interesariuszy (zainteresowanych hałasem) w postaci sąsiadów.

Dzięki tej przejrzystości moja żona mogłaby sprawniej komunikować się z sąsiadami, a oni mogliby nagle zachcieć mieć podobny wieszak u siebie, gdyż otrzymali bardzo jasne informacje na temat tego, co się dzieje i co można zyskać na poszczególnych etapach prac.

Czy to jest PSI?

No sam powiedz, czy to PSI?

Mamy tu jakiś fragment wieszaka: mocowanie do ściany, ramię do wieszania, podpora oraz mocowanie do podłogi. Czy to już wieszak? W jakimś sensie tak, nie do końca o to chodziło, ale pewien typ ubrań można wieszać.

W PSI ważna jest literka P - potencjalnie. Gdyby ktoś chciał, to potencjalnie mógłby tego użyć, akceptując ograniczenia tej funkcjonalności. Dla mnie osobiście "P" oznacza, że klient ma wystarczający obraz tego, jak wieszak będzie wyglądał na końcu, aby dać zielone światło i pieniądze na dalsze prace.

W tym sensie ułomny pół-wieszak robi na kliencie o wiele lepsze wrażenie niż bałagan w pokoju, a w tle przerażający pisk szlifierki kątowej.

PSI zmienia się w SI

SI, czyli shippable increment.

Czy tak trzeba, czy można robić?

W zeszłym roku remontowałem łazienkę na działce, a wyglądało to tak.

Żona i dzieci wypoczywali nad morzem. Żadnych szczegółowych wytycznych do łazienki nie było, prócz takiej, żeby ją w końcu naprawić. Więc rozoraliśmy z tatą pół domku, a po tygodniu łazienka była gotowa. Żadnego sprzątania na wieczór - proces wytwórczy zoptymalizowany "pod wykonawcę".

Podsumowując mamy dwa sposoby optymalizacji pracy nad oprogramowaniem:

• "montaż wieszaka w garderobie" - optymalizacja procesu wytwórczego "pod klienta"
  
• "remont łazienki na działce" - optymalizacja procesu wytwórczego "pod wykonawcę"
  

Który i kiedy wybrać? To będzie na deser ;)

Uważaj na negatywne kryteria akceptacji

Jeden z portali dostarczył sposobności, aby krótko przybliżyć niebezpieczeństwo negatywnych kryteriów akceptacji. Popatrzmy na rysunek:

No więc, Są świadkowie, którzy nie słyszeli sygnałów dźwiękowych".

Zdejmijmy sobie schemat tego stwierdzenia: Istnieją X, które nie odebrały informacji A.

I zastosujmy ten schemat w innym kontekście: Są dinozaury, które nie zwróciły uwagi na nadlatujący meteoryt.

Czy w takim razie możemy wyprowadzić stąd logiczny wniosek, że meteorytu nie było?

Bingo! Fakt, że coś się nie zdarzyło nie implikuje, że zaistniało coś przeciwnego. Jeśli klient oczekuje, że nowa funkcjonalność ma nie być uciążliwa w użytkowaniu, to niesie to za sobą informację o UX, ale nie mówi Ci co konkretnie ma zostać dostarczone.

Idźmy dalej. Przekonwertujmy w/w schemat w inne logicznie równoważne schematy:

• Niektóre z X nie odebrały informacji A
• Nie wszystkie z X odebrały informację A

i teraz ponowna aplikacja do tytułu portalowego newsa:

• Są świadkowie, którzy nie słyszeli sygnałów dźwiękowych.
• Niektórzy świadkowie nie słyszeli sygnałów dźwiękowych
• 
  
• Nie wszyscy świadkowie słyszeli sygnały dźwiękowe

Które zdanie pobudza Cię najbardziej? :)

Język naturalny pozwala na takie żonglowanie kontekstami i znaczeniami pojęć, aby tą samą informacją wywołać wrażenie innych pseudologicznych wniosków. Język wymagań ma dążyć do jednoznaczności.

Getting Things Programmed - nominacje

Moja książka Getting Things Programmed została nominowana do konkursu wydawnictwa Helion jako:

• Najlepsza książka w kategorii Programowanie
• Najlepsza książka roku 2016

Jeśli więc miałeś okazję się z nią zapoznać i uważasz, że jest warta Twojego głosu - to poproszę o ten głos.

Więcej informacji na: http://helion.pl/osk-nom.phtml i Facebooku

Jak dostarczać przetestowane zadania?

Poniższe pytania i odpowiedzi są możliwie konkretne. Niestety im bardziej konkretna odpowiedź, tym mniejszy kontekst jej stosowalności. I jeszcze bardziej niestety duża szansa na zastosowanie odpowiedzi w niewłaściwym kontekście albo (z powodu nieuwagi autora) wyciągnięcie z tych odpowiedzi wniosków, których autor wcale nie miał na myśli.

Z w/w powodów proszę aby, jeśli wyciągniesz z poniższego tekstu wniosek, który jest sprzeczny ze zdrowym rozsądkiem, Twoim doświadczeniem, Scrum Guidem itp., niezwłocznie mnie o tym poinformuj w komentarzu – w miarę możliwości doprecyzuję tekst.

Problem:

• Sprint trwa 2 tygodnie
  
• Zespół planuje prace na cały sprint
  
• Po wykonaniu zadania PO zleca testy biznesowe osobom z biznesu i na tej podstawie odbiera zadania ze sprintu
  
• Bywa, że osoby z biznesu nie zdążają przetestować zadania przed sprint review i zadanie jest undone
  
• Jak zatem planować prace i współpracować, aby dostarczać zadania, które są done?
  

1. Czy powinniśmy zaplanować development tylko na 1. tydzień sprintu, dając tym samym biznesowi czas na przetestowanie w 2. tygodniu sprintu tego, co zrobiliśmy w 1. sprincie?

- Nie. Tydzień siedzenia i czekania jest stratą czasu i pieniędzy.

2. Czy w takim razie powinniśmy zorganizować prace tak, że testowanie biznesowe odbywa się w kolejnym sprincie?

- Nie. Poprawki zgłoszone do zadań z poprzedniego sprintu będą zaburzać wasze prace w bieżącym sprincie. Modelowo zespół pracuje time & material i otrzymuje wynagrodzenie na koniec sprintu za to, co dostarczył w sprincie. Z perspektywy zespołu nie ma sensu robić w sprincie pracy, która na koniec nie zostanie odebrana i opłacona.

Jednym z kluczowych przesłanek za pracą w iteracjach i inkrementach jest ta, że PO po każdym sprincie może zdecydować się na wstrzymanie prac programistycznych, aby skupić się na biznesowym zarabianiu na produkcie. Może też zdecydować, że już osiągnął to, co chciał i współpraca z zespołem dobiegła końca. Planowanie testów na kolejny sprint odbiera mu tę możliwość.

3. Ale nasz PO liczy mendeje, które spaliliśmy w sprincie. Musimy zaraportować prace na jakieś zadania.

- Dobrze, że je liczy. Powinien również liczyć zysk z dostarczonej pracy. Jeśli zysk jest, to w czym problem?

4. Wy tym, że przecież nie możemy przez dzień czy więcej siedzieć tylko i pić kawę.

- Częściowo to prawda. Chodzi nam o subtelną zmianę priorytetów: przestajemy dążyć do maksymalnej utylizacji Waszego czasu pracy, zaczynamy dążyć do maksymalnej wartości Waszej pracy. Jeśli zatem okazuje się, że wszystko jest done i macie jeszcze czas w sprincie, to warto zastanowić się nad zwiększeniem dostarczanej wartości np. poprzez planowanie większej ilości wartościowej pracy. Poza tym PO nie płaci za wykonane zadania/user story/funkcjonalności, lecz za osiągnięcie celu sprintu.

5. Przypuśćmy, że mamy taką sytuację: w pierwszym tygodniu sprintu zrobiliśmy zadania i poprosiliśmy PO o akceptację (a więc o biznesowe przetestowanie). Czym mam się zająć w następnej kolejności?

- Kolejnym zadaniem ze sprint backloga.

6. Ale wszystkie są już ‘in progress’

- Pomóż kolegom/koleżankom sprawniej uporać się z ich zadaniami, abyście szybciej osiągnęli cel sprintu.

7. Ale oni mówią, że w tej chwili nie potrzebują pomocy i że będziemy sobie przeszkadzać

- Zacznij testować zadania kolegów/koleżanek.

8. Ale oni już zaczęli swoje testy deweloperskie?

- Zacznij testować biznesowo.

9. Ale to analitycy z biznesu mają się tym zająć.

- A kto ma otrzymać wynagrodzenie za pracę, która jest done – Wy czy analitycy z biznesu?

10. Czyli analitycy mają nie testować biznesowo?

- Nie wiem jak jest ułożona Wasza współpraca. Może i mają testować, ale odpowiedzialność za dostarczenie celu sprintu spoczywa na zespole.

11. Ale nie mamy żadnej metody, żeby ich zmusić do testowania na czas

- Co do zasady, to da się zmusić współpracowników do pewnego zachowania, ale wtedy cały czas musisz podtrzymywać bodziec przymuszający np. zagrożenie eskalacją. Ostatnie 40 lat doświadczeń wskazuje, że postawienie na współpracę, budowanie relacji i podejście win-win daje w typowym środowisku biznesowym lepsze efekty.

12. A co zrobić jeśli analitycy nie mają czasu na testowanie?

- Zgłosić PO. Jeśli nie mają czasu odebrać zadania, to nie jest ono wystarczająco ważne albo nie zostało przez nich wycenione biznesowo. Osobiście rozważyłbym niebranie na sprint zadań, co do których nie ma zobowiązania, że zostaną odebrane.

13. Mówiliśmy im, że mają się zobowiązać, ale oni mówią, żeby ze sporym wyprzedzeniem podać kiedy mają testować bo muszą zaplanować swoje prace, a my nie jesteśmy w stanie tego przewidzieć

- Czyli chcecie, aby biznes zaplanował swoją pracę „pod Was”, bo wy nie jesteście w stanie zaplanować swojej?

14. To nie tak. Nie da się patrząc na zadanie podać nawet ‘mniej więcej’ kiedy będzie gotowe do testowania.

- Prawdopodobnie zadania są zbyt duże. Prawdopodobnie należy się przyjrzeć refinementowi.

15. Nie da się ich bardziej podzielić.

- Da się. Zróbmy warsztat na ten temat. Byle na Waszych przypadkach nie na ogólnych schematach.

16. Powiedzmy, że chciałbym testować biznesowo, ale nie wiem jak, nie mam potrzebnej wiedzy.

- Zapytaj analityków z biznesu.

17. Mówią, że nie mają czasu.

- Zapytaj jeszcze raz.

18. Znów nie mają czasu.

- Pytaj aż do skutku. Wpadnij na kawę, na lunch. Popracuj na ich piętrze.

19. Nawet jeśli się czegoś dowiem, to testowanie idzie mi wolno nie wyrobię się do końca sprintu.

- Do końca tego sprintu może i nie, ale za 2-3 może nabierzesz wprawy.

20. A co jeśli do końca sprintu zostało 2 dni, czekamy tylko na wyniki testów biznesowych. Czy możemy zacząć nowe zadanie?

- Zanim to zrobisz, to poświęć chwilę na refinement, poprawę jakości kodu, dopisanie koniecznych testów, spłatę długu technologicznego.

21. Już to wszystko zrobiliśmy…

- To dobierzcie zadanie z product backloga. Unikajcie w trakcie planingu wrzucania do sprint backloga zadań rezerwowych.

22. Dlaczego? Przecież i tak dobieramy z backloga?

- Ale z produktowego, a nie z napchanego sprint backloga.

23. Co za różnica?

- Taka, że jeśli na początku napchacie sprint backlog rezerwowymi zadaniami, to na koniec sprintu prawie na pewno zostaną Wam niewykonane zadania.

24. Ale przecież chodzi o osiągnięcie celu sprintu, a nie o wykonanie wszystkich zadań.

- To prawda. Jeśli cel jest osiągnięty i zostały jakieś zadania, to nie ma dramatu. Mimo to ludzie lepiej się czują jeśli zrobią wszystko, co sobie zaplanowali. Nawet jeśli doskonale rozumieją, że nie jest to celem, to niepusty sprint backlog ich ‘uwiera’.

25. Czyli mamy planować tak, aby wykonać wszystkie zadania ze sprintu?

- Nie. Tego nie powiedziałem. Powiedziałem tylko, żebyście unikali napychania sprint backloga rezerwowymi zadaniami. Tylko tyle. Popełniasz błąd wnioskowania polegający na niewłaściwym odwróceniu implikacji. Poczytaj o błędach poznawczych. np. Sztuka myślenia

26. Przypuśćmy zatem, że dobierzemy jakieś zdanie z product backloga. W takim razie te zadania nie zostaną przetestowane biznesowo do końca sprintu.

- To podzielcie na mniejsze i sami testujcie biznesowo.

27. No, to powiedzmy, że zostało 2h do końca sprintu, dobrałem zadanie i na pewno nie zostanie ono przetestowane biznesowo do końca sprintu.

- No, prawdopodobnie nie zostanie.

28. Ale wcześniej napisałeś, żeby nie robić takich zadań, bo jak skończymy współpracę na tym sprincie, to nam nie zapłacą za nieodebrane zadania.

- Istnieje takie ryzyko. Zmniejszasz je dobierając zdania z wierzchu product backloga w nadziei, że kolejny sprint jednak ruszy, dokończysz to zadanie i otrzymasz zapłatę.

Lecz zanim zdecydujesz się rozgrzebać zadanie, które będziesz kontynuował w kolejnym sprincie, najpierw przeprowadź w/w 27-punktowy ciąg rozumowania ;)