Czym jest Agile (i Scrum)?

Po zapoznaniu się z procesem wdrożenia projektu na produkcję przyszedł czas na rozpoczęcie nowego segmentu naszego cyklu w którym zobaczymy jak się pracuje w IT i czym to się różni od innych branż.

Uwaga! W tej serii zajmuję się opisowym przedstawieniem tematu, a celem jest zapoznanie z zagadnieniem w sposób luźny i zrozumiały dla nowicjusza. W związku z tym wiele elementów siłą rzeczy musi zostać pominiętych. Tych z was, którzy chcieliby się dowiedzieć więcej, zapraszam do źródeł na końcu artykułu.

Jak zbudować dom?

Zakładając, że jedyne co mamy na start to pomysł i fundusze na jego realizację, to trzeba zacząć od znalezienia odpowiedniej lokalizacji wpisującej się w nasze potrzeby. Wolimy wiejskie klimaty czy peryferia dużego miasta? Zależy nam na odosobnieniu czy chcemy być otoczeni przez sąsiadów? Z okna ma być widok na góry, morze czy kwieciste łąki? No i oczywiście – czy potencjalna działka ma być już uzbrojona czy goła i wesoła?

-Zakładając, że mam już miejsce – czy mogę się wprowadzać?
-Jak posiadasz namiot to jak najbardziej!

Kiedy już wybierzemy i wykupimy wymarzoną parcelę musimy postarać się o projekt domu opisujący wszystko w najdrobniejszych szczegółach – od liczby pokoi aż po typ cementu w posadzce. Nie może być żadnych nieścisłości ani pola do nadinterpretacji. To jest również dobry moment aby zatroszczyć się o kwestie prawne i zdobyć wszystkie niezbędne pozwolenia, a jeśli teren jest nieuzbrojony – zaaplikować o podłączenie wody, prądu, kanalizacji i ewentualnie gazu.

-Mam miejsce, projekt, pozwolenia – czy mogę się wprowadzać?
-Ale, że niby gdzie? Domu jeszcze nie ma.

Następnym krokiem jest wynajęcie ekipy budowlanej i zleceniem im wylania fundamentów. To samo w sobie potrwa kilka tygodni, a potem jeszcze trzeba poczekać parę miesięcy aby beton wysechł, osiadł na gruncie i stanowił solidną platformę do dalszych prac budowlanych.

-Fundament wylany i wyschnięty – czy mogę się wprowadzać?
-Jeszcze nie, przecież tam nawet dachu nie ma!

Prace trwają. Ściany pną się do góry, powstaje piętro, potem strych, strop i następuje ustawianie więźby dachowej na której zostanie położona blachodachówka. Dom wreszcie zaczyna przypominać miejsce do życia, ale brak drzwi i okien jasno daje do zrozumienia, że do wprowadzenia się inwestora jeszcze daleka droga.

-Czy mogę się wpr…
-Ej, czy ty w ogóle czytasz co ja piszę?!

Ziejące pustką wnęki zostały załatane oknami, pojawiły się też solidne drzwi antywłamaniowe. Elektryk i hydraulik zrobili co do nich należało. Do pracy wzięli się wykończeniowcy – pojawił się tynk na ścianach, izolacja, panele, płytki, armatura, kolory i dekoracje. Zaczyna to wszystko wyglądać całkiem ładnie.

-Czy mogę się już wprowadzać?
-Teoretycznie tak, ale gdzie będziesz spał?

Ostatnim etapem jest umeblowanie. Kupujemy i ustawiamy szafy, kanapy, łóżka, stoły itd. Podłączamy urządzenia AGD i RTV. Dodajemy roślinność, przyczepiamy obrazy nadające trochę życia gołym ścianom. Wieszamy zasłony, kładziemy wycieraczkę z napisem „Welcome” i…

-Czy mogę się w końcu wprowadzać?
-Tak! W końcu dom jest gotowy i można w nim mieszkać!

Ale, ale! To, że w środku wreszcie pojawili się mieszkańcy wcale nie oznacza, że robota dobiegła końca. Każdy posiadacz własnej posesji wie, że koło chałupy zawsze znajdzie się jakaś robota: można postawić garaż albo szopkę na narzędzia, ułożyć kostkę brukową, zamienić stryszek w poddasze z dodatkowymi pokojami i tak dalej.

Powyższy schemat działania (lub inaczej „metodologia”) przez wiele lat był również podstawą rozwoju oprogramowania.

Analogicznie do budowy domu, najpierw układano dokładny plan jak zadana aplikacja będzie wyglądać w chwili ukończenia. Wykonywano analizy, przygotowywano infrastrukturę, wykupywano domeny, podpisywano kontrakty. Potem zespół programistów brał się za projekt i wykonywał go punkt po punkcie. Następnie pałeczka przechodziła do działu QA i testowano wszystko sprawdzając czy wpisuje się w wymagania klienta. Czasami coś się wywalało i funkcjonalność wracała do poprawki, potem znów testy, a czas leciał. A konkurencja nie spała.

Posiadając pomysł i finanse rozpoczynaliśmy mozoloną drogę na końcu której jawił się nasz Święty Graal w postaci gotowej aplikacji pełnej użytkowników przynoszących czysty profit. Takie podejście nazwano:

Waterfall

Waterfall działał nawet nieźle, ale tylko do czasu rozkwitu Internetu. Wówczas wszystko nabrało tępa i mogło się okazać, że twój pomysł na aplikację – który z początku prezentował się świetnie – po ukończeniu był jak ten stary dziadek pośród młodszych, bogatszych w „ficzery”, appek.

W 2001 roku, 17 dzielnych deweloperów z USA reagując na zachodzące zmiany wydało manifest będący instrukcją nowoczesnego wytwórstwa oprogramowania. Można go podsumować w czterech punktach:

1. Ludzie i ich wzajemne interakcje powinny być ponad procedurami
2. Działający soft jest ważniejszy od dobrej dokumentacji
3. Zamiast sztywnego kontraktu – ciągła współpraca na linii zespół-inwestor
4. Zamiast dalekosiężnego planu – błyskawiczne reagowanie na zachodzące zmiany

Agile

Ową metodologię nazwano, całkiem akuratnie: „Zwinna” (ang. agile). W praktyce opiera się to na tzw. „Sprintach” czyli stosunkowo krótkich okresach czasu (1-4 tygodnie) poświęconych na ubogacenie projektu o nową REALNĄ* wartość.

(*) Czyli np. dokumentacja odpada – owszem, jest ważna ale tylko z poziomu zespołu, a dla końcowego użytkownika nie ma większego znaczenia.

W budownictwie coś takiego nie miałoby większego sensu, bo przekładałoby się na system gdzie najpierw stawiamy słomiany szałas, potem robimy z niego drewnianą szopę, dalej ceglaną komórkę i parę iteracji dalej magicznie wychodzi nam z tego rezydencja.

Ale w rozwoju oprogramowania AGILE sprawdza się wyśmienicie.

Nieodłączną częścią Agile jest tzw.

Scrum

Jednak zanim wytłumaczymy sobie czym jest Scrum, omówmy kilku członków personelu pojawiających się w Agile, z których każdy może być tłumaczony na polskie słówko „kierownik”.

• Product owner
  Tymczasowy „właściciel produktu” i pośrednik pomiędzy zespołem deweloperskim, a inwestorem. Tłumaczy język biznesu na techniczny i na odwrót.
  
• Product manager
  Kierownik „strategiczny” zajmujący się wizją produktu i planujący długofalowe podejście w jego rozwoju („roadmap”). Jego zadaniem jest takie wymodelowanie projektu, aby na koniec klient dostał nie to co wydawało mu się, że chciał, ale to co faktycznie potrzebował.
  
• Scrum master
  Jego domeną jest sam Agile oraz wszystko co z nim związane: organizacja i moderacja spotkań scrumowych, zarządzanie sprintami oraz ogólna pomoc zespołowi polegająca na usuwaniu przeszkód które mogą spowalniać zwinne podejście.
  
• Team leader
  Podczas gdy SM może być programistą (ale nie musi, bo równie dobrze nada się tam ktoś po psychologii, albo zarządzaniu), lider zespołu musi być zaznajomiony z używanymi technologiami – to on wyznacza ludzi do poszczególnych zadań, monitoruje postęp prac i rozwiązuje konflikty w ekipie.

Czym wobec tego jest ten „Scrum”

To framework zawierający zasady i procedury pomagające rozwijać projekt w metodologii Agile. Kluczowymi elementami jest Product owner który tworzy i priorytetyzuje tzw. Backlog (inaczej: „rzeczy do zrobienia”) oraz Scrum master i jego regularne spotkania z zespołem deweloperskim:

• planowanie następnego Sprintu (Sprint planning)
• codzienny „Daliy Scrum” gdzie każdy członek zespołu opowiada co zrobił poprzedniego dnia i co chce zrobić dzisiaj
• Sprint review to krótkie podsumowanie zakończonego właśnie Sprintu
• Retro (Sprint retrospective) to spotkanie pomiędzy etapami „review” oraz „planning” gdzie zespół ocenia sam siebie i dyskutuje jak można uwydajnić pracę

Dla przykładu, Daily Scrum może wyglądać jak poniżej:

Scrum Master: Ok, to zaczynamy od Ewki. Ewa, jak wczorajszy dzień?
Ewa: Udało mi się wreszcie wrzucić automatyzację do testów E2E.
Scrum Master: O, fajnie, wczoraj mówiłaś, że były z tym problemy.
Ewa: Znalazłam w sieci fajny skrypt do Jenkinsa. Wystarczyło zmienić parę linijek i dodać nasze zmienne środowiskowe.
Scrum Master: Jenkins? Znam to narzędzie i sam wielokrotnie z niego korzystałem, chociaż w innych celach. Ok, a jakie masz plany na potem?
Ewa: Teraz już mogę się zabrać za moduł autoryzujący użytkowników.
Scrum Master: Doskonale, długo na to czekaliśmy. Czy przewidujesz jakieś problemy?
Ewa: Raczej nie, bawiłam się już tym w wolnych chwilach i powinno pójść gładko.
Scrum Master: Dzięki, Ewa! Teraz przejdźmy do Marka. Marek, dałeś sobie radę z tym nowym interfejsem na płatnościach?
Marek: ...

Ktoś teraz mógłby się zapytać:

1. Czy jak Agile to zawsze Scrum?
2. Czy w IT zawsze pracuje się w Agile?
3. Czy Agile nadaje się tylko do IT?

AD1. Scrum jest starszy od Agile – jego zasady zostały spisane w 1995 r. więc siłą rzeczy nie jest tylko częścią zwinnej metodologii, aczkolwiek oba te koncepty mają wiele wspólnych elementów.

AD2. Waterfall jeszcze żyje i w pewnych, bardziej konserwatywnych branżach, ma się doskonale. Do tego mamy jeszcze „Kanban” czyli taki Agile bez podziału na Sprinty – jest często stosowany np. w zespołach DevOpsowych. A dla niezdecydowanych zostaje „Scrumban” czyli taka hybryda.

AD3. Cóż, jako że jest to ciekawe ćwiczenie myślowe – sprawdźmy sami na przykładzie personelu pierwszego lepszego dyskontu spożywczego do którego ambitny kierownik wprowadził Scruma:

Scrum Master: Ok, to zaczynamy od Ewki. Ewa, jak wczorajszy dzień?
Ewa: Udało mi się wreszcie rozładować te palety blokujące dostęp do alejki z kolonialem.
Scrum Master: O, fajnie, wczoraj mówiłaś, że były z tym problemy.
Ewa: Tak, miałam to zrobić wcześniej, ale grasował tam taki duży szczur. Dzisiaj z rana udało mi się go zaje*ać mopem.
Scrum Master: Mopem? Znam to narzędzie i sam wielokrotnie z niego korzystałem, chociaż w innych celach. Ok, a jakie masz plany na potem?
Ewa: Teraz już mogę się zabrać za posprzątanie tej plamy po maślance którą ktoś rozbił we środę.
Scrum Master: Doskonale, długo na to czekaliśmy. Czy przewidujesz jakieś problemy?
Ewa: Raczej nie, bawiłam się już tym w wolnych chwilach i powinno pójść gładko.
Scrum Master: Dzięki, Ewa! Teraz przejdźmy do Marka. Marek, dałeś sobie radę z tym nowym interfejsem na kasach samoobsługowych?
Marek: ... 

Wiedza o metodologii pracy nie jest jakimś „must-have” i z pewnością pracodawców bardziej interesuje to czy np. znasz Dockera albo dobrze odnajdujesz się w pracy z Gitem. W jaki sposób będziesz wykonywał swoje obowiązki zostanie ci wytłumaczone w procesie zwanym:

onboarding

Z języka angielskiego oznacza to coś w stylu „wejście na pokład” – tam poznasz zasady panujące w biurze, dostaniesz służbowego laptopa, otrzymasz pouczenie na temat BHP i zostaną ci przyznane wszelkie wymagane hasła dostępu.

Mimo to warto wiedzieć jak wygląda taki „big picture” czyli tworzenie oprogramowania widziane z perspektywy kierownictwa i inwestorów. Jest to kluczowe w podejściu DDD i sprawia, że z małpki jedynie wykonującej taski rytmicznym waleniem w klawiaturę stajesz się integralnym członkiem zespołu, który ma wpływ na końcowy wygląd projektu. A to przekłada się na prestiż i tym samym zwiększa możliwości awansu.

Przygotowując ten wpis natrafiłem na bardzo ciekawy podcast „Porządny agile”, który pokazuje w/w podejście i skupia się na schematach pracy zespołu, problemach i tym jak sobie z nimi radzić. Polecam.

Dziękuję za uwagę i do zobaczenia w następnym odcinku w którym przyjrzymy się bliżej narzędziu Jira służącemu do zarządzania pracą, analizy postępów i dystrybucji zadań.

---

Źródła:
Agile, Scrum, Kanban – wyjaśnienie ANG
Podcast Porządny Agile POL