Scrum nie jest uniwersalnym rozwiązaniem

Rozproszona odpowiedzialność za projekt sprawia, że trudno nim zarządzać. W trakcie sprintów zbieranych jest wiele informacji, które warto w odpowiedni sposób monitorować i analizować, aby utrzymać kontrolę nad postępem projektu. Jest to na przykład wydajność zespołu czy poprawność estymacji i skomplikowania zadania. Zdarza się jednak, że zespoły nie zastanawiają się nad tym, zanim przystąpią do pracy w scrum. Zamiast tego próbują wypracować podejście już po zebraniu pierwszych danych. Często okazuje się, że oprócz tego, co zostało zanotowane w poprzednim sprincie, przydałyby się dodatkowe dane lub zmiana sposobu ich raportowania. Zajmuje to dodatkowy czas zespołu oraz uniemożliwia porównywanie tych samych danych na przestrzeni minionych sprintów. Dlatego warto dokładnie przemyśleć, jakie informacje powinniśmy gromadzić w czasie pracy nad projektem oraz w jakim celu będziemy je potem wykorzystywać.

Praca w scrum zajmuje dużo czasu

Szacowanie czasu i planowanie sprintów to powtarzalne elementy scrum. Oprócz tego zespoły muszą rejestrować faktyczny czas spędzony nad danym zadaniem, aby porównać, czy dobrze oszacowały poziom jego skomplikowania. Na koniec sprintu odbywa się jego podsumowanie i demonstracja wykonanych historyjek użytkownika.

Zobacz również:

  • Partnerstwo w zakresie rozwoju oprogramowania - 5 najlepszych praktyk

Po jednym lub kilku sprintach mogą być wydawane wersje, co oznacza, że dotychczas zrealizowane fragmenty rozwiązania trafiają na środowisko produkcyjne. Dobrą praktyką jest też regularna rewizja i porządkowanie kodu. Wszystkie te czynności zajmują czas i tworzą koszty, co powinno być brane pod uwagę przy podejmowaniu decyzji o wprowadzeniu scrum.

W praktyce trudno o prawdziwego właściciela produktu

Istotną rolę w zespole scrum odgrywa właściciel produktu. Reprezentuje on użytkowników końcowych rozwiązania i bezpośrednio uczestniczy w pracach zespołu. Właściciel produktu decyduje również o zmianach w zakresie produkowanych funkcjonalności oraz akceptuje dotychczas zrealizowane historyjki. W dużych organizacjach właściciel produktu wywodzi się najczęściej z biznesu. Często swoją rolę projektową musi on pełnić obok zadań operacyjnych, co stwarza problemy z jego dostępnością, na przykład na cyklicznych spotkaniach. Pewnym rozwiązaniem jest wyznaczenie na właściciela produktu osoby, której czas w większości lub nawet w całości może być przeznaczony na potrzeby projektu. Zwykle jednak ma ona mniejszą decyzyjność w zakresie priorytetów biznesowych, budżetu czy harmonogramu projektu.

Problemy wynikają też często z faktu, że zwykle to dział IT inicjuje pomysł wprowadzenia scrum i szkoli tylko swoich pracowników w tym kierunku. Zatem w trakcie rozpoczynania pracy w scrum użytkownicy biznesowi, którzy także mają brać udział w projektach, nie są równie dobrze przygotowani jak ich koledzy z IT. Utrudnia to komunikację w zespole i zniechęca do angażowania właściciela produktu we wszystkie elementy sprintu – niechęć ta widoczna jest zarówno po stronie zespołu, jak i samego właściciela.


TOP 200