fbpx

Krótka historia czym jest planning

planning

Krótka historia czym jest planning

Poziom zaawansowania:
1/5

Spotkań scrumowych jest kilka i każdy z nich ma swoją określoną charakterystykę. Trwa określoną ilość czasu, odbywa się regularnie i co najważniejsze jest po coś. Po co? Zależy od spotkania. Kiedy opowiadałam Ci o daily mówiłam o codziennym statusie postępu prac. Dzisiaj szczegółowo zgłębimy się w sens planowania i spotkania nazywanego sprint planning.

Czym jest planning?

Planning jest spotkaniem, na którym jak sama nazwa wskazuje będziemy coś planować. Co dokładnie? Pracę na nadchodzący sprint. Jest to jedno z 4 spotkań w scrumie, które pozwalaja na zwinne zarządzanie projektem. Na planningu powinniśmy ustalić przede wszystkim cel nadchodzącego sprintu. Mówiąc wprost chodzi nam o to, jaką wartość biznesową chcemy dowieźć po najbliższym sprincie.

Kiedy odbywa się planning?

Planning raczej nie odbywa się na koniec jednego sprintu, a przed rozpoczęciem następnego co może nam podpowiadać intuicja. Zwykle dzieje się to koło połowy trwającego sprintu. To najlepszy termin, żeby praca w zespole szła płynnie i nie generować przestojów. Jeśli ktoś skończy swoją pracę sprintową wcześniej lub równo ze sprintem to musiałby czekać na planowanie, aby dowiedzieć się co ma robić. Jeśli planowanie odbyło się w połowie trwającego sprintu, to zadania na nowy już czekają na realizację więc ma wtedy dwie opcje. Albo dobrać coś z backlogu do sprintu co na ostatnią chwilę jest ryzykowne, biorąc pod uwagę cały proces wytwarzania oprogramowania. Druga opcja to zabrać się spokojnie za realizację już nadchodzącego sprintu.

Jak odbywa się planning?

Ważny element to określenie celu sprintu, ponieważ dzięki niemu będziemy w stanie zweryfikować na końcu, czy go osiągnęliśmy czy nie. Pamiętajmy, że naszym celem samym w sobie nie jest zrealizowanie zadań i zmienienie im statusu. To tylko środek do celu. Cel ma być wartością dla klienta, to w końcu on nam płaci, powinien widzieć jakiś przyrost projektu. Pilnowaniem, aby tak się działo powinien się zająć PM lub Scrum Master. Oczywiście mogą oni być wspierani przez lidera.

Jeśli zespół nie przeprowadza pielęgnacji/groomingu/backlog refinement nazw jest na to wiele, to kolejnym krokiem jest dokładne opisanie i doszczegółowienie zadań. Ustalenie sposobu realizacji na dużych klockach. Omówienie zagadnienia, sprawdzenie czy aby zadanie nie jest zbyt duże, bo może powinno zostać rozbite.  Osobiście uważam, że pielęgnacja powinna odbywać się na osobnym spotkaniu przed planowaniem. Na planowanie zadania powinny być już przygotowanie i opisane, tak by kolejnym krokiem jaki podejmiemy była już jedynie ich estymacja.

Kiedy planujemy zadania do realizacji powinniśmy je estymować, czyli określać, ile czasu zajmie ich realizacja. Scrum wprowadza coś takiego jak story pointy, czym są to długa historia na inny artykuł, ale w ogromnym skrócie, chodzi o określanie poziomu skomplikowania zadania, a nie potrzebnego czasu. Zdarzyło mi się ich używać w projektach i są super, aczkolwiek dużo zależy od tego jak zaczniemy z nimi przygodę w projekcie.

Jeśli nie story pointy to czas, ale ważne, żeby jakkolwiek określać, ile może nam zająć zadanie. Dlaczego to takie ważne? Bo gdy wybieramy zadania do sprintu tylko na podstawie ich opisów to optymiści wezmą za dużo, a pesymiści za mało. Idąc tą analogią raczej nie spotkałam realisty, który by się wstrzelił, zawsze się nagina w którąś stronę.

Gdy wiemy, ile potrwają zadania możemy ostatecznie zweryfikować czy w te dwa lub trzy tygodnie, w zależności jak długie mamy sprinty, uda nam się wykonać tę pracę. Dobra rada: nigdy nie zakładajcie 8h jako dzień pracy. Każdy potrzebuje iść do toalety, zrobić sobie kawę czy zjeść obiad. Dlatego nie strzelaj sobie w stopę już na starcie. Z mojego doświadczenia wynika, że najlepiej, gdy założycie 6,5h produktywnej pracy dziennie. Nie oznacza to, że 1,5 spędzicie na kawie, ale umówmy się praca przy komputerze a produktywna praca nad zadaniem to dwie różne rzeczy. 

Oprócz planowania zadań warto określić sobie jakiś bufor na rzeczy niespodziewane. W końcu dobrze wiemy, że po wystartowaniu sprintu nie jest tak, że zespół zamyka się w pokoju bez okien i nic niespodziewanego do nich nie dotrze. Pojawi się jakiś błąd, który nie został wcześniej wykryty, awaria lub inne sytuacje nieprzewidziane przy opisywaniu zadań i już plan bierze w łeb. Dlatego warto badań przy każdym sprincie jak dużo takich sytuacji wpada i ile czasu zabierają, aby następnie na tej podstawie oszacować bufor. 

Na tak przygotowaną pulę zadań warto na koniec spojrzeć z lotu ptaka. Czy jest realna do wykonania. Teraz najważniejsza, często łamana przez zespoły zasada:

Nie przypisujemy zadań w sprincie!

To bardzo kuszące, aby teraz skoro mamy przygotowany sprint usiąść i przypisać zadania do ludzi. Ani mi się waż! Dlaczego nie powinno się tego robić to długa historia, którą opowiem pisząc o samym sprincie, ale wierz mi na słowo. To działa bardzo źle na dowiezienie sprintu.

Podczas całego takiego spotkania bardzo przydaje się moderator. Najlepiej, gdyby był to scrum master. Przy tak długich posiedzeniach bardzo szybko tracimy koncentrację, zaczyna nam się nudzić, ziewamy zarażamy innych albo wkręcamy się w dyskusję na mało istotny temat. Warto mieć kogoś kogo zadaniem jest pilnowanie, aby czas spędzony na planowaniu rzeczywiście był planowaniem, a nie pogaduchami przy kawie. Mamy w końcu coś z tego wynieść.

A propos wynoszenia. Pamiętajcie jeszcze o jednej rzeczy. Róbcie notatki! Opisujcie zadania w systemach do zarządzania, ale także w systemach do magazynowania dokumentacji. Twórzcie ogólne notatki ze spotkań. Nie ma nic bardziej irytującego jak trzeci raz analizowanie tego samego, ponieważ nikt nie zrobił notatek, a potem wszystkim w magiczny sposób umknęło.

Ile powinien trwać planning?

Planning jako spotkanie powinno mieć swoje ramy czasowe. Najlepiej, gdy ustali to zespół na początku swojej współpracy. Ze swoim zespołem zwykle ustalaliśmy, że planning nie przekracza 4 godzin i z tego co wiem taki czas jest rekomendowany. Jeśli nie skończyliśmy w tym czasie to ustalamy kontynuację na inny dzień, ale na pewno nie siedzimy do upadłego. Po 4 godzinach gadania każdy by padł albo z nudy, albo głowa by mu parowała. Do tego, jeśli 4 godziny to połowa dnia pracy to drugie cztery mamy na jakąkolwiek inną pracę, która mimo wszystko idzie do przodu.

Planning okiem lidera

Planning dla team leadera nie jest aż tak ważny jak daily. Jednak funkcja lidera na planningu jest kluczowa. W końcu to na plannigu podejmowane są decyzje o pracach na najbliższy sprint. Jeśli z perspektywy lidera istnieją zadania nie przekładające się bezpośrednio na wartość biznesową, ale z perspektywy technicznej są ważne jak np. dodatkowe zabezpieczenia, prace ogólne nad aplikacją czy niewielkie refaktoryzacje, które znacznie zminimalizują dług technologiczny, może je wtedy zgłosić. Do tego czuwa nad logiką wybieranych zadań. Weryfikuje czy są one w ogóle do realizacji czy np. wymagają innych prac. Są to elementy, które powinien na planningu robić w dużej mierze cały zespół, jednak lider w szczególności powinien patrzeć na prace jako na całość przyrostu. Jeśli zespół nie przeprowadza pielęgnacji, a zadania omawia na planingu, to jest to również czas, kiedy zapadają ważne decyzje techniczne dotyczące realizacji funkcjonalności. Ostateczne zdanie lidera może się okazać niezbędne.

Zgarnij darmowy ebook i cotygodniową dawkę wiedzy

.
Tags:
Magdalena Limanówka-Kuciel
magdalena@panizkomputerem.pl

Jestem programistką, która lubi mieć ręce pełne roboty. Do życia potrzebuje komputera z internetem i kubka gorącej kawy. Więcej na stronie o mnie.