Podejście kaskadowe, a agile

Czym właściwie wyróżnia się Agile i dlaczego zdobył taką popularność? Odpowiedź na to pytanie jest złożona. Aby dojść do tego, co sprawia że projekty kończą się sukcesem, zacznijmy od drugiej strony i zadania sobie pytania: dlaczego projekty kończą się porażką (rozumianą jako znaczące przekroczenie budżetu, terminu, czy rezygnację z realizacji)? Od roku 1994 roku, grupa Standish publikuje tzw. „Chaos report”, czyli dokument opisujący zagadnienia związane z zarządzaniem projektami. Jedną z ciekawszych części raportu jest informacja dotycząca tego, co ankietowani wskazują jako przyczyny niepowodzeń w swojej pracy. Czołowe miejsca zajmują tam co roku takie zagadnienia jak: brak komunikacji, źle zdefiniowany zakres prac, nieskuteczne planowanie. Warto zwrócić uwagę, że nie są to problemy związane z technologią. Dotyczą bardziej organizacji pracy. Z tego samego raportu możemy wyczytać, że czynnikami usprawniającymi prace projektowe są: zaangażowanie klienta, wsparcie kierownictwa czy jasno zdefiniowane wymagania.

I właśnie biorąc pod uwagę powyższe spostrzeżenia powstały metody zarządzania oparte o częstą komunikację, bieżące dostosowywanie wymagań i pilnowanie jakości. Zwinność w zarządzaniu pomaga zminimalizować wymienione problemy poprzez wzmocnienie zachowań wymienianych jako pozytywne. Metodyki pracy agile jak Scrum, czy Kanban dają właściwe gotowy zestaw narzędzi do sprawnego zbierania wymagań, priorytetyzowania ich, testowania.

Dla zobrazowania różnicy w podejściach, możemy przyjrzeć się temu, jak wygląda zarządzanie wymaganiami – jest to jeden z aspektów, gdzie agile znacząco rózni się od waterfalla. Opisy są oczywiście mocno uproszczone.

Tradycyjne podejście kaskadowe zakłada zapisanie wszystkich wymagań jeszcze przed rozpoczęciem programowania. Najczęściej dokładne określenie wymagań na tym etapie jest niemożliwe. Niezwykle trudno opisać szczegóły systemu, który jeszcze nie istnieje i nad którym prace jeszcze nie wystartowały. Prowadzi to do produkowania szczegółowej koncepcji biznesowej, którą i tak trzeba często modyfikować już w trakcie prac programistów. Odbiór oprogramowania następuje całościowo – system sprawdzany jest po wytworzeniu całości. Dopiero na tym etapie może więc okazać się, że program odbiega od tego, czego naprawdę potrzebował klient.

Podejście zwinne zakłada z kolei przyrostową metodę prac. Początkowe założenia co do zakresu prac są dość ogólne. Zespół programistów zaczyna pracę nad kilkoma podstawowymi funkcjonalnościami, tak by zamawiający mógł szybko zobaczyć system na żywo, przetestować go i zweryfikować jego zgodność ze swoimi oczekiwaniami. Na kolejnych etapach prac, programiści rozbudowują tę pierwotną wersję systemu regularnie pokazując efekty prac klientom i dostosowując się do ich uwag. Dzięki temu oprogramowanie jest wyprodukowane szybciej, a sam system odpowiada temu, czego faktycznie oczekuje klient. Bieżące sprawdzanie stanu prac i ciągłe dopracowywanie szczegółów eliminuje problemy związane z całościowym odbiorem oprogramowania. Warto też zwrócić uwagę, że takie podejście mocniej angażuje klientów i zaciera granicę między biznesem, a technologią, ponieważ programiści lepiej znają kontekst swojej pracy.

Sposób pracy PSI

Biorąc pod uwagę korzyści podejścia agile, w PSI Polska staramy się do naszych projektów wdrożyć jak najwięcej elementów pracy zwinnej. Poza umową, dla każdego projektu przygotowywany jest Podręcznik Projektu, który szczegółowo ustala sposób pracy. Wspólnie z klientem, uzgadniamy w jaki sposób będziemy się komunikować, jak będzie wyglądał odbiór, kto jest odpowiedzialny za poszczególne obszary. Forma współpracy powina więc być jak najbardziej zbliżona do założeń podejścia zwinnego – częste spotkania, krótkoterminowe planowanie prac, jasno zdefiniowane zadania i priorytety. Taki styl pracy pomaga nam dostarczyć lepszą jakość naszych systemów. Każde wdrożenie jest unikalne, dlatego każdorazowo dokładamy starań, by forma współpracy była jak najkorzystniejsza i dobieramy takie praktyki z różnych metod zarządzania, by sprostać oczekiwaniom klientów.

Agile w prawie zamówień publicznych

Metodyki zwinne do tej pory nie były często wykorzystywane w pracach dla firm z branży przemysłowych, czy transportowych. Przepisy dotyczące zamówień publicznych faktycznie nie zawsze pozwalały na zastosowanie takich metodyk pracy. Zmieniło się to natomiast w zeszłym roku, gdy polska ustawa Prawo zamówień publicznych została dostosowana do Dyrektyw PE i Rady 2014/24 UE i 2014/25/UE. Mechanizmy dopuszczone przez aktualne przepisy to m. in.:
a)    Komunikacja elektroniczna między klientami, a wykonawcami
b)    Elastyczne elementy opisu przedmiotu zamówienia
c)    Nowy tryb udzielania zamówień publicznych – partnerstwo innowacyjne

Dozwolony jest już też podział projektu na tzw. sprinty, elastyczny mechanizm rozliczeń i zmian zakresu prac. Nowe regulacje pozwalają więc na większą swobodę w konstruowaniu umów i czynią cały proces mniej formalnym. Przykładowo, przy częstych zmianach wymagań, wprowadzenie możliwości dokonania korekt zakresu prac w formie elektronicznej, znacznie skraca czas trwania procesu i umożliwia szybszą reakcję na nowe warunki. Zmniejsza się więc ryzyko przekroczenia terminów założonych na realizację projektu.

Wspomniałem tu jedynie o kilku najważniejszych aspektach formalno-prawnych dotyczących agile w zamówieniach publicznych. Pełną analizę możliwości zastosowania metodyk zwinnych można znaleźć pod tym adresem w opinii prawnej sporządzonej dla Centrum Projektów Polska Cyfrowa.

Zmiany w prawie zaistniały dopiero w połowie roku 2016, mamy więc nadzieję, że z czasem coraz większą ilość projektów uda nam się poprowadzić zwinnie.