#088 – Definicja Ukończenia

Definicja Ukończenia – Definition of Done – jest ważnym zobowiązaniem scrumowym powiązanym z Przyrostem produktu. Tworzy ona przejrzystość, dzięki której wszyscy rozumieją jaką pracę trzeba wykonać. Zdefiniowanie Definicji Ukończenia to zadanie Zespołu Scrumowego. Podamy Ci przykłady, co może wchodzić w skład DoD i dodamy kilka wskazówek i obserwacji z naszej praktyki.

Zapraszamy Cię do obejrzenia nagrania podcastu i przeczytania artykułu.

Jednym ze zobowiązań scrumowych powiązanych z przyrostem produktu jest Definicja Ukończenia. Czym jest ta Definicja Ukończenia i dlaczego jest tak istotna w Scrumie?

W tym artykule opowiemy nie tylko o tym, co oznacza Definicja Ukończenia, czyli Definition of Done (DoD), ale co ważniejsze, podamy Ci przykłady jej elementów składowych oraz podzielimy się praktycznymi wskazówkami jak efektywnie stosować DoD w pracy.

Czym jest Definicji Ukończenia?

Zgodnie z Przewodnikiem po Scrumie Definicja Ukończenia to formalny opis stanu przyrostu, w którym spełnia on kryteria jakościowe wymagane dla produktu. Konkretny przyrost powstaje, kiedy element Backlogu Produktu osiąga zgodność z Definition of Done. 

Definicja Ukończenia tworzy przejrzystość. Powoduje, że wszyscy tak samo rozumieją, jaką pracę trzeba wykonać, żeby osiągnąć przyrost, który będzie ukończony. 

W najnowszej wersji Przewodnika po Scrumie dodano bardzo ważne zastrzeżenie, że jeśli dany element Backlogu Produktu nie osiągnął stanu zgodnego z Definicją Ukończenia, nie może zostać nawet pokazany podczas przeglądu Sprintu.

Odpowiedzialność za zdefiniowanie Definicji Ukończenia spoczywa na Zespole Scrumowym, a jeśli więcej zespołów korzysta z DoD, to powinny one umówić się na określony standard i wówczas żaden zespół nie może dostarczać swojej części produktu w niższym standardzie. Może za to dostarczać go w wyższym. 

Jeśli organizacja formułuje pewne ograniczenia, oczekiwania, czy standardy dla zespołów, to powinny one przyjąć te oczekiwania jako część swojego Definition of Done.

W celu podkreślenia istotności tego narzędzia przedstawimy Ci pewne analogie z życia codziennego. Pierwsza z nich jest powiązana z hobby, np. prace w ogrodzie. Gdy Kuba kosi trawnik, to oprócz samego skoszenia trawy i sprawienia, że jest ona krótsza, to musi on także zrobić po sobie porządek. Kosiarka nie może zostać na środku trawnika, kabel powinien być zwinięty, a trawa, która nie trafiła do pojemnika w kosiarce, zgrabiona i wyrzucona. Jeśli tego nie zrobi, to będzie to wyglądać nieestetycznie, a trawnik będzie zawalony składowymi koszenia. W momencie, gdy będzie chciał ponownie skosić trawnik, to może mieć problem ze znalezieniem np. kosiarki, bo ktoś inny schował ją w inne miejsce niż zazwyczaj. 

Drugim przykładem, od Jacka, jest hobby związane z pracami w domowym warsztacie samochodowym. Pełni ją wydzielona strefa w garażu. Część rzeczy ma tam poukładane i wie, że np. klucze nasadowe znajdują się w określonych pojemnikach. Zdarza się tak, że kończy on swoje prace późno, ale ma ochotę jechać na przejażdżkę testową. Żeby było szybciej narzędzia, które używał, odkłada na bok, zamiast na swoje miejsce. I to właśnie będzie rodziło problemy w przyszłości, bo nie będzie wiedział, gdzie są poszczególne narzędzia. Dlatego częścią naprawy powinno być posprzątanie i odłożenie narzędzi tam, gdzie powinny się znajdować. Dzięki temu kolejnym razem nie będzie miał niespodzianek i nie będzie tracić czasu na szukanie narzędzi. 

Te dwie analogie pokazują, że częścią pracy jest także doprowadzenie pewnych czynności do “dodatkowego” końca, czyli posprzątanie po sobie, poukładanie narzędzi. 

Ostatnią analogią podzielił się mentor Kuby na początku jego pracy: „Wyobraź sobie, że podbijamy jakiś nowy teren, jesteśmy zdobywcami i wykonujemy konkretne kolejne kroki. Osiągamy pewną granicę terenu i my ten teren, który zdobywamy, umacniamy. Tworzymy zabudowania, tworzymy jakiś bastion, tworzymy mury i te mury już są nienaruszalne. Osiągamy ten stan i mamy gwarancję, że już ten etap osiągnęliśmy i w kolejnym kroku możemy znowu podbić kawałek terenu i znowu go umocnić”. Jest to poniekąd metafora ukończonych, kolejnych, kompletnych kroków. Jeśli działamy zgodnie z Definicją Ukończenia, to każdy kolejny krok jest właśnie w tym sensie umocniony. Nie musimy się cofać, nie musimy się martwić, nie musimy się zastanawiać, czy za nami nie zostało coś niedokończonego. Każdy krok, każdy kolejny kawałek produktu, jest już kompletny, skończony, w tym samym jednoznacznym, nienaruszonym standardzie.

Przykłady elementów składowych Definicji Ukończenie w Zespole Scrumowym.

W skład Definicji Ukończenia mogą wchodzić:

1. Spełnione kryteria akceptacji
Produkt, przyrost czy konkretny element Backlog Produktu jest skończony wtedy, gdy spełnione są kryteria akceptacji, które zostały sformułowane dla tego elementu.

Czym są kryteria akceptacji? Można powiedzieć, że jest to unikatowa umowa mówiąca, po czym poznamy, że konkretny element z Backlogu Produktu został zrealizowany zgodnie z oczekiwaniami. Natomiast oczekiwanie, że kryteria akceptacji będą spełnione, jako część Definicji Ukończenia oznacza, że każdy element, który ma przejść przez Definicję Ukończenia z pozytywnym skutkiem, po prostu musi mieć wcześniej zapewnione to, że kryteria akceptacji są sprawdzone. Potwierdzamy, że dokładnie tego oczekiwaliśmy od tego konkretnego elementu.

2. Przetestowane przez inną osobę niż ta, która implementowała
Wiąże, się to z tym że jakość w zespołach bywa różna. Ponadto są też zespoły, w których nie jest jasno powiedziane, co oznacza, że coś zostało przetestowane. Przekazanie czynności wykonania testu innej osobie od tej, która implementowała, zwykle pomaga w wychwyceniu błędów, które dla osoby, która tworzy, są niewidoczne, albo z jakichś powodów w procesie testowania pomija pewne ścieżki.

3. Dotrzymane standardy kodowania
Jest to powtórzenie pewnego minimalnego standardu, którego oczekuje się od każdego zespołu programistycznego w danej firmie. Może się jednak okazać, że my sami jako zespół Scrum Scrumowy, jakiś standard dodatkowo podnosimy.

4. Obowiązkowy Code Review
Code Review, czyli przegląd kodu, który jest na bieżąco sprawdzany, testowany i oceniany przez innego developera. Ta ocena to po prostu merytoryczny feedback. Przegląd kodu pozwala na wczesnym etapie i regularnie upewniać się, że wszystko działa, tak jak powinno, jest napisane zgodnie z ustaleniami, a standardy, na które się umówiliśmy, zostały spełnione.

5. Zgoda zespołu, na jakie środowisko wprowadzamy zmiany
Spotykamy się z zespołami, które nie mają tego ustalonego i robią to w sposób bardzo różnorodny. Jedni pokazują kawałek rozwiązania na swoim środowisku deweloperskim, inni na jakimś testowym, jeszcze inni na jakimś integracyjnym. To może pociągać za sobą różne konsekwencje (np. niedopilnowany standard jakościowy) oraz może wymagać dodatkowych czynności, np. związanych z przygotowaniem jakichś narzędzi czy skryptów. W rezultacie może się okazać, że produkt końcowy nie jest taki, jak zakładaliśmy.

6. Zaktualizowane statusy pracy
Istotna jest też umowa na to, że praca jest zakończona w momencie, kiedy zaktualizowaliśmy także status tej pracy w jakimś konkretnym narzędziu. Ułatwia to planowanie kolejnego Sprintu, gdyż nie musimy przechodzić przez cały Backlog, upewniając się, czy ten kawałek pracy jest wykonany, lub czy ten status jest odpowiedni. 

7. Instrukcja dla użytkownika zaktualizowana o najnowsze zmiany
Warto pamiętać, że świat nie kończy się na części deweloperskiej i są dodatkowe obszary, które należy zaopiekować. Przykładowo użytkownik zegarka sportowego po aktualizacji firmware’u i dodaniu nowej funkcjonalności powinien nie tylko zostać poinformowany o tej funkcjonalności, ale także powinien móc znaleźć w instrukcji użytkownika jak jej używać. 

8. Zaktualizowana otoczka marketingowa dla produktu
Mamy tu na myśli komunikację, reklamy czy materiały marketingowe, aby całość naszych działań była aktualna i spójna.

Oczywiście pamiętaj, że te wszystkie punkty są tylko przykładami. Po pierwsze, nie każdy zespół musi mieć wszystkie te elementy. Po drugie, pewnie są jeszcze dziesiątki elementów, które w różnych zespołach z jakiegoś powodu znajdą się w takiej Definicji Ukończenia. 

Kilka wskazówek praktycznych dla stosowania Definicji Ukończenia

Bazując na naszym doświadczeniu podzielimy się teraz z Tobą dobrymi praktykami związanymi z Definition of Done:

1. Bądź realistą
Na początku pracy z Definicją Ukończenia, w szczególności, jeśli pierwszy raz z niej korzystamy, warto postawić sobie poprzeczkę na takim realnym poziomie.

Piszemy o tym, gdyż zespoły bardzo często wpadają w pułapkę wymyślania bardzo wysublimowanej i ambitnej wersji Definicji Ukończenia. Nie odzwierciedla ona stanu aktualnego, a przez to, że jest nierealna, szybko przestają jej przestrzegać. Dlatego zachęcamy, aby na początku odzwierciedlić rzeczywistość, odpowiedzieć sobie na pytanie, co dzisiaj robimy i zastanowić się nad jakimś jednym prostym usprawnieniem, jakimś drobnym podniesieniem poprzeczki.

Tak naprawdę to trochę eksperymentujemy, czy my w ogóle jesteśmy w stanie w taki sposób pracować, stąd warto zacząć od tego, żeby ta poprzeczka była po prostu na osiągalnym poziomie.

2. Zadbajcie o egzekwowanie Definicji Ukończenia
Egzekwowanie wykonania Definicji Ukończenia bywa trudnością dla wielu zespołów, dlatego też potrzebna jest tu dyscyplina. Spotykamy się z sytuacją, w której Definition of Done jest gdzieś spisane, jednak nikt nie pamięta gdzie, co pokazuje, że od dawna nie zaglądano do tego miejsca. Ponieważ miewa ona zwykle kilkanaście punktów, to raczej nie nikt jej też nie zna na pamięć.

3. Ułatwiajcie sobie korzystanie z Definicji Ukończenia 
Mamy tu na myśli korzystanie z różnego typu narzędzi i technik, które zapobiegną zapominaniu o DoD. Przykładem takiego działania może być przykładowo dodanie do każdego elementu Backlogu Produktu checklisty z kryteriami akceptacji. Innym sposobem może być wyznaczenie osoby odpowiedzialnej za pilnowanie wszystkich punktów Definicji Ukończenia. 

4. Wymuszanie pewnych kroków
Czasem trzeba rozważyć wymuszanie pewnych kroków spełnienia Definicji Ukończenia poprzez  na przykład ustawienia w narzędziu, z którego korzystamy. Mamy tu na myśli, takie rzeczy, które są krytyczne z perspektywy organizacji czy biznesu.

Chodzi tu o takie ustawienie narzędzi, żeby pewne kroki były obowiązkowe i nie można było ich pominąć, co będzie pewnym rodzajem przypominajki, albo po prostu zabezpieczenia, że nikt nie pominie jakiegoś kroku, który jest po prostu wymagany i obowiązkowy.

Na koniec chcemy się podzielić z Tobą jeszcze jedną myślą. Bywa i tak, że Definicja Ukończenia jest narzucana przez organizację. Najczęściej wynika to z tego, że management chce mieć pewność, że tworzony produkt spełnia konkretne oczekiwania co do jego działania czy jakości. Naszą rekomendacją jest tutaj unikanie przesadnego kwestionowania zasadności tego. Oczywiście nie zachęcamy Cię do przyjmowania wszystkiego w ciemno, merytoryczna dyskusja jest wskazana, ale jeśli organizacja ma racjonalne uzasadnienie takiego postępowania, to znaczy, że warto zaakceptować te oczekiwania. Często wynikają one z wcześniejszych doświadczeń. Jeśli natomiast zauważymy pewne niedoskonałości tej Definicji Ukończenia, to pamiętajcie, że może ona ewoluować i rozmowa dotycząca usprawnień będzie na pewno dobrze widziana.

Jesteś ciekawi jak w Twoim zespole lub firmie podchodzicie do Definicji Ukończenia. Chętnie poznamy Wasze dobre praktyki lub problemy, z jakimi się zmagacie. 

Dołącz do dyskusji o tym odcinku na naszych social mediach

Materiały dodatkowe

Chcesz przeczytać transkrypcję naszej rozmowy w tym odcinku podcastu? Czytaj poniżej!

Kuba: Ten odcinek będzie o Definicji Ukończenia, jednym ze zobowiązań scrumowych powiązanych z przyrostem produktu. 

Jacek: Opowiemy dzisiaj, czym jest Definicja Ukończenia. Zdefiniujemy ją. Opowiemy, dlaczego jest to ważne zobowiązanie. W Scrumie. Podamy przykłady elementów składowych Definicji Ukończenia i podzielimy się praktycznymi wskazówkami jak zastosować Definicję Ukończenia w realnym życiu.

Kuba: No i zaczynamy od definicji Definicji. Zdajemy sobie sprawę, że ten początek będzie dosyć formalny i taki teoretyczny, czysty scrumowo. No ale, jest to akurat taki odcinek, że my od tego musimy, czujemy, że musimy zacząć. Definicja Ukończenia zgodnie z Przewodnikiem po Scrumie, to formalny opis stanu przyrostu, w którym spełnia on kryteria jakościowe wymagane dla produktu.

Jacek: Konkretny przyrost powstaje, kiedy element Backlogu Produktu osiąga zgodność z Definicją Ukończenia.

Kuba: Zgodnie z tym, co Przewodnik po Scrumie mówi, ta Definicja Ukończenia tworzy przejrzystość. Powoduje, że wszyscy tak samo rozumieją, jaką pracę trzeba wykonać, żeby osiągnąć właśnie przyrost, który jest ukończony. No i pamiętajmy o tym bardzo ważnym zastrzeżeniu wprowadzonym w najnowszej aktualizacji Przewodnika po Scrumie, że jeśli dany element Backlogu Produktu nie osiągnął tego stanu zgodnego z Definicją Ukończenia, nie może zostać nawet pokazany podczas przeglądu Sprintu.

Jacek: Odpowiedzialność za zdefiniowanie Definicji Ukończenia spoczywa na Zespole Scrumowym. Na to też warto zwrócić uwagę, że mówimy tutaj o odpowiedzialnościach Product Owera, deweloperów i myślimy też o Scrum Masterze. Jeżeli jest więcej zespołów, które używają Definicji Ukończenia, no to należy się umówić na jakiś określony standard. I w takiej sytuacji żaden zespół nie może dostarczać swojej części produktu w niższym standardzie. Może za to dostarczać go w wyższym. I może być tak, że organizacja formułuje pewne ograniczenia, czy oczekiwania, czy standardy dla zespołów. I w tym przypadku Zespoły Scrumowe powinny przyjąć te oczekiwania jako część swojego Definition of Done.

Kuba: No i to, co powiedzieliśmy to swoimi słowami dosyć wierna adaptacja tego, co jest częścią definicji Scruma. Natomiast chcemy trochę więcej poszerzyć wątek istotności tego narzędzia, bo z takiej suchej definicji może to niewystarczająco wybrzmiewać. Ale to dlaczego jest to ważne, chcemy opowiedzieć na paru analogiach, które tutaj mapują się z takim życiem, bym powiedział codziennym. No tę i analogię czujemy, że mogą być wartościowe. Pierwsza rzecz, która mi przychodzi do głowy, jest powiązana z hobby. Akurat hobby mam wiele, ale przychodzi mi tu przede wszystkim do głowy temat mojego ogrodu, a konkretnie mojego trawnika. Gdy pracuję w tym ogrodzie, gdy koszę tę trawę, oprócz wykonania samego faktycznego wykoszenia, w sensie trawa jest krótsza. Muszę też w ramach tego danego procesu, danej sesji wykaszania, zrobić też po sobie porządek. Czyli kosiarka nie może zostać na środku trawnika, albo trawa jeszcze w ogóle gdzieś tam się wysypująca, resztki niepodkoszone. Kabel z prądem, bo mam elektryczną kosiarkę, nie może zostać gdzieś niezwinięty, albo zwinięty byle jak, czy zwinięty i rzucony gdzieś w korytarz. Mam tutaj jednak pewne konkretne zasady, które mi pomagają do kolejnych razów, że ten kabel jest dobrze zwinięty, niepoplątany, zwinięty. Czy poukładany jest cały zestaw do koszenia? Kosiarka, wykaszarka i wszystkie te składowe. Jeśli bym tego nie robił z jakichś powodów to będzie to nieestetyczne. W najczarniejszym scenariuszu ten trawnik nie będzie się nadawał do użycia, bo będzie zawalony tymi wszystkimi składowymi do koszenia. I kolejne przypadki, gdy będę kolejny raz chciał kosić, to będę szukał ,gdzie ja zostawiłem tym razem przewód. Dlaczego kosiarka jest gdzieś schowana w innym miejscu niż zwykle?

Jacek: Tak Kuba opowiedział. Ja wierzę, że nie masz tych problemów. W sensie, że to jest zrobione porządnie. Ja mam trochę taką szarą strefę w swoim garażu, który pełni też rolę warsztatu samochodowego jako hobby. U mnie to jest tak, że część rzeczy mam poukładanych. Czyli wiem, że jakieś tam klucze nasadowe mam w jakiś określonych pojemnikach. Wiem gdzie mam wkrętarkę. Wiem gdzie mam jakieś konkretne narzędzia, ale zdarza mi się kiedy kończę pracę, jest na przykład późno, chcę jechać na przejażdżkę testową, że jakieś tam, no narzędzia najczęściej, odkładam tak po prostu gdzieś na bok, żeby było mi wygodnie. Ten moment odkładania to jest ten moment, kiedy wiem, że właśnie będę miał z tego powodu problemy. No bo tak naprawdę częścią naprawy powinno być posprzątanie, odłożenie, czyli po prostu zapewnienie, że następnym razem, jak podejdę do pracy, no to też po prostu nie będzie niespodzianek i naprawa po prostu nie będzie trwała dłużej.

Kuba: I te dwie analogie bardziej poruszają wątek takiego warsztatu pracy, porządku, doprowadzenia pewnych czynności do dodatkowego końca. Częścią koszenia nie jest samo koszenie, ale też dodatkowych kilka kroków. Tak samo częścią naprawy nie jest tylko fakt, że silnik z powrotem odpalił, ale też być może posprawdzanie pewnych elementów i podkładanie tak jak należy. Ale mam jeszcze jedną analogię. Analogię, którą pamiętam z zupełnego początku mojej drogi zwinnej, gdzie mój ówczesny mentor odpowiedział mi na pytanie moje takie ciekawskie, wczesne, bardzo bardzo nieświadome. Gdy zobaczyłem, że mój pierwszy zespół deweloperski, z którym współpracowałem, automatyzował testy i zajmowało im to sporo czasu. Do tej pory w mojej karierze się z tym nie spotkałem, żeby ktoś wykonywał testy integracyjne, właśnie automatyczne. No i chciałem zrozumieć, o co chodzi, bo widzę, że zajmuje to czas. W sumie nie widzę do końca wartości dodanej. Nie rozumiem jej. No i właśnie wtedy ten mój mentor mi opowiedział taką metaforę, która moim zdaniem oddaje nie tylko sens automatyzacji, ale w ogóle sens robienia ukończonych, kolejnych kroków. On mówi coś takiego. „Wyobraź sobie, że podbijamy jakiś nowy teren, jesteśmy zdobywcami i wykonujemy konkretne kolejne kroki. Osiągamy pewną granicę terenu i my ten teren, który zdobywamy, umacniamy. Tworzymy zabudowania, tworzymy jakiś bastion, tworzymy mury i te mury już są nienaruszalne. Osiągamy ten stan i mamy gwarancję, że już ten etap osiągnęliśmy i w kolejnym kroku możemy znowu podbić kawałek terenu i znowu go umocnić”. I to był argument za automatyzacją działań, automatyczną regresją. Dla mnie to też jest metafora ukończonych, kolejnych, kompletnych kroków. Jeśli działamy zgodnie z Definicją Ukończenia, to każdy kolejny krok jest właśnie w tym sensie umocniony. Nie musimy się cofać, nie musimy się martwić, nie musimy się zastanawiać, czy za nami nie zostało coś niedokończonego. Tylko w pełnym kompletnym sensie. Każdy krok, każdy kolejny kawałek produktu, jest już kompletny, skończony, w tym samym jednoznacznym, nienaruszonym standardzie. I wychodząc z tych opowieści, przykładów, metafor, analogii, chcemy bardzo konkretnie wymienić kilka przykładów tego, co może wchodzić w skład Definicji Ukończenia w konkretnym Zespole Scrumowym. Pierwsza rzecz, która przychodzi automatycznie na myśl, to to, że produkt jest skończony, przyrost jest skończony, czy konkretny item Backlog Produktu jest skończony wtedy, gdy spełnione są kryteria akceptacji, które zostały sformułowane dla tego elementu.

Jacek: Warto tutaj zwrócić uwagę na taki detal, który bardzo często wyłapuję w trakcie rozmów z zespołami, które wspieram. Kryteria akceptacji, o których Kuba mówi, to jest unikatowa umowa, po czym poznamy, że konkretny element z Backlogu Produktu został zrealizowany zgodnie z oczekiwaniami. Natomiast oczekiwanie, że kryteria akceptacji będą spełnione, jako część Definicji Ukończenia oznacza, że każdy element, który ma przejść przez Definicję Ukończenia z pozytywnym skutkiem, po prostu musi mieć wcześniej zapewnione to, że kryteria akceptacji ktoś sprawdził, ktoś na nie spojrzał no i jakby świeci się na zielono. Potwierdzamy, że dokładnie tego oczekiwaliśmy od tego konkretnego elementu.

Jacek: Kolejną rzeczą, którą bardzo często można spotkać w Definicji Ukończenia, to takie oczekiwanie, że praca, którą wykonujemy zostanie przetestowana przez inną osobę, niż ta która, tę pracę implementowała. Brzmi to może tak bardzo formalnie, że to musi zrobić ktoś inny. Natomiast wynika to z tego, że jakość w zespołach bywa różna. Są zespoły, w których po prostu nie ma jakiejś sensownej umowy na to, co to znaczy, że coś jest przetestowane, bądź nie jest przetestowane. No, więc kiedy dopytuję, co to znaczy, że są zrobione testy, no to po prostu deweloper, który implementował, spojrzał, upewnił się. No i działało. Stąd warto zwrócić uwagę, żeby jednak jakość była zapewniana przez inną osobę, niż ta, która implementowała. Zwykle pomaga to w wychwyceniu błędów, które dla osoby, która tworzy, po prostu są niewidoczne, albo z jakichś powodów w procesie testowania pomija pewne ścieżki.

Jacek: Kolejną rzeczą, którą bardzo często można spotkać w Definicji Ukończenia, to takie oczekiwanie, że praca, którą wykonujemy, zostanie przetestowana przez inną osobę, niż ta która, tę pracę implementowała. Brzmi to może tak bardzo formalnie, że to musi zrobić ktoś inny. Natomiast wynika to z tego, że jakość w zespołach bywa różna. Są zespoły, w których po prostu nie ma jakiejś sensownej umowy na to, co to znaczy, że coś jest przetestowane, bądź nie jest przetestowane. No, więc kiedy dopytuję, co to znaczy, że są zrobione testy, no to po prostu deweloper, który implementował, spojrzał, upewnił się. No i działało. Stąd warto zwrócić uwagę, żeby jednak jakość była zapewniana przez inną osobę, niż ta, która implementowała. Zwykle pomaga to w wychwyceniu błędów, które dla osoby, która tworzy, po prostu są niewidoczne, albo z jakichś powodów w procesie testowania pomija pewne ścieżki.

Kuba: Trzecim kandydatem na punkt do Definicji Ukończenia, jest dotrzymanie standardów kodowania. I te standardy kodowania, to jest dobry przykład na coś, co być może zapewnia, czy troszkę oczekuje, wymaga organizacja. Może ta część organizacji, ta konkretna technologia, w której działamy. Więc jest to jakieś powtórzenie pewnego minimalnego standardu, którego oczekuje się od każdego zespołu programistycznego w danej firmie. Ale może się okazać, że my sami jako zespół Scrum Scrumowy, też sobie jakiś standard dodatkowo podnosimy, jakieś podpowiedzi co robimy lub czego nie robimy, czego używamy, a czego unikamy. I to może mieć duże znaczenie, zwłaszcza w kontekście kolejnego popularnego elementu.

Jacek: Takim kolejnym przykładowym popularnym elementem jest code review, czyli obowiązkowy przegląd kodu, który mamy wmontowany w nasz proces deweloperski. Oznacza to, że jeżeli ja tworzę kawałek kodu, no to jest jakaś inna osoba w zespole, inny deweloper, który na ten kawałek kodu spojrzy, oceni, skomentuje, da informację zwrotną. Jest to taka bramka jakościowa na bardzo wczesnym etapie, która zapewnia, że od tej strony takiej technicznej to działa tak, jak powinno. To jest napisane w taki sposób, w jaki się umówiliśmy, że będziemy pisać kod. Pewne wzorce postępowania, na które się umówiliśmy, są spełnione.

Jacek: Kolejny punkt, już nie taki oczywisty i nie tak często widuję, a moim zdaniem powinien być również uwzględniony w Definicji Ukończenia, czy może być, to jakaś wspólna zgoda całego zespołu, na jakie środowisko wprowadzamy zmiany. Niektóre zespoły, które mają to niedogadane, niestety robią to właśnie w sposób taki różnorodny. Niektórzy pokazują kawałek rozwiązania na swoim środowisku deweloperskim, inni na jakimś testowym, na jakimś integracyjnym. I może się okazać, że akurat to, do jakiego środowiska dociągamy nasze rozwiązanie, mówiąc potocznie, może robić wielką różnicę. Dodatkowe czynności związane z integracją, dodatkowe czynności związane z przygotowaniem jakichś narzędzi, skryptów. Z jednej strony, to może być niejednorodność ilości pracy do wykonania, a z drugiej strony, to może być też po prostu trochę niedotrzymane czy niedopilnowany standard jakościowy. Być może pewne uproszczenia, które są na jakichś wcześniejszych środowiskach, powodują, że pewne rozwiązania działa. Ale potem robimy wdrożenie i niespodzianka, bo jednak nie działa to tak idealnie, jak sobie zakładaliśmy.

Jacek: Kolejnym takim mniej oczywistym punktem, który warto rozważyć w Definicji Ukończenia, to jest umowa na to, że praca jest zakończona w momencie, kiedy zaktualizowaliśmy także status tej pracy w jakimś konkretnym narzędziu. Czy to będzie Jira, Trello, ma to mniejsze znaczenie. Natomiast pozwala taki punkt zapewnić, że w momencie kiedy przechodzimy do planowania kolejnego Sprintu, no to nie musimy przechodzić żmudnie przez cały Backlog upewniając się, czy ten kawałek pracy jest wykonany, czy ten status jest odpowiedni, czy to prawda, że to zadanie jest zblokowane i tak dalej. Czyli taka też właśnie higiena pracy, na zasadzie, jeżeli coś się zmienia w mojej pracy, w sensie mamy jakieś flow, no to po prostu ja jak kończę in progres i oczekuję, że teraz ktoś zrobi code review, no to zmieniam status na zasadzie czeka na code review. Przykładowo oczywiście. W momencie, kiedy kończę pracę, dochodzimy do jakiegoś stanu zrobione, czy do stanu done, no to, jeżeli tak faktycznie jest, no to narzędzie pracy, z którego korzystamy, powinno zaraz, jak ten stan faktycznie się objawi, być zaktualizowane.

Jacek: Kolejnym przykładem na to co można umieścić w Definicji Ukończenia, to zapis, który zapewni nam, że te elementy, które nie są częścią taką czysto deweloperską, również zostaną odpowiednio zaktualizowane. Czyli może to oznaczać na przykład, że jakaś instrukcja dla użytkownika, z której użytkownik korzysta, zostanie zaktualizowana o najnowsze zmiany. Czyli przykładowo, jak używam zegarka sportowego, następuje aktualizacja firmware’u, pojawia się jakaś nowa opcja, na przykład do zegarka dostajemy test biegowy, która pozwala nam sprawdzić, w jakiej kondycji aktualnie się znajdujemy. No to dobrze by było, że w momencie kiedy ja mam to już na zegarku, mogę tego używać, żeby adekwatna porcja informacji na temat tego, jak tej konkretnej funkcji używać, żeby się znalazła po prostu w instrukcji dla użytkownika. Niby prosta rzecz, ale doświadczenie mi pokazuje, że często zespoły zapominają o tym, że świat nie kończy się tylko na tej części deweloperskiej. Tylko jednak są jeszcze jakieś dodatkowe punkty i obszary, które po prostu warto zaopiekować.

Kuba: I drugi przykład, bardziej z mojego doświadczenia dosyć świeżego, to to, że takim niedeweloperskim fragmentem Definicji Ukończenia może być też aktualizacja otoczki marketingowej dla naszego produktu. Może to są jakieś reklamy, może to są jakieś materiały promocyjne, jakieś banery. Wszystko to może być powiązane z ficzerami, z rozwiązaniami, czy z jakimiś procesami, decyzjami biznesowymi, które zmieniliśmy w danym przyroście. One również muszą być zaktualizowane, te tematy marketingowe, żeby to łącznie cały produkt był ukończony, a nie tylko software, który przygotowaliśmy, jest ukończony, ale cała reszta jest absolutnie niegotowa i niestety, na przykład nie może być to wypuszczone na rynek. I podkreślę jeszcze raz coś, co powiedziałem na samym początku, to, co wymieniliśmy, to są przykłady. Po pierwsze, nie każdy zespół musi mieć wszystkie te elementy, które wymieniliśmy. Mało tego, pewnie są jeszcze dziesiątki elementów, które w różnych zespołach z jakiegoś powodu znajdą się w takiej Definicji Ukończenia. Więc traktuj drogi słuchaczu lub słuchaczko to, co przed chwilą powiedzieliśmy, jako raczej takie przykłady z bardzo różnych perspektyw, czy z różnych dziedzin, które najczęściej widujemy, ale to nie jest na pewno lista kompletna, czy wyczerpująca.

Kuba: I przechodząc do ostatniej części odcinka. Chcielibyśmy też wymienić kilka wskazówek i obserwacji, na bazie naszej praktyki związanej z Definicją Ukończenia.

Jacek: Warto na początku pracy z Definicją Ukończenia być realistą. Na takiej zasadzie, żeby przygotowując pierwszą wersję Definicji Ukończenia, w szczególności, jeśli pierwszy raz korzystamy z Definicji Ukończenia w swoim zespole, ustawić sobie poprzeczkę na takim realnym poziomie. To, co często obserwuję to to, że zespoły bardzo szybko wpadają w taki tryb, w którym wymyślają sobie bardzo wysublimowaną i taką ambitną wersje Definicji Ukończenia, która nie odzwierciedla tego stanu aktualnego. Stąd bardzo szybko przestają przestrzegać Definicji Ukończenia, no bo po prostu ona jest nierealna. Więc osobiście jestem fanem tego, żeby na początku sobie odzwierciedlić rzeczywistość, co ona dzisiaj robimy i zastanowić się nad jakimś jednym prostym usprawnieniem, jakimś drobnym podniesieniem poprzeczki, które sobie dopisujemy no i sprawdzamy. Tak naprawdę eksperymentujemy, czy my w ogóle jesteśmy w stanie w taki sposób pracować. Tak więc na pewno warto zacząć od tego, żeby ta poprzeczka była po prostu na osiągalnym poziomie.

Kuba: I ta realność, albo osiągalność tej poprzeczki, może wynikać z wielu rzeczy. Bo to może być kwestia tego, że nie umiemy, na przykład dobrze zrobić code review, nie umiemy pracować w parze, nie umiemy zautomatyzować testów. To może być też tak, że my nie mamy narzędzi do tego, nie mamy dostępu do odpowiednich środowisk, licencji, nie korzystaliśmy do tej pory z jakichś narzędzi. No i wtedy to jest takie trochę wzajemne frustrowanie się. Fajnie byłoby mieć super fajny standard, taki, że można się na konferencji programistycznej pochwalić. No, tylko jest on poza naszym zasięgiem. W żadnym z pierwszych kilku Sprintów nie jesteśmy w stanie nic skończyć. To może być frustrujące. To może być też nawet troszkę niebezpieczne dla koncepcji wykorzystania, w ogóle podejścia zwinnego czy konkretnie Scruma. Bo ktoś z boku patrzący na ten zespół może powiedzieć – No, ej, ale do tej pory mieliście postępy, a teraz nagle przestaliście mieć postępy. I to nie jest prawda, że nie ma postępów, tylko w takim bardzo surowym zdyscyplinowanym Scrumie, są one jednak przez chwilę, być może wolniejsze.

Kuba: Druga wskazówka, którą mamy to sugestia o tym, że egzekwowanie wykonania DoD, czyli skrót od Definition of Done, to może być trudność dla typowego zespołu. Ta dyscyplina, to jest coś, co może być po prostu nieobecne w tym zespole. Definition of Done jest jednym z tych przykładów takiego bardzo 0:1 nowego podejścia. Scrum tutaj w paru miejscach jest bardzo surowy. No i są zespoły, które po prostu na dzisiaj w swojej kulturze, w kulturze funkcjonowania danego zespołu, takiej dyscypliny nie mają. Może to jest taka trochę swoboda, może trochę takie kawaleryjskie podejście, że będzie co będzie, zobaczymy. No i niestety, ale DoD w takim środowisku, w takiej kulturze pracy, nie może zafunkcjonować lub bardzo łatwo przestać je stosować.

Jacek: Częsty przypadek jest taki, że ta Definicja Ukończona, gdzieś jest zapisana, spisana. Kiedy dopytuję gdzie, to jakieś tam się Confluence, czy inne narzędzie ujawnia. Natomiast długość poszukiwania, gdzie tak dokładnie Definicja Ukończenia leży tam w strukturze, wskazuje na to, że najprawdopodobniej od dawien dawna nikt tam nie zaglądał. No a warto pamiętać, że często Definicja Ukończenia ma tych punktów trochę, często kilkanaście. Więc też nie łudziłbym się, że w głowie każdej osoby w zespole, dokładnie te punkty są odzwierciedlone. Chociażby z tego powodu, że dochodzą do zespołu osoby, inne odchodzą. No i może się okazać, że za pół roku gdyby zrobić test, co tak naprawdę mamy w Definicji Ukończenia, no to dostaniemy takie prawie dobre odpowiedzi. No, a częścią używania Definicji Ukończenia jest to, że to są dokładnie te punkty i chcemy je spełnić. No i tutaj ta przestrzeń na szarość, co do zasady nie powinna występować.

Jacek: Kolejna myśl, którą chcemy się podzielić dotyczy tego, że można sobie ułatwić narzędziowo korzystanie z Definicji Ukończenia. Na takiej zasadzie, że wszelkiego rodzaju przypominajki, albo świadome kroki w procesie mogą nas nakierować na to, że powinniśmy o tym pamiętać. Do dzisiaj pamiętam, jak pracowałem z jednym z zespołów, który poradził sobie z problemem zapominania o Definicji Ukończenia na takiej zasadzie, że właściwie do każdego elementu Backlogu Produktu dokładali sobie check-listę, którą odznaczyli sobie check-box’ami, jak tylko w procesie to ta konkretna praca, te check- box’y mogły zapalać na zielono. Czyli, jeśli już byliśmy, mieliśmy na przykład zrobione code review, no to tam się już świeciło na zielono. Jeśli były zrobione testy, to również, i na przykład jeszcze nie mieliśmy pewności, czy są spełnione kryteria akceptacji. No więc tam po prostu jeszcze był czerwony X. Więc było to utrzymywane na zasadzie opisu, części opisu konkretnego elementu Backlogu Produktu, który był do wykonania, który zespół sobie edytował. Więc właściwie rzut oka na opis, od razu wskazywał na to, nawet tak wizualnie kolorystycznie, że jeszcze coś z perspektywy Definicji Ukończenia jest do zrealizowania.

Kuba: Praktyka, którą też czasami spotykam w niektórych zespołach, zwłaszcza takich, które dopiero zaczynają w tak zdyscyplinowany sposób stosować DoD, to jest jakiś dodatkowy krok blisko końca procesu wytwórczego. Jeszcze dodatkowo ktoś z nas wszystkich sprawdza, czy wszystkie punkty z Definicji Ukończenia są wypełnione, żebyśmy tego nie gubili, żebyśmy budowali sobie pewien nawyk, żebyśmy się upewniali, że ten metaforyczny bastion, o którym wspominałem, faktycznie ma szczelne ściany. I tu akurat też nie zapomnieliśmy o zmianie w dokumentacji, albo o automatyzacji testów. No i taka praktyka, którą też widuję w zespołach, chociaż ona jest bardziej adekwatna dla zespołów kolokowanych, no to po prostu jakiś rodzaj plakatu, jakieś przypomnienie, jakaś kartka z flip-chart’a, na której są wypisane wszystkie punkty, których zgodziliśmy się na ostatniej Retrospektywie, że będziemy przestrzegać wszystkie punkty z najświeższe aktualnej wersji Definicji Ukończenia.

Kuba: Przedostatnia myśl w temacie takiego praktycznego stosowania Definicji Ukończenia. To taka sugestia, że czasem trzeba rozważyć wymuszanie pewnych kroków spełnienia Definicji Ukończenia poprzez wymuszenia na przykład w narzędziu. Myślę tu o takich rzeczach, które są krytyczne z perspektywy organizacji czy biznesu. Na przykład w niektórych branżach, super krytyczny jest temat bezpieczeństwa, bezpieczeństwa informacji. Większość organizacji też bardzo poważnie podchodzi do jakości związanej ze wdrożeniami, i może się okazać, że ma sens. Nie jest to może najprzyjemniejsze. Nie jest może najbardziej frywolne, ale mimo wszystko ma sens takie ustawienie procesu wytwórczego. Takie ustawienie narzędzi, żeby pewne kroki były obowiązkowe, nie można ich przeskoczyć, nie można ich pominąć, co może być pewnym rodzajem przypominajki, albo pewnym rodzajem zabezpieczenia, że tutaj nikt z rozpędu, przypadkiem, albo nawet bardzo świadomie nie pominie jakiegoś kroku, który jest po prostu wymagany i obowiązkowy.

Jacek: I ostatnia myśl, którą chcemy się podzielić, to myśl taka, że Definicja Ukończenia bywa narzucana przez organizacje. Najczęściej wynika to z tego, że organizacja, management, chce mieć pewność, że produkt, który jest produkowany często też w różnych zespołach, no po prostu spełnia jakieś takie wspólne normy oczekiwania, jeśli chodzi o kompletność, czy o jakość. I tutaj nasza rekomendacja jest taka, żeby przesadnie z tym nie dyskutować. W sensie widzę czasem zespoły, które kwestionują. A po co? Dlaczego? Pewne rzeczy są oczekiwane. Być może w takich sytuacjach warto zapewnić na poziomie komunikacji szerszy kontekst. Dlaczego to robimy? Z czego to wynika? W ciemno strzelam, że jakieś wcześniejsze, czy przeszłe problemy związane z jakością, no po prostu są takim bodźcem, który popycha organizację do tego, żeby jednak się na pewien konkretny poziom jakościowy umówić. No i poniżej tego poziomu po prostu nie schodzić.

Kuba: To, że sugerujemy brak dyskusji z takimi punktami DoD, narzucanymi przez organizacje, oczywiście nie oznacza, że w dłuższym horyzoncie czasowym nie warto inspirować firmy do tego, żeby na przykład te pewne niedoskonałości takiej definicji wspólnej dla wszystkich poprawiać, może podnosić poprzeczkę. To też mogą być oddolne nurty, wynikające z danego zespołu, z danej Retrospektywy. Może Retrospektywy międzyzespołowej, może jakichś doświadczeń z konkretnego wdrożenia, konkretnego jakiegoś etapu. Więc to jest taka myśl, że zarówno na poziomie zespołowym, jak i też organizacyjnym takie DoD może ewoluować. Natomiast mimo wszystko tu i teraz, gdzie jesteśmy zazwyczaj, jeśli organizacja oczekuje, że na przykład robimy testy, albo korzystamy z konkretnego narzędzia, trzymamy się konkretnego standardu kodowania, konkretnych technologii, to prawdopodobnie tutaj marnowanie emocji i energii na to, żeby z tym dyskutować, wiele nie wniesie. Co najwyżej skupmy się na tym, co to dla nas dokładnie oznacza. Czy jesteśmy gotowi na to, żeby to wypełniać.

Kuba: Zbliżając się powoli do końca. Jeszcze jedna dodatkowa myśl. Obserwujemy, że niektóre firmy od czasu do czasu organizują wewnętrzne spotkania swojej zwinnej społeczności. Dołączamy do takich wydarzeń i prowadzimy na nich inspiracyjne prezentacje oraz praktyczne warsztaty.

Jacek: Jeżeli chcesz, żebyśmy również u Ciebie stali się częścią takiego wydarzenia, skontaktuj się z nami poprzez formularz na stronie porzadnyagile.pl/kontakt

Kuba: Notatki do tego odcinka, artykuł, transkrypcję oraz wideo z naszej rozmowy, znajdziesz na stronie porzadnyagile.pl/88.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek. Do usłyszenia wkrótce.

Daj nam znać co sądzisz o tym odcinku


Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

Newsletter „Porządny Agile”

.

Jesteśmy też tutaj

Podcast od kuchni. Tak nagrywamy dla Ciebie!

Jacek Wieczorek i Kuba Szczepanik
scenariusz do nagrania podcastu
Jacek Wieczorek Kuba Szczepanik podcast

Opinie naszych słuchaczy.

„To jest to! Ekstremalnie dobra dawka potrzebnej wiedzy. Część podcastów otwiera oczy, część porządkuje wiedzę. Polecam!”

„Mimo iż nie jestem bardzo związany z agilem/scrumem, jakieś doświadczenia z nim miałem („retrożale” ;), to bardzo przyjemnie się Panów słucha. Duża i bardzo konkretna dawka wiedzy, bez przynudzania, widać „napracowanie” przy każdym odcinku, jakość ścieżki audio na poziomie, całość w odbiorze sprawia profesjonalne wrażenie. Życzę obu prowadzącym sił do kontunuowania tego (nie)małego dzieła. :)”.

„Takich podcastów nam potrzeba!”

Oceń podcast. Kliknij poniżej.

Apple Podcast logo
logo stitcher
Wordpress Social Share Plugin powered by Ultimatelysocial