Scrum jest frameworkiem opartym o manifest Agile służącym szybszemu dostarczania wartości biznesowej klientowi. Powiem tak, widziałem wiele z fotela programisty. Sam wdrażałem trzy razy zasady scrum-a do małych kilkuosobowych projektów, byłem w kilku firmach gdzie on był wdrożony w dużej skali. Czasem to działało fajnie, a innym razem wychodziły potworki z połączenia waterfalla ze scrumem. Mam kilka przemyśleń o patoscrumie, czyli niezrozumieniu czym on jest i jakie ma cele.
Przeliczanie story pointów na czas
Jak zapewne wiecie w scrumie używa się tzw. story pointów do szacowania złożoności zadań. Jest to liczba z ciągu fibonnacciego np. 1,3,5,7 itd. Zespół oszacowuje złożoność i na tej podstawie powinno się decydować czy np. dane zadanie powinno być podzielone na mniejsze i czy zespół powinien się nim zajmować w aktualnym sprincie.
Niektórzy klienci traktują storypointy jako wyrocznie i sobie przeliczają np. 3 storypointy to 2 dni robocze. Zespół robi 21 punktów w ciągu sprintów. Do dowiezienia epika trzeba 120, więc w 6 sprintów epik będzie gotowy na produkcji. Nie do końca tak to działa.
Jeśli zespół składa się z robotów, żadne nieprzewidziane sytuacje nie są planowane, dokładnie wiadomo co i kiedy trzeba zrobić, to jeszcze ma szansę to działać. W praktyce wygląda to zupełnie inaczej. Bóg słysząc o jakichkolwiek planach daje nam pstryczka w nos i cały misterny plan w ….. 😉
We know from chaos theory that even if you had a perfect model of the world, you’d need infinite precision in order to predict future events. With sociopolitical or economic phenomena, we don’t have anything like that. Nassim Nicholas Taleb, autor m.in "Czarnego Łabędź", "Antykruchość"
A co jeśli zmieni się skład zespołu. Na przykład, dochodzi nowa osoba, więc trzeba ją wprowadzić. Zajmuje to czas i uwagę doświadczonych developerów, więc ich produktywność spada, a to wpływa na wyniki zespołu. Najbardziej doświadczony developer idzie na urlop, co wpływa bardzo negatywnie na produktywność, szczególnie w złożonych projektach, gdzie nie ma tradycji prowadzenia dokumentacji i testów.
Słyszałem historię, o jednym kliencie, który chciał wynegocjować pakiet storypointów np. 100 pkt- 10k złotych zamiast płacić standardowo za godziny, czy projekt/moduł. Rodzi to ciekawe patologie jak np. sztuczne rozdmuchiwanie estymat, problemy z rozliczaniem teamu za faktyczną pracą. Co w przypadku jak funkcjonalności zawierają błędy, jak je rozliczać?
Czy to oznacza, że nie warto tego robić?
Jestem zwolennikiem estymowania, bo to wprowadza moment do dyskusji o zadaniach i czekających zespół wyzwaniach. Wszyscy są świadomi, szczególnie product owner potencjalnych zagrożeń dla celu sprintu. Nie brałbym estymacji 100% poważnie, ze względu na to co może się wydarzyć w trakcie sprintu. Na pewno bym nie używał punktów do ustalania budżetu projektu.
No estimate
Obecnie coraz popularniejszy staje się podejście "#NoEstimates" polegające, aby w ogóle nie estymować zadań. Polecam ciekawy artykuł na BullDog Jobs o tej strategii Ruch #NoEstimates, czyli koniec estymat
Sam autor scruma wypowiedział się krytycznie o estymowaniu za pomocą storypointów.
Klient jest Product Ownerem
Według definicji scruma – product owner reprezentuje klienta, powinna to być osoba od strony wykonawcy, która ma bezpośredni kontakt z klientem. W niektórych aplikacjach scruma, właścicielem produktu jest mianowana osoba od strony zleceniodawcy. Największym plusem jest to, że skracamy ścieżkę decyzyjną i przyśpieszamy proces wytwórczy. Zespół developerski otrzymuje osobę, która jest zazwyczaj najbardziej kompetentna. Wybór osoby od klienta jako PO ma kilka strategicznych wad.
Załóżmy że klient przynosi dużo pieniędzy firmie. Może się wycofać z projektu i przejść z nim do konkurencji. Powoduje to konflikt interesu i potrzebę uprawiania polityki. Klient nie może się dowiedzieć o wszystkim co się dzieje, szczególnie o trudnych sprawach, bo źle to wpływa na PR firmy tworzącej oprogramowanie. Szczególnie kłopotliwe jest, jeśli zespół przechodzi trudne momenty, a product owner jest na każdym spotkaniu, szczególnie na daily. Według podręcznika scruma, PO nie powinno na nim być.
Jeśli PO nie zna scruma, to na scrum masterze spoczywa dodatkowa odpowiedzialność – nauczenie zasad pracy zwinnej, co nie zawsze jest proste i przyjemne.
Scrumowodospad
Scrum i waterfall wydają się być jak bracia z różnych matek i ojców. W teorii można stosować scruma w waterfallu, ale jest to trudniejsze niż samo prowadzenie projektu czysto agilowego, bo mieszamy różne sposoby i zasady pracy.
Widziałem projekt, który był prowadzony w formie scrumowodospadu. Miał być jako scrum, ale powstała dziwna mieszanka, bo prawdopodobnie menadżerowie z wyższej półki od klienta dotąd głównie pracowali w wodospadach.
Zespół dostawał z góry zaplanowany zestaw gotowych zadań z wybranych epików na dany sprint. Zadania zazwyczaj nie miały kryteriów akceptacji. Nikt w zespole nie wiedział, dlaczego to robimy, jaki jest "wyższy cel". Programiści po prostu klepali kodzik.
Oprogramowanie stale się zmienia. Każda zmiana może wymuszać wiele innych zmian, a to wpływa na jakość doświadczenia z danego produktu. Niemal niemożliwe jest przewidzenie każdego problemu z góry.
Dla nas developerów jest bardzo ważne, abyśmy mieli wpływ na backlog i mogli brać udział w planowaniu sprintu. Daje to więcej satysfakcji, pozwala na wcześniejsze przygotowanie się i zmniejsza napięcie w zespole. Nie mówiąc o tym, że daje dużo większą szansę na dowiezienie sprintu do końca.
Definition of Done jest nie zdefiniowane
Według definicji definition of done, czyli "definicja ukończenia" określa, co oznacza, że coś jest ukończone. Każdy w zespole powinien rozumieć, co oznacza, kiedy zespół developerski mówi, że skończył pracę nad funkcjonalnością, którą wziął do sprintu. Każdy powinien też zrozumieć co zostało wykonane i co może być jeszcze potrzebne, aby wdrożyć dane rozwiązanie na produkcję.
Zdefiniowanie definicji ukończenia należy do obowiązków zespołu.
Praktycznie nie widziałem dobrej definicji w projektach, co nieraz budziło dyskusje, czy coś faktycznie jest gotowe. Dla niektórych to zamknięcie zadania przez developera było oznaczeniem jako "ukończone", a dla innych akceptacja przez QA czy dopiero moment sprawdzenia wdrożonej funkcjonalności na produkcji.
źródło: Definition of Done – po co i jak stworzyć? | QAgile – Jakość w Agile
Brak kryteriów akceptacji czy definiowanie ich podczas trwania sprintu
Kryteria akceptacji (acceptance criteria) to lista konkretnych warunków i wymagań stanowiących podstawę do określenia historyjki jako kompletnej z biznesowego punktu widzenia.
Klasyk w patoscrumach. Zadania nie są dobrze zdefiniowane, nie wiadomo jak dokładnie coś ma działać, brakuje dokumentacji, przykładów. Developerzy estymują takie zadania na podstawie tytułu ticketa, ew. kilku słów od analityka czy product owner. A w trakcie pracy developer musi zdefiniować kryteria akceptacji. W trakcji pracy okazuje się, że nie da się wykonać zadania, bo brakuje elementów układanki, są zależności których się nie przewidziało.
Powoduje to masę opóźnień w projektach, przepalanie energii developerów na tworzenie zbędnych lub źle działających funkcjonalności.
Wyciskanie sprintu na maksa – brak przestrzeni na nieprzewidziane
Kierownictwo myśli sobie – "nasz zespół developerski przez ostatnie sprinty robi średnio 20pkt. Więc w tym sprincie też pewnie tyle zrobi. Przypiszmy im tyle, a może nawet więcej. Niech się wykażą i szybciej dowiozą nowe historyjki na którym zależy prezesowi." Może się to udawać, jeśli nie wydarzy się nic nieprzewidzianego, a estymacje biorą dokładnie pod uwagę, że trzeba np. przygotować infrastrukturę, napisać testy, dokumentacje, testować, developować itd. Na pewno coś wydarzy się nieprzewidzianego np. choroba dziecka jednego z członków zespołu, zepsuje się laptop, trzeba będzie szybko poprawić poważny i złożony błąd na produkcji.
Jeszcze raz powtórzę, punkty to nie estymacja czasowa 😉
Dobry zespół scrumowy powinien zawsze przeznaczać bufor bezpieczeństwa np. 20% czasu na nieprzewidziane obsuwy.
Słyszałem o ciekawej praktyce w jednym zespole. Co każdy sprint, jedna z osób zostawała "szeryfem". Jakie było jej zadanie? Miała obsługiwać wszystkie wykryte błędy, wspierać użytkowników produktu i support. Wtedy nie miała przyznawanych story pointów, a zespół mógł się skupić na dostarczaniu nowych funkcjonalności i nie był rozpraszany "wrzutkami"
Podsumowanie
Źle używane narzędzie może się łatwo obrócić przeciwko użytkownikowi. Podobnie jest z metodykami agile, szczególnie ze scrumem. Wierzę, że można dobrze prowadzić projekt, szczególnie jeśli słucha się potrzeb zespołu. Z jakiegoś powodu "retro" jest najbardziej znienawidzonym rodzajem spotkań. Dlaczego? Myślę, że wynika to z wyuczonej bezradności. Zespół nie wierzy, że coś się może zmienić. Otrzymuje on teksty w stylu "nie da się", "tak już tutaj jest" itd. Szczególnie wtedy jest łatwo o dalszy rozwój patalogii.
Artykuł został opublikowany w 3 numerze magazynu "Think IT Magazyn". Można go pobrać za darmo ze strony: https://bulldogjob.pl/for-employers/think-it-magazyn-hr
Niestety wszystkie z powyższych nader często widywane w życiu 🙁