najczęstsze błędy podczas układania tasków w projekcie IT – część 1
Odpowiednie rozbicie historii na taski ma kluczowy czynnik w powodzeniu projektu. Jeśli ta czynność jest źle wykonana – czas realizacji projektu się wydłuża, a w zespole rośnie frustracja bo nikt nie wie gdzie leży problem. Developerzy pracują w pocie czoła, PM skrupulatnie trzyma się metodologii prowadzenia projektu, a mimo to są opóźnienia (które niestety najczęściej przypisuje się developerom). Jeśli nie wiesz, dlaczego projekty prowadzone przez Ciebie mają opóźnienie, zrób rewizję rozkładania historii na czynniki pierwsze – taski/subtaski – być może Twój problem tkwi właśnie tutaj.
Wprowadzałem ostatnio w pracy osobę do zarządzania projektami IT. Podczas przygotowania project plan’u trzeba było rozbić pewną historię na zadania dla developerów. Wykonanie tego zadania nie stanowiłoby dla mnie problemu, o tyle wytłumaczenie jak to zrobić – nie było takie proste. Robiłem to zawsze intuicyjnie, więc w pierwszych minutach ciężko było mi ułożyć algorytm jak do tego podejść. Pracę w IT zaczynałem jako programista, więc PM przypisywali do mnie różne taski, które realizowałem. Niektóre z nich były sensownie ułożone, inne nie. Bazując na historii realizacji tych zadań, wyciągnąłem wspólny mianownik i zdefiniowałem kilka cech, których taski nie powinny posiadać. Oto najczęstsze błędy, które można popełnić rozbijając historię na zadania:
1. różne poziomy szczegółowości tasków
ciężko było wyłonić, który błąd ulokować jako pierwszy. Według mnie trzy pierwsze pozycje powinny być ex aequo.
Wyobraźmy sobie task „moduł płatności” z estymatą 3 tygodnie (abstrahując od tego jak ciężka jest wycena takiego zadania) vs task „sortowanie malejące elementów w menu” z estymatą na 15m. Jeśli zadania znacznie różnią się czasem wykonania ciężko jest zaplanować np. sprint w scrum lub ułożyć harmonogram. Jest to wykonalne, ale znacznie mniej wygodne do śledzenia postępu. Gdy taski są na równym poziomie szczegółowości – łatwiej jest nam śledzić postęp, planować tydzień lub dzień. Podałem tutaj jaskrawy przykład dużej rozpiętości tasków – według mnie najlepiej gdy odchylenie tasków od średniej (estymaty) nie przekracza ~50%. Oczywiście nie ma nic złego w długich taskach (prototypy), gdy jeszcze nie znamy szczegółów funkcjonalności, a chcemy sobie pogrupować zadania. Nie ma też nic złego w bardzo krótkich i szczegółowych taskach gdy np. poprawiamy bug w aplikacji. Problem może wystąpić wtedy gdy tak różne estymaty łączą się w jeden projekt.
2. rozbicie tasków według złego klucza
Jest to indywidualna kwestia każdego projektu. W stronach WWW dobrze sprawdza się rozbicie tasków na widoki, np. #1 strona główna, #2 kokpit użytkownika, #3 zarządzanie kontem użytkownika itp. W API rozbicie tasków układa się praktycznie samoistnie. Bardzo logicznym podziałem będą endpointy, np. #1 logowanie – user/login, #2 rejestracja – user/register, #3 edycja konta user/edit itp. W przypadku strony WWW bardziej problematyczne będzie zrealizowanie zadań gdy rozbijemy je po encjach np. ( #1 moduł użytkowniów, #2 moduł ogłoszeń). Co właściwie znaczy „moduł użytkowników” w kontekście strony internetowej? Nawet gdy są dobrze opisane kryteria akceptacji (ang. acceptance criteria, dalej zwane AC), ciężko jest to wyobrazić sobie zamknięcie takiego etapu. Task będzie zawierał elementy frontendowe i backendowe, będzie również zawierał przygotowanie struktury w bazie danych itp. Jak widzimy zadanie jest bardzo złożone, możemy je rozbić na subtaski, które częściowo rozwiążą nasz problem. Tylko po co szukać rozwiązania problemu, skoro można go uniknąć wybierając inny klucz rozbicia.
Kolejnym przykładem jest task o nazwie „moduł powiadomień”, w którym opisane są funkcjonalności do realizacji powiadomień, np. użytkownika gdy: dostanie nową wiadomość, ktoś zaprosi go do znajomych itp. Oczywiście, że możemy napisać ogólne metody, które zrealizują tą funkcjonalność, ale będzie to trudniejsze. Developer będzie miał dużo pytań w jaki sposób dokładnie zrealizować te metody, PM będzie miał dużo pracy żeby zawrzeć to i opisać każdy kontekst w AC. Dużo łatwiej rozbić to na widok powiadomień, gdzie developer zna kontekst, jest w stanie to sobie wyobrazić. W ten sposób dopisujemy funkcjonalność do naszego kodu/programu (efekt kuli śniegowej), zamiast zrobić cały moduł notyfikacji „na zaś” i później go personalizować pod to jaki kontekst wyjdzie ostatecznie 🙂
Projekt da się zrealizować w oparciu o każdy sposób rozbicia jeśli pełen zakres projektu jest w nich ujęty. Wpływa to natomiast na pracochłonność przygotowania zadań, edycji AC po ponownych ustaleniach i wielu call z developerami na temat „jak to powinno właściwie wyglądać?”.
3. zadania typu „almost done”
Zadania „almost done” stanowią zazwyczaj najliczniejszą grupę statusu tasków. Ile razy słyszeliście, „jest skończone, muszę tylko poprawić…” – błąd, nie jest skończone jeśli musisz coś poprawić. „Prawie skończone” zadanie może być też wynikiem braku dokładności u developera – to osobny temat, ale wina może też leżeć po stronie tworzącego zadania – PM. Jeśli zadania mocno się ze sobą zazębiają, a diagram sieci między zadaniami jest ułożony niepoprawnie, nie możemy zamknąć większości zadań, wtedy trafiają w otchłań – „almost done”. Taki stan rzeczy przeszkadza w śledzeniu postępu projektu, jeśli mamy 2/10 zadań skończonych i 3/10 w „almost done” (prawie skończone = ~95%). To faktycznie mamy około 50% zrealizowanego projektu, natomiast według statystyk mamy tylko 20%. Taka rozbieżność utrudnia komunikację z klientem, bo spróbuj wytłumaczyć osobie nietechnicznej, że musisz poczekać na aktualizację obiektów Entities, gdy dodacie kilka kolumn, czyli masz 20% zamkniętych tasków, ale w sumie 50%… To jak w końcu? 😉
4. złe kryterium akceptacji
AC, potocznie zwane checklistą. Są to wytyczne, wg których developer może sam ocenić czy zadanie zostało wykonane. Jeśli nie ma jasno wytyczonych AC są sytuacje typu – „mógłbyś rzucić okiem czy o to chodziło?”, „to miało działać w ten sposób?”. Developer traci czas na zgadywanie, później na poprawki – wystarczyłby zrozumiały opis (bo wyjaśnienia werbalne umykają). Dobrze sprawdzają się kryteria akceptacji rozbite na podstawie aktorów, np. „jako użytkownik mogę […]”, „jako gość mogę […]”. Tworzą się z tego krótkie historie np. „jako użytkownik zostanę zablokowany po 3 błędnych próbach podania loginu i hasła”. Nie piszmy skrótowo, nie używajmy skrótów gdzie nie jest to konieczne, trzymajmy się jednej nomenklatury.
Drugą częśc artykułu znajdziecie pod tym linkiem. Napisz w komentarzu błędy, które według Ciebie są najczęstsze podczas układania zadań w projekcie IT. 🙂
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
