Wady i zalety podejścia tradycyjnego i agile w projektach

Jeszcze dwa lata temu, nowością było wykorzystanie zwinnych metodyk na poziomie projektów biznesowych. Dzisiaj 33% CIO wiodących firm deklaruje, że agile w korporacji to jedna z najważniejszych kompetencji IT. Prezentujemy efekt debaty na prowadzonej przez naszą redakcję grupie IT Professionals in Poland na serwisie LinkedIn.

Jarosław Żeliński, właściciel firmy IT-Consulting Analiza Biznesowa
Wiem, co to jest PMI i PRINCE2, bo mam książki z opisami metodyki, a co to takiego ten agile? Mam wrażenie, że agile, podobnie jak Web 2.0, To wszystko, czyli nic, taki buzzword. Złośliwy mój kolega mówi, że jak ktoś czegoś nie potrafi, ale robi coś źle, to nadaje temu nową nazwę, aby nikt nie zauważył. Manifest agile to jeden z najogólniejszych manifestów, jaki widziałem, w zasadzie wszystko tu pasuje, nawet RUP, jeżeli uznać, że zmotywowany pracownik pracuje w pierwszej kolejności dla satysfakcji klienta, a w drugiej dopiero dla papieru.

Adam Jadczak, redaktor naczelny ITwiz
Jarek, czy SCRUM to też buzzword?

Jarosław Żeliński
Zapytam inaczej, jaka wiedza i jak utrwalona zostaje po zakończeniu projektu, nie licząc ewentualnego produktu? SCRUM to uporządkowany proces realizacji, nie precyzuje zakresu projektu, tylko to, jak go realizować, i zawsze pojawia się pytanie: czy przed rozpoczęciem projektu wiemy, co ma powstać?

Adam Jadczak
Tu musiałby się wypowiedzieć praktyk… Znalazłem jednak ciekawe wyjaśnienie podejścia agile: Metody zwinnego zarządzania projektami są tak skonstruowane, że mimo braku pewności, co do dróg osiągnięcia celów projektu, jeden parametr jest cały czas w punkcie skupienia – zarówno kierownictwa projektu, jak i każdego członka zespołu. Tym parametrem jest przepływ dodanej wartości biznesowej dla odbiorcy produktów projektu.

Michał Pośnik, Business Process Management Consultant w Domdata AG
Przede wszystkim agile nie definiuje fazy rozpoczęcia i zamknięcia projektu, więc zgodzę się tu z Jarosławem. Osobiście uważam, że dobrą hybrydą jest łączenie elementów tradycyjnych metodyk zarządzania projektami ze zwinną realizacją prac z wykorzystaniem np. SCRUM.

Jarosław Żeliński
Nadal uważam, że nie wiem, co to agile. Sprint to synonim “krótki okres pracy”, SCRUM to “rodzaj spotkania”, Product Owner to rola w projekcie polegająca na tym, że nikt poza nim nie może zabierać głosu na temat tego, co ma powstać. Nie zmienia to faktu, że opis tego, co ma powstać nie istnieje do końca projektu. Cel projektu – np. dołożymy starań by klient był zadowolony z naszej pracy – nie jest jego produktem, cel będący jedynie budżetem do skonsumowania to nie to samo, co zakres projektu.

W jednym z SIWZ widziałem zapis: projekt zostanie skończony po zrealizowaniu wszystkich zadań lub wyczerpaniu budżetu. Jakikolwiek plan inwestycyjny ma, co najmniej dokładny opis tego, czym jest owa inwestycja. Skoro jest to plan, to znaczy, że opis tego, co chcemy wytworzyć jest dostępny przed projektem, a nie po. Ja, jako pierwszy etap projektu traktuję zdefiniowanie celu i studium wykonywalności. Potem powstaje koncepcja rozwiązania oraz dowód jej słuszności – Proof Of Concept. Teraz jest miejsce na opracowanie etapów, produktów częściowych, ale duży produkt jest dzielony na części mające same z siebie wartość, dzięki temu mogę – w miarę zmian na rynku – decydować o tym, w jakiej kolejności powstaną “Proof Of Conceptmoduły” i czy na pewno powstaną wszystkie, ale od samego początku wiadomo, co ma powstać i łatwo stwierdzić, czy projekt został zrealizowany i w jakim stopniu. Dokumentacja powstaje zawsze przed, ale tylko ta, która czemuś służy na danym etapie, a nie “cała dokumentacja na początku projektu”, bo to bez sensu. Nie wiem, czy to zwinność, czy rozsądek.

Michał, dlatego mogę się zgodzić, że agile i SCRUM to metoda zarządzania realizacją prac, ale nie, że jest to metodyka zarządzania projektem.

Michał Pośnik
Dokładnie o to mi chodziło. Sam agile/SCRUM nie nadaje się do całościowego zarządzania projektem, bo później może okazać się, że bez odpowiedniego uzasadnienia biznesowego – i jego ciągłej weryfikacji – oraz dokumentacji projektowej, wytwarzanej na potrzeby konkretnych etapów, klient nie podpisze odbioru dostarczanych produktów.

Popularność metodyk zwinnych i chęć ich stosowania w projektach wynika z tego, co napisał na samym początku Piotr – klient oczekuje sprawnego i szybkiego wprowadzenia zmian, realizacji wdrożenia. Jednak wydaje mi się, że często błąd wynika z niedoprecyzowanej definicji “zarządzania projektem metodyką zwinną” i niedokładnego rozumienia wykorzystania agile przez samego klienta. Dlatego uważam, że najlepiej sprawdzają się w tym wypadku różne połączenia metodyk i modeli wytwarzania oprogramowania.

Jacek Kuroś, COO w New GO
Wśród świadomego towarzystwa projektowego może być stosowany PRINCE2, PMI, SCRUM, agile i ich kompilacje. Dla mnie i niektórych klientów podejście “agile” to pewna kultura pracy, kultura projektowa związana z realizacją, uwzględniająca permanentne zmiany, czyli “zwinne” zarządzanie zmianą. Co ciekawe, agile zaczyna być dostrzegane nie tylko w IT, ale też w biznesie, jako metoda dostosowania się do zmieniającej się rzeczywistości. Taki nowy paradygmat zarządzania.

Jarosław Żeliński
Jacku, to co piszesz to nie nowe, to stary cukierek o nazwie “systemy adaptacyjne” i znam go z wojska z lat 80. XX wieku. Tylko w wojsku nie ma wstrętu do planowania działań i oceny rezultatów, bo jest to sztabowy obowiązek.

Jacek Kuroś
Jarosław, jak dobrze wiemy, wojsko jest motorem napędowym dla wielu pomysłów, działań, nauki, przemysłu. Wcześniej, czy później istotna część z tego trafia do zastosowań cywilnych.

József Jungbauer, CIO w iForex, Regional Sales Manager w ATOLL Technologies
Podzielam zdanie sceptyczne Jarosława, co do agile, jako metodyki prowadzenia projektów. Od pewnego czasu jednak jej nie neguję. Podczas mojej pracy zawodowej, zdrowy rozsądek pomagał mi – jako kierownikowi projektu – aby zakończyć projekt sukcesem, czyli osiągnąć wartość biznesową – cele biznesowe i zmieścić się w budżecie i terminie. Nie zależało to od tego, jakiej metodyki ode mnie wymagano.

Będąc na kilku warsztatach agile, doszedłem do wniosku, że jest doskonała metoda dla rozwoju niedokładnie określonych produktów – projektów badawczych, poszukiwań nowych rozwiązań. Nie poprawi sytuacji osoby, która tak naprawdę nie wie, czego chce. Nie zastąpi wcześniejszego planowania. Elementy podejścia agile są stosowane w obu firmach, w których pracuję, lecz nigdy nie powiedziałbym, że stosujemy metodyki agile. Dlatego mam wątpliwość, co do stwierdzeń tak dużej ilości kierowników projektów i CIO, że oni używają agile. W KBC na Węgrzech od dwóch lat próbują wprowadzić agile. Nie powiem, aby osiągnęli sukces, choć się starają.

Zbigniew Łukasiak, programista w Opera Software
Wiadomo, że nie ma nic nowego pod słońcem i wszystko, co dzisiaj uważamy za nowości to tylko kombinacja myśli już wcześniejszych. Na pewnym poziomie ogólności agile to nic innego, jak OODA loop i podobne – stare, jak świat – metody. Ale na trochę bardziej szczegółowym poziomie metodyki agile mają różne, konkretne zalecenia i na pewno łatwo można określić, czy się stosuje agile, czy nie.

Przyznam się, że nigdy nie pracowałem, jako programista, w projekcie stosującym metodyki takie, jak waterfall, PRINCE2, czy PMI. Zawsze było to tak, że nie stosowało się żadnego ścisłego planowania, a elementy agile pozwalały przynajmniej zapanować nad zupełnym chaosem.

Trudno mi porównywać te podejścia, ale podam tylko taki przykład. Prototypowanie jest przecież zupełnie nie kontrowersyjnym sposobem projektowania. Dla mnie agile to w dużej mierze taki zespół zaleceń pozwalający na sprawdzanie na prototypach jak najwięcej – zamiast planowania wszystkiego w głowie, czy na papierze.

Jarosław Żeliński
Prototyp rękami programisty będzie zawsze trwał dłużej i będzie bardziej kosztowny niż Proof Of Concept na “desce kreślarskiej”…

Marek Adamczuk, niezależny ekspert ds. SQL Server
Miałem okazję przez blisko rok pracować w zespole programistycznym zgodnie z metodyką SCRUM. I to nie z luźną wariacją na ten temat, ale bardzo konsekwentnie stosowanymi zaleceniami scrum.org.

Efekty: – subiektywnie 3-4 krotny wzrost wydajności zespołu,
– poczucie, że tematy są kończone w krótkim czasie,
– wzrost jakości wytwarzanego produktu, na początku zadania Service Desk zabierał 60% czasu zespołu, na koniec nie więcej niż 20%,
– lepszy kontakt z biznesem – kompletna zmiana retoryki z “nic nie robicie” na rywalizację poszczególnych zleceniodawców o to, co “załapie się” do następnego sprinta,
– duża pewność biznesu, co do terminu otrzymania umówionej funkcjonalności,
– po ok 3 miesiącach zespół nabrał zdolności dokładnego szacowania kolejnych prac.

– konsekwentne trzymanie się timeboxów na poszczególne spotkania (nauczyło to szanować czas),
– aktywny udział biznesu: od groomingu, poprzez konsultacje w czasie realizacji, aż po odbiór,
– konsekwentna weryfikacja przez zespół kryteriów odbioru i Definition of Done,
– obudzenie “ducha zespołu” – poczucia wspólnej odpowiedzialności za “dowiezienie sprinta”,
– świetny Product Owner – człowiek o olbrzymim wyczuciu tego, co jest potrzebne i konsekwentnie stosujący reguły, szczególnie w zakresie odbioru.

Oczywiście, nie od razu było idealnie. Na szczęście w tę metodykę wbudowane jest również samodoskonalenie procesu, co również się działo. A co do narzędzi, to później użyliśmy Atlassiana i bardzo nam pomogła, ale zaczynaliśmy od korkowej tablicy i zadań zapisanych ręcznie na kartkach.

Jarosław Żeliński
A jakie projekty to były?

Marek Adamczuk
Zespół rozwijał system ERP na potrzeby dużego sklepu internetowego i integrował go z innymi produktami używanymi wewnętrznie oraz systemami partnerów biznesowych.

Jarosław Żeliński
Co zawierał harmonogram?

Marek Adamczuk
Co przez to rozumiesz? Funkcjonalności biznesowe, które realizowaliśmy? Jeśli tak, to niestety wiąże mnie umowa o zachowaniu poufności. Niezależnie od tego, pojęcie harmonogramu jest obce SCRUM. Jest rejestr produktu – backlog, który jest priorytetyzowany przez Product Ownera oraz rejestr sprintu, czyli gorący szczyt rejestru produktu, który zespół przyjął na planowaniu do realizacji w najbliższym sprincie. Na koniec sprintu nieodebrane zadania – o ile są – trafiają z powrotem do rejestru produktu, ten jest ponownie priorytetyzowany przez Product Ownera i przedstawiany do realizacji zespołowi.

Jarosław Żeliński
Mam odpowiedź, “pojęcie harmonogramu jest obce SCRUM”, czyli w zasadzie nie istnieje pojęcie odpowiedzialności za nic poza samym “braniem się za robotę”…

Marek Adamczuk
To nieprawda. Oczywiście, że w agile odpowiedzialność istnieje. Zespół przyjmując Sprint Backlog do realizacji zobowiązuje się do dostarczenia działającego produktu na koniec sprintu. Product Owner poprzez priorytetyzację Product Backlogu bierze odpowiedzialność za wytworzenie możliwie najbardziej wartościowego biznesowo inkrementu produktu w kolejnych sprintach. Product Owner i interesariusze w czasie review biorą odpowiedzialność za odebranie lub nie poszczególnych zadań. Zadania odebrane są gotowe do wdrożenia na produkcję i natychmiast zaczynają przynosić im korzyść biznesową. Wybacz, ale nie widzę bezpośredniej, wzajemnie jednoznacznej relacji pomiędzy harmonogramem i odpowiedzialnością.

Jarosław Żeliński
Mnie stale nurtuje to, że biznes ma wymaganie biznesowe w rodzaju “konkretne funkcjonalności mają być dostępne w konkretnym terminie” i po raz kolejny słyszę, że “staramy się” a mi chodzi o to, że mam konkretny zakres i konkretny termin. W biznesie to albo nowa księgowość działa z początkiem roku obrachunkowego albo nie, tu nie ma “troszkę”. Jak tu mam rozumieć “najbardziej wartościowy biznesowo inkrement”? Mam zakres projektu i termin, i albo ten zakres jest zrealizowany, albo nie. W przeciwnym wypadku jest to, co ma teraz jeden mój potencjalny klient – “obecna firma wdrożeniowa wylatuje, bo nie udało się wdrożyć w terminie systemu zamówień i sprzedaży, tym razem chcemy jednak opracować projekt całości, wybrać dostawce i podpisać umowę fixed-price”. W tej firmie słowo agile jest słowem zakazanym i zrozummy tych ludzi.

Piotr Wojciechowski, koordynator portfolio projektów IT, TAURON Polska Energia
Ponieważ wg zasad to dwa podmioty muszą być agilowe – dostawca i zamawiający. Co do tego, co Jarku piszesz, można pracować agilowo na produktach i terminach. Musiałbym długo pisać jak. W skrócie, produkty traktujesz jak backlog i określasz, kiedy kończy się projekt. Całą resztę robimy zwinnie.

Zbigniew Łukasiak
Skoro już słowo bitwa zostało użyte – to ja proponuję taką analogię – artyleria ma za zadanie zniszczyć określone stanowisko wroga. Artylerzyści mogą obliczyć tor lotu itp., ale nikt nie wymaga od nich, że zagwarantują, iż za pierwszą, czy drugą salwą zniszczą cel. Oni strzelają, obserwator informuje, czy za daleko, czy za blisko i poprawiają. To jest właśnie OODA Loop. Standardowa procedura. Z tym braniem odpowiedzialności to jest często tak, że marketing oczywiście podpisuje papiery, że coś będzie skończone – robi się szczegółowe plany, ale wychodzi jak zwykle.

József Jungbauer
Zbigniew, bardzo mi się podoba przykład. Wyjaśnia dosyć dobrze istotę agile. Jednakże rozwijanie produktu lub zmiany funkcjonalności, czy nowej funkcji nie kończy się na zniszczeniu wroga. W twoim przykładzie w końcu udało się trafić w cel. Jednakże istnieje wiele innych celów oprócz “trafienia” nowej funkcji, produktu. Opis funkcjonalny jest ważnym elementem, lecz niewystarczającym. Przykładowo, koszt utrzymania, operacji i eksploatacji rozwiązania, bezpieczeństwo rozwiązania, dostępność, wiarygodność, niezawodność itp. Większość z tych wymagań “jakościowych” można zrealizować bez metody agile i przeważnie robi się to o wiele bezpieczniej standardowymi metodami – na czas, w ramach przewidzianego kosztu i według standardów korporacji.

Marek Adamczuk
Jarosław, problem polega na tym, że jeśli zakres jest ogromny – np. na rok roboty – to stawiam dolary przeciw orzechom, że zanim zostanie zaimplementowany, biznesowi zmieni się świat i wyobrażenia. Wobec tego albo jest on nie do utrzymania, albo dostarczymy coś, z czego biznes nie będzie zadowolony. I w tym miejscu, w “normalnym projekcie” zaczyna się chocholi taniec dostawcy z zamawiającym polegający na udowadnianiu, co jest nową funkcjonalnością, a co mieści się w projekcie. Angażujemy do tego armię analityków i Project Managerów, a często i programistów oraz wdrażających, powodując gigantyczne koszty. Agile proponuje coś innego – znajdźmy najważniejsze funkcjonalności, zróbmy je najpierw, przekonajmy się, czy jesteśmy w stanie z tym ruszyć. Jeśli tak, to ruszmy. Jeśli nie, znajdźmy kolejne najważniejsze brakujące funkcjonalności w już funkcjonalnym produkcie i te zróbmy najpierw. Gdy już ruszymy, jeszcze lepiej się przekonamy, jaka zmiana w produkcie da nam największą korzyść, czyli jak wygenerować najkorzystniejszy biznesowo inkrement produktu. Potem, w kolejnych inkrementach, dorobimy resztę.

Całej dyskusji nie byliśmy w stanie opublikować, bo było to ponad 90 komentarzy. Zapraszamy jednak na grupę IT Professionals in Poland na LinkedIn.