Zasada Pareto w procesie Waterfall z elementami Scrum w procesie oprogramowania działu utrzymania ruchu

Streszczenie

Artykuł porusza tematykę związaną z zarządzaniem ryzykiem i zaufaniem do usług informacyjnych na przykładzie procesu wytworzenia oprogramowania dedykowanego dla dużej organizacji produkcyjnej pracującej wg norm ISO 9001 oraz ISO 14001. Streszcza ponadroczną pracę pięcioosobowego zespołu nad systemem wsparcia działu utrzymania ruchu fabryki zatrudniającej 1500 pracowników jako przykład zastosowania metodyki Waterfall wzbogaconej o elementy Scrum. Konkluzją artykułu jest wyodrębnienie najefektywniejszych praktyk zarządzania w procesie produkcji oprogramowania na wybranym przykładzie. Konkluzja ta w zamierzeniu tworzyć ma podwaliny pod nową, innowacyjną metodykę projektową. Trzon innowacyjności metodyki stanowić ma narzędzie o nazwie Scheduler – kalkulator projektowy w zamierzeniu autora definiujący nową jakość szacowania projektów informatycznych.

Wstęp

Każde działanie zespołu ludzi podlegać powinno planowaniu przed jego podjęciem. Powyższa zasada znajduje szczególne zastosowanie w dziedzinie projektów informatycznych. Rolą kierownika projektu jest odpowiedni dobór szeregu parametrów projektu, łączący przeciwne interesy udziałowców, jakimi są: zespół Klienta (chce osiągnąć maksymalną jakość minimalnym kosztem kontrolując możliwie ściśle przebieg projektu) oraz zespół wytwórców (interesuje go maksymalizacja zysku przy optymalnej ilości pracy). Wraz z zakresem projektu odpowiedzialność kierownika projektu rośnie. Gdy do zaplanowania i realizacji pojawia się aplikacja optymalizująca procesy biznesowe w dużej fabryce, gdzie pracuje ponad 1500 osób łącznie na wszystkich stanowiskach, wesprzeć należy się powszechnie znanymi standardami i praktykami. W opisywanym procesie wytwórczym zastosowałem metodykę Waterfall wzbogaconą o elementami typu Agile. Każdy ze „schodków” został wykorzystany, jednak wewnątrz procesów stosowane były dodatkowe praktyki zaczerpnięte z metodyk lekkich, które miały zmaksymalizować odczucie kontroli nad przebiegiem projektu przez Klienta oraz zwiększyć jego poczucie bezpieczeństwa, co za tym idzie również zaufania do firmy wytwórczej i do samego wyniku jej prac. Z uwagi na sukces ponad 12 miesięcznego projektu w kwietniu 2011, warto prześledzić, które z czynności przyczyniły się do największej produktywności i sukcesu projektu, a które można było pominąć lub sprowadzić na dalszy plan jako mniej produktywne. W podsumowaniu przedstawię koncepcję dodania do procesu nowej praktyki, której nie zastosowałem tym razem dotyczącej algorytmizacji procesu planowania oraz maksymalizacji opłacalności projektu z punktu widzenia udziałowców.

Zasada Pareto w procesie Waterfall + Scrum – kryterium nr 1 podziału procesow składowych

W analizowanym procesie wytwórczym wyodrębnione zostanie 20% kluczowych procesów, które przełożyło się na 80% sukcesu projektu. Na pozostałe 80% zaklasyfikowane zostaną procesy malejąco pod względem ich znaczenia (takie, które przełożyły się w coraz to mniejszym stopniu na sukces projektu, aż do procesów zbędnych w kontekście badanego przypadku). [Tablica 2.1.] Wyciągnięte wnioski posłużą do identyfikacji procesów najefektywniejszych, co w kolejnym etapie badań podłoży podwaliny pod zautomatyzowaną metodę szacowania projektów o roboczej nazwie „Scheduler”.

Metodyka: Waterfall [1] + Agile [2]
Metodyka jest połączeniem metodyk zwinnych rozumianych poprzez zachowanie następujących cech procesu:

1. działające oprogramowanie jest dostarczane etapami,
2. miarą postępu jest osiąganie checkpointów,
3. zmiany w specyfikacji w późniejszych etapach nie mają destrukcyjnego wpływu,
4. bliska, bezpośrednia współpraca pomiędzy klientem a wytwórcą,
5. dążenie do upraszczania procesów,
6. bezpośredni kontakt to najlepsza forma komunikacji w zespole i poza nim,
7. satysfakcja strony klienta osiągnięta przez szybkość wytwarzania,
8. nacisk na aspekty techniczne oraz spójny biznesowo wynik etapu projektowania,
9. adaptacja do zmieniających się wymagań w ramach budżetu na zmiany,

oraz metodyki Waterfall złożonej z klasycznych „schodków” (analiza, projektowanie, implementacja, wdrożenie, testowanie).

Procesy zrealizowane w ramach procesu wytwórczego aplikacji wspierającej eliminację przestojów maszyn produkcyjnych zostały podzielone według dwóch kryteriów. Pierwsze z nich prezentowane jest poniżej.

Kryterium 1 – stopień produktywności przekładającej się bezpośrednio na sukces projektu. Każdemu z procesów przypisano wartość liczbową WP, klasyfikującą proces do odpowiedniego przedziału na skali wpływu na  sukces projektu. WP przypisaną każdemu z procesów wyznaczono wg poniższego przypisania [Rys.1]:

Największe skupienie procesów niezbędnych dla osiągnięcia sukcesu projektu ma miejsce kolejno w: analizie wymagań (S1) - 3, implementacji (S3) - 2, wdrożeniu (S4) - 2 oraz w testowaniu (S5) - 1. Prawidłowość ta wskazuje na spełnienie przez proces założeń procesu Waterfall, w którym najważniejsze dla nieprzekroczenia budżetu i terminu realizacji projektu procesy mają miejsce w początkowych fazach wytwarzania.

Kryterium nr 2 klasyfikacji procesów

Kryterium 2 – przynależność do znanych metodyk: A – proces typowy dla Agile, W – proces typowy dla Waterfall, A+W – proces na pograniczu Agile i Waterfall, P – proces klasyfikowany jako typu prawnego (tworzenie prawnych ram projektu – czas trwania, budżet). Klasyfikacja według kryterium 2 została przedstawiona na rysunku poniżej [Rys. 2.]:

Powyższa klasyfikacja wskazuje na wysoką skuteczność proponowanej metodyki mieszanej, w której przeplatają się procesy charakterystyczne dla Waterfall i metodyk lekkich. Nieodłącznym elementem są także odpowiednio sformułowane wymagania prawno-organizacyjne.

Wnioski - koncepcja wstępna algorytmu Scheduler

Na podstawie wskazanych najefektywniejszych procesów, analizy innych przypadków z literatury branżowej, analizy przypadków należących do doświadczeń pozyskanych z dziedziny biznesu na przecięciu z wiedzą akademicką możliwe będzie utworzenie zbioru atrybutów w formie analogicznej, jak skonstruowane jest to w formularzach szacowania kwoty ubezpieczenia np. od odpowiedzialności cywilnej kierowcy pojazdu samochodowego. Nadanie szeregowi mierzalnych atrybutów (jak np.: termin wykonania, doświadczenie zespołu, zakres projektu, wymagania co do spełnienia określonych standardów przez system i inne) konkretnych lub mieszczących się w odpowiednich przedziałach wartości, dodanie lub ujęcie wybranych kryteriów pozwoli nam wstępnie oszacować projekt bazując w empiryczny sposób na dotychczasowych doświadczeniach. Interfejs zarówno dla klienta jak i wykonawcy (różniący się) w aplikacji Schedule pozwoliłby na sytuację, gdzie klient poruszając dla przykładu „suwakiem terminu” sam zwiększa lub zmniejsza budżet projektu, który zamierza zlecić.

Bibliografia

1. O modelu kaskadowym: Royce, W.W., "Managing the Development of Large Software Systems" (PDF) Artykuł z 1970 roku, w którym W.W. Royce zaproponował pojęcie "modelu kaskadowego".
2. The Accidental Agilists: One Team’s Journey from Waterfall to Agile 978-0-7695-3321-6/08 2008 IEEE DOI 10.1109/Agile.2008.68

Opracowano:
Maciej Pardo
Politechnika Gdańska, Katedra Inżynierii Systemów i Baz Danych

Dodano: 9 kwietnia 2013 Zaktualizowano: 28 marca 2013