Od planowania do testów i wdrożenia produktu. O idei Building Blocks

Kluczową kwestią pracy w oparciu o produkty jest ciągłe szukanie potrzeb naszych klientów, zarówno zewnętrznych, jak i tych wewnątrz organizacji. Odpowiednie zrozumienie i zrealizowanie tych potrzeb okazało się istotne w usprawnieniu jednego z wielu złożonych procesów wstępnych badań nad lekami. O tym, jak Building Blocks pomogło w opracowaniu tych badań, opowiadam poniżej.

Krzysztof Pajszczyk. IT Manager w dziale zajmującym się tworzeniem i rozwojem kluczowych produktów ułatwiających i przyspieszających pracę na wstępnym etapie wynajdowania nowych leków w GSK. Absolwent wydziału Informatyki na Politechnice Poznańskiej, pracuje w branży od 12 lat.

Projekt, którym chciałbym się z Wami podzielić, zrealizowaliśmy na potrzeby wsparcia naukowców-chemików.

Na początek, trochę kontekstu. Podczas pierwszych faz pracy nad nowymi lekami, kluczowym celem naukowców staje się znalezienie kilkudziesięciu związków chemicznych, które będą oddziaływały z bakteriami, wirusami czy też organizmem potencjalnego pacjenta. Jest to zadanie wymagające nie tylko dużych nakładów czasu, ale również nakładów finansowych: jednym z najbardziej wymagających wyzwań jest synteza (wytworzenie) rzeczywistych związków chemicznych, które mogą zostać później przetestowane.

Sposobem znacząco ułatwiającym taką syntezę, jest użycie Building Blocks, czyli już zsyntetyzowanych lub sprawdzonych “cegiełek”, które można połączyć w celu uzyskania innego związku chemicznego. Wiele firm farmaceutycznych korzysta z usług firm partnerskich, dzięki czemu są w stanie masowo dostarczać “cegiełki”. W praktyce przekłada się to na możliwość łatwego i szybkiego tworzenia oraz testowania dużych ilości różnych związków chemicznych, przy niższych nakładach finansowych.

Building Blocks wykorzystujemy także w GSK. Aby umożliwić i ułatwić naszym zespołom badawczym codzienną pracę z “cegiełkami”, wdrożyliśmy nowy system umożliwiający logistykę związaną z transportem oraz zamówieniami takich substancji na dużą skalę. Dodaliśmy także odpowiednie funkcjonalności do już używanych aplikacji w celu jak największego zautomatyzowania procesów badawczych.

Projekt, który roboczo nazwaliśmy “Building Blocks Warehouse” stał się ciekawy nie tylko ze względu na wiedzę techniczną konieczną przy tworzeniu nowego produktu, ale również ze względu na konieczność nawiązania i zarządzania pracą zespołów z kilku firm partnerskich jednocześnie.

Początek projektu

Pierwszym krokiem projektu było stworzenie wstępnych celów, co wymagało przede wszystkim bliskiej współpracy naszego Właściciela Produktu (Product Ownera) oraz kluczowych klientów, czyli osób nadzorujących ważne projekty badawcze. W branży Pharma R&D to zadanie Product Ownerów, wymagające od nich połączenia wiedzy technicznej i biznesowo-naukowej. To jedno z głównych wyzwań tej roli.

Przy ustalaniu wymagań pomocne okazało się podejście MoSCoW:
– M – MUST (musi być). Opisuje wymaganie, które musi być spełnione w końcowym, finalnym rozwiązaniu.

– S – SHOULD (powinien być). Reprezentuje pozycję o wysokim priorytecie, która powinna być zawarta w rozwiązaniu, jeżeli jest to możliwe.

– C – COULD (może być). Opisuje wymaganie, które jest postrzegane jako pożądane, ale niekonieczne. Zostanie ono zawarte, jeżeli pozwolą na to czas i zasoby.

– W – WON’T (nie będzie). Reprezentuje wymaganie, które – za zgodą interesariuszy – nie będzie implementowane w danym wydaniu, ale może być rozpatrzone w przyszłości.

Pozwoliło to na stworzenie listy “User Stories”, czyli celów projektu spisanych zgodnie z podejściem Agile. Wiedza techniczna oraz jednoczesny bliski kontakt z klientem pozwoliły z kolei na odpowiednią priorytetyzację kroków z listy.

Oferty pracy z

Przy prowadzeniu projektów w naszej firmie posługujemy się głównie narzędziami JIRA i Confluence. W większych zespołach korzystamy z pomocy ludzi na stanowiskach nazwanych jako “Agile Facilitator”. Osoby te wspierają zarówno Product Ownerów, jak i zespoły techniczne, w odpowiednim zarządzaniu projektem, aby był on jak najbardziej zbliżony do metodologii Agile i wykorzystał jej atuty. Tak było też w tym przypadku: lista “User Stories” została formalnie zapisana w Confluence i następnie skonsultowana z jedną z osób na stanowisku Tech Lead z naszego zespołu inżynieryjnego. Powstał dzięki temu ogólny projekt architektury nowej aplikacji oraz koniecznych zmian w już używanych narzędziach.

Przejdźmy do realizacji

Z powodu dynamicznego rozwoju i częstych zmian w podejściu do badań, jednym z podstawowych założeń w architekturze wielu nowych produktów są u nas mikroserwisy. Podejście takie polega na podzieleniu systemu na dużą ilość mikroserwisów, z których każdy odpowiada za wykonanie konkretnych procesów. Pozwala to w przyszłości na łatwe skalowanie aplikacji i pełne wykorzystanie potencjalnych zalet rozwiązań w chmurze (przykładowo: znaczne zmniejszenie mocy obliczeniowych w nocy i znaczne ich zwiększenie w momencie kiedy pracują jednocześnie naukowcy w Europie oraz w Stanach Zjednoczonych).

Ponadto taka architektura ułatwia późniejsze wprowadzanie zmian w funkcjonalności oraz zintegrowanie aplikacji z innymi systemami. W naszym projekcie zdecydowaliśmy się także na architekturę opartą na mikroserwisach. Było to o tyle istotne, że oprócz konieczności stworzenia nowego systemu odpowiadającego za logistykę “Building Blocks”, projekt zakładał konieczną integrację istniejącego już systemu wykorzystywanego przez chemików (a w przyszłości prawdopodobnie kolejnych kilku systemów).

W celu zrealizowania tych założeń zdecydowaliśmy się na utworzenie trzech mini-zespołów w projekcie, z których każdy zajął się pracą nad inną funkcjonalnością:

1. zespół A został dostarczony z zewnętrznej firmy, która od wielu już lat pracuje z technologią “Building Blocks” i ma duże doświadczenie nie tylko z techniczną częścią projektu, ale również z logistyką związkami chemicznymi; zespół A zajął się stworzeniem systemu logistyki od strony back-end,
2. zespół B składający się z programistów frontend z naszego zespołu, którzy zajęli się stworzeniem interfejsu użytkownika dla aplikacji dostarczonej przez zespół A, w sposób który będzie łatwy w zintegrowaniu z istniejącymi już systemami,
3. zespół C integrujący pracę zespołów A i B oraz konsultujący to z wewnętrznym zespołem zajmującym się infrastrukturą oraz, przede wszystkim, z zewnętrzną firmą, z której produktu codziennie korzystają naukowcy, w celu zaimplementowania interfejsu dostarczonego przez zespół B jako dodatkowy moduł.

W projekt zaangażowanych było łącznie dziewięciu developerów (podzielonych na trzy mini-zespoły), Product Owner, Agile Facilitator oraz dodatkowo osoba pracująca jako Tech Writer, której zadaniem było zadbanie o dokumentację (zarówno techniczną, jak i projektową). Z racji, że był to projekt o stosunkowo niedużej skali, zdecydowaliśmy się, by za testowanie odpowiadał zespół doświadczonych developerów, wspierany przez ekspertów ze strony użytkownika.

Zgodnie z przyjętym u nas standardem, długość sprintów została ustalona jako dwutygodniowe, zaczynające się zawsze sesją planowania, zawierające codzienny stand-up trwający 15 minut (dzięki którym zespoły A, B i C mogły być na bieżąco z postępami poszczególnych elementów projektu) oraz kończące się rewizją (w celu ustalenia optymalnego tempa pracy lub znalezienia czynników blokujących projekt). Jak już wspomniałem, sprinty prowadziła osoba na stanowisku Agile Facilitator, co znacząco pomagało w utrzymaniu odpowiedniej długości spotkań oraz w śledzeniu postępów projektu w sposób zrozumiały zarówno dla zespołu inżynierów, jak i kluczowych klientów oraz właściciela produktu.

Jednym z większych wyzwań w trakcie pracy developerów było odpowiednie zintegrowanie pracy osób z naszej organizacji oraz z firm partnerskich. W dużej mierze za sukces w tym przypadku odpowiadali Tech Lead oraz Agile Facilitator. Osoby te zapewniły użycie odpowiednich technologii oraz jasne wyznaczanie celów do osiągnięcia przez każdą ze stron podczas kolejnych sprintów.

Głównymi technologiami, które zdecydowaliśmy się użyć, były:

• React JS od strony frontend,
• Java od strony backend (oraz użycie architektury mikroserwisów wraz z REST w celu integracji),
• Wewnętrzny hosting przy użyciu klastra Kubernetes (w celu łatwego zarządzania mikro serwisami),
• Wewnętrzne repozytorium GIT,
• Za automatyzację integracji oraz dostarczania (CI/CD – continuous integration/continuous delivery) odpowiadała platforma Azure DevOps,
• Utworzenie 3 środowisk: deweloperskiego, UAT (user acceptance testing – czyli testów użytkownika) oraz produkcyjnego.

Testowanie i wdrożenie

Za testowanie systemu odpowiedzialny był zespół deweloperów, w związku z czym kluczowe było zadbanie o dobre testy jednostkowe obejmujące jak największą ilość metod i obiektów. Przy odpowiednim połączeniu testów jednostkowych (Unit Testing) z automatyzacją integracji (CI – Continuous Integration) zaowocowało to minimalnym nakładem czasu oraz dużą szansą na wyłapanie błędów możliwie najwcześniej.

Testy integracyjne były kolejnym ważnym elementem, który jednak stał się stosunkowo łatwy przy użyciu architektury mikroserwisów. Użyliśmy w tym celu odpowiednich skryptów testowych oraz narzędzia SoapUI.

Podczas testów akceptacyjnych skorzystaliśmy z pomocy ekspertów od strony naszego klienta, czyli naukowców przeważnie zaangażowanych w projekty, które nasz dział wdraża w systemy wykorzystywane podczas codziennej pracy. Ponieważ podejście Agile w projektach zakłada częsty kontakt zespołu projektowego z klientem, wykorzystanie go w czasie testów akceptacyjnych pomogło nie tylko w wyłapaniu błędów natury technicznej, ale także w zadbaniu o interfejs użytkownika, który będzie zgodny ze specyficznym nazewnictwem wykorzystywanym podczas badań nad lekami.

Wdrożenie aplikacji postępowało w ramach kolejnych sprintów i polegało na regularnym przenoszeniu ostatniej stabilnej wersji ze środowiska deweloperskiego na środowisko UAT, gdzie dany release mógł przechodzić testy akceptacyjne równolegle do dalszej pracy zespołu deweloperskiego.

W momencie uzyskania stabilnej wersji systemu spełniającej wymagania zakwalifikowane jako MUST i SHOULD, została ona wdrożona na środowisku produkcyjnym.

Ostatnim elementem wdrożenia nowego systemu jako produkt nazywany u nas “Established”, czyli rozwinięty do wersji docelowej, było przekazanie go pod opiekę zespołu wsparcia aplikacji. Najczęściej kluczowe w tym celu są trzy elementy:

• dokumentacja zawierająca dokładny opis produktu, zarówno w zakresie technologii, jak i wymagań funkcjonalnych,
• odpowiednio przeprowadzone sesje wymiany wiedzy technicznej oraz biznesowej,
• wsparcie zespołu wsparcia przez zespół deweloperów w trakcie pierwszych tygodni po wdrożeniu systemu na produkcję (szczególnie w przypadku gdyby pojawiły się niewykryte wcześniej błędy).

Podsumowanie

Opisany tutaj przykładowy projekt, który realizowaliśmy, pokazuje, jak ważne jest znalezienie prawdziwych potrzeb klientów (w tym przypadku – naukowców z naszej organizacji), zaplanowanie jak te potrzeby można zrealizować, odpowiednie zaprojektowanie systemu, aby był on skalowalny przez najbliższe lata. Istotnym elementem, poza wiedzą techniczną, jest także zarządzanie współpracą wielu zespołów.

Zastosowanie wielu nowoczesnych technologii w projekcie Building Blocks pozwoliło zespołowi podejść kompleksowo do tego wyzwania. W chwili pisania artykułu system działa na środowisku produkcyjnym już od czterech tygodni i w ciągu najbliższych dwóch, zespół deweloperów odda aplikację w całości pod opiekę zespołu wsparcia. Dzięki temu deweloperzy będą mogli rozpocząć kolejny projekt, a naukowcy w widoczny sposób przyspieszyć badania na wczesnym etapie pracy nad nowymi lekami, znacząco skracając czas potrzebny na syntezę związków chemicznych.

Każdego dnia korzystamy z bardzo szerokiej gamy technologii, coraz częściej używając machine learning, data lake, high performance computing, no i oczywiście – rozwiązań w chmurze oraz architektury opartej o mikro-serwisy.

Ten projekt to też świetny przykład tego, jak ważna jest współpraca technologii i nauki, oraz że każdego dnia nasza praca w GSK Tech ma wpływ na poprawę jakości ludzkiego życia.

SUPP-2103819