{"id":9121,"date":"2021-08-11T13:45:00","date_gmt":"2021-08-11T13:45:00","guid":{"rendered":"https:\/\/econsulting.co\/?post_type=blog&p=9121"},"modified":"2022-06-29T22:32:18","modified_gmt":"2022-06-29T22:32:18","slug":"zarzadzanie-projektem-it-wyzwanie-dla-walidacji","status":"publish","type":"blog","link":"https:\/\/econsulting.co\/pl\/blog\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\/","title":{"rendered":"Zarz\u0105dzanie projektem IT \u2013 wyzwanie dla walidacji"},"content":{"rendered":"\n

Walidacja system\u00f3w komputerowych to proces wyst\u0119puj\u0105cy w ka\u017cdej firmie farmaceutycznej lub produkuj\u0105cej wyroby medyczne, kt\u00f3ra wykorzystuje systemy informatyczne na etapie produkcji, logistyki czy dystrybucji swoich produkt\u00f3w. Tworzenie nowego systemu i jego modyfikacje czy implementacja gotowego oprogramowania wymagaj\u0105 odpowiedniego zarz\u0105dzania projektem. W projektach informatycznych dominuj\u0105 dwa podej\u015bcia do tego typu procesu \u2013 tradycyjne i zwinne (agile). Niniejszy artyku\u0142 stanowi o r\u00f3\u017cnicach pomi\u0119dzy metodykami i ich zaletach z punktu widzenia walidacji.<\/strong><\/p>\n\n\n\n

G\u0142\u00f3wny temat stanowi podej\u015bcie do prowadzenia projekt\u00f3w obejmuj\u0105cych walidacj\u0119 system\u00f3w skomputeryzowanych w przemy\u015ble farmaceutycznym. Ze wzgl\u0119du na wymogi serializacji, wiele \ufb01rm farmaceutycznych czeka wdra\u017canie ca\u0142kiem nowego oprogramowania. Projekty prowadzone s\u0105 najcz\u0119\u015bciej za pomoc\u0105 podej\u015bcia kaskadowego (Waterfall) lub tradycyjnego, a tak\u017ce podej\u015bcia Agile, czyli zwinnego. Jakie s\u0105 r\u00f3z\u0144ice pomi\u0119dzy nimi i w jakich sytuacjach lepiej sprawdzaj\u0105 si\u0119 omawiane podej\u015bcia?<\/p>\n\n\n\n

Metodyki tradycyjne, na przyk\u0142ad Prince2 czy PMI, dziel\u0105 projekt na poszczeg\u00f3lne etapy (analiz\u0119, planowanie, realizacj\u0119, wdro\u017cenie), kt\u00f3re s\u0105 realizowane jeden po drugim, st\u0105d te\u017c nazwa \u201eprojekty kaskadowe\u201d. Projekt jest realizowany wed\u0142ug \u015bcis\u0142ego planu, znana jest jego funkcjonalno\u015b\u0107 oraz wymagania i wszystkie obszary s\u0105 dok\u0142adnie okre\u015blone \u2013 czas trwania, mierzalny produkt biznesowy, zasoby, struktura organizacyjna z zakresem obowi\u0105zk\u00f3w i r\u00f3l niezb\u0119dnych do zarz\u0105dzania projektem. Projekt jest dostarczany w ca\u0142o\u015bci. Podej\u015bcie to charakteryzuje si\u0119 \u015bcis\u0142ym nast\u0119pstwem poszczeg\u00f3lnych etap\u00f3w. Je\u015bli etap poprzedzaj\u0105cy nie zosta\u0142 zako\u0144czony zadowalaj\u0105cym efektem, to nast\u0119pny nie mo\u017ce zosta\u0107 rozpocz\u0119ty. Konieczny jest powr\u00f3t do poprzedniego etapu i naniesienie zmian daj\u0105cych oczekiwany efekt.<\/p>\n\n\n\n

Z kolei w podej\u015bciu zwinnym, na przyk\u0142ad Scrum, plan r\u00f3wnie\u017c jest okre\u015blony, ale wszystko przebiega w spos\u00f3b elastyczny. Zesp\u00f3\u0142 sam si\u0119 organizuje, przydziela zadania, a projekt jest realizowany ma\u0142ymi etapami. W trakcie realizacji projektu mog\u0105 pojawi\u0107 si\u0119 nowe potrzeby, za kt\u00f3rymi zesp\u00f3\u0142 mo\u017ce pod\u0105\u017ca\u0107. Zakres musi by\u0107 zdefiniowany zar\u00f3wno w projekcie prowadzonym metodyk\u0105 zwinn\u0105, jak i w projekcie kaskadowym i mo\u017ce by\u0107 taki sam, ale je\u015bli w projekcie czy w harmonogramie projektu wyst\u0119puje konieczno\u015b\u0107 wprowadzania zmian, to r\u00f3\u017cnica mi\u0119dzy metodykami jest bardzo widoczna. W metodykach zwinnych mamy instrumenty, kt\u00f3re pozwalaj\u0105 nam \u0142atwo i szybko ten zakres modyfikowa\u0107. W klasycznym podej\u015bciu takie procedury tak\u017ce posiadamy, ale s\u0105 one czasoch\u0142onne i wymagaj\u0105 wi\u0119kszego zaanga\u017cowania. Warto te\u017c doda\u0107, \u017ce realizacja projektu podej\u015bciem Waterfall wymaga wi\u0119cej czasu, co zazwyczaj oznacza wi\u0119ksze koszty. Jest to zwi\u0105zane mi\u0119dzy innymi z konieczno\u015bci\u0105 powtarzania poszczeg\u00f3lnych etap\u00f3w w wyniku braku efekt\u00f3w lub gdy efekty nie s\u0105 takie, jak oczekiwano i, co si\u0119 z tym wi\u0105\u017ce, dochodzi do przestoj\u00f3w.<\/p>\n\n\n\n

Warto te\u017c wspomnie\u0107 o metodyce hybrydowej AgilePM, gdzie s\u0105 mechanizmy kontroli znane z tradycyjnych metodyk, s\u0105 aspekty projektu, takie jak ryzyka, bud\u017cet, czas, jako\u015b\u0107, ale paradygmatem jest ci\u0105g\u0142e zbieranie i odkrywanie nowych wymaga\u0144 oraz pod\u0105\u017canie za zmian\u0105.<\/p>\n\n\n\n

Jak wi\u0119c te r\u00f3\u017cnice maj\u0105 si\u0119 do prowadzenia proces\u00f3w walidacji w projekcie?<\/strong><\/h3>\n\n\n\n

Walidacja jest takim dosy\u0107 sztywnym, nazwijmy to, podej\u015bciem, kt\u00f3re wymaga procedur, instrukcji i dalekie jest od elastyczno\u015bci, kt\u00f3r\u0105 pewnie w wielu projektach dobrze by\u0142oby mie\u0107. Mo\u017cna powiedzie\u0107, \u017ce jest takim typowym procesem kaskadowym i z naszej perspektywy w Agile w\u0142a\u015bnie ta ci\u0105g\u0142a zmienno\u015b\u0107 jest pewnym wyzwaniem, przede wszystkim z punktu widzenia prowadzenia dokumentacji i test\u00f3w. W przypadku projekt\u00f3w prowadzonych metodyk\u0105 zwinn\u0105 istotne i jednocze\u015bnie problematyczne jest ustawienie naszych regu\u0142 walidacyjnych tak, \u017ceby \u201enie wypaczy\u0107\u201d tego zwinnego podej\u015bcia za bardzo. Czyli \u017ceby wci\u0105\u017c pozostawi\u0107 t\u0119 mo\u017cliwo\u015b\u0107 elastycznego definiowania czy zmieniania zakresu, a z drugiej strony dope\u0142ni\u0107 formalno\u015bci, kt\u00f3re s\u0105 wymagane w procesie walidacyjnym, czyli opracowa\u0107 analiz\u0119 ryzyka i nadzorowa\u0107 ryzyko w procesie, zaplanowa\u0107 zakres prac walidacyjnych i zakres test\u00f3w, zdefiniowa\u0107 i opracowa\u0107 wymagan\u0105 dokumentacj\u0119 techniczn\u0105 bez ryzyka, \u017ce co\u015b zosta\u0142o pomini\u0119te albo na przyk\u0142ad, \u017ce zakres test\u00f3w by\u0142 nieodpowiedni.<\/p>\n\n\n\n

Nale\u017cy r\u00f3wnie\u017c pami\u0119ta\u0107, \u017ce proces walidacji ma tak zwane hard gates, kt\u00f3re musz\u0105 zosta\u0107 spe\u0142nione przed przej\u015bciem do kolejnego etapu. Na przyk\u0142ad dokumentacja specyfikuj\u0105ca (URS, FS, DS) musi zosta\u0107 opracowana przed rozpocz\u0119ciem test\u00f3w. W przypadku zwinnych metodyk, kiedy funkcjonalno\u015bci zmieniaj\u0105 si\u0119 dynamicznie, ma to, chocia\u017cby bezpo\u015bredni wp\u0142yw na dokumentacj\u0119, a to z kolei przek\u0142ada si\u0119 na testy. Z mojej perspektywy, to ca\u0142a sztuka w walidacji projekt\u00f3w zwinnych polega w\u0142a\u015bnie na zbudowaniu takiego podej\u015bcia czy modelu walidacji, \u017ceby dope\u0142niaj\u0105c formalno\u015bci w taki czy inny spos\u00f3b, nie blokowa\u0107 elastyczno\u015bci zmian w projekcie.<\/p>\n\n\n\n

Je\u017celi projekt jest na tyle prosty, \u017ce nie da si\u0119 go rozbi\u0107 na mniejsze fazy, czyli w nomenklaturze Scrum sprinty, to ci\u0119\u017cko m\u00f3wi\u0107 o projekcie Agile. Podzia\u0142 projektu na sprinty polega na sukcesywnym dodawaniu funkcjonalno\u015bci, kt\u00f3ra ze sprintu na sprint jest bli\u017csza wymaganiom klienta, bo praktycznie na tym to polega. W Waterfall mamy wszystko zaplanowane od a do z (przede wszystkim, jak ma wygl\u0105da\u0107 produkt ko\u0144cowy), przechodzimy przez poszczeg\u00f3lne etapy produkcyjne i dostarczamy oraz sprawdzamy od razu finalny produkt, a w metodykach zwinnych dostarczamy poszczeg\u00f3lne elementy, funkcjonalno\u015bci, kt\u00f3re sk\u0142adaj\u0105 si\u0119 na ca\u0142o\u015b\u0107. B\u0142\u0119dne jest my\u015blenie, \u017ce w Agile plan jest improwizowany, bo og\u00f3lnie ka\u017cde dzia\u0142anie jest okre\u015blone i wbrew pozorom w niekt\u00f3rych metodykach zwinnych s\u0105 r\u00f3wnie\u017c nieprzekraczalne terminy, czyli mamy tak zwany timebox. Ka\u017cdy, nawet kr\u00f3tki etap pracy, jak iteracja czy sprint, w metodyce Scrum jest na sztywno okre\u015blony. Zadania s\u0105 wykonywane precyzyjnie i wszelkie nasze rezultaty s\u0105 weryfikowane na bie\u017c\u0105co. Na pewno \u0142atwiej weryfikowa\u0107 wykonanie zada\u0144 i rezultaty po poszczeg\u00f3lnych sprintach, gdy\u017c w przypadku zidentyfikowania b\u0142\u0119d\u00f3w w dostarczonych funkcjonalno\u015bciach z ostatniego sprintu mo\u017cna ich popraw\u0119 wdro\u017cy\u0107 po samym zidentyfikowaniu b\u0142\u0119du lub zaplanowa\u0107 ich napraw\u0119 na najbli\u017cszy sprint. Z punktu widzenia na przyk\u0142ad tworzenia oprogramowania jest to bardzo du\u017ca zaleta. Z punktu widzenia walidacji to komplikuje ca\u0142\u0105 sytuacj\u0119.<\/p>\n\n\n\n

Czy to oznacza, \u017ce w ramach danej iteracji czy sprintu mo\u017cna realizowa\u0107 zadania walidacyjne, kt\u00f3re b\u0119d\u0105 realizowane wraz z procesem Agile ca\u0142ego projektu?<\/strong><\/h3>\n\n\n\n

To zale\u017cy, w jakiej fazie jest projekt. Zdarza si\u0119 cz\u0119sto, \u017ce te pierwsze fazy \u2013 gdy na przyk\u0142ad przygotowywane jest \u015brodowisko, tworzony jest kod backend i konfiguracji \u2013 nie wnosz\u0105 zbyt wiele do ca\u0142o\u015bci i z punktu widzenia walidatora mog\u0105 by\u0107 stracone. Spotka\u0142em si\u0119 z dwoma podej\u015bciami w takiej sytuacji. W pierwszym podej\u015bciu walidator jest zaanga\u017cowany w projekt od pocz\u0105tku i rozpoczyna swoje dzia\u0142ania w 2\/3, 3\/4 sprintu, na przyk\u0142ad sprawdza dokumentacj\u0119, czy te\u017c waliduje kod aplikacji. Jest na bie\u017c\u0105co i przekazuje uwagi, komentarze, co jest \u017ale zrobione z punktu widzenia walidacji. Walidator ma sta\u0142\u0105 kontrol\u0119 nad ca\u0142ym procesem wytwarzania oraz mo\u017ce weryfikowa\u0107 poszczeg\u00f3lne etapy czy funkcjonalno\u015bci. Minimalizowane jest ryzyko, \u017ce finalny produkt b\u0119dzie niezgodny z celami biznesowymi i wymaganiami, a ca\u0142y proces by\u0142 prowadzony niezgodnie z przepisami, regulacjami czy dobr\u0105 praktyk\u0105 wytwarzania. Oczywi\u015bcie s\u0105 i minusy takiego rozwi\u0105zania \u2013 cz\u0119sto jest tak, \u017ce jaka\u015b funkcjonalno\u015b\u0107, kt\u00f3ra powsta\u0142a w czasie sprint\u00f3w, nie wyst\u0119puje w produkcie finalnym, bo z niej zrezygnowano. Taki scenariusz k\u0142\u00f3ci si\u0119 z podej\u015bciem walidatora, bo jego rol\u0105 jest, zadbanie o to by rozwi\u0105zanie by\u0142o zgodne celami biznesowymi czy specyfikacj\u0105. W podej\u015bciu drugim walidator wchodzi w projekt w ostatnich jego fazach, za\u0142\u00f3\u017cmy jak, jest 80% dostarczonej funkcjonalno\u015bci. Rozpoczyna walidacj\u0119 i prac\u0119 z osob\u0105 odpowiedzialn\u0105 za dokumentacj\u0119, za kod \u017ar\u00f3d\u0142owy, a tak\u017ce otrzymuje dokumenty, kt\u00f3re potrzebne s\u0105 na koniec projektu.<\/p>\n\n\n\n

To ostatnie podej\u015bcie ma oczywi\u015bcie bardzo du\u017cy minus. Je\u015bli wszystko by\u0142o prowadzone prawid\u0142owo, nie ma brak\u00f3w w dokumentacji, nie pope\u0142niono b\u0142\u0119d\u00f3w i nie ma defekt\u00f3w, to proces walidacji przebiega sprawnie. Je\u015bli jednak pojawiaj\u0105 si\u0119 komplikacje, braki czy defekty, to walidacja trwa d\u0142u\u017cej i ma bezpo\u015bredni wp\u0142yw na dostarczenie finalnego produktu zwalidowanego. Zdecydowanie lepszym modelem jest zaanga\u017cowanie walidatora w projekt ju\u017c na pierwszych etapach, cho\u0107
w mniejszym zakresie.<\/p>\n\n\n\n

Kiedy zatem walidator lub zesp\u00f3\u0142 walidator\u00f3w powinien rozpocz\u0105\u0107 prac\u0119 w przypadku projektu dotycz\u0105cego wytwarzania lub wdro\u017cenia oprogramowania w firmie farmaceutycznej?<\/strong><\/h3>\n\n\n\n

Im p\u00f3\u017aniej wejdziemy w projekt, tym gorzej. Najgorszym wariantem jest w\u0142\u0105czenie walidacji przed samymi testami, bo w praktyce oznacza to najwi\u0119cej pracy dla wszystkich. Z jednej strony, \u017ceby projekt walidacyjny wystartowa\u0142, musi powsta\u0107 dokument, taki jak analiza ryzyka czy plan walidacji. Nawet je\u015bli m\u00f3wimy o podej\u015bciu Agile, czy ju\u017c konkretnie Scrum, nasze zaanga\u017cowanie powinno rozpocz\u0105\u0107 si\u0119 na samym pocz\u0105tku od analizy ryzyka. Walidator powinien mie\u0107 wp\u0142yw na budow\u0119 strategii test\u00f3w, kiedy s\u0105 wykonywane, jakie testy s\u0105 wykonywane, jaka dokumentacja jest tworzona w trakcie trwania projektu, czy jest prowadzona skrupulatnie, jakie s\u0105 \u015brodowiska pracy, jak ma wygl\u0105da\u0107 implementacja, na jakich \u015brodowiskach i wiele wi\u0119cej. Nawet je\u015bli gros aktywno\u015bci walidatora jest przewidziany w fazie testowania i przed implementacj\u0105, to nasze zaanga\u017cowanie we wczesnych fazach projektu jest po\u017c\u0105dane. Wej\u015bcie do projektu w p\u00f3\u017anych fazach mo\u017ce spowodowa\u0107 op\u00f3\u017anienia czy szereg dodatkowych prac i koszt\u00f3w, kt\u00f3re b\u0119d\u0105 konieczne, aby projekt spe\u0142nia\u0142 za\u0142o\u017cenia i by\u0142 zgodny z regulacjami, oczywi\u015bcie gdy m\u00f3wimy o konieczno\u015bci jego walidacji. Jestem pewien, \u017ce nie jest dla nikogo tajemnic\u0105, \u017ce wprowadzanie poprawek do projektu na jego pocz\u0105tku kosztuje najmniej, zar\u00f3wno w wymiarze czasu i zaanga\u017cowania, jak i w wymiarze finansowym.<\/p>\n\n\n\n

W\u0142\u0105czenie walidacji na samym pocz\u0105tku jest kluczowe, bo zesp\u00f3\u0142 projektowy powinien wiedzie\u0107, co si\u0119 dzieje, jakie s\u0105 oczekiwania. To, \u017ce nie ma zakresu ani planu projektu, to nie jest kwestia metodyki zwinnej, to jest kwestia z\u0142ej organizacji projektu. Przy projektach informatycznych funkcjonuje czasem b\u0142\u0119dne przekonanie, \u017ce jak projekt realizowany jest w podej\u015bciu zwinnym, to do pewnych kwestii mo\u017cna podej\u015b\u0107 swobodniej \u2013 dokumentacj\u0119 napiszemy p\u00f3\u017aniej, plany zrobimy p\u00f3\u017aniej. To nie
jest prawda, zakres projektu i plan jego realizacji zawsze musi by\u0107 znany, udokumentowany i zapisany. Dokumentacja te\u017c musi by\u0107 dostarczona. Tak, jak powiedzia\u0142em na pocz\u0105tku, jedyna r\u00f3\u017cnica jest taka, czy mo\u017cemy rozbi\u0107 to na etapy i czy mamy procedury lub funkcje, kt\u00f3re pozwalaj\u0105 nam na wprowadzenie tych zmian.<\/p>\n\n\n\n

Za\u0142\u00f3\u017cmy, \u017ce realizowany jest projekt w metodyce zwinnej, ale w trakcie jednego z etap\u00f3w pojawia si\u0119 defekt albo niezgodno\u015b\u0107 z dokumentacj\u0105. Co si\u0119 wtedy dzieje? Czy sprint lub etap zostaje przerwany, gdy funkcjonalno\u015b\u0107 dzia\u0142a? Czy s\u0105 przewidziane jakie\u015b dzia\u0142ania?<\/strong><\/h3>\n\n\n\n

Nale\u017cy odnie\u015b\u0107 si\u0119 tutaj do metodologii Scrum. Sprinty s\u0105 to etapy najcz\u0119\u015bciej dwutygodniowe i w ich trakcie s\u0105 zaplanowane konkretne zadania do wykonania. Po ka\u017cdym sprincie prezentowane s\u0105 efekty, opisywane s\u0105 zadania, kt\u00f3re z zaplanowanego sprintu uda\u0142o si\u0119 zrealizowa\u0107, oraz jakie b\u0142\u0119dy zosta\u0142y zidentyfikowane (wymagaj\u0105 poprawki). Po prezentacji aktualnego stanu produktu odbywa si\u0119 kolejne spotkanie z dzia\u0142em biznesu, na kt\u00f3rym planowany jest zakres najbli\u017cszego sprintu. Na takim spotkaniu mo\u017cna przedyskutowa\u0107 szczeg\u00f3\u0142owe wymagania czy te\u017c rozwia\u0107 wszelkie w\u0105tpliwo\u015bci, jak dane wymagania maj\u0105 zosta\u0107 zrealizowane. Je\u015bli pojawiaj\u0105 si\u0119 b\u0142\u0119dy, to ich naprawienie jest uwzgl\u0119dnione w planie. W projektach prowadzonych metodyk\u0105 Scrum nie s\u0105 planowane sprinty od pocz\u0105tku do ko\u0144ca projektu. Najpro\u015bciej m\u00f3wi\u0105c, projekt zbiorczy jest zbiorem poszczeg\u00f3lnych zada\u0144, kt\u00f3re musz\u0105 by\u0107 wykonane w trakcie jego trwania, aby produkt ko\u0144cowy by\u0142 zgodny z za\u0142o\u017ceniami. Jednak w trakcie trwania projektu cz\u0119sto przybywa sprint\u00f3w, bo pojawiaj\u0105 si\u0119 b\u0142\u0119dy, kt\u00f3re trzeba rozwi\u0105za\u0107 lub nowe funkcjonalno\u015bci. Podczas sprint\u00f3w powinny by\u0107 r\u00f3wnie\u017c zaplanowane testy przewidziane w projekcie, aby m\u00f3c p\u00f3\u017aniej przygotowa\u0107 dokumentacj\u0119, zaraportowa\u0107 post\u0119py oraz wykryte b\u0142\u0119dy i plan ich poprawienia.<\/p>\n\n\n\n

Tutaj te\u017c wychodzi r\u00f3\u017cnica w podej\u015bciu Waterfall i Agile. W metodykach tradycyjnych pojawienie si\u0119 problemu krytycznego wstrzymuje nam projekt, bo testy robimy na przyk\u0142ad przed wdro\u017ceniem ca\u0142o\u015bci, wi\u0119c do czasu rozwi\u0105zania problemu projekt nie mo\u017ce ruszy\u0107 z miejsca. W przypadku metodyki zwinnej niekoniecznie oznacza to zast\u00f3j prac. Je\u015bli dany sprint b\u0105d\u017a iteracja nie ma wp\u0142ywu na inne etapy czy funkcjonalno\u015bci (a cz\u0119sto nie ma, bo kolejne etapy s\u0105 dopiero planowane), to jeden zesp\u00f3\u0142 mo\u017ce pracowa\u0107 nad rozwi\u0105zaniem problemu, a inny realizowa\u0107 ju\u017c kolejne zadania. Ale o problemach czy b\u0142\u0119dach wiemy w zasadzie na bie\u017c\u0105co.<\/p>\n\n\n\n

Patrz\u0105c te\u017c z perspektywy walidacji, w przypadku projekt\u00f3w prowadzonych wed\u0142ug podej\u015bcia Agile nale\u017cy podej\u015b\u0107 do tego bardziej elastycznie, ale wci\u0105\u017c w ramach dobrych praktyk wytwarzania. Og\u00f3lne wytyczne co do walidacji, czy to w przypadku metodyk tradycyjnych czy te\u017c zwinnych, s\u0105 identyczne. Kluczowe jest dobranie odpowiednich narz\u0119dzi umo\u017cliwiaj\u0105cych prowadzenie procesu walidacji w \u201ezmiennym \u015brodowisku\u201d. Mo\u017cna, chocia\u017cby zamiast korzystania z tradycyjnych dokument\u00f3w, budowa\u0107 dokumenty modu\u0142owo albo wprowadza\u0107 rewizje po\u015brednie (nie tylko g\u0142\u00f3wne wersje), \u017ceby umo\u017cliwi\u0107 cz\u0119stsz\u0105 ich aktualizacj\u0119. Bo tak naprawd\u0119 wszystko sprowadza si\u0119 do metod dokumentowania i p\u00f3\u017aniej zatwierdzania dokument\u00f3w przed poszczeg\u00f3lnymi fazami. \u0179le zbudowana dokumentacja, nawet w przypadku tradycyjnego podej\u015bcia, mo\u017ce uziemi\u0107 projekt, a zw\u0142aszcza projekt Agile. Poza dokumentami nale\u017cy si\u0119 oczywi\u015bcie przyjrze\u0107 fazie testowania i r\u00f3wnie\u017c w tym przypadku przewidzie\u0107, czy podczas poszczeg\u00f3lnych sprint\u00f3w tylko fragmenty systemu mog\u0105 by\u0107 weryfikowane. \u017beby mie\u0107 pewno\u015b\u0107, \u017ce ca\u0142y system dzia\u0142a poprawnie jako zintegrowana ca\u0142o\u015b\u0107, mo\u017cna na koniec projektu zaplanowa\u0107 faz\u0119 test\u00f3w regresyjnych albo przekrojowych end-to-end przez ca\u0142y system. Przy dobrym planowaniu takie testy mo\u017cna wcze\u015bniej zautomatyzowa\u0107, co r\u00f3wnie\u017c przyspieszy ca\u0142y proces testowania.<\/p>\n\n\n\n

Kt\u00f3r\u0105 metodyk\u0119 zatem najlepiej wybra\u0107 do realizacji projekt\u00f3w z uwzgl\u0119dnieniem walidacji?<\/strong><\/h3>\n\n\n\n

Najlepszym rozwi\u0105zaniem jest realizacja projektu w metodyce hybrydowej, na przyk\u0142ad AgilePM, czyli g\u0142\u00f3wne fazy poprowadzi si\u0119 tradycyjnie z zachowaniem wszystkich wymaga\u0144 formalnych z rozbiciem na fazy najni\u017csze, czyli te grupy zada\u0144, kt\u00f3re mo\u017ce podzieli\u0107 na iteracje charakterystyczne dla metodyki Agile.<\/p>\n\n\n\n

Przy ka\u017cdym projekcie bardzo istotna jest dobra organizacja pracy, plan prac i harmonogram oraz przep\u0142yw informacji, aby ka\u017cdy uczestnik projektu wiedzia\u0142, za co jest odpowiedzialny i zna\u0142 status projektu. Pozwala to zminimalizowa\u0107 liczb\u0119 b\u0142\u0119d\u00f3w, kt\u00f3re mog\u0105 si\u0119 zdarzy\u0107. Wa\u017cna jest te\u017c wsp\u00f3\u0142praca z zamawiaj\u0105cym i jego bliskie zaanga\u017cowanie w projekt. Wymiana informacji mi\u0119dzy zamawiaj\u0105cym a zespo\u0142em realizuj\u0105cym projekt jest wtedy zdecydowanie lepsza i na pewno \u0142atwiej jest dostarczy\u0107 projekt w 100% zgodny z oczekiwaniami w kr\u00f3tszym czasie.<\/p>\n\n\n\n

Metodyki zwinne nie s\u0105 lekarstwem na wszystkie bol\u0105czki, ale mog\u0105 czasami przy\u015bpieszy\u0107 projekt. Przed rozpocz\u0119ciem projektu nale\u017cy przeprowadzi\u0107 jego analiz\u0119 na podstawie na przyk\u0142ad analizy wymaga\u0144, co pozwoli u\u015bwiadomi\u0107 sobie, w jaki spos\u00f3b ten projekt mo\u017ce zosta\u0107 poprowadzony. Z punktu widzenia proces\u00f3w walidacji, niezale\u017cnie od tego, jaka metodyka zostanie wybrana, wa\u017cnym aspektem jest zaanga\u017cowanie walidatora od pocz\u0105tku w proces, by mo\u017cna by\u0142o uwzgl\u0119dni\u0107 jego uwagi i zalecenie oraz prac\u0119, jak\u0105 ma wykona\u0107 w ca\u0142ym projekcie. Oszcz\u0119dzi to wszystkim czasu i zniweluje przestoje, na czym najbardziej zale\u017cy wbrew pozorom nie tylko klientowi, ale i wykonawcy.<\/p>\n\n\n\n

\n
\"Changing<\/figure>\n<\/figure>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

Walidacja system\u00f3w komputerowych to proces wyst\u0119puj\u0105cy w ka\u017cdej firmie farmaceutycznej lub produkuj\u0105cej wyroby medyczne, kt\u00f3ra wykorzystuje systemy informatyczne na etapie produkcji, logistyki czy dystrybucji swoich produkt\u00f3w. Tworzenie nowego systemu i jego modyfikacje czy implementacja gotowego oprogramowania wymagaj\u0105 odpowiedniego zarz\u0105dzania projektem. W projektach informatycznych dominuj\u0105 dwa podej\u015bcia do tego typu procesu \u2013 tradycyjne i zwinne (agile). […]<\/p>\n","protected":false},"featured_media":3327,"template":"","categories":[],"class_list":["post-9121","blog","type-blog","status-publish","has-post-thumbnail","hentry"],"acf":[],"yoast_head":"\nZarz\u0105dzanie projektem IT \u2013 wyzwanie dla walidacji - eConsulting<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/econsulting.co\/pl\/blog\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\/\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:title\" content=\"Zarz\u0105dzanie projektem IT \u2013 wyzwanie dla walidacji - eConsulting\" \/>\n<meta name=\"twitter:description\" content=\"Walidacja system\u00f3w komputerowych to proces wyst\u0119puj\u0105cy w ka\u017cdej firmie farmaceutycznej lub produkuj\u0105cej wyroby medyczne, kt\u00f3ra wykorzystuje systemy informatyczne na etapie produkcji, logistyki czy dystrybucji swoich produkt\u00f3w. Tworzenie nowego systemu i jego modyfikacje czy implementacja gotowego oprogramowania wymagaj\u0105 odpowiedniego zarz\u0105dzania projektem. W projektach informatycznych dominuj\u0105 dwa podej\u015bcia do tego typu procesu \u2013 tradycyjne i zwinne (agile). […]\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/econsulting.co\/wp-content\/uploads\/agile-scaled.jpeg\" \/>\n<meta name=\"twitter:label1\" content=\"Szacowany czas czytania\" \/>\n\t<meta name=\"twitter:data1\" content=\"13 minut\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/econsulting.co\\\/pl\\\/blog\\\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\\\/\",\"url\":\"https:\\\/\\\/econsulting.co\\\/pl\\\/blog\\\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\\\/\",\"name\":\"Zarz\u0105dzanie projektem IT \u2013 wyzwanie dla walidacji - eConsulting\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/econsulting.pl\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/econsulting.co\\\/pl\\\/blog\\\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/econsulting.co\\\/pl\\\/blog\\\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/econsulting.co\\\/wp-content\\\/uploads\\\/agile-scaled.jpeg\",\"datePublished\":\"2021-08-11T13:45:00+00:00\",\"dateModified\":\"2022-06-29T22:32:18+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/econsulting.co\\\/pl\\\/blog\\\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\\\/#breadcrumb\"},\"inLanguage\":\"pl-PL\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/econsulting.co\\\/pl\\\/blog\\\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pl-PL\",\"@id\":\"https:\\\/\\\/econsulting.co\\\/pl\\\/blog\\\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\\\/#primaryimage\",\"url\":\"https:\\\/\\\/econsulting.co\\\/wp-content\\\/uploads\\\/agile-scaled.jpeg\",\"contentUrl\":\"https:\\\/\\\/econsulting.co\\\/wp-content\\\/uploads\\\/agile-scaled.jpeg\",\"width\":2560,\"height\":1582,\"caption\":\"Changing Project Management Methodology From Traditional to Agile PM\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/econsulting.co\\\/pl\\\/blog\\\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/econsulting.co\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Zarz\u0105dzanie projektem IT \u2013 wyzwanie dla walidacji\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/econsulting.pl\\\/#website\",\"url\":\"https:\\\/\\\/econsulting.pl\\\/\",\"name\":\"eConsulting\",\"description\":\"Cornerstone IT services, validation, IT outsourcing, Salesforce\",\"publisher\":{\"@id\":\"https:\\\/\\\/econsulting.pl\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/econsulting.pl\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"pl-PL\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/econsulting.pl\\\/#organization\",\"name\":\"eConsulting\",\"url\":\"https:\\\/\\\/econsulting.pl\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pl-PL\",\"@id\":\"https:\\\/\\\/econsulting.pl\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/econsulting.co\\\/wp-content\\\/uploads\\\/2020\\\/08\\\/e-fav.png\",\"contentUrl\":\"https:\\\/\\\/econsulting.co\\\/wp-content\\\/uploads\\\/2020\\\/08\\\/e-fav.png\",\"width\":513,\"height\":513,\"caption\":\"eConsulting\"},\"image\":{\"@id\":\"https:\\\/\\\/econsulting.pl\\\/#\\\/schema\\\/logo\\\/image\\\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Zarz\u0105dzanie projektem IT \u2013 wyzwanie dla walidacji - eConsulting","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/econsulting.co\/pl\/blog\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\/","twitter_card":"summary_large_image","twitter_title":"Zarz\u0105dzanie projektem IT \u2013 wyzwanie dla walidacji - eConsulting","twitter_description":"Walidacja system\u00f3w komputerowych to proces wyst\u0119puj\u0105cy w ka\u017cdej firmie farmaceutycznej lub produkuj\u0105cej wyroby medyczne, kt\u00f3ra wykorzystuje systemy informatyczne na etapie produkcji, logistyki czy dystrybucji swoich produkt\u00f3w. Tworzenie nowego systemu i jego modyfikacje czy implementacja gotowego oprogramowania wymagaj\u0105 odpowiedniego zarz\u0105dzania projektem. W projektach informatycznych dominuj\u0105 dwa podej\u015bcia do tego typu procesu \u2013 tradycyjne i zwinne (agile). […]","twitter_image":"https:\/\/econsulting.co\/wp-content\/uploads\/agile-scaled.jpeg","twitter_misc":{"Szacowany czas czytania":"13 minut"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/econsulting.co\/pl\/blog\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\/","url":"https:\/\/econsulting.co\/pl\/blog\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\/","name":"Zarz\u0105dzanie projektem IT \u2013 wyzwanie dla walidacji - eConsulting","isPartOf":{"@id":"https:\/\/econsulting.pl\/#website"},"primaryImageOfPage":{"@id":"https:\/\/econsulting.co\/pl\/blog\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\/#primaryimage"},"image":{"@id":"https:\/\/econsulting.co\/pl\/blog\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\/#primaryimage"},"thumbnailUrl":"https:\/\/econsulting.co\/wp-content\/uploads\/agile-scaled.jpeg","datePublished":"2021-08-11T13:45:00+00:00","dateModified":"2022-06-29T22:32:18+00:00","breadcrumb":{"@id":"https:\/\/econsulting.co\/pl\/blog\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\/#breadcrumb"},"inLanguage":"pl-PL","potentialAction":[{"@type":"ReadAction","target":["https:\/\/econsulting.co\/pl\/blog\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\/"]}]},{"@type":"ImageObject","inLanguage":"pl-PL","@id":"https:\/\/econsulting.co\/pl\/blog\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\/#primaryimage","url":"https:\/\/econsulting.co\/wp-content\/uploads\/agile-scaled.jpeg","contentUrl":"https:\/\/econsulting.co\/wp-content\/uploads\/agile-scaled.jpeg","width":2560,"height":1582,"caption":"Changing Project Management Methodology From Traditional to Agile PM"},{"@type":"BreadcrumbList","@id":"https:\/\/econsulting.co\/pl\/blog\/zarzadzanie-projektem-it-wyzwanie-dla-walidacji\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/econsulting.co\/"},{"@type":"ListItem","position":2,"name":"Zarz\u0105dzanie projektem IT \u2013 wyzwanie dla walidacji"}]},{"@type":"WebSite","@id":"https:\/\/econsulting.pl\/#website","url":"https:\/\/econsulting.pl\/","name":"eConsulting","description":"Cornerstone IT services, validation, IT outsourcing, Salesforce","publisher":{"@id":"https:\/\/econsulting.pl\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/econsulting.pl\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"pl-PL"},{"@type":"Organization","@id":"https:\/\/econsulting.pl\/#organization","name":"eConsulting","url":"https:\/\/econsulting.pl\/","logo":{"@type":"ImageObject","inLanguage":"pl-PL","@id":"https:\/\/econsulting.pl\/#\/schema\/logo\/image\/","url":"https:\/\/econsulting.co\/wp-content\/uploads\/2020\/08\/e-fav.png","contentUrl":"https:\/\/econsulting.co\/wp-content\/uploads\/2020\/08\/e-fav.png","width":513,"height":513,"caption":"eConsulting"},"image":{"@id":"https:\/\/econsulting.pl\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/econsulting.co\/pl\/wp-json\/wp\/v2\/blog\/9121","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/econsulting.co\/pl\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/econsulting.co\/pl\/wp-json\/wp\/v2\/types\/blog"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/econsulting.co\/pl\/wp-json\/wp\/v2\/media\/3327"}],"wp:attachment":[{"href":"https:\/\/econsulting.co\/pl\/wp-json\/wp\/v2\/media?parent=9121"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/econsulting.co\/pl\/wp-json\/wp\/v2\/categories?post=9121"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}