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