Wdrażaj i testuj

Na czym polega model V ?  

Nie wiem czy gdzieś wcześniej o tym pisałam, ale jestem słuchaczką na studiach „ Analityk, profesjonalista na styku IT i biznesu” gdzie uczę się o swoim wymarzonym zawodzie w super wyidealizowanym środowisku akademickim😉

 W programie przewidziany został przedmiot o wdzięcznej nazwie „Role Analityka” prowadzone przez pana Jerzego Leyka (cudowny człowiek, od którego czerpie mnóstwo inspiracji). To właśnie on ciągle nam kładzie do głowy, że te wszystkie BPMNy, UMLe to jest pikuś w porównaniu do zarządzania ludźmi i próby budowania z nim poprawnych relacji, ale dziś nie o tym 😉

Na dzisiejszym wykładzie omawialiśmy planowanie podejścia analizy biznesowej z wykorzystaniem „metodyk ciężkich”, ja wcześniej spotkałam się z nazwą „metodyki tradycyjne”, ale te „ciężkie” dużo bardziej do mnie przemawiają 😉

Czym, że jest ta „ciężka metodyka” ?

A no niczym innym jak dobrze wszystkim znany wodospad, watterfall, kaskada czy jak tam chcecie ją sobie nazwać. 😉

Nastawiona jest głównie na planowanie, dokładne przewidywanie kolejnych kroków każdego przedsięwzięcia, opracowywanie poszczególnych iteracji z uwzględnieniem szczegółowego harmonogramu, zasobów i kosztów itd., itp. Takie podejście jest bliskie ludziom kultury „pogreckiej”. Planowanie jest wpisane w ludzką naturę. Tylko otworzymy jedno oko i już zaczynamy planować, pójdziemy pod prysznic, ubierzemy się, zjemy śniadanie, wypijemy kawę, łykniemy magnez, bo przecież kawa wypłukała to i owo, później wskoczymy do auta/ pociągu/autobusu/tramwaju dotrzemy do pracy, posiedzimy 8h, wyjdziemy, wsiądziemy w auto/pociąg/autobus/tramwaj, zjemy obiadokolacje, przebierzemy się, umyjemy, pójdziemy spać, ale zanim się położymy, to zaplanujemy sobie kolejny dzień i tak w kółko. Taką mamy naturę i dlatego ten model tak dobrze wpisywał się w potrzeby organizacji i zespołów.

Tylko z tym wodospadem jest taki jeden mały, tyci problem. Sprawdzenie poprawności działania funkcjonalności odbywa się dłuuuuuuuuuuugo po rozpoczęciu projektu, no bo startujemy od wymagań, zbieramy je, analizujemy, projektujemy system, implementujemy i dopiero po implementacji odbywają się testy. I jeśli wpadnie jakiś gruby błąd -a to, że wpadnie jest prawie pewne – (staram się nie używać twardych kwantyfikatorów, takich jak zawsze, na pewno, nigdy, ponieważ obarczone są sporą odpowiedzialnością, dlatego też wykorzystałam przedrostek prawie, ale nie czuje się z tym komfortowo, bo w moich projektach ZAWSZE coś się wysypało w trakcie wrzucania dużych „klocków” na proda 😉) to narazimy siebie i zespół na szereg nikomu niepotrzebnych nerwów.

Dlatego postanowiono wprowadzić model V ( uff, wreszcie do niego dotarłam)

Model V, czym jest ?

A no wg Inżynierii Wymagań jest rozwinięciem modelu kaskadowego. Rozwinięcie polega na rozróżnieniu kroków związanych z wytwarzaniem i weryfikacją, oraz wprowadzeniu zasady, że KAŻDY krok wdrożeniowy ma swój odpowiednik w kroku weryfikacji. Model V, lub ( Metodyka V ) nie jest realizowana liniowo w dół, jak to miało miejsce w Kaskadzie. Jego przebieg, sekwencja, droga wygląda jak litera V (stąd też ta jakże porywająca nazwa).

A no i V- to pierwsza litera słowa Victoria…. Tak dosadnego przesłania nie można lekceważyć! 😊

Jak interpretować powyższy diagram?
Już spieszę z wyjaśnieniami :)

Lewa gałąź pokazuje etap projektowania systemu, podobnie jak w kaskadzie startujemy od wymagań, przechodzimy przez analizę, architekturę, modelujemy poszczególne moduły i implementujemy. Normalnie w modeli kaskadowym zeszlibyśmy liniowo w dół pokazując testy modułów (komponentów), architektury, weryfikacje poprawności analizy i na koniec potwierdzilibyśmy wszystko testami akceptacyjnymi. Niemniej model V prezentuje inne podejście. Faza weryfikacji "unosi" diagram liniowo w górę, tak, aby poszczególne "klocki" testów znajdowały się na jednym poziomie z odpowiadającymi im elementami z projektowania. To ma sugerować, że każdy fragment lewej "łapki" naszego V ma swój odpowiednik na prawej "łapce". Te przejścia oczywiście działają w obie strony (co pokazują groty na obu końcach strzałek).
Np.: po zaimplementowaniu modułu systemu, sprawdzamy ten kawałek, prosimy testerów o wsparcie, oni niczym snajperzy wyszukują wszystko to co może się wywalić, wracają do developerów co należy poprawić, developerzy poprawiają, wrzucają poprawki, proszą testerów o weryfikację, tester sprawdza itd. Taki sam proces odbywa się na każdym poziomie diagramu V.

No i trzeba przyznać, że jest to dużo sensowniejsze podejście do wdrażania nowych systemów. A dlaczego ? 😉 bo jesteśmy w stanie dużo wcześniej wykryć jakieś większe „babole” przez co nie narażamy projektu na spektakularną klęskę.  Oczywiście, jak wszystko, model V nie jest idealny, wymaga przygotowania dużo większej ilości testów, wymusza wcześniejsze rozpoczęcie weryfikacji rozwiązania, za tym idą kolejne kwity, papiery przeglądy, ale wg mnie gra jest warta świeczki. Bo lepiej jest poprawić 5 małych błędów niż jednego, wielkiego faulta😊. Można śmiało uznać go za jeden z najlepszych modeli wspierających zarówno procesy opracowywania wymagań jak i zarządzania wymaganiami dla dobrze zdefiniowanych i stabilnych obszarów.