Month: Luty 2016

Czy warto suszyć i całować Backlog?

W jednym z moich poprzednich artykułów pisałam o tym, że:

W Scrumie za jakość odpowiada zespół deweloperski.

Pisałam też o tym że dobry Produkt Backlog, delikatnie mówiąc, ułatwia sprawę. W interesie zespołu jest więc wspomagać PO jak tylko może w utrzymaniu porządnego Product Backlogu. Nie dotyczy to tylko osób wykonujących zadania związane z biznesem. Programistom też się przyda dobre źródło informacji o produkcie.

Do czego?

Będę to powtarzać do znudzenia.

Każda osoba w zespole deweloperskim podejmuje codziennie dziesiątki decyzji. Mogę one wspierać wizję Product Ownera i jego priorytety lub… coś całkiem innego.

Co? Na przykład chęć szybkiego wyjścia z pracy, chęć zaimponowania kolegom bardziej skomplikowanym rozwiązaniem, chęć powiedzenia następnego dnia że już jest zrobione. Każdy z nas chce być bohaterem. Nie ma w tym nic złego. Sztuka polega na tym aby razem z Product Ownerem doprowadzić do takiej motywacji, aby koncentracja na produkcie była czymś zupełnie oczywistym, a inne rzeczy nie zaprzątały nam głowy.

Product Owner jest ekspertem od wizji. Deweloperzy są ekspertami od jakości. Jakość kodu jest ściśle związana z jego czytelnością. Zarówno dobrzy programiści jak testerzy i analitycy biznesowi są w kwestii czytelności absolutnymi ekspertami. Jak więc mogą pomóc Product Ownerowi osiągnąć przejrzystość w Backlogu? Otóż okazuje się, że zgrabnie ujęte zasady związane z czytelnością, które ułatwiają utrzymanie czystego kodu programistom z powodzeniem można zastosować do Backlogu. Mówię tu o trzech zasadach.

 dry

DRY czyli z angielskiego “Don’t reapet yourself”

a po polsku “Nie powtarzaj się”.

“Czekaj, tam jest ten opis, skopiuje się…” – to jest ten moment w którym należy ingerować, bo inaczej Doktor Copy-Paste zamieni Product Backlog w niekończącą się litanię powtarzających się fragmentów dokumentacji. Oczywiście nie dokładnie takich samych, bo świat się zmienia. Klient zmienia zdanie. Rynek się zmienia. Dokumentacja też się zmienia, ale przeważnie tylko jedna kopia, czasem dwie, jeśli o nich pamiętamy. Rzadko wszystkie. Więc jeśli chcesz mieć dostęp do rzetelnych informacji, trzymajmy każdą z nich dokładnie raz. A kopiować można jakiś odnośnik do niej.

pablo (2)

KISS czyli “Keep it simple stupid”,

czyli “Niech będzie tak proste, że aż głupie”.

Czy warto poświęcać czas na wygładzanie opisów w Product Backlogu. Na szlifowaniu ich tak, żeby każdy klient użytkownik i deweloper je zrozumiał. Na ślęczeniu przy nich tak długo, że zrozumiemy je nawet jak siądziemy do nich za rok czasu.

Odpowiedź brzmi TAK.

Z dwóch powodów. Służy to użytkownikom i autorowi:

  1. Użytkownikom bo Product Backlog stanowi plan – do planu zagląda się często. Aby go doszlifowywać, weryfikować i wreszcie realizować. Zagląda tam sporo osób. Użytkownicy, klienci, deweloperzy, zarząd a przede wszystkim autor. Powinien być więc tak prosty i przejrzysty jak tylko się da. Aby nie marnować czasu odbiorców i zachęcać do korzystania. Jeśli będzie się kojarzył z kodeksem, to nikt tam nie zajrzy i będzie mnóstwo niespodzianek. Product Owner będzie miał niespodziankę jeśli nie dostanie tego co chciał, bo deweloper nie zajrzał. Klient będzie miał niespodziankę jak nie dostanie tego co chciał, bo nie zajrzał i nie zauważył, że go nie zrozumiano i tak dalej. Jeżeli do planu nie zagląda się często i nie jest potrzebny wielu osobom, to coś jest nie tak. Planujemy na zbyt długie okresy czasu? A może nie mamy kontaktu z odbiorcami? Nie zbieramy od nich informacji zwrotnej? Możliwości jest wiele. Optymalny Product Backlog jest krótki, zwięzły, aktualny, zmienia się często i jest używany.
  2. Przydaje się też autorowi bo proces klaryfikacji opisu klaryfikuje wizję autora. Czy zdarzyło wam się skasować przypadkiem wyniki swojej pracy, przez co byliście zmuszeni do wykonania jej jeszcze raz? Mi się zdarzało. Bardzo często efekt pracy był dużo lepszy niż pierwotna wersja. Co więcej moje zrozumienie tematu staje się o niebo lepsze. Tak samo jest z kodem i tak samo jest z Produck Backlogiem. Praca nad nim sprawia że, wizja staje się coraz wyraźniejsza i dokładniejsza. Czasem sprawia też, że wizja zmienia się bo autor odkrywa coś czego wcześniej nie wiedział, lub wpada na lepszy pomysł. Konieczność wyrażenia czegoś w prosty sposób, doprowadza do zrozumienia tego lepiej. Warto poświęcić na to czas. Jeżeli wasz Product Owner nie spędza mnóstwa czasu wpatrując się w Product Backlog, to wiedzcie, że coś niedobrego się dzieje z produktem.

4315444

YAGNI czyli “You aren’t gonna need it”,

po polsku “Nie, nie będziesz tego potrzebował”.

Product Backlog jest centralnym punktem informacji o produkcie. Wydaje się więc, że powinien być duży. To nie prawda. Powinno być tam wszystko co ważne, krótko i zwięźle, a nie wszystko co kiedykolwiek ktoś wymyślił. Nadmiar informacji jest świetnym sposobem na ukrycie tego co jest ważne, tyle, że w przypadku Product Backlogu intencja jest odwrotna. Chcemy to przejrzyście pokazać. Tak jak dobry deweloper uczy się w pewnym momencie kasować kod, który napisał bo okazuje się, że nie jest używany, tak i Product Owner uczy się kasować rzeczy, których jednak nie będzie realizował. Niezależnie od tego jak dużo czasu poświęcił na ich zaplanowanie. Wiem to trudne, ale warto. Przy okazji uczymy się, że nie warto planować szczegółów tego, co będziemy robić za pół roku i nie warto trzymać tego planu jeżeli już go mamy, bo i tak za pół roku zrobimy to inaczej. Za pół roku będziemy innymi ludźmi dosłownie lub w przenośni.

Oczywiście nie tylko te zasady czystego kodu z powodzeniem można stosować do Product Backlogu. Czytelność w obu przypadkach jest kluczowa, programiści wykorzystajcie więc swojej doświadczenie w utrzymaniu czystego i czytelnego kodu i pokażcie jak to robić waszym Product Ownerom. Nie z altruizmy. Zróbcie to bo jest to w waszym interesie.

Agent do zadań specjalnych. Pierwszy w Polsce Trener Professional Scrum Developer oraz pierwsza kobieta na świecie z takimi kompetencjami!

Definition of Done dla Product Ownerów – Poradnik Użytkownika

 

Co to jest DoD?

Umowa ma dwie strony – tych, którzy mówią co, i tych którzy mówią jak.

Pewnie słyszeliście już nie raz o  Definition of Done. DoD jest ważne i potrzebne. Tylko  do czego służy Product Ownerowi?

Konia z rzędem pierwszemu Product Ownerowi, który nie zdębiał na dźwięk jakichś „Continuous Integration”, „TDD”, „BDD”, „feature toggle” i innych magicznych haseł, rzucanych przez zespół. Nie widać tego, pomacać się nie da, a żeby zrozumieć trzeba się wczytać w jakieś podejrzane szlaczki.

Zacznijmy od tego, co to jest za wynalazek, to całe Definition of Done.

DoD to umowa – umowa o poziom jakości. Odpowiada na pytanie:  jak bardzo bezawaryjny i przemyślany ma być nasz system? Ile pieniędzy chcemy poświęcić na zachowanie jakości?

W przypadku produkcji butów jest to dość proste – ustawiamy maszyny testujące na wybrane egzemplarze z partii i je rozciągamy, naciskamy, imitujemy zużycie. Wszystko widać. Koszty jakości i ryzyka jej niezachowania bardzo łatwo policzyć. Bułka z masłem.

Tu są smoki

W przypadku softu sprawa jest nieco bardziej interesująca.

DoD to jedno miejsce, w którym znajdziemy warunki określające, co to znaczy, że coś jest zrobione, czyli wykonane i gotowe do wydania (w niektórych przypadkach już wydane) oraz jakich praktyk jakościowych dotrzymaliśmy, żeby do tego dotrzeć. Brzmi bardzo prosto. DoD przykładane jest do każdego elementu Product Backlogu (PBI), jaki bierzemy do pracy, czyli musi być jakościową częścią wspólną.

DoD jest też często mylone z kryteriami akceptacji – czyli specyficznymi warunkami, które dotyczą konkretnego zadania.

Budujemy nowy dom…

Definition of Done w działaniu

Budujemy sobie dom. W domu ma być piwnica, parter i poddasze. Na parterze ma być kuchnia, salon, łazienka, gabinet i wiatrołap. Mamy z tego backlog wyglądający tak:

– Kuchnia (Parter)

– Łazienka (Parter)

– Salon (Parter)

– Wiatrołap (Parter)

– Gabinet (Parter)

– Piwnica

– Poddasze

Jakie może być tu DoD? Na przykład:

– Podłogi panele Krono Sound

– Ściany farba bezlateksowa (Dzieci mają uczulenie)

– Ściany z porothermu

– Okna drewniane, trzyszybowe

– Osprzęt elektryczny biały, Simon54

Zauważcie, że powyższe warunki dotyczą wszystkich pomieszczeń. W kryteriach akceptacji znajdziemy wytyczne dla danego pomieszczenia– na przykład wanna w łazience, albo biurko w gabinecie.

Mogą też być wyjątki – w łazience nie będzie podłogi z panelami, tylko kafle. Ale to już trzeba dokładnie zaznaczyć w opisie.

W przypadku softu DoD pełni taką samą funkcję.

Przykład:

Kod w repozytorium, opisany i zgodny z ustaleniami czytelności

Algorytmy stworzone w Pair Programmingu i TDD

Metody nie dłuższe niż 40 linii

Regresja przechodzi

Pokrycie min. 78%

Kto to ma rozumieć?

Warto rozmawiać.

Zespoły są zobowiązane wytłumaczyć PO, na czym polegają różne elementy DoD. Chociaż PO także musi mieć elementarną wiedzę z tego zakresu. Tak jak budując dom, jego właściciel uczy się o aspektach budownictwa.

A co się stanie jeśli DoD nie zostanie zachowane? Właśnie w taki sposób tworzy się dług technologiczny. Jak z bajki o Wielkim-Złym-Project-Managerze.

Format

Najlepiej na początku spisać sobie DoD w formie umowy. Z podpisami. Dlaczego tak? Bo umów z własnym podpisem raczej się pilnuje i przestrzega, a każde od nich odstępstwo musi być zgłaszane. Pamiętajcie tylko, że co prawda ciężar DoD spoczywa na zespole, jednak jest to umowa, a umowa ma dwie strony. Może się zdarzyć że PO jakaś praktyka wydaje się niepotrzebna. Wtedy trzeba to przedyskutować na retro. Podobnie jeśli jakieś nieścisłości widzi Zespół.

Niektóre zespoły wbudowują DoD w swoje Sprint Backlogi tak, żeby przy dodawaniu elementu ten automatycznie rozwijał się we wszystkie elementy DoD.

A inne używają do tego po prostu kartki na ścianie.

Zgodność

A co w takim razie ze sprawdzaniem zgodności DoD? Skąd mamy wiedzieć, że oddany element ją spełnia?

Po pierwsze trzeba sobie uświadomić, że PO nie ma zwykle wystarczającej wiedzy, żeby taką zgodność sprawdzać. Kto zatem pilnuje żeby wszystko się z DoD zgadzało? Pewnie już się domyślasz – Scrum Master, DoD to w końcu część procesu. W tym akurat przypadku bardzo rzadko SM osobiście  sprawdza, czy wszystko jest zgodne. DoD jest weryfikowana podczas sprintu, na bieżąco. Kiedy tylko PBI  jest ukończone. DoD jest zwykle używana przy planowaniu sprintu, więc nic nie umyka. Zdarza się, że kiedy zespół jeszcze się uczy pracy w Scrumie, SM sprawdza od czasu do czasu, czy coś nie umknęło, ale na pewno nie kontroluje zgodności dla każdego PBI.

Idealna DoD

Byle z umiarem

Warto też nadmienić, że problemy z DoD często są powodowane tym, że jest ona albo za prosta albo zbyt skomplikowana. W pierwszym przypadku wszystko ją spełnia, więc nie ma sensu się wysilać, a w drugim zespół po prostu nie pamięta wszystkich jej ustaleń. Warto więc trzymać DoD w sensownej wielkości.

Mentorka o niezwykłej charyzmie. Jeden z najbardziej doświadczonych ekspertów Scruma i pierwszy trener Scaled Professional Scrum w Polsce.

Bajka o Wielkim Złym Project Managerze

Usiądźcie wygodnie dziatki. Opowiem wam bajkę. Będzie strasznie. Dobrego zakończenia też nie ma, ale Bajki Braci Grimm też do najweselszych nie należą. Jak to w bajkach z morałem.

Za siedmioma górami, za siedmioma lasami w Software „Spierniqa” pracował sobie Development Team o wdzięcznej nazwie „Misie”. Misie produkowały sobie świetny soft. Klienci byli zadowoleni, Misie spełniały się jako eksperci.

99

Pewnego dnia, Misie zaplanowały sobie release. Zaplanowały jak zawsze, z uwzględnieniem prędkości którą miały w poprzednich sprintach. Z planowania wyszło im coś takiego:

8

Jednak komuś się to nie spodobało. Chciał żeby to, co zostało zaplanowane dostarczono szybciej. Co więc zrobił? To co podpowiadało mu doświadczenie i wykrzyknął gromko „Pracujcie szybciej!”

7

No więc Misie pracowały szybciej. Na wykresie wyglądało to tak. Jak myślicie, czym jest to coś zaznaczone klamerką? To jest NIEZROBIONE, znane też pod nazwą długu technologicznego albo śmierdzącego kodu.

Jaki efekt ma takie „niezrobione”? Najczęściej taki, że kod jest nieczytelny, są tam rozwiązania „na słowo honoru”, przez co pojawia się więcej błędów, więc i częstsze awarie, i wiele innych rzeczy.

Czy Wielki-Zły-Project-Manager osiągnął zlecone mu cele? Oczywiście! Zespół dostarczył szybciej. Więc Wielki-Zły-Project-Manager dostał swój worek pieniędzy i poszedł dalej, do kolejnego projektu.

6

A Misie? Misie zostały z tym coraz brzydszym kodem.

5

Więc zaplanowały sobie kolejny release. Tym razem już praca szła im wolniej, bo musiały przebijać się przez poprzednio stworzony dług technologiczny.

4

To już zdecydowanie się komuś nie podobało. Ponieważ poprzedni Wielki-Zły-Project-Manager już dawno pracował nad innym projektem, zatrudnił do pogodnienia Misiów Ogromnego-Jeszcze-Gorszego-Project-Managera, z jeszcze większym batem, który strzelił z niego i głębokim głosem nakazał Misiom: „Pracujcie szybciej!”

3

Co się stało zapytacie? Ano pracowali szybciej tworząc kolejne pokłady długu i nie mogąc go spłacać. Ale dostarczyli szybciej. Więc Ogromny-Jeszcze-Gorszy-Project-Manager osiągnąwszy swój cel dostał swój worek pieniędzy i poszedł dalej.

2

Kilka releasów później, gdy produkt był już w stanie nie nadającym się do rozwoju, bo każda dopisana linijka generowała błędy i konflikty, nadszedł czas na przepisanie tego rozwiązania. Które kosztuje więcej niż rozwój obecnego do tej pory.

1

Bajka ta niestety nie ma dobrego zakończenia. Misie poszukały sobie pracy gdzie indziej, a do przepisania produktu wzięło się kilkoro praktykantów.

Czy warto więc zatrudniać zmieniających się Wielkich-Złych-Project-Managerów? To pozostawiam Waszej ocenie.

A co by się stało, gdyby ten produkt miał pracującego z zespołem Product Ownera? Kiedy zacząłby naciskać na zespół podczas pierwszego releasu, spowolnienie ugryzłoby go w zad bardzo szybko i okazałoby się, że takie ruchy są nieopłacalne. Ale zmieniający się PM-owie nie mają szansy tego zauważyć.

Jakby tego było mało, wyobraźcie sobie morale tego zespołu, który pod batem ogląda, jak powoli sami niszczą coś, co wspólnymi siłami budowali.

Uwaga dla hejterów: ta bajka nie ma za zadanie zdyskredytowania działań PM-ów i nie oznacza , że wszyscy PM-owie są źli. Jest tu pokazany pewien specyficzny, ale i częsty przypadek, którego ofiarami sa także PM-owie, bo w tym przypadku po prostu wykonują dobrze swoją pracę – osiągają zlecone im cele. Ale o wyznaczaniu i osiąganiu celów w kolejnej bajce. Śpijcie dobrze.

Mentorka o niezwykłej charyzmie. Jeden z najbardziej doświadczonych ekspertów Scruma i pierwszy trener Scaled Professional Scrum w Polsce.

© 2017 Brass Willow Blog

Theme by Anders NorenUp ↑