Sunday, July 16, 2017

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 ;)





Friday, February 17, 2017

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.




Wednesday, February 1, 2017

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