Część 4 już była, ale komuś nie podobała się zawarta w niej teza i usunął (czyli zniknoł) na zawsze
Część 4, czyli jak wygląda codzienna praca programisty w korpo.
Młody dynamiczny zespół. Agile. Scrum. Mogliście spotkać się z tymi wyrażeniami. Tak jak pierwszy z reguły jest zagrywką pijarową, tak zwinność i scrum często okazują się rzeczywistością. I nie są one adaptowane w firmach, bo rzeczywiście przyniosą jakąś korzyść, ale dlatego, że jest to teraz modne i wszyscy tego używają. Niestety.
Aha, jeżeli MDZ okaże się rzeczywistością, to może być jeszcze gorzej - to znak, że zespół składa się z ludzi niedoświadczonych i firma oszczędza na najważniejszym - pracownikach.
Ale pozostańmy przy Scrumie i o tym jak się w nim pracuje, jakie są wady, korzyści i po co to komu w ogóle.
Podstawą tej metodologii są samodzielne zespoły deweloperskie. Oprócz nich jest product owner, czyli właściciel produktu, który ustala najważniejsze rzeczy do zrobienia w produkcie w określonym przedziale czasowym (np. w danym kwartale). Taką listę przekazuje do zespołu (który składa się z 3-9 uzupełniających nawzajem jednostek). Teamy dostają taką listę priorytetów od ownera, jednak to one ustalają co, ile oraz jak zrobią.
Praca w Scrumie polega na przeprowadzaniu tzw. sprintów, czyli małych okresach podczas których zespół jest w stanie zapewnić dostarczenie jakiegoś rzeczywistego usprawnienia do produktu. U nas są one dwutygodniowe.
Przed całym sprintem zespół wspólnymi siłami ustala ile jest w stanie zrobić, szuka ewentualnych blokerów, które uniemożliwią dostarczenie rzeczy na czas, ustala wewnętrzne kompetencje i demokratycznie deklaruje product ownerowi co zrobi w danym sprincie. Na końcu każdego sprintu jest demo, czyli zaprezentowania tego co udało się zrealizować. Podczas trwania sprintu codziennie odbywa się standup (daily scrum) podczas którego następuje synchronizacja zespołu w kwestii postępu prac.
To tyle w teorii. Jak to wygląda w praktyce? Multum spotkań. Scrum definiuje pewny maksymalny czas, który może być przeznaczony na mityngi. W trakcie dwutygodniowej pracy jest to:
- planowanie, max. 10%, czyli 8h,
- standup - 15minut*8dni -> 2h,
- demo - godzina,
- sprint review - godzina.
Łącznie daje nam to praktycznie dwa dni wyjęte z pracy na wysiedzenie dupogodzin. No ale tragedii nie ma, 8 dni ciągłej developerki na 10 dni pracy? Haha, nie ma tak dobrze.
Niestety często w zespołach brakuje kompetencji na dany temat, potrzebna jest konsultacja, upewnienie się czy na pewno dobrze zrozumieliśmy temat, zasygnalizowanie product ownerowi ew. blokerów, brak potrzebnych narzędzi - cokolwiek. I tym samym ten czas się przedłuża (i trzeba zamulać na makekaszu :|).
Ale na tym się nie kończy. Zmiany w priorytetach powinny nie odbywać się, ale jeżeli już, to co sprint, nie w trakcie. Jak się domyślacie - tak nie jest. Często otrzymujemy jakieś wrzuty, bo "to zajmie moment", "możesz na to spojrzeć", "a ty kojarzysz ten temat", "no jak już spojrzałeś to sie tym zajmij" itd., itp. I tym samym nierzadko główny plan sprintu nie może zostać dotrzymany i kolejna seria pytań "ale jak to", "wyciągnijcie lekcję z tego sprintu", "postarajcie sie nie dopuścić do takiej sytuacji ponownie".
Kolejną sprawą jest, że zespół jako drużyna powinna łączyć siły w pracy nad zadaniami. Aktualnie większość iteracji odbywa się na zasadzie takiej, że team jest tworem formalnym, a każdy jego członek pracuje nad czymś innym. A potem czas na standup i synchronizacji - na pewno pół teamu nie wie czym ja się zajmuje od strony technicznej (znają tylko nagłówek zadania), z kolei ja nie wiem co robi drugie pół teamu Tak być niepowinno.
Wracając do planowania i kolejnego naruszania zasad Scruma - zespół powininen sam określać co zrobi w danym okresie i potem to raportować do ownera. Ostatnio "z góry" przyszło rozporządzenie, że menedżer liniowy (czyli bezpośredni przełożony) ma również uczestniczyć w planningach i ew. wpływać na końcowy commitment, tak aby zapewnić 100% dostarczenia wartości w sprincie. Wiecie jak to się skończyło? Tak, że zespoły deklarują absolutne minimum do zrobienia, a resztę robią "na czarno", bo jakby znowu jakaś nieplanowana rzecz wpadła, to będzie świecić się na czerwono "u góry".
Jeszcze taki przykład real-life: PO rzucił nam tematy na kwartał i mieliśmy się w nie wdrożyć we własnym zakresie. Spoko, już wiemy co chcemy zrobić, mamy propozycje implementacji, ale potrzebujemy konsultacji z architektem systemu, żeby zapewnić odpowiedni performance i zapewnić jak najmniejszy wpływ na zasoby serwera. Od 3 sprintów rezerwujemy czas na to - nigdy nie dostalismy architekta i te zadeklarowane godziny przepadają na nic nie robienie. Fajnie? Sami zdecydujcie.
To tyle o Scrumie. Czy dobrze mi się w nim pracuje? Tak - tak długo jak jego zasady sa zachowane i nie ma niespodzianek. Czyli nigdy. Znacznie bardziej do mnie przemawia Waterfall, czyli z góry określone wymagania i jedno duże planowanie, a dogadywanie szczegółów na bieżąco - jednak to sprawdza się w małych projektach (rocznych?), a nie 20 letniej kobyłce
- 6
8 komentarzy
Rekomendowane komentarze
Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto
Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.
Zarejestruj nowe konto
Załóż nowe konto. To bardzo proste!
Zarejestruj sięZaloguj się
Posiadasz już konto? Zaloguj się poniżej.
Zaloguj się