Agile w projektach IT: jak zarządzać nimi efektywnie z klientem

Agile w projektach IT polega na dostarczaniu oprogramowania w krótkich cyklach, po których klient widzi działający fragment systemu i może zmienić priorytety na kolejny cykl. Dzięki temu błędne założenia wychodzą po kilku tygodniach, a nie po roku. Żeby to działało, potrzebne są trzy rzeczy: aktywny udział klienta, umowa, która dopuszcza zmianę zakresu, i zespół, który naprawdę kończy każdy cykl czymś, co da się pokazać. Poniżej opisuję zasady, najpopularniejsze frameworki i to, jak Agile wygląda we współpracy software house’u z klientem.

Czym jest Agile i czym różni się od Waterfall

Agile to podejście do wytwarzania oprogramowania, które zamiast jednego dużego planu na cały projekt zakłada planowanie i dostarczanie w krótkich iteracjach. W modelu kaskadowym, czyli Waterfall, najpierw powstaje pełna specyfikacja, potem projekt, programowanie, testy i wdrożenie, a klient widzi wynik na końcu.

Źródłem podejścia jest Manifest programowania zwinnego, który stawia wyżej ludzi i interakcje od procesów i narzędzi, działające oprogramowanie od szczegółowej dokumentacji, współpracę z klientem od negocjacji umów oraz reagowanie na zmiany od realizacji założonego planu. Ważne jest zdanie, które często się pomija: elementy po prawej też są wartościowe. Agile nie oznacza braku dokumentacji, umowy ani planu.

Waterfall ma sens, gdy wymagania są stałe i dobrze znane, na przykład przy wdrożeniu wynikającym z przepisów z określonym zakresem. Agile sprawdza się, gdy produkt jest nowy, a firma dopiero uczy się, czego potrzebują użytkownicy.

Scrum, Kanban i XP: który framework wybrać

Agile to zbiór wartości i zasad, a frameworki to konkretne sposoby ich stosowania. W projektach IT najczęściej spotkasz trzy.

• Scrum: praca w sprintach o stałej długości, z planowaniem, codziennym krótkim spotkaniem zespołu, przeglądem wyniku i retrospektywą.
• Kanban: ciągły przepływ zadań, wizualizacja pracy na tablicy i limit zadań w toku. Dobrze pasuje do utrzymania i rozwoju istniejących systemów.
• Extreme Programming (XP): praktyki techniczne, takie jak testy automatyczne, ciągła integracja i programowanie w parach. Często łączy się je ze Scrumem.

Według aktualnej wersji Scrum Guide zespół ma trzy role: Product Ownera, Scrum Mastera i Developers, czyli osoby wytwarzające produkt. Sprinty mają stałą długość, nie dłuższą niż miesiąc, a codzienne spotkanie zespołu trwa 15 minut. W starszych materiałach znajdziesz jeszcze nazwę zespół deweloperski, która z przewodnika zniknęła.

Agile w projektach IT realizowanych z klientem

W projekcie realizowanym przez zewnętrzny zespół Agile działa tylko wtedy, gdy klient bierze w nim udział, a nie czeka na gotowy system. Najważniejsza jest rola Product Ownera: osoby, która zna potrzeby biznesu, ustala priorytety i ma prawo podejmować decyzje.

Gdy Product Owner jest po stronie klienta, musi mieć na projekt czas: kilka godzin w tygodniu na odpowiedzi, przegląd wyników sprintu i planowanie. Gdy tego czasu nie ma, zespół zaczyna zgadywać, a zgadywanie kończy się pracą do wyrzucenia. Dlatego przed startem pytam klientów, kto konkretnie będzie podejmował decyzje i ile czasu może na to poświęcić.

Przegląd wyniku po każdym sprincie to dla klienta najcenniejszy moment. Widzi działający fragment systemu, może go przetestować i zmienić priorytety na kolejny cykl. Warto, żeby na tych spotkaniach były osoby, które będą z systemu korzystać, a nie tylko zarząd.

Agile a wycena i umowa

Największe napięcie w Agile we współpracy z klientem dotyczy pieniędzy. Klient chce znać koszt i termin, a podejście zwinne zakłada, że zakres będzie się zmieniał.

W praktyce stosuje się kilka rozwiązań. Rozliczenie za czas pracy z budżetem na sprint daje największą elastyczność, ale wymaga zaufania i dobrej kontroli priorytetów. Stała cena za dobrze opisany pierwszy etap, a potem rozliczenie za czas, łączy przewidywalność z możliwością zmian. Stała cena za cały projekt prowadzony zwinnie działa tylko wtedy, gdy umowa pozwala wymieniać funkcje o podobnej pracochłonności. Szczegółowe porównanie znajdziesz we wpisie fixed price czy time and materials.

Niezależnie od modelu potrzebny jest opis celów i głównych funkcji na starcie. Agile nie zwalnia z przygotowania dobrej specyfikacji wymagań systemu, tylko zmienia jej szczegółowość: dokładnie opisujemy najbliższe sprinty, a dalsze etapy ogólniej.

Jak wdrożyć Agile w firmie

Wdrożenie Agile to zmiana sposobu pracy i podejmowania decyzji, a nie tylko nowe narzędzie. Najlepiej zacząć od jednego projektu i rozszerzać podejście po zebraniu doświadczeń.

1. Szkolenie zespołu i decydentów: wszyscy muszą rozumieć zasady, także zarząd, który zatwierdza budżety. Jak wybrać szkolenie, opisałem w tekście o tym, kiedy opłacają się szkolenia z zarządzania projektami IT.
2. Projekt pilotażowy: średniej wielkości, z zaangażowanym właścicielem po stronie biznesu.
3. Wsparcie zarządu: zgoda na to, że plan będzie się zmieniał, i na decyzje podejmowane przez Product Ownera.
4. Narzędzia: Jira, Trello lub inna tablica zadań, dobrana do skali projektu.

Najczęstsze problemy przy wdrażaniu Agile

Większość problemów z Agile wynika z przeniesienia nazw bez zmiany sposobu pracy. Sprinty są, ale na końcu nie ma nic do pokazania. Codzienne spotkania są, ale służą raportowaniu przełożonemu.

• Opór przed zmianą: ludzie przyzwyczajeni do szczegółowych planów czują się niepewnie. Pomaga pokazanie efektów pilotażu.
• Brak decyzyjnego Product Ownera: każda decyzja wymaga zebrania zarządu, więc sprint stoi.
• Hierarchiczna struktura: zespół nie może sam zdecydować, jak wykonać zadanie.
• Brak definicji ukończenia: zadanie jest zrobione według programisty, ale nie przetestowane i nie wdrożone.

Kiedy Agile nie jest dobrym wyborem

Agile nie pasuje do każdego projektu i nie warto go stosować tylko dlatego, że tak się dziś mówi. Podejście zwinne słabo sprawdza się tam, gdzie zakres jest z góry przesądzony przez przepisy albo dokumentację przetargową i nie można go zmieniać bez nowej procedury.

Kłopot pojawia się też wtedy, gdy po stronie klienta nikt nie może poświęcić czasu na regularne decyzje, a zarząd oczekuje dokładnego harmonogramu na rok do przodu. W takiej sytuacji uczciwiej jest prowadzić projekt etapami z pełną specyfikacją każdego etapu, a z Agile wziąć tylko pojedyncze praktyki. Jak ustalam takie zasady na starcie projektu, opisuję na stronie o współpracy przy projektach IT.

Dobre praktyki, które działają w każdym projekcie

Kilka praktyk z Agile warto stosować nawet wtedy, gdy projekt prowadzony jest klasycznie. Dają przejrzystość i wczesne ostrzeżenia bez zmiany całej organizacji.

• Krótkie cykle z działającym wynikiem: klient regularnie widzi postęp na systemie, nie na slajdach.
• Retrospektywy: zespół co cykl ustala jedną rzecz do poprawy i sprawdza ją w następnym.
• Priorytety ustalane przez biznes: zespół wie, co jest najważniejsze, i robi to najpierw.
• Wspólna definicja ukończenia: zadanie jest skończone, gdy przeszło testy i może trafić do użytkowników. Kryteria odbioru dobrze ustalić z góry, co opisuję we wpisie o tym, jak przygotować odbiór systemu i testy akceptacyjne.

Jeśli zastanawiasz się, czy Agile w projektach IT sprawdzi się w Twojej firmie, zacznij od jednego pytania: kto po Twojej stronie będzie co tydzień podejmował decyzje o priorytetach i czy ma na to czas. Jeśli taka osoba jest, następnym krokiem jest pilotaż na jednym projekcie z krótkimi cyklami i przeglądem wyniku po każdym z nich.