Agile „magiczną” receptą na wszystko

Ostatnio coraz częściej można spotkać się z hasłem Agile i zwinnym zarządzaniem projektami. Jak zwinne zarządzanie projektami ma się do rzeczywistości i czy naprawdę Agile jest lekiem na wszystkie bolączki projektów?

Miałem okazję uczestniczyć w wielu różnych projektach z zakresu rozwoju systemów bankowych, wytwarzania oprogramowania „szytego na miarę”, wdrożeń systemów IT, optymalizacji procesów, czy organizacji obszarów IT. Każdy z nich różnił się od siebie sposobem zarządzania. Napotykał na różne problemy. W oparciu o te projekty chciałbym przedstawić moje podejście do ich realizacji oparte o osobiste doświadczenia dotyczące wykorzystywania metodyk Agile.

Różnice pomiędzy wodospadem a rwącą rzeką

Wiele projektów w których miałem okazję brać udział – jako pracownik banku, czy zewnętrzny konsultant – miało zazwyczaj klasyczne podejście do realizacji. Był to tzw. model kaskadowy (waterfall). Najpierw następowała faza planowania i analizy, następnie faza projektowania rozwiązania i implementacji aż po fazę testów i wdrożenia, a następnie pielęgnowania wdrożonego rozwiązania. To podejście ma wiele plusów, ale i wiele minusów, które przy długotrwałych projektach potrafią być dość kosztowne. Błędy analizy wykryte dopiero w fazie implementacji lub w fazie testów, albo – niestety – po fazie wdrożenia i w trakcie pielęgnacji systemu, są dużo droższe w naprawie niż błędy wykryte na samym początku prac.

Klasyczny, kaskadowy model zakłada realizację prac następujących po sobie w określonych etapach, bez możliwości powrotu do poprzedniego etapu po jego zakończeniu. Jednak często okazuje się, że nie jest to rozwiązanie najbardziej optymalne i efektywne, szczególnie w takich projektach programistycznych, w których ich zakres nie jest dokładnie znany od samego początku, a terminy realizacji są napięte.

Wodospad ma to do siebie, że regularnie przetacza ogromne ilości wody przez kolejne poziomy powierzchni, na które napotyka. Alternatywą (projektową, nie wynikającą wprost z natury) jest rwąca rzeka, która stara się przedrzeć przez różne szczeliny i wnęki. Woda w takiej rzece płynie z nurtem poziomo, a nie pionowo. Dzięki temu możliwe jest wstrzymanie nurtu lub jego odwrócenie. W przeciwieństwie do wodospadu z którego woda zlatuje bez możliwości odwrotu i zmiany kierunku.

Zwinnie nie oznacza łatwo

Użyta przeze mnie metafora być może nie jest idealna, ale w dość dobry sposób uwypukla różnice pomiędzy klasycznym podejściem do realizacji projektów, a metodykami zwinnymi. Nie oznacza to oczywiście, że metodyki zwinne są jedynym słusznym rozwiązaniem wszystkich naszych problemów i magicznym środkiem na niepowodzenia w nich.

Przede wszystkim należy pamiętać, że metodyki zwinne powstały w ramach wsparcia realizacji projektów programistycznych i takie też (w moim mniemaniu) pozostają w swoich założeniach. Nie oznacza to oczywiście, że metodyki zwinne nie nadają się dorealizacji innego rodzaju projektów, ale projekty programistyczne są ich głównym celem.

Każdego kto brał udział w projekcie wdrożeniowym – gotowego produktu dostosowywanego pod wymagania klienta, a nie wytwarzanego od zera, tzn. szytego na miarę – wie, że skuteczne i pełne wdrożenie metodyki zwinnej graniczy z cudem, o ile dana firma nie opracowała wcześniej własnej metodyki wdrożeniowej opartej o zwinne zarządzanie projektami IT. Jest to związane z tym, że wiele firm nie uwzględnia sztywnego podziału na role, jak np. sugeruje Scrum, o który opieram się w tym artykule. Ponadto często zaniedbywane są daily scrumy, aktualizacja backloga oraz przegląd wykonanych prac (założonych i nadmiarowych).

Podobnie jest po stronie biznesu, szczególnie jeśli jesteśmy z firmy zewnętrznej i rolę Product Ownera powinien obejmować ktoś po stronie klienta. Często to jest już pierwszą barierą uniemożliwiającą skuteczne działanie i wdrożenie. Zdarza się też taka sytuacja, gdy Product Owner został powołany i jest świadomy swojej roli, ale całkowicie nie współgra to ze Scrum Masterem po stronie zespołu wdrożeniowego. Zarówno Scrum Master, jak i Product Owner muszą posiadać pełną i kompletną wiedzę na temat realizowanego wdrożenia, i w nim uczestniczyć w pełnym wymiarze, a nie „z doskoku”, jak to niestety często bywa w korporacjach.

Skuteczne wdrożenie metodyki zwinnej wiąże się z pełnym jej rozumieniem i stosowaniem się do jej podstawowych zasad i reguł. Natomiast bardzo często okazuje się, że członkowie zespołu projektowego są zaangażowani w inne, dodatkowe prace, realizują obowiązki i czynności operacyjne wynikające z ich stanowiska w firmie, a nie roli w projekcie. Dlatego niezwykle istotne jest, aby po stronie klienta była świadomość o konieczności wydzielenia odpowiednich zasobów na czas realizacji projektu. Bardzo często okazuje się to nietrywialnym problemem, który uniemożliwia sprawne zarządzanie projektem w zwinny sposób.

Dostosowanie metodyki do rodzaju projektu

Nawet jeśli skupimy się wyłącznie na projektach IT to nie sposób traktować je wszystkie w ten sam sposób. Czym innym jest projekt mający na celu stworzenie systemu klasy CRM, a czym innym wdrożenie systemu BPM i obiegu dokumentów, integracja systemów kredytowych z systemem centralnym w banku, czy też reorganizacja działu IT u klienta. W związku z tym nie możemy i nie powinniśmy na sztywno uznawać, że każdy z takich projektów można zrealizować zwinnie, i że będzie to najlepsze rozwiązanie z możliwych.

Wbrew pozorom może się okazać, że dużo lepszy od agile będzie wspomniany wcześniej model kaskadowy albo inne klasyczne sposoby zarządzania projektem. Tym bardziej, że czynników decydujących o wyborze metodyki jest wiele. Jednym z nich jest chociażby zakontraktowany sposób płatności za projekt – projekty realizowane zwinnie są raczej rozliczane na zasadzie Time & Material, ponieważ przy Fixed Price istnieje duże prawdopodobieństwo przekroczenia budżetu. Poza tym Time & Material jest „bezpieczniejszy” przy projektach w których zakres nie jest dokładnie określony lub może się zmieniać w czasie. Przykładowo wiemy, że za 7 miesięcy będą konieczne zmiany w systemie wynikające z rekomendacji KNF, ale w chwili obecnej nie jesteśmy w stanie ich uwzględnić, bo nie znamy dokładnych wytycznych tej rekomendacji.

Generalnie musimy mieć na uwadze to, że Agile nie jest złotym środkiem i mimo tego, że coraz częściej się dzisiaj o nim mówi to wciąż należy weryfikować sens jego wykorzystania w projekcie, który będziemy prowadzić.

Hybrydowe podejście do projektów

Z własnych obserwacji i doświadczeń mogę stwierdzić, że dobrze komponuje się wykorzystanie metodyki zwinnej (wspomniany wcześniej Scrum) w połączeniu z PRINCE2. W tej hybrydzie etapy inicjacji i zamknięcia projektu realizowane są zgodnie z wytycznymi PRINCE2, natomiast część „wykonawcza” za pomocą sprintów Scruma. Jest to o tyle wygodne podejście, że często klient nie jest w stanie zaakceptować w pełni założeń metodyk zwinnych i wymaga od nas dokumentacji projektowej i formalnych dokumentów tworzonych w ramach inicjowania projektu oraz jego zamykania.

Etapy analityczne oraz te związane z wytwarzaniem odpowiedniej dokumentacji również możemy „ubrać” w sprinty i wpleść je w harmonogram całego projektu. Cykle te realizowane są wtedy zgodnie z zasadami Scrum, ale ich produktami do odbioru są powstałe dokumenty i zakończone etapy analizy. Na tej podstawie możemy potem przejść do klasycznych sprintów, w których wytwarzane jest oprogramowanie lub wdrażane są kolejne elementy systemu IT. W przypadku gdy klient nie może sobie pozwolić na odbiory pewnych produktów nie posiadających dokumentacji – bo wymagają tego procedury wewnętrzne – takie rozwiązanie jest wygodne i praktyczne, nawet jeśli nieznacznie wydłuża czas realizacji projektu.

Generalnie metodyki zwinne mogą nam wiele ułatwić, ale konieczne jest zrozumienie sensu ich zastosowania przez wszystkie strony realizujące projekt. W przypadku gdy faktyczne oczekiwania są zupełnie inne i niezgodne z zasadami zwinnego zarządzania projektem, warto zastanowić się nad jakąś klasyczną metodyką lub połączeniem metody klasycznej z zasadami Agile.

Michał Pośnik jest Business Process Management Consultant w Domdata AG sp. z o.o.

Na co zwrócić uwagę planując wykorzystanie Agile: • Metodyki zwinne powstały w ramach wsparcia realizacji projektów programistycznych i takie też pozostają w swoich założeniach.
• Nawet jeśli jednak skupimy się wyłącznie na projektach IT to nie sposób traktować je wszystkie w ten sam sposób.
• Skuteczne wdrożenie metodyki zwinnej wiąże się z pełnym jej rozumieniem i stosowaniem się do jej podstawowych zasad i reguł.
• Niezwykle istotne jest, aby po stronie klienta była świadomość o konieczności wydzielenia odpowiednich zasobów na czas realizacji projektu.
• Projekty realizowane zwinnie powinny być raczej rozliczane na zasadzie Time & Material, ponieważ przy Fixed Price istnieje duże prawdopodobieństwo przekroczenia budżetu.