Trochę scruma i agile widziałem w swojej karierze 😉 I to chyba by było tyle w temacie pozytywnych elementów tego wpisu, ponieważ chciałbym opisać te złe podejścia do scruma jakich doświadczyłem. Myślę, że moje doświadczenie jest naprawdę nikłe, ale podzielę się nim z opinią publiczną. Na wstępie zaznaczam, że nigdy nie używałem scruma. Były to jedynie elementy scruma, lub nawet gorzej elementy agile (bo wstyd to scrumem nazywać). Wynikało to na pewno z tego, że osoby wyrażające scruma w tych zespołach robiły to po raz pierwszy i nie miały żadnego doświadczenia w tym temacie. Ale do rzeczy. Opiszę wszystkie elementy, które zawodziły i które osoby nieznające się na tematyce agile lub nie zagłębiające się w tajniki scruma mogą utkwić w głowach osobób początkujących i zniekształcić spojrzenie na scruma. Liczę, że może pomoże to Wam usprawnić zarządzanie projektem w metodologi scrum.
Definiowanie story. O czym często zapomina zespół deweloperski to porządne zdefiniowanie definition of done. Bez dobrej definicji, sztywnego zakresu i pewnych informacji nie da się wycenić story. Product owner który nie chce wziąć odpowiedzialności za tworzenie porządnych opisów powinien skapitulować i poszukać innej pracy. Jeśli chce pracować w scrumie to jest jego zajęcie. Złym podejściem jest lenistwo osób, które niby chcą pracować w scrumie, ale nie chce im się tracić czasu na definiowanie story. Niestety takie są role w zespole i trzeba podjąc odpowiedzialność i chęci za definiowanie story by w scrumie pracowało się dobrze i przynosił on efekty.
Wyceny. Myślę że jedynie abstrakcyjne wartości mają rację bytu. Dla większości członków zespołu wszystko jest łatwe, szczególnie do czasu gdy nie zaczną swojego zadania. A wtedy jest juz za późno. Wycena powinna być zawsze odniesieniem do już znanego wykonanego elementu systemu z uwzględnieniem, że zespół się uczy i tego samego typu zadania z biegiem czasu wykonują szybciej. Tu znowu wrogiem scruma jest lenistwo i niechęc do omawiania zadania, czy odczuwalne przez osoby niedoświadczone podejście „wszystko jest proste” i „zrobię to w 4 godziny”.
Udawanie scruma, czy agile. Co znaczy być zwinnym? Czy jest to nie używanie żadnej metodologii, czy to tak zwana nijakość czy bylejakość? Jeśli nie chcesz używać żadnej metodyki zarządzania projektem to powiedz : „używam agile” będziesz cool. Szkoda, że większość ludzi używa słowa agile niezgodnie z przeznaczeniem. Jeśli nie masz dużej znajomości scruma a chcesz go wdrażać – daruj sobie. Dzięki temu nie nabawisz się siwych włosów na głowie i będziesz spać spokojnie. Scrum wymaga poświęcenia czasu. W scrumie ważny jest zespół nie jednostki. To Scrum Master ma usprawnić pracę zespołowi. Po to jest retrospekcja. Scrum i agile nie jest po to, by klient mógł w dowolnej chwili powiedzieć „zróbcie mi to na dziś, czy wczoraj”. Scrum to proces, który ma dostarczyć określone rezultaty. Pokazać prędkość zespołu. Pokazać, że pewien zakres projektu zostanie wytworzony w założonym czasie.
Retrospekcja. Jeśli chcesz dołożyć sobie pracy jako scrum master, wdróż scruma i rób retrospekcję. Zespół scrumowy zawsze będzie dążyć do tego, żeby pracowało mu się lepiej, nawet gdy projekt jest super, warunki pracy są super, członkowie zespołu będą zgłaszać problemy którymi scrum master będzie musiał się zajmować. Najgorzej będziesz miał, jeśli wyniki retrospekcji będą spisywane, i rozliczane. Wtedy jesteś spalony, bo wyjdzie na jaw, że Tobie nie zależy. A Ty przecież masz w tyle swojej pracy, a oni czyli zespoł Ci jej jeszcze dokłada. Jeśli jesteś scrum masterem pamiętaj, że ta rola wymaga od Ciebie poświęcenia. To Ty odpowiadasz za wdrożenie automatu na napoje, zakupienie przez dyrektora klimatyzatora czy licencję na resharpera. To Ty masz ułatwić pracę zespołowi!
Daily standup, to nie jest narzędzie by scrum master, czy product owner dowiedzieli się co się dzieje w projekcie. To czas 15 min dla zespołu. To moment gdy zespól może porozmawiać i wymienić się problemami ustalić czy ktoś potrzebuje pomocy, zaktualizować swój status wewnątrz zespołu.
Podsumowując myślę, że moje przemyślenia pomogą niektórym używać lepiej scruma, a w szczególności poprawią jego gorsze elementy. Moim zdaniem warto jest pracować w scrumie i korzystać z jego pozytywnych elementów. Na pewno ciężko jest wdrożyc „pełnego” scruma w zespołach, ale należy do tego dążyć.