Dlaczego Agile?

W Software House Intellect działamy w modelu zwinnym – czyli Agile. Co jednak dokładnie to oznacza? W dzisiejszym artykule nasz CEO – Marcin Szczurek – wyjaśnia, co oznacza dla nas zwinność i dlaczego realizujemy projekty w duchu Agile.

Co oznacza „zwinna realizacja projektów”?

Bycie zwinnym to gotowość na dostarczanie tego, czego chce klient dokładnie wtedy, kiedy tego potrzebuje.

 

Praca zwinna zakłada dostarczanie klientowi wartości biznesowej. To reagowanie na zmiany i adaptacja do nich, by wytwarzać wartościowe i konkurencyjne rozwiązania tu i teraz. Zwinność to sposób pracy zespołowej, w której znając wiele sposobów na osiągnięcie celu wybieramy optymalny. Zamiast pracować w sposób kaskadowy, przyjmujemy zmieniające się wymagania, dostarczamy rzeczy w możliwie najkrótszym czasie, uczymy się jak i co musimy budować dalej w oparciu o wiedzę na temat tego, co i jak już dostarczyliśmy na rynek.

Cechy Agile

Najbardziej charakterystycznymi cechami Agile są:

• Wytwarzanie produktu w krótkich okresach czasu (iteracjach)
• Ścisła i partnerska współpraca wykonawcy z zamawiającym, oparta na stałej i bieżącej komunikacji
• Realizowanie projektu przez wykwalifikowany, komplementarny, zdyscyplinowany, zaangażowany i umocowany prawnie zespół (zarówno po stronie zamawiającego jak i wykonawcy)
• Otwartość na zmiany, korekty zakresu prac, budżetu i harmonogramu w możliwie prosty sposób na możliwie najwcześniejszym etapie
• Inspekcja pracy, wnioskowanie i usprawnianie

Skąd wziął się Agile i jego Manifest?

W Lutym 2001 roku, w Snowbird w stanie Utah (USA), doszło do spotkania, siedemnastu czołowych reprezentantów nowych metodyk tworzenia oprogramowania. Efektem spotkania było powstanie Manifestu Zwinnego Wytwarzania Oprogramowania.

Agile jako pojęcie, opisuje dwa aspekty:

• Jako sposób myślenia (tzw. mindset) o zarządzaniu złożonym przedsięwzięciami, charakteryzujący się następującymi cechami:
  • partnerska współpraca stron, jak najbardziej ściśle;
  • iteracyjny i przyrostowy sposób wytwarzania
  • otwartość na zmiany poprzez adaptację do aktualnie zmieniających się okoliczności
• Jako termin opisujący podejścia do wytwarzania oprogramowania (np. Scrum, Extreme Programming), których wspólnym mianownikiem jest zachowanie wartości Manifestu Agile

Powodem ogłoszenia Manifestu Agile była znacząca i wciąż rosnąca liczba nieudanych projektów realizowanych w modelu kaskadowym (Waterfall). Głównym czynnikiem słabego performowania modelu kaskadowego jest koncentrowanie się na realizacji projektu w kształcie, w jakim został on opisany na pierwszym etapie w dokumencie projektowym lub specyfikacji. Realizacja przeprowadzana jest w następujących po sobie, długich etapach uniemożliwiających lub utrudniających bieżącą weryfikację dostarczanych rezultatów. Zamrożenie specyfikacji i zakresu prac wpływa znacząco na rezultat końcowy projektu. W efekcie praca w modelu kaskadowym jest realizacją założonego planu, zamiast dostarczenie wartości biznesowych i satysfakcji zamawiającego.

Głównymi bolączkami metody kaskadowej jest:

1. od planu do realizacji mija znaczący czas, co wpływa na dezaktualizację pierwotnych założeń, które nie przystają do aktualnych okoliczności
2. współpraca pomiędzy zamawiającym i wykonawcą jest znikoma (pracujemy według specyfikacji i ustalonego planu)
3. potrzeba zmian identyfikowana jest na etapie testów funkcjonalnych na końcu każdego etapu (lub – co gorsza – na etapie odbioru projektu), kiedy czas i budżet został znacząco wykorzystany.

Stwierdzenia te nasuwają wniosek, że realizacja projektów w metodzie kaskadowej naraża zleceniodawcę na wysokie ryzyko porażki projektu w związku z:

1. brakiem możliwości lub z istotnymi problemami w dokonaniu zmian w zakresie projektu
2. brakiem wystarczającej komunikacji i możliwości interpretacji elementów zakresu (założenie posiadanie planu/specyfikacji jako wystarczającego kryterium do wytworzenia)
3. dezaktualizacją założeń wstępnych, które spełnia dostarczony produkt, względem potrzeb zamawiającego, albo stanu zastanego w momencie zakończenia projektu.

Niesławnym, sztandarowym przykładem porażki projektu prowadzonego kaskadowo, jest historia informatyzacji brytyjskiej służby zdrowia – który pochłonął 12 mld funtów, trwał 10 lat – a w jego efekcie nie dostarczono żadnego rezultatu przydatnego dla zamawiającego.

Przykładem, gdzie Agile uratował przedsięwzięcie jest projekt Sentinel prowadzony przez FBI – polegający na wdrożeniu systemu do obiegu dokumentów. Początkowo realizowano go kaskadowo i mimo wydania 500 mln USD nie osiągnięto zamierzonych efektów. Całe przedsięwzięcie uratowało zastosowanie metodyk zwinnych – w krótkim czasie doprowadziło ono do dostarczenia działającego, w pełni funkcjonalnego systemu.

Czy Agile to zawsze najlepszy wybór?

Głównym czynnikiem, który decyduje o tym, czy projekt możemy przeprowadzić zgodnie z duchem Agile nie jest to, jak bardzo precyzyjnie mamy określony zakres prac, lecz czy zakres prac może być w trakcie projektu modyfikowany i czy w umowie są zawarte potrzebne do tego mechanizmy.

Warto również pamiętać o tym, że Agile nie jest rozwiązaniem uniwersalnym, dobrym dla każdego projektu. Agile się nie sprawdzi i nie przyniesie oczekiwanych rezultatów, jeśli zakres projektu nie jest możliwy do rozbicia na mniejsze elementy (które później iteracyjnie i przyrostowo będą składane w cały produkt) lub nie jest możliwe operacyjne zaangażowanie Klienta w pracę nad projektem. W pierwszym przypadku najprawdopodobniej musimy podejść kaskadowo do realizacji. W drugim przypadku rozwiązaniem na brak zaangażowania Klienta może być powołanie po stronie zleceniobiorcy (Intellectu) tzw. Proxy Product Ownera, który będzie w imieniu Klienta prowadził projekt. Różnica pomiędzy Menedżerem Projektu a Proxy Product Ownerem jest diametralna. W odróżnieniu od PM’a, PPO posiada umocowanie prawne od zamawiającego do zarządzania zakresem prac i kształtem projektu. De facto jest wysłannikiem zamawiającego. PPO i zamawiający w tej sytuacji muszą współpracować ściśle, by wizja produktu przekazana do PPO była tożsama z wizją Klienta, a decyzje, które podejmuje PPO odzwierciedlały potrzeby i wartości biznesowe, które chce uzyskać Klient.

Czy podejście Agile możemy zastosować w polskim sektorze publicznym?

Przepisy ustawy z dnia 29 kwietnia 2004 r. Prawo zamówień publicznych (Dz. U. z 2015 r. poz. 2164 z późn. zm.), pozwalają na realizację w sektorze publicznym projektów w modelu Agile. Jest to możliwe przede wszystkim dzięki nowelizacji Prawa zamówień publicznych, jaka miała miejsce na podstawie ustawy z dnia 22 czerwca 2016 r. o zmianie ustawy Prawo zamówień publicznych oraz niektórych innych ustaw (Dz. U. z 2016 r. poz. 1020). Przywołana nowelizacja wprowadziła szereg instrumentów pozwalających na stosowanie zasad metodyk zwinnych na potrzeby realizacji projektów w sektorze publicznym.

Agile vs Waterfall

Według The Standish Group model Agile uznawany jest za główny czynnik sukcesów projektów informatycznych. Grupa ta prowadzi statystyki, które potwierdzają tę tezę. Poniżej porównanie metody kaskadowej z modelem Agile w okresie 2011-2015.

Zgodnie z badaniami zebranymi w ramach Chaos Report 2015, wśród przedsięwzięć IT, w założonym budżecie i czasie i w zaplanowanym z góry zakresie przedmiotowym, udało się̨ ukończyć jedynie 11% projektów prowadzonych kaskadowo. 60% z nich udało się̨ dokończyć, ale po napotkaniu istotnych trudności (dotyczących głownie zakresu, budżetu lub harmonogramu). Aż 29% przedsięwzięć skończyło się̨ zupełnym fiaskiem (nie udało się̨ ukończyć projektu w jakimkolwiek stopniu).

Scrum

Scrum to framework (nie jest to metodologia ani metodyka), zestaw podstawowych zasad, ról czy spotkań, tworzących ramy/szkielet, w obrębie których każdy zespół samodzielnie decyduje, jak chce pracować.

Najważniejsze reguły Scruma to:

Przejrzystość + Inspekcja + Adaptacja

To filary, które mają zapewnić poprawne działania Scruma w duchu Agile, i powinny być stosowane cały czas, na każdym kroku pracy Scrumem.

Przejrzystość zapewnia Zespołowi Scrumowemu i wszystkim w organizacji dostęp do całości prac i takie samo rozumienie każdego elementu Scruma. Dzięki temu nie ma niejasności i nieporozumień. Przykładem może być udostępnienie tablicy z zadaniami i aktualnym postępem prac Klientowi, który może na bieżąco obserwować i decydować o realizacji.

Inspekcja pozwala na bieżące monitorowanie i weryfikowanie przedmiotu pracy i sposobu pracy Zespołu.

Adaptacja powinna być wynikiem Inspekcji i prowadzić do niezbędnych zmian naprowadzających Zespół na właściwy tor pracy.

„Scrum to metoda organizacji pracy zespołu, który pracuje nad rozwojem produktu. Praca w Scrumie odbywa się w krótkich iteracjach, zwanych „sprintami”. Każdy sprint trwa nie dłużej niż 30 dni kalendarzowych. W kolejnych sprintach powstają gotowe przyrosty produktu. Zespół sam organizuje swoją pracę w sprincie. Każdy sprint rozpoczyna się od planowania, podczas którego ustalana jest lista najbardziej wartościowych rzeczy do zrobienia. W trakcie sprintu, zespół codziennie spotyka się, żeby przygotować plan działań na najbliższe dwadzieścia cztery godziny pracy. Pod koniec sprintu odbywa się wspólny przegląd produktu. Sprint kończy retrospektywa, w trakcie której zespół analizuje swój dotychczasowy sposób pracy oraz planuje usprawnienia.” – Mariusz Chrapko

Kiedy możemy stosować podejście zwinne?

Wszędzie tam, gdzie zmienny jest zakres prac.