Bardzo rzadko się zdarza, aby pierwotne założenia projektu, zwłaszcza w IT, pozostały w niezmienionej formie w momencie jego zakończenia. Wszystko ulega stopniowym zmianom, ulepszeniom, aktualizacjom i nie warto kurczowo trzymać się specyfikacji, gdy możemy zrobić coś lepiej. Wiele modeli prowadzenia projektu jest jednak na takie dynamicznie pojawiające się zmiany niegotowa. Tutaj właśnie błyszczy jasnym światłem Agile, który jest elastyczny i dynamiczny. Pozwala się dostosować.
W trakcie projektu zmienia się bardzo wiele i z różnych powodów. Zmiany w budżecie, pojawienie się na rynku konkurencyjnego produktu o podobnych możliwościach, czy po prostu zmiana zdania klienta. Poniżej przedstawiam kilka sposobów, w jaki system Agile pomaga radzić sobie z projektami zmieniającymi się w takcie ich realizacji:
1. Zaangażowanie klienta przez cały czas trwania projektu
Tradycyjnie realizowane projekty były tworzone na podstawie specyfikacji przekazanej od klienta. Następnie realizowano np. aplikację. Mogło to trwać nawet miesiącami. Po ukończeniu projektu przedstawiano gotowy produkt klientowi. Wtedy pojawiały się liczne różnice między gotowym programem, a oczekiwaniami klienta. Konieczny był powrót do projektu, często jego gruntowna przebudowa. Mnóstwo kodu idzie do kosza, trzeba wracać do podstaw, czasem lepiej jest pisać program na nowo, niż zmieniać w nim aż tak wiele.
W systemie Agile, po każdym dwutygodniowym sprincie następuje wymiana komunikacji z klientem. Może on szybko poinformować o wszelkich zmianach już na wczesnym etapie. Może on też szybko zobaczyć jak sprawuje się wymyślona przez niego koncepcja. Nawet gdyby doszło do większych zmian i odstępstw od założeń projektu, trzeba napisać od nowa lub zmodyfikować tylko część kodu (np. ostatni sprint), zamiast zaczynać wszystko od nowa. System ten pozwala programistom na podejmowanie odważniejszych i bardziej innowacyjnych projektów, ponieważ dużo szybciej będzie możliwe ich przedstawienie klientowi i zweryfikowanie ewentualnych założeń.
2. Backlog produktu wyznacza priorytety zespołowi projektowemu
„Product backlog” może stanowić spore wyzwanie, aby kontrolować go przez cały projekt. Jednak dobrze zarządzany i stosowany pozawala w łatwy sposób kontrolować priorytety i wykonywanie poszczególnych elementów projektu na czas i we właściwej kolejności. Właściwie wszyscy członkowie zespołu i klient mogą mieć wpływ na backlog. Ostateczny wpływ na wygląd backlogu powinien mieć scrum master. Ważne jednak, że jest to dokument, który intensywnie żyje przez cały czas realizacji projektu.
Przykładowy Product Backlog. Każdy backlog może wyglądać nieco inaczej. Ważne, aby spełniał swoją rolę i pomagał w pracy.
3. Częste spotkania poprawiają komunikację
Naturą Agile są częste krótkie spotkania zespołu. Mogą to być poranne szybkie rozmowy na stojąco lub inna forma krótkiej komunikacji umożliwiającej sprawną wymianę informacji. Wiele zespołów na czas trwania projektu stara się pracować np. w jednym pokoju, aby łatwiej się komunikować. Dzięki temu wszyscy wiedzą nad czym kto pracuje, mogą wspólnie rozwiązywać problemy, a pracownicy o mniejszych kwalifikacjach szybciej uczą się od bardziej doświadczonych kolegów z zespołu. Jeśli w projekcie zachodzi dużo zmian, dużo łatwiej jest je zrealizować zespołowi, który dobrze się komunikuje. Nawet najmniejsze zmiany często dotyczą więcej niż jednego obszaru (np. zmiana jednej funkcji może dotyczyć programisty, testera, grafika i copywritera). Dlatego częste spotkania i aktualizacje są tak ważne.
Spotkania są też sposobnością do wymiany pomysłów, które mogą wzbogacić projekt, czy przyspieszyć jego ukończenie.
Koniec części pierwszej. Następne sposoby w jakie Agile pomaga realizować tego typu projekty przedstawię za około 2 tygodnie.
