Agile – czyli jak pracować zwinnie?

Cześć! Cieszę się, że mnie odwiedziłeś/aś. Zanim przejdziesz do artykułu chciałbym zwrocić Ci uwagę na to, że ten artykuł był pisany kilka lat temu (2013-09-30) miej więc proszę na uwadzę że rozwiązania i przemyślenia które tu znajdziesz nie muszą być aktualne. Niemniej jednak zachęcam do przeczytania.

Agile to skrót myślowy od Agile software development czyli programowania zwinnego. Jest to taka duża, jakby to powiedzieć.. Nad grupa, w której znajdują się już konkretne metodologie typu Scrum czy Kanban. W nomenklaturze programistycznej można by powiedzieć że każda metodologia nazywana zwinną dziedziczy po Agile’u.

Metodyk zwinnych mamy kilka, ja napisze więcej tylko o Scrum’ie i Kanban’ie – poza nimi jest jeszcze chociażby XP (Programowanie Ekstremalne) czy TTD (Test-driven development).

Ok, fajnie że już wiemy że sama idea idzie w kilka stron, ale czym to tak w ogóle jest?

Agile to inne podejście do programowania. Przed wprowadzeniem tej metodyki projekty były tworzone kaskadowo. Tzn że każdy projekt był dzielony na różne etapy. No i w sumie fajnie, nie? Więc wygląda to np. tak:

Czas sobie mija, kolejne etapy projektu się wykonują i wszystko gra, prawda? No.. Ale nic nie jest idealne. Wyobraźmy sobie sytuację kiedy to przychodzi klient i chce byśmy zrobili mu np. stronę WWW, która będzie wizytówką jego firmy. No i mówi że może tło niebieskie, że może na górze jakiś banner, a może na dole niech niebieskie przechodzi w zielone.. No ogólnie „wymyślcie coś! Ma być ładne.” – w tym momencie nasze skrupulatne notowanie jakoś traci sens, bo klient.. Sam nie wie czego chce. I tak jest bardzo często – wizja jeszcze nie jest pełna. A przecież model kaskadowy zakłada wykonanie pełnej specyfikacji przed rozpoczęciem implementacji – żeby było wiadomo co robimy.

Już w tym momencie model ten zaczyna być niewystarczający. Czyli już na samym początku – przed napisaniem choćby linijki kodu.

Każdy projekt może się nie powieść, prawda? Jest to tzw. stopień ryzyka. Określa on szansę na stracenie pieniędzy – a bo nie zdążyliśmy, a bo klient się wycofał itp. Stopień ryzyka w modelu kaskadowym jest wysoki już na samym początku!

Najważniejszym aspektem ryzyka jest oczywiście zmiana specyfikacji którą sobie stworzyliśmy. Załóżmy że klient dzwoni i mówi że już nie chciałby żeby to było tylko wizytówka, ale też żeby był tam mały sklep. I co teraz się dzieje? Trzeba przebudować cały projekt. Od nowa analiza, specyfikacja, implementacja i tak dalej..

Firma traci pieniądze – jest nieźle jeśli straci tylko różnicę w kwocie przeznaczonej dla pracowników a zarobionej na projekcie, bo to znaczy że projekt mimo wszystko został skończony, a co jeśli klient, jak usłyszy czas jaki będzie potrzebny za zrealizowanie jego wymagań, podziękuję za współpracę? No właśnie…

Jak się łatwo domyśleć – sporo projektów zyskiwało status „failed!”, co skłoniło ludzi do myślenia i z niego powstał zarys Agile’a :)

Główne postulaty Agile, są znane chyba wszystkim, mniej lubi więcej znających się na Inżynierii Oprogramowania:

Ludzie i interakcje ponad procesy i narzędzia.

Agile stawia bardziej na wzajemne budowanie interakcji między ludźmi, która zawsze zaowocuje świetnymi wynikami, niż wyuczone, odgórnie narzucone procesy. Powstały takie terminy jak „team building” czy „integration days”, które często są sponsorowane przez firmy, aby ludzie mogli się wzajemnie lepiej poznać.

Działające oprogramowanie ponad obszerną dokumentację.

Tak, w końcu się to stało. Pomysł tworzenia dokumentacji odsunięto na drugi plan. Na pierwszym jest tylko działający kod.

Współpracę z klientem ponad formalne ustalenia.

Nie ma sztywnych specyfikacji. Tworzy się ona dynamicznie wraz z upływem czasu i wzmożonym kontaktem z klientem – pozwala to na uniknięcie niepotrzebnych przestojów czasowych, nerwów pracowników i przede wszystkim nerwów klienta.

Reagowanie na zmiany ponad podążanie za planem.

Zmiany są czymś normalnym i nie boimy się ich jak ognia. W każdej chwili możemy je zaadoptować do projektu nie niszcząc przy tym całego procesu.

 

Zostały one napisane w 2001 roku w Snowbird. Całość dostępna na tej stronie.

Team to już nie tylko pracownicy, ale również klient.

Wymagana funkcjonalność przedstawiana jest przez Product Ownera (właściciela projektu) w formie tzw. „User Story” – historyjek na temat realizowanego projektu – nieformalnych opisów jakiejś funkcjonalności. Każda historyjka ma przypisaną notatkę DoD – czyli Definition od Done -które, prostujące hasła, wyjaśniające, kiedy można historyjkę uznać za skończoną.

W tej chwili wejdźmy w Scrum’a.

W tej metodyce team ustala długość iteracji (sprintu) – czasu po których obiecuje dostarczyć nową wartość biznesową (funkcjonalność). Każde User Story jest oceniane. Odbywa się to często za pośrednictwem kart Agile’owych (poker estymacyjny). Mają one napisane cyfry określające złożoność konkretnej historyjki.

 

Członkowie teamu (od 3 do 8 osób najoptymalniej) czytają wymagania i oceniają. Kładą wybrane przez siebie karty na stół i osoba z najniższą wartością i najwyższą debatują między sobą ustalając finalną wartość danej historii. Sumaryczna wartość „wag” wybranych na konkretny sprint nie może przekraczać określonego limitu czyli długości iteracji. Klient może sprecyzować priorytety konkretnych funkcjonalności.

Tak przygotowane historyjki są dzielone na jeszcze mniejsze zadania (Tasks, Sticks) i już tylko od Teamu zależy kto czym się zajmie. Daje to duże pole do manewru, bo małe jest wtedy prawdopodobieństwo że ktoś będzie pisał coś czego nie umie/nie lubi – zyskując zadowolenie z pracy i zwiększając tym swoją efektywność. Ba, swoją. Całego zespołu!

Czas sprintu nie powinien się zmieniać podczas projektu, daje to możliwość określenia szybkości pracy teamu.

W Agile’u nie ma jako takiego lidera grupy. Za to mamy Scrum Mastera – osobę która pomaga grupie w każdy możliwy sposób i dba o to żeby zasady Scruma były przestrzegane. To on komunikuje się z Product Ownerem.

Codziennie rano odbywają się tzw. Stand up’y. Czyli krótkie spotkania np. przy kawie czy herbacie rano polegające na lakonicznym opowiedzeniu o tym nad czym się aktualnie pracuje, jakie są z tym problemy i co fajnego udało się już stworzyć. Pomaga to być całemu teamowi na bieżąco z każdą częścią aplikacji. A poza tym kawka czy herbatka z rana zwiększa morale :)

Pod koniec każdego Sprintu odbywają się retrospekcje (Sprint Retrospective), które służą do zebrania informacji o tym co podczas ostatniego sprintu było ok a co warto poprawić. Można tutaj powiedzieć wszystko wraz z narzekaniem na warunki pracy (np. za zimno, za ciepło, za ciemno, za widno itp)

 

Praca teamu jest opisywana statystykami takimi jak chociażby wykres spalania (Burn down chart) czyli ile zostało do wykonania zadań (w ramach iteracji) lub ile zostało opowieści (w punktach).

Jak realizowany jest Agile? Najczęściej w postaci fizycznej tablicy gdzie mamy kolumny odpowiadające etapom powstawania i członkowie teamu sobie przyklejają karteczki zapisując daty zmian. Drugą możliwością jest korzystanie z narzędzi które dają takie możliwości wirtualnie – np. ScrumWorks czy świetnie zapowiadający się projekt Tubo.

 

 

Kanban jest metodyką prostszą. Mającą mniej zasad i nie zamykającą się w iteracjach. Statystyki nadal określają szybkość i skuteczność teamu’u, ale nie jest to już burn down chart a chociażby średnie wartości czasu który potrzeba na wykonanie historyjki o danym poziomie trudności. W Kanbanie zazwyczaj nie ma aż tylu wartości wykorzystywanych do oceny jak w Scrumie. Systematyczne pomiary takich wartości, jak czas i płynność wykonywania zadań, używane są w celu optymalizacji procesów. Wprowadzono też limit zadań wykonywanych jednocześnie. Przykładem aplikacji która służy do wizualizacji przepływu w Kanbanie jest KANBAN Tool. Zobaczmy jak wyglądają wykresy po nałożeniu na nich wartości odpowiadających Agile’owi.

 

Visibility – kontakt w klientem jest zawsze.

Adaptability – podatność na zmiany wysoka w każdym punkcie projektu. Funkcja maleje wolno.

Business Value – Bardzo często dostarczamy jakąś część aplikacji.

Risk – ryzyko wysokie tylko na początku projektu.

 

Podsumowując.. Agile jest ciekawym rozwiązaniem jeśli chodzi o zarządzanie projektami. Widzę tylko dwa problemy związanie z podejściem zwinnym – pierwszy to fakt, że klient musi się mocno zaangażować w cały projekt a nie przygotować specyfikację i „mieć wyjebane”. Drugim problemem jest fakt że programiści mimo wszystko „przywiązują się” się do swojego kodu – i nagła potrzeba skorzystania z kombinacji klawiszy ctrl+a i delete nie zawsze jest przyjmowana z uśmiechem ;)

 

Tak czy siak – warto wprowadzić Agile we własnej firmie.

Pozdrawiam!