Walidacja systemów komputerowych to proces występujący w każdej firmie farmaceutycznej lub produkującej wyroby medyczne, która wykorzystuje systemy informatyczne na etapie produkcji, logistyki czy dystrybucji swoich produktów. Tworzenie nowego systemu i jego modyfikacje czy implementacja gotowego oprogramowania wymagają odpowiedniego zarządzania projektem. W projektach informatycznych dominują dwa podejścia do tego typu procesu – tradycyjne i zwinne (agile). Niniejszy artykuł stanowi o różnicach pomiędzy metodykami i ich zaletach z punktu widzenia walidacji.

Główny temat stanowi podejście do prowadzenia projektów obejmujących walidację systemów skomputeryzowanych w przemyśle farmaceutycznym. Ze względu na wymogi serializacji, wiele firm farmaceutycznych czeka wdrażanie całkiem nowego oprogramowania. Projekty prowadzone są najczęściej za pomocą podejścia kaskadowego (Waterfall) lub tradycyjnego, a także podejścia Agile, czyli zwinnego. Jakie są rózńice pomiędzy nimi i w jakich sytuacjach lepiej sprawdzają się omawiane podejścia?

Metodyki tradycyjne, na przykład Prince2 czy PMI, dzielą projekt na poszczególne etapy (analizę, planowanie, realizację, wdrożenie), które są realizowane jeden po drugim, stąd też nazwa „projekty kaskadowe”. Projekt jest realizowany według ścisłego planu, znana jest jego funkcjonalność oraz wymagania i wszystkie obszary są dokładnie określone – czas trwania, mierzalny produkt biznesowy, zasoby, struktura organizacyjna z zakresem obowiązków i ról niezbędnych do zarządzania projektem. Projekt jest dostarczany w całości. Podejście to charakteryzuje się ścisłym następstwem poszczególnych etapów. Jeśli etap poprzedzający nie został zakończony zadowalającym efektem, to następny nie może zostać rozpoczęty. Konieczny jest powrót do poprzedniego etapu i naniesienie zmian dających oczekiwany efekt.

Z kolei w podejściu zwinnym, na przykład Scrum, plan również jest określony, ale wszystko przebiega w sposób elastyczny. Zespół sam się organizuje, przydziela zadania, a projekt jest realizowany małymi etapami. W trakcie realizacji projektu mogą pojawić się nowe potrzeby, za którymi zespół może podążać. Zakres musi być zdefiniowany zarówno w projekcie prowadzonym metodyką zwinną, jak i w projekcie kaskadowym i może być taki sam, ale jeśli w projekcie czy w harmonogramie projektu występuje konieczność wprowadzania zmian, to różnica między metodykami jest bardzo widoczna. W metodykach zwinnych mamy instrumenty, które pozwalają nam łatwo i szybko ten zakres modyfikować. W klasycznym podejściu takie procedury także posiadamy, ale są one czasochłonne i wymagają większego zaangażowania. Warto też dodać, że realizacja projektu podejściem Waterfall wymaga więcej czasu, co zazwyczaj oznacza większe koszty. Jest to związane między innymi z koniecznością powtarzania poszczególnych etapów w wyniku braku efektów lub gdy efekty nie są takie, jak oczekiwano i, co się z tym wiąże, dochodzi do przestojów.

Warto też wspomnieć o metodyce hybrydowej AgilePM, gdzie są mechanizmy kontroli znane z tradycyjnych metodyk, są aspekty projektu, takie jak ryzyka, budżet, czas, jakość, ale paradygmatem jest ciągłe zbieranie i odkrywanie nowych wymagań oraz podążanie za zmianą.

Jak więc te różnice mają się do prowadzenia procesów walidacji w projekcie?

Walidacja jest takim dosyć sztywnym, nazwijmy to, podejściem, które wymaga procedur, instrukcji i dalekie jest od elastyczności, którą pewnie w wielu projektach dobrze byłoby mieć. Można powiedzieć, że jest takim typowym procesem kaskadowym i z naszej perspektywy w Agile właśnie ta ciągła zmienność jest pewnym wyzwaniem, przede wszystkim z punktu widzenia prowadzenia dokumentacji i testów. W przypadku projektów prowadzonych metodyką zwinną istotne i jednocześnie problematyczne jest ustawienie naszych reguł walidacyjnych tak, żeby „nie wypaczyć” tego zwinnego podejścia za bardzo. Czyli żeby wciąż pozostawić tę możliwość elastycznego definiowania czy zmieniania zakresu, a z drugiej strony dopełnić formalności, które są wymagane w procesie walidacyjnym, czyli opracować analizę ryzyka i nadzorować ryzyko w procesie, zaplanować zakres prac walidacyjnych i zakres testów, zdefiniować i opracować wymaganą dokumentację techniczną bez ryzyka, że coś zostało pominięte albo na przykład, że zakres testów był nieodpowiedni.

Należy również pamiętać, że proces walidacji ma tak zwane hard gates, które muszą zostać spełnione przed przejściem do kolejnego etapu. Na przykład dokumentacja specyfikująca (URS, FS, DS) musi zostać opracowana przed rozpoczęciem testów. W przypadku zwinnych metodyk, kiedy funkcjonalności zmieniają się dynamicznie, ma to, chociażby bezpośredni wpływ na dokumentację, a to z kolei przekłada się na testy. Z mojej perspektywy, to cała sztuka w walidacji projektów zwinnych polega właśnie na zbudowaniu takiego podejścia czy modelu walidacji, żeby dopełniając formalności w taki czy inny sposób, nie blokować elastyczności zmian w projekcie.

Jeżeli projekt jest na tyle prosty, że nie da się go rozbić na mniejsze fazy, czyli w nomenklaturze Scrum sprinty, to ciężko mówić o projekcie Agile. Podział projektu na sprinty polega na sukcesywnym dodawaniu funkcjonalności, która ze sprintu na sprint jest bliższa wymaganiom klienta, bo praktycznie na tym to polega. W Waterfall mamy wszystko zaplanowane od a do z (przede wszystkim, jak ma wyglądać produkt końcowy), przechodzimy przez poszczególne etapy produkcyjne i dostarczamy oraz sprawdzamy od razu finalny produkt, a w metodykach zwinnych dostarczamy poszczególne elementy, funkcjonalności, które składają się na całość. Błędne jest myślenie, że w Agile plan jest improwizowany, bo ogólnie każde działanie jest określone i wbrew pozorom w niektórych metodykach zwinnych są również nieprzekraczalne terminy, czyli mamy tak zwany timebox. Każdy, nawet krótki etap pracy, jak iteracja czy sprint, w metodyce Scrum jest na sztywno określony. Zadania są wykonywane precyzyjnie i wszelkie nasze rezultaty są weryfikowane na bieżąco. Na pewno łatwiej weryfikować wykonanie zadań i rezultaty po poszczególnych sprintach, gdyż w przypadku zidentyfikowania błędów w dostarczonych funkcjonalnościach z ostatniego sprintu można ich poprawę wdrożyć po samym zidentyfikowaniu błędu lub zaplanować ich naprawę na najbliższy sprint. Z punktu widzenia na przykład tworzenia oprogramowania jest to bardzo duża zaleta. Z punktu widzenia walidacji to komplikuje całą sytuację.

Czy to oznacza, że w ramach danej iteracji czy sprintu można realizować zadania walidacyjne, które będą realizowane wraz z procesem Agile całego projektu?

To zależy, w jakiej fazie jest projekt. Zdarza się często, że te pierwsze fazy – gdy na przykład przygotowywane jest środowisko, tworzony jest kod backend i konfiguracji – nie wnoszą zbyt wiele do całości i z punktu widzenia walidatora mogą być stracone. Spotkałem się z dwoma podejściami w takiej sytuacji. W pierwszym podejściu walidator jest zaangażowany w projekt od początku i rozpoczyna swoje działania w 2/3, 3/4 sprintu, na przykład sprawdza dokumentację, czy też waliduje kod aplikacji. Jest na bieżąco i przekazuje uwagi, komentarze, co jest źle zrobione z punktu widzenia walidacji. Walidator ma stałą kontrolę nad całym procesem wytwarzania oraz może weryfikować poszczególne etapy czy funkcjonalności. Minimalizowane jest ryzyko, że finalny produkt będzie niezgodny z celami biznesowymi i wymaganiami, a cały proces był prowadzony niezgodnie z przepisami, regulacjami czy dobrą praktyką wytwarzania. Oczywiście są i minusy takiego rozwiązania – często jest tak, że jakaś funkcjonalność, która powstała w czasie sprintów, nie występuje w produkcie finalnym, bo z niej zrezygnowano. Taki scenariusz kłóci się z podejściem walidatora, bo jego rolą jest, zadbanie o to by rozwiązanie było zgodne celami biznesowymi czy specyfikacją. W podejściu drugim walidator wchodzi w projekt w ostatnich jego fazach, załóżmy jak, jest 80% dostarczonej funkcjonalności. Rozpoczyna walidację i pracę z osobą odpowiedzialną za dokumentację, za kod źródłowy, a także otrzymuje dokumenty, które potrzebne są na koniec projektu.

To ostatnie podejście ma oczywiście bardzo duży minus. Jeśli wszystko było prowadzone prawidłowo, nie ma braków w dokumentacji, nie popełniono błędów i nie ma defektów, to proces walidacji przebiega sprawnie. Jeśli jednak pojawiają się komplikacje, braki czy defekty, to walidacja trwa dłużej i ma bezpośredni wpływ na dostarczenie finalnego produktu zwalidowanego. Zdecydowanie lepszym modelem jest zaangażowanie walidatora w projekt już na pierwszych etapach, choć
w mniejszym zakresie.

Kiedy zatem walidator lub zespół walidatorów powinien rozpocząć pracę w przypadku projektu dotyczącego wytwarzania lub wdrożenia oprogramowania w firmie farmaceutycznej?

Im później wejdziemy w projekt, tym gorzej. Najgorszym wariantem jest włączenie walidacji przed samymi testami, bo w praktyce oznacza to najwięcej pracy dla wszystkich. Z jednej strony, żeby projekt walidacyjny wystartował, musi powstać dokument, taki jak analiza ryzyka czy plan walidacji. Nawet jeśli mówimy o podejściu Agile, czy już konkretnie Scrum, nasze zaangażowanie powinno rozpocząć się na samym początku od analizy ryzyka. Walidator powinien mieć wpływ na budowę strategii testów, kiedy są wykonywane, jakie testy są wykonywane, jaka dokumentacja jest tworzona w trakcie trwania projektu, czy jest prowadzona skrupulatnie, jakie są środowiska pracy, jak ma wyglądać implementacja, na jakich środowiskach i wiele więcej. Nawet jeśli gros aktywności walidatora jest przewidziany w fazie testowania i przed implementacją, to nasze zaangażowanie we wczesnych fazach projektu jest pożądane. Wejście do projektu w późnych fazach może spowodować opóźnienia czy szereg dodatkowych prac i kosztów, które będą konieczne, aby projekt spełniał założenia i był zgodny z regulacjami, oczywiście gdy mówimy o konieczności jego walidacji. Jestem pewien, że nie jest dla nikogo tajemnicą, że wprowadzanie poprawek do projektu na jego początku kosztuje najmniej, zarówno w wymiarze czasu i zaangażowania, jak i w wymiarze finansowym.

Włączenie walidacji na samym początku jest kluczowe, bo zespół projektowy powinien wiedzieć, co się dzieje, jakie są oczekiwania. To, że nie ma zakresu ani planu projektu, to nie jest kwestia metodyki zwinnej, to jest kwestia złej organizacji projektu. Przy projektach informatycznych funkcjonuje czasem błędne przekonanie, że jak projekt realizowany jest w podejściu zwinnym, to do pewnych kwestii można podejść swobodniej – dokumentację napiszemy później, plany zrobimy później. To nie
jest prawda, zakres projektu i plan jego realizacji zawsze musi być znany, udokumentowany i zapisany. Dokumentacja też musi być dostarczona. Tak, jak powiedziałem na początku, jedyna różnica jest taka, czy możemy rozbić to na etapy i czy mamy procedury lub funkcje, które pozwalają nam na wprowadzenie tych zmian.

Załóżmy, że realizowany jest projekt w metodyce zwinnej, ale w trakcie jednego z etapów pojawia się defekt albo niezgodność z dokumentacją. Co się wtedy dzieje? Czy sprint lub etap zostaje przerwany, gdy funkcjonalność działa? Czy są przewidziane jakieś działania?

Należy odnieść się tutaj do metodologii Scrum. Sprinty są to etapy najczęściej dwutygodniowe i w ich trakcie są zaplanowane konkretne zadania do wykonania. Po każdym sprincie prezentowane są efekty, opisywane są zadania, które z zaplanowanego sprintu udało się zrealizować, oraz jakie błędy zostały zidentyfikowane (wymagają poprawki). Po prezentacji aktualnego stanu produktu odbywa się kolejne spotkanie z działem biznesu, na którym planowany jest zakres najbliższego sprintu. Na takim spotkaniu można przedyskutować szczegółowe wymagania czy też rozwiać wszelkie wątpliwości, jak dane wymagania mają zostać zrealizowane. Jeśli pojawiają się błędy, to ich naprawienie jest uwzględnione w planie. W projektach prowadzonych metodyką Scrum nie są planowane sprinty od początku do końca projektu. Najprościej mówiąc, projekt zbiorczy jest zbiorem poszczególnych zadań, które muszą być wykonane w trakcie jego trwania, aby produkt końcowy był zgodny z założeniami. Jednak w trakcie trwania projektu często przybywa sprintów, bo pojawiają się błędy, które trzeba rozwiązać lub nowe funkcjonalności. Podczas sprintów powinny być również zaplanowane testy przewidziane w projekcie, aby móc później przygotować dokumentację, zaraportować postępy oraz wykryte błędy i plan ich poprawienia.

Tutaj też wychodzi różnica w podejściu Waterfall i Agile. W metodykach tradycyjnych pojawienie się problemu krytycznego wstrzymuje nam projekt, bo testy robimy na przykład przed wdrożeniem całości, więc do czasu rozwiązania problemu projekt nie może ruszyć z miejsca. W przypadku metodyki zwinnej niekoniecznie oznacza to zastój prac. Jeśli dany sprint bądź iteracja nie ma wpływu na inne etapy czy funkcjonalności (a często nie ma, bo kolejne etapy są dopiero planowane), to jeden zespół może pracować nad rozwiązaniem problemu, a inny realizować już kolejne zadania. Ale o problemach czy błędach wiemy w zasadzie na bieżąco.

Patrząc też z perspektywy walidacji, w przypadku projektów prowadzonych według podejścia Agile należy podejść do tego bardziej elastycznie, ale wciąż w ramach dobrych praktyk wytwarzania. Ogólne wytyczne co do walidacji, czy to w przypadku metodyk tradycyjnych czy też zwinnych, są identyczne. Kluczowe jest dobranie odpowiednich narzędzi umożliwiających prowadzenie procesu walidacji w „zmiennym środowisku”. Można, chociażby zamiast korzystania z tradycyjnych dokumentów, budować dokumenty modułowo albo wprowadzać rewizje pośrednie (nie tylko główne wersje), żeby umożliwić częstszą ich aktualizację. Bo tak naprawdę wszystko sprowadza się do metod dokumentowania i później zatwierdzania dokumentów przed poszczególnymi fazami. Źle zbudowana dokumentacja, nawet w przypadku tradycyjnego podejścia, może uziemić projekt, a zwłaszcza projekt Agile. Poza dokumentami należy się oczywiście przyjrzeć fazie testowania i również w tym przypadku przewidzieć, czy podczas poszczególnych sprintów tylko fragmenty systemu mogą być weryfikowane. Żeby mieć pewność, że cały system działa poprawnie jako zintegrowana całość, można na koniec projektu zaplanować fazę testów regresyjnych albo przekrojowych end-to-end przez cały system. Przy dobrym planowaniu takie testy można wcześniej zautomatyzować, co również przyspieszy cały proces testowania.

Którą metodykę zatem najlepiej wybrać do realizacji projektów z uwzględnieniem walidacji?

Najlepszym rozwiązaniem jest realizacja projektu w metodyce hybrydowej, na przykład AgilePM, czyli główne fazy poprowadzi się tradycyjnie z zachowaniem wszystkich wymagań formalnych z rozbiciem na fazy najniższe, czyli te grupy zadań, które może podzielić na iteracje charakterystyczne dla metodyki Agile.

Przy każdym projekcie bardzo istotna jest dobra organizacja pracy, plan prac i harmonogram oraz przepływ informacji, aby każdy uczestnik projektu wiedział, za co jest odpowiedzialny i znał status projektu. Pozwala to zminimalizować liczbę błędów, które mogą się zdarzyć. Ważna jest też współpraca z zamawiającym i jego bliskie zaangażowanie w projekt. Wymiana informacji między zamawiającym a zespołem realizującym projekt jest wtedy zdecydowanie lepsza i na pewno łatwiej jest dostarczyć projekt w 100% zgodny z oczekiwaniami w krótszym czasie.

Metodyki zwinne nie są lekarstwem na wszystkie bolączki, ale mogą czasami przyśpieszyć projekt. Przed rozpoczęciem projektu należy przeprowadzić jego analizę na podstawie na przykład analizy wymagań, co pozwoli uświadomić sobie, w jaki sposób ten projekt może zostać poprowadzony. Z punktu widzenia procesów walidacji, niezależnie od tego, jaka metodyka zostanie wybrana, ważnym aspektem jest zaangażowanie walidatora od początku w proces, by można było uwzględnić jego uwagi i zalecenie oraz pracę, jaką ma wykonać w całym projekcie. Oszczędzi to wszystkim czasu i zniweluje przestoje, na czym najbardziej zależy wbrew pozorom nie tylko klientowi, ale i wykonawcy.