Agile, czyli projekty IT o wysokiej jakości i zgodnie z harmonogramem

Z raportu “Chaos Summary” przygotowanego przez Standish Group wynika, ze jedynie 32% prowadzonych projektów informatycznych zakończyło się pełnym sukcesem, tj. zostało wdrożonych z pełną funkcjonalnością, zgodnie z zaplanowanym harmonogramem i mieszcząc się w planowanym budżecie. Natomiast 24% zostało anulowanych lub nie wprowadzono ich do użycia.

Mój rozmówca, Pan Paweł Rogowicz - certyfikowany Scrum Master, przedstawia przyczyny takiej sytuacji. Tłumaczy również, co wnoszą nowoczesne metodyki prowadzenia projektów IT, takie jak Agile oraz dlaczego pozwalają zmaksymalizować ROI i zlikwidować powtarzające się problemy.

MM: Panie Pawle, co ma wspólnego tworzenie oprogramowania z budowaniem mostów?

PR: Tworzenie oprogramowania jest dziedziną stosunkowo młodą, więc procesy i sposób podejścia do budowy systemów informatycznych od początku były wzorowane na innych sprawdzonych metodach, pochodzących z dziedzin takich jak inżynieria budowlana. Przykładowo, budując most kierownik projektu na początku musi dostarczyć dokładne wymagania – m.in. funkcjonalność, wygląd, budżet, itd. Następnie, na ich postawie musi stworzyć odpowiedni projekt techniczny, przeprowadzić obliczenia, stworzyć dokładny plan działania i w momencie, gdy wszystko zostanie zaakceptowane przez inwestora – przystąpić do właściwej budowy.

MM: Podczas właściwych prac budowlanych nie powinno być już oczywiście miejsca na zmiany i potencjalne błędy?

PR: Dokładnie, gdyż koszt związany z cofaniem się w trakcie budowy jest zbyt duży i generuje zbyt duże ryzyko. Przekładając powyższy proces na projekty informatyczne procedura często była podobna – w takim wypadku mówimy o podejściu tradycyjnym do zarządzania projektami IT.

Czytaj dalej poniżej

“(...) to zespół decyduje o sukcesie projektu, nie miejsce” - Wywiad z Kamilem Adamczykiem, CEO Intelclinic tworzącym opaskę ZizZ Tomasz Krela

Świadome inwestowanie polega na chłodnej analizie – wywiad z Marcinem Przasnyskim ze StockWatch.pl Paweł Kozierkiewicz

MM: Jak krok po kroku wygląda tradycyjny proces tworzenie oprogramowania?

Najpierw analityk biznesowy przeprowadza serie rozmów z inwestorem/klientem, celem zdefiniowania wymagań. Spisuje je zgodnie z ustaloną nomenklaturą i wspólnie z klientem dokonuje akceptacji.

Następnie przystępujemy do fazy drugiej projektu – architekci oraz projektanci na podstawie zatwierdzonej specyfikacji wymagań dokonują wyboru odpowiedniej technologii, narzędzi, rysują diagramy, projektują architekturę aplikacji. Wszystko to zostaje dokładnie spisane i również poddane procesowi akceptacji przez klienta.

W tym momencie, zazwyczaj po kilku tygodniach/miesiącach można rozpocząć właściwe prace, czyli zespołowi programistów przekazane zostają wymagania i projekt techniczny z założeniem, że na ich podstawie utworzony zostanie system informatyczny. Programiści przystępują do pracy, wykonują wszystko mniej więcej zgodnie z wytycznymi i z mniejszym lub większym późnieniem.

Po kolejnych kilku miesiącach prac osiągają zamierzony kamień milowy projektu. Jeśli proces został dość dobrze przemyślany, rezultat zostaje pokazany klientowi – gorzej, jeśli rezultat zostaje pokazywany dopiero na samym końcu.

MM: Teraz klient musi już tylko zaakceptować rezultaty?

PR: Niestety, w większości przypadków klient widząc rezultaty stwierdza, że w mniejszej lub większej części to, co zostało wykonane nie jest zgodne z jego wymaganiami i wizją, a przy okazji wpadł na kilka lepszych pomysłów, więc i wymagania trzeba zmienić…

W tym momencie następuje pisanie CR (Change Request) oraz zmianie ulega specyfikacja wymagań i specyfikacja techniczna, oczywiście podlegające procesowi zatwierdzenia, co także trwa trochę czasu. Zespół programistów otrzymuje nowe wymagania oraz nowy projekt techniczny, do których musi przystosować aktualny projekt.

MM: Czy po wprowadzeniu zmian można w końcu sfinalizować projekt?

PR: To zależy. W najlepszym przypadku taka sytuacja wydarzy się tylko raz, w większości jednak proces ten powtórzy się kilkukrotnie, powodując, że pierwotne dokumenty opisujące wymagania oraz projekt techniczny zostaną kompletnie zmienione. W międzyczasie nastąpi również kilka kryzysowych sytuacji na linii klient-wykonawca, ponieważ każda ze stron będzie się starała przeforsować swoje stanowisko.

Podsumowując – okazuje się, że projekt zostaje poważnie opóźniony, produkt zostaje często dostarczony bez pełnej funkcjonalności lub o niskiej jakości. Zostaje on wdrożony, ale przez kolejnych kilka miesięcy lub nawet lat będzie poprawiany. Brzmi znajomo?

MM: Niestety chyba dla większości firm, które zamawiały oprogramowanie tak… Kto jest winny tym opóźnieniom i problemom – firma zamawiająca, czy wykonawca?

PR: W powyższym przypadku często pojawiają się wątpliwości tego typu – kto wykonał swoją pracę nieumiejętnie: czy klient, niedokładnie precyzując wymagania na samym początku, czy może wykonawca, nie tłumacząc dokładnie klientowi co zamierza z tym zrobić. Odpowiedź tak naprawdę leży po środku, ponieważ winien jest przede wszystkim proces, który większość przyjęła za słuszny i jedyny właściwy – poprzez analogię do innych dziedzin.

MM: Czym tak naprawdę różnią się projekty informatyczne od projektów z innych dziedzin?

PR: Wymieniłbym głównie cztery zasadnicze różnice, ale jest jeszcze kilka mniejszych. Po pierwsze jest to brak możliwości zdefiniowania dokładnych wymagań na początku, z racji małej wiedzy, zmieniających się wymagań oraz dochodzących, nowych wymagań. Po drugie, narzędzia i procesy potrzebne przy przeprowadzaniu projektu nie są takie oczywiste i może się okazać, że trzeba będzie je dostosować w trakcie projektu. Może się również okazać, że należy wprowadzić zmiany do etapu, który został już wykonany. W końcu – należy wykonać więcej rozmów pomiędzy klientem a wykonawcą, celem lepszego zrozumienia się.

MM: W Polsce ciągle jeszcze dominuje podejście tradycyjne do zarządzania projektami IT?

PR: Niestety tak. Powyższej sytuacji nie polepsza procedura zamówień publicznych w Polsce, gdzie wymagania sformułowane są zazwyczaj bardzo ogólnie, możliwość ich doprecyzowania jest ograniczona, a zazwyczaj jedynym kryterium wyboru jest cena. Zamawiający z jednej strony cieszy się, że uzyskał wykonawcę najtańszego – z drugiej strony wcale nie wiadomo, czy najlepszego. Proces ten preferuje wykonawców, którzy albo celowo ograniczają swoje koszty lub przedstawiają oferty poniżej własnych kosztów, wychodząc z założenia, że „jakoś to będzie” i może uda się stworzyć taniej. Wszystko to odbija się jednak na jakości tworzonych systemów i rzadko kiedy zamawiający jest zadowolony z tego, co uzyskał.

MM: Domyślam się, że alternatywą dla podejścia tradycyjnego jest Agile, czyli zwinne metodyki prowadzenia projektów IT. Może mi Pan przybliżyć założenia tego podejścia?

PR: W 2001 roku 17 osób wywodzących się ze środowiska tworzenia oprogramowania spotkało się wspólnie i sformułowało tzw. „Manifest Agile” przedstawiający bardzo ogólne zasady jakich należy się trzymać, tworząc oprogramowanie. Zasady te są bazą dla wielu konkretnych metodyk związanych z ruchem Agile. Brzmią one następująco:

1. Programiści i ich harmonijna współpraca jest ważniejsza od procesów i narzędzi
2. Działające oprogramowanie jest ważniejsze od wyczerpującej dokumentacji
3. Faktyczna współpraca z klientem jest ważniejsza od negocjacji zasad kontraktu
4. Reagowanie na zmiany jest ważniejsze od konsekwentnego realizowania planu

Zasady te sformułowano przede wszystkim na podstawie obserwacji procesów zarzadzania wykorzystywanych tradycyjnie i identyfikując najczęściej pojawiające się problemy. Nie są to obserwacje ani wnioski przełomowe, bardziej można określić, że stanowią kolejny etap w ewolucji inżynierii oprogramowania. Organizacja Agile Alliance1 nie narzuca określonych metod i ścisłych praktyk tworzenia oprogramowania, wskazuje jedynie pewne wzorce i praktyki, które okazały się skuteczne oraz grupuje je pod wspólną nazwą Agile.

MM: Która ze zwinnych metodyk jest najpopularniejsza?

PR: Taką metodyką, wykorzystywaną przy prowadzeniu projektów informatycznych jest SCRUM (ang. młyn). Scrum definiuje już konkretne procesy, bazując na zwinnych praktykach. W zespole projektowym, pracującym zgodnie z metodyką Scrum możemy wyróżnić kilka podstawowych funkcji:

Scrum Master - jest to osoba odpowiedzialna za pilnowanie poprawności procesu oraz zarządzaniu tzw. backlog (lista funkcjonalności do wykonania)

Product Owner, właściciel projektu – osoba definiująca funkcjonalności do wykonania, funkcja ta powinna być pełniona przez przedstawiciela klienta

Zespół – zespół realizujący projekt, w założeniu powinien być interdyscyplinarny, z całkowitą wymiennością funkcji pomiędzy jej członkami. Scrum Master jest również członkiem zespołu.

MM: Na początku przedstawił Pan fazy projektu w ujęciu tradycyjnym. Jak więc wygląda cały proces tworzenia oprogramowania z wykorzystaniem metodyk zwinnych?

PR: Zespół dostarcza funkcjonalności w iteracjach zwanych sprintami, będących etapami pracy i trwającymi zazwyczaj 2-4 tygodni. Każdy etap rozpoczyna się szczegółowym planowaniem (w którym powinien uczestniczyć przedstawiciel klienta), kończy się natomiast dostarczeniem klientowi konkretnych funkcjonalności biznesowych. W trakcie trwania sprintu dla wybranych funkcjonalności realizowane są wszystkie fazy związane z tworzeniem projektu informatycznego, czyli analiza, projektowanie, implementacja i testowanie.

MM: Rozumiem. Jeśli byłabym klientem zamawiającym oprogramowanie w Pana firmie, otrzymywałabym konkretną wartość biznesową po każdym sprincie, a nie dopiero na koniec projektu, jak w przypadku tradycyjnego podejścia.

PR: Zdecydowanie tak, ale to nie wszystko. Dzięki takiemu podejściu klient może już na wczesnym etapie prac zauważyć, w którym kierunku rozwija się projekt i reagować na błędy powstające w wyniku prac lub już na etapie specyfikowania wymagań. Wynika to także z jednej z podstawowych zasad zwinnych metodyk – bądź gotowy na zmianę (ang. embrace the change). Dlaczego? Ponieważ zmiany są nieuniknionym elementem projektów informatycznych i powinniśmy być w stanie na nie reagować.

MM: Scrum definiuje praktyki dotyczące sposobu prowadzenia projektu, chciałabym jednak wiedzieć, z jakimi praktykami programistycznymi można go łączyć.

PR: Scrum zasadniczo stosuje się wraz z jednoczesnym wykorzystaniem tzw. XP (eXtreme Programming, z ang. programowanie ekstremalne), które definiuje praktyki programistyczne pozwalające uzyskać wysokiej jakości produkty – wysoka jakość to kolejne założenie Agile. Na XP składają się następujące, istotne elementy:

• Brak projektowania z góry, czyli założenie, że projektowanie powinno zostać odłożone do ostatniego momentu, kiedy jest to możliwe i nie powinno odbywać się wcześniej
• Ciągła modyfikacja architektury – architektura systemu nie powinna być na stałe narzucona, tylko zmieniać się odpowiednio i dostosowywać do zmieniających potrzeb
• Programowanie parami – technika polegająca na tym, że przy jednym komputerze programują dwie osoby, jedna bezpośrednio przy klawiaturze, druga zgłaszając uwagi, co pozwala osiągnąć wyższą jakość
• TDD – Test Driven Development – testy dla modułów powinny być pisane przed implementacją samych modułów

MM: Czy zwinne metodyki przeznaczone są dla każdej firmy?

PR: Zwinne metodyki na przestrzeni ostatnich lat wdrożone zostały w wielu organizacjach, zarówno działających w branży IT, jak i w branżach innych, posiadających jedynie działy IT. Wdrożenia te w większości przypadków nie były bezbolesne, czasami kończyły się porażką i powrotem do tradycyjnych procesów. Doświadczenia te dowiodły jednoznacznie, że nie ma procesów idealnych i przede wszystkim należy stosować to, co działa, a także dostosowywać działania do specyfiki danej organizacji. Dowiodły jednak również, że firmy, które poprawnie wdrożyły metodyki zwinne (np. Scrum) zdecydowanie na tym zyskały.

MM: Jakie korzyści odniosły firmy, które poprawnie wdrożyły zwinne metodyki?

PR: Firmy te potrafiły wskazać następujące korzyści: większą widoczność aktualnego statusu projektu, zmniejszenie biurokratyzacji procesu i jego kosztów – mniej spotkań, mniej dokumentacji, nacisk na bezpośrednią komunikację z klientem, regularną opinię zwrotną od klienta, przewidywalny rytm projektu, mieszalną i zwiększoną produktywność zespołów, interdyscyplinarność i samoorganizację zespołów, łatwość reakcji na zmiany, szybką identyfikację pojawiających się problemów a także łatwość tworzenia przewidywalnych harmonogramów projektu.

Scott W. Ambler każdego roku przeprowadza badania dotyczące stosowania Agile i praktyk z nim związanych. Z badań za 2008 rok można przytoczyć następujące wyniki pokazujące jak zastosowanie Agile wpłynęło na projekty IT:

• 82% respondentów stwierdziło, że osiągnęło wyższą lub dużo wyższą produktywność
• 77% respondentów stwierdziło, że osiągnęło wyższą lub dużo wyższą jakość produktów
• 78% respondentów stwierdziło, że satysfakcja klientów z osiągniętych rezultatów była wyższa lub dużo wyższa
• 37% respondentów stwierdziło, że koszt wytworzenia produktów był niższy, natomiast 23% stwierdziło, że był wyższy
• 78% zespołów pracujących w metodyce Agile stwierdziło, że ich projekty zakończyły się sukcesem

MM: Można więc powiedzieć, że zwinne metodyki są skuteczne i powinny być brane pod uwagę przez organizacje tworzące oprogramowanie?

PR: Jak widać na podstawie przedstawionych wyników metodyki zwinne nie tylko sprawdzają się ale też są zdecydowanie krokiem w odpowiednim kierunku. Są one stosowane i praktykowane w Europie Zachodniej już od kilku lat, w Polsce niestety wciąż są rzadkością, co ma przełożenie na niską jakość powstających u nas systemów informatycznych i na brak zadowolenia klientów.

MM: Jak to wygląda z perspektywy klienta – w jaki sposób ma wybrać firmę IT, która stworzy dla niego oprogramowanie szyte na miarę?

PR: Dokładniej eksplorując polski rynek IT można znaleźć nieliczne spółki informatyczne, które stosują w praktyce Agile i dzięki którym klienci mogą wymiernie skorzystać z zalet zwinnych metodyk. Dlatego w przypadku zapotrzebowania na usługi IT, szczególnie złożonych systemów informatycznych, zachęcam wszystkich zainteresowanych do bardziej wnikliwego poszukiwania odpowiedniego dostawcy – zwracając szczególną uwagę nie tylko na ostateczny koszt usługi, ale na sposób, w jaki zostanie zrealizowana. Jeśli wykonawca zastosuje niewłaściwą metodykę pracy, lub nieskutecznie ją zaimplementuje, realny koszt jaki poniesie klient może się diametralnie różnić od pierwotnie oferowanego.

MM: Dziękuję za interesującą rozmowę

PR: Również dziękuję

Paweł Rogowicz – założyciel i Prezes Zarządu firmy Espeo Software. Przed założeniem firmy pracował kilka lat w Finlandii jako programista i projektant oprogramowania, gdzie miał okazję obserwować i uczestniczyć w procesach wdrażania zwinnych metodyk w dużych firmach działających w sektorze ICT. Obecnie stara się przenosić na polski rynek najlepsze z zaobserwowanych wzorców i praktyk, budując organizację, w której Agile stanowi kulturę pracy.

Foto Woman standin and juggling with statistics via Shutterstock