[SCRUM] Model kaskadowy

Denerwują Cię ciągle zmieniające się wymagania zamawiającego?
Wkurza Cię, że gdy pokażesz kawałek aplikacji odbiorcy – w jego głowie pojawiają się dziesiątki pomysłów na to co można by jeszcze zrobić?
W specyfikacji nie było na ten temat ani słowa?

Wiesz co to oznacza – przebudowanie specyfikacji, architektury, modelu bazy danych, DAL, GUI i pewnie paru innych elementów.
Wiesz, że wiąże się to z przestojem: programiści będą czekać aż architekci zamodelują nową sytuację, później do akcji wejdą bazodanowcy, projektanci, graficy, a na końcu programiści. Wszyscy znów będą narzekać…

Sytuacja przypomina łańcuchu pokarmowym, jedni „zjadają produkty” wytworzone przez poprzedników, tak naprawdę nic nie wiedząc o ich pracy:

Łańcuch pokarmowy

Aby uzdrowić znakomitą część tych problemów wymyślono zwinne metodyki wytwarzania oprogramowania, metodyką najczęściej używaną w IT jest SCRUM.

Model Kaskadowy

Aby dowiedzieć się czym jest SCRUM spróbujmy najpierw… zobaczyć czym nie jest.

Na co dzień, często spotykamy się z klasycznym modelem kaskadowym (waterfall model) .
Zakłada on następujący przepływ zadań:

Model kaskadowy

Zadania muszą być wykonywane w określonej kolejności, najczęstszą praktyką jest podział zespołu (ZESPÓŁ – to ważne pojęcie w SCRUM) na kilka grup, lub (co gorsza) – na skutek braku zasobów – na indywidualnych graczy i przydzielenie każdemu autonomicznych zadań z poszczególnych segmentów.

Zakładamy, że użytkownik bardzo dobrze wie czego chce i jest to w stanie opisać, każda zmiana jest kosztowna i wymaga uruchomienia powyższej procedury kaskadowej od nowa.

Co najczęściej słyszy Menadżer Projektu „to nie moja sprawa„, każdy – odpycha problem i uważa, że błąd leży w „nie jego warstwie„, w konsekwencji nikt nie czuje się odpowiedzialny za produkt, mało komu zależy na dobrej realizacji całości.
Najgorsze jest to, że nikt w 100% nie czuwa nad projektem, wiedza jest rozmyta pomiędzy poszczególnych członków zespołu, którzy się „nie do zastąpienia„.

Biedny menadżer projektu stara się nad wszystkim zapanować, widząc ciągłe odpychanie problemów i wkradającą się dezorganizacje przechodzi w jedyny słuszny, wojskowo-totalitarny styl zarządzania, czyli „rozkaz i kontrola„.

Menadżerowi zaczyna się wydawać, że bez niego (a przede wszystkim bez jego długiego bata) projekt się zawali, musi nad wszystkim czuwać; swoimi dobrymi chęciami burzy  zapał i inicjatywę w zespole.

Co robi zespół – zespół uważa, że nie ma się czym martwić, na pierwszej linii frontu stoi wysunięty PM, wystarczy wykonywać jego polecenia.
Zespół przestają się zbytnio angażować – przestaje wdrażać swoje pomysły i brać odpowiedzialność za pracę – jakby co – wszystkiemu winien jest wódz – przecież on wydał takie rozkazy – nie ważne, że można było to zrobić lepiej!
Brak jest emocjonalnej więzi z produktem.

Z każdym pytaniem zespół zwraca się do menadżera, on ustala wszystko z odbiorcą (zespół jest niegodzien bezpośredniego kontaktu, jeszcze coś przekręci, wcale zresztą mu to nie przeszkadza – po co wychodzić z przytulnego bunkru?) w efekcie tracimy czas na rozdzielanie zadań, pośredni kontakt z klientem, przekazywanie informacji, uzgodnienia, szczegóły…

Koniec końców pasja do pracy w zespole jest wypierana przez zwyczajne klepanie kodu.

W końcu coś zaczyna nie wychodzić, wiadomo już, że terminy nie będą dotrzymane, rozpoczynamy tak zwaną „FAZĘ DRUGĄ„, czyli zbieranie „pisemnych podkładek” powszechnie zwanymi „blachami na dupę„, lub po prostu  „dupochronami”.
Dokumentacja, umowy i długie elaboraty staja się ważniejsze niż kontakt z klientem; klient ogląda nasza aplikację okazjonalnie i zawsze ma uwagi.
Komunikacja w zespole praktycznie nie istnieje, każdy jego członek siedzi w swoim bunkrze, a w razie ostrzału wyciąga swoją – skrzętnie przygotowaną – blachę i zakłada zgodnie z przeznaczeniem…

System ten sprawdza się w wojsku (ale i tak nie wszędzie, napiszę kiedyś wpis na ten temat), w programowaniu, które jest przecież sztuką i wymaga kreatywności – nie specjalnie.
Przejaskrawiłem – fakt, ale jestem pewien, że wielu czytelników zauważa znajome podobieństwo…
Ten, lub zmodyfikowany rysunek zna pewnie każdy interesujący się inżynierią oprogramowania:

hustawka
Współpraca…

Zmiana

W podejściu klasycznym każda zmiana boli, w SCRUM będziemy się starać oswoić zmianę.
SCRUM nie jest złotym środkiem, nowe pole w bazie danych i WCF-ach i tak będzie trzeba dorobić, jednak:

  • nie będziemy w tym sami – pomoże nam zespół,
  • klient będzie dobrze wiedział co się dzieje i dlaczego,
  • nie spowoduje to konieczności poprawek w setkach stron dokumentacji,
  • nie będzie potrzebne tworzenia nowej pisemnej podkładki, klient zrozumie, że wydłuży to projekt, bo sam będzie brał udział w szacowaniu czasu jego ukończenia,
  • ciągła obecność klienta na prawie każdym etapie produkcji programu sprawi, że wcześniej dostrzeże potrzebę zmiany przez co nie będzie ona tak kosztowna (szybsza „korekta kursu” sprawi, że „droga do nadrobienia” będzie krótsza),
  • ogólna atmosfera pracy będzie przyjemniejsza.

Jakie są wady

Według mnie główna wada jest jedna: zamawiający program (nazywany Właścicielem Produktu) musi być gotów do ciągłej współpracy – bardzo wiele od niego zależy.
Jeśli nikogo takiego nie ma po drugiej stronie – będzie trudno, ale czy model kaskadowy sprawdziłby się lepiej..?
Druga istotna kwestia: SCRUM stawia na ciągła komunikację, zalecane jest aby zespół pracował w jednym miejscu – znacznie ułatwi to pracę.
Problem ten można jednak załagodzić poprzez korzystanie z aplikacji do zdalnej komunikacji (komunikatory wideo), oraz „wirtualnych narzędzi” do prowadzenia projektu – jedno z nich (darmowe i dobre) zostanie omówione w jednym z kolejnych wpisów.

W kolejnym artykule dowiemy się co to właściwie jest SCRUM i na jakich założeniach bazuje.

Zapraszam do lektury!

Leave a Reply