SŁOWNICZEK AGILE

Po co ten Słownik Agile?

Poniżej staram się przybliżyć różne pojęcia z zakresu Agile, które są chlebem powszednim każdego Product Ownera w firmie, która zarządza swoimi projektami w którejś z metodologii zwinnych. Ja do Zwinnie Przez Świat wykorzystam Scruma. Nie traktujcie tego jak podręcznika! To wszystko przetestowane zostało przeze mnie w boju, w jednej firmie, a nie dziesięciu różnych - może się zdarzyć, że spotkaliście inne nazwy tych pojęć, które też będą właściwe. Nie mniej jednak - ceremonie takie jak planowanie, demo albo retro są w tej metodologii stałe i filozofię wszędzie będą miały podobną. Tutaj opisuję to wszystko "po swojemu" i podejmuje pierwszą próbę odnalezienia analogii między moją pracą zawodową a zarządzaniem takim projektem, jakim jest roczna podróż.

Grupa zwinnych metodyk zarządzania projektami, odznaczających się dużym nastawieniem na elastyczność i możliwość zmiany planu albo wymagań w trakcie realizacji projektu. Stosowany głównie w tworzeniu oprogramowania, aplikacji on-line’owych, mobilnych itp.

Konserwatywne, starsze metodologie zarządzania projektami (np. Waterfall) skupiały się najczęściej na jak najlepszym wyspecyfikowaniu wymagań przed rozpoczęciem prac programistycznych, co zajmowało ogromną ilość czasu. Analityk Biznesowy (albo ktoś w tym stylu) razem z programistami analizowali potem te wszystkie wymagania. Doprecyzowywali je z biznesem, szacowali czas potrzebny na wykonania, zamykali specyfikację i siadali do pracy. W trakcie kodowania właściwie nie kontaktowali się bezpośrednio z osobami, które tworzyły wymagania, dowozili to, co opisywała specyfikacja i często nie to, co biznes miał na myśli 🙂 Nie wspominając o tym, że kodowanie zajmowało na przykład 3 miesiące i otoczenie biznesowe w tym czasie zupełnie się zmieniło, więc i wymagania powinny zostać dostosowane.

Agile zakłada, że programiści są z „biznesem” w ciągłym kontakcie. Specyfikacje są tworzone non-stop, w małych kawałkach. Produkt jest „dowożony” w małych porcjach, każda powinna przynieść jakiś biznesowy efekt. Po dowiezieniu takiej porcji, mierzony jest jej wpływ na biznes, analizowany jest też sam proces wdrożenia pod kątem jego efektywności. Na tej podstawie podejmowane są decyzje, co robimy dalej: czy realizujemy wcześniej stworzony plan, czy może należy go trochę zmienić.

W taki właśnie sposób będziemy planować i realizować naszą podróż 🙂 W mniejszych kawałkach, dostosowując się do zmian, które zajdą w otoczeniu i w nas samych.

Jedna z najczęściej stosowanych metodologii z grupy Agile. Określa cykl pracy nad rozwojem produktu i przypisuje konkretne role do osób w zespole.  W każdym zespole SCRUM musza się znaleźć:

• Scrum Master - dba o to, żeby proces dobrze działał, organizuje wszystkie spotkania, raportuje realizację planu itp. Najczęściej jeden z programistów.
• Product Owner – właściciel produktu czyli przedstawiciel biznesu, który odpowiada za produkt swoim ciałem, umysłem i duszą 🙂 To on tworzy wymagania, dostosowuje je, kiedy jest taka potrzeba, decyduje o priorytetach, zbiera wymagania z całej organizacji, pilnując długookresowego planu.
• Developers - programiści, którzy piszą kod i tworzą aplikację. Mogą obsługiwać różne języki programistyczne, czasem wszyscy są jednego rodzaju, czasem różnych specjalizacji – wszystko zależy od technologii, za pomocą której budowany jest produkt.

Czasem dodatkowo może ten zespół wzbogacić Project Manager, Tech Lead albo Specjalista od UX – ale możemy to sobie tutaj pominąć.

Proces wdrożenia w Scrumie zakłada, że produkt jest budowany w sprintach (najczęściej 2 albo 3 tygodniowych), każdy sprint zaczyna się planowaniem, kończy demonstracją nowych funkcjonalności, a potem wdrożeniem ich na produkcję. W międzyczasie codziennie odbywają się tzw. „Daily Stand Ups”, a każdy sprint podsumowuje się na „Retro”. Opisy wszystkich tych elementów składowych w dalszej części Słowniczka.

U nas ciężko będzie role Scrum’owe przypisać – jesteśmy zespołem dwuosobowym i obawiam się, że ja będę zarówno SM jak i PO 😉 Bogdan to developer i w sytuacjach kryzysowych Mega Scrum Master.

Ale! Skorzystamy mocno ze wszystkich części składowych procesu. Popatrzcie w pozostałe definicje.

Konkretny odcinek czasu, w którym zespół projektowy dowozi i wdraża zaplanowaną „porcję” produktu. Każdy sprint zaczyna się od planowania, a kończy implementacją nowych rzeczy na produkcji.

Konkretny odcinek podróży! 🙂 Czasem będzie to jeden kraj, czasem tylko część. Będzie trwał albo 2 albo 3 tygodnie w zależności od potrzeb. Każdy taki odcinek będzie się składał zawsze z takich samych części jeśli chodzi o realizację planu i kategorie wpisów, które umieścimy na stronie. Co 2 lub 3 tygodnie cykl będzie się rozpoczynał od nowa tylko w innym miejscu świata!

Jest to spotkanie, na którym zespół ustala co wchodzi do kolejnego sprintu. Które „User Stories” decyduje się dowieźć za 2 tygodnie. Sprawdzane jest, czy wszystkie wymagania są skompletowane, jasne, zmierzone pod kątem skomplikowania i jeśli wszyscy twierdzą, że plan jest w porządku – nie za duży, nie za mały – sprint zostaje rozpoczęty.

W pierwszym dniu każdego odcinka podróży napiszemy jaki mamy plan na ten sprint. Plan zostanie zaprezentowany w formie listy „User Stories”, które to opiszą poszczególne mniejsze rzeczy, które chcemy zobaczyć, przeżyć, spróbować, poznać, zjeść, usłyszeć…itd. W tych wpisach pokażemy też trasę na następny sprint.

To mały kawałek wymagań, który opisuje, co chcielibyśmy dodać do produktu albo w nim zmienić. User Story musi być na tyle duże, żeby przynosiło konkretną wartość biznesową, ale też na tyle małe, żeby w trakcie jednego sprintu dało się zakończyć jego implementację.

Jedna konkretna rzecz, którą chcemy w trakcie któregoś z odcinków podróży zrobić. Takim User Story może być na przykład:

Jako fotograf amator, chciałabym pojechać na Galapagos, żeby sfotografować tamtejszą przyrodę.

W opisie takiego „User story” zawrzemy trochę szczegółów odnośnie planu, czyli jak planujemy to Galapagos zwiedzać, jak będziemy się przemieszczać, ile czasu nam to zajmie. Każdy User Story zmierzymy punktami- tzw. „Story Points”. Będą odzwierciedlały nasz wysiłek, który musimy włożyć w jego realizację. 1,2  lub 3 punkty to historyjki z kategorii raczej prostych typu zjedzenie lokalnego specjału albo poleżenie na plaży. 5,8 i 13 to większe imprezy 🙂 Na przykład taka wyprawa na Galapagos to pewnie z 8 Story Pointów.

Codzienne, bardzo krótkie (max 15 min) spotkania, na którym każdy z zespołu może powiedzieć: co robił wczoraj, co robił dzisiaj, czy wszystko jest generalnie OK, czy nie jest przyblokowany kimś innym i czy potrzebuje pomocy.

Krótkie wpisy, parę w ciągu jednego odcinka podróży (nie codziennie), które ogólnie opiszą co tam słychać 🙂 Gdzie akurat jesteśmy, co zrobiliśmy, co planujemy teraz.

To moment pod koniec sprintu, kiedy wszystkie ustalone funkcjonalności zostały już zaprogramowane i przetestowane i zespół jest gotowy, żeby pokazać wynik swojej pracy w kompletnej formie Product Ownerowi i innym zainteresowanym osobom. To jest właśnie Demo.

Release, czyli implementacja, to już samo włączenie tej nowości na działającym już przecież wcześniej żywym produkcie.

U nas będzie to jeden podsumowujący wpis na koniec każdego odcinka podróży. Będzie się charakteryzował sporą galerią zdjęć z danego etapu (sprintu! 🙂 ) i kilkoma najważniejszymi benefitami, które z tego odcinka wynieśliśmy.

To mój ulubiony element Scruma! Jak już sprint zostanie zakończony, nowe funkcjonalności działają już na produkcji, przychodzi czas na moment zadumy 🙂 Cały zespół Scrum’owy zbiera się na godzinkę albo dwie i patrzy wstecz. Zastanawia się nad wszystkim co dobre i co się udało, ale też wyciąga wnioski z tego, co sukcesem nie było. Każde retro kończy się maksymalnie 3 punktami do poprawy, zmiany, nauki.