Od pomysłu do przemysłu – cykl życia robota to dużo więcej niż myślisz

Współczesne platformy robotyczne zawierają cały szereg funkcjonalności ułatwiających projektowanie, kodowanie i testowanie robotów. Można je stworzyć na podstawie szablonu, używając gotowego komponentu z biblioteki lub nawet „nagrywając” proces w trakcie jego działania. Niestety, tak zbudowane roboty działają zwykle dla trywialnych lub sztucznie wymyślonych przypadków. Prawdziwym wyzwaniem jest efektywna automatyzacja procesów, które zmieniają się w czasie, a co za tym idzie – wymuszają zmiany w robotach. Aby nad nimi zapanować trzeba wiedzieć jak wygląda cykl życia robota – od pomysłu co miałby robić, przez jego wytworzenie, utrzymanie, aż do momentu, kiedy uznamy, że jego misja się wypełniła i trzeba go wyłączyć.

Od czego zaczyna się cykl życia robota, czyli zarządzanie pomysłami

Wbrew pozorom najczęściej zespoły, które są odpowiedzialne za robotyzację nie narzekają na brak pomysłów na to, gdzie roboty mogłyby się sprawdzić. Zwykle tych pomysłów jest za dużo i trzeba się dobrze zastanowić jak wybrać tylko te wartościowe. Jak więc rozpoczyna się cykl życia robota? Konieczne jest zbudowanie procesu pozwalającego efektywnie ocenić według obiektywnych kryteriów, które roboty przyniosą największe korzyści. Nie jest to trywialne zadanie. W krótkim wpisie mogę je wyłącznie zasygnalizować i podkreślić, że obiektywność kryteriów jest tu absolutnym kluczem do sukcesu.

Bardzo dobrym pytaniem, które warto zadać na samym początku, jest to, czy na pewno w konkretnym przypadku potrzebujemy robota. To, że robot może coś zrobić nie oznacza, że powinien. Często są inne, prostsze rozwiązania, które warto wziąć pod uwagę. Jakkolwiek robotyzacja jest szybka i efektywna, to jest jednak dość złożonym przedsięwzięciem informatycznym, więc warto po nie sięgać z rozwagą.

Co napisać przed kodowaniem, czyli dokumentacja projektowa

Zgodnie z manifestem agile – działające oprogramowanie jest ważniejsze niż szczegółowa dokumentacja. Trudno się z tym nie zgodzić. Jednak nawet najzagorzalsi zwolennicy zwinnych metod wiedzą, że wcześniej, czy później nadchodzi moment, kiedy trzeba sięgnąć do oryginalnych założeń, żeby zrozumieć, czy robot rzeczywiście robi to, co powinien.

Są dwa podstawowe dokumenty, które warto przynajmniej naszkicować, aby uniknąć frustrujących dyskusji w trakcie testów akceptacyjnych. Pierwszy z nich to PDD (Process Design Document). Jest tworzony przede wszystkim przez analityków biznesowych. Pomaga programistom zrozumieć w jaki sposób działa proces, jakimi regułami jest sterowany, jak obsługiwać przypadki szczególne oraz błędy. Dobry dokument PDD powinien zawierać mapę procesu.

Drugi z dokumentów to SDD (Solution Design Document) tworzony zwykle przez architektów procesów dla programistów. Dzięki SDD programiści powinni mieć jasność jakimi standardami się posłużyć w kodowaniu konkretnego procesu, jakich szablonów użyć, a także jakich gotowych komponentów.

Doświadczony zespół deweloperski może zrezygnować z SDD. Ostatecznie działający kod robota jest wcieleniem SDD w realną implementację, więc może na końcu służyć jako samodokumentujący się kod.

To, co tygrysy lubią najbardziej, czyli dewelopment

Roboty są bardzo wdzięcznym polem do popisu dla zwinnych metod wytwarzania oprogramowania. Są ze swojej natury zgodne z duchem agile, czyli ciągłym, przyrostowym budowaniem nowej wartości. Dzięki temu, że najlepsze platformy robotyczne oferują wsparcie dla procesu kodowania, zwykle oferując graficzne reprezentacje procesów, kodowanie robotów często polega na wyborze odpowiednich gotowych komponentów.

Z mojego doświadczenia powiem, że w trakcie kodowania należy skupić się na dwóch aspektach, które przynoszą korzyści w długiej perspektywie.

Pierwsza to technika peer review, która polega na ocenie wytworzonego kodu przez koleżanki i kolegów z zespołu. Świetnie wspiera ona wymianę wiedzy i podnosi jakość nie tylko wybranego fragmentu rozwiązania. Długofalowo regularne stosowanie peer review pozwala uniknąć bardzo kosztownych błędów i daje możliwość podnoszenia poziomu kompetencji całego zespołu. Często zdarza się, że w trakcie wspólnej oceny kodu najbardziej doświadczeni członkowie zespołu dostrzegają obszary, w których sami mogą się poprawić. Peer review wbrew pozorom jest jedną z najbardziej cenionych i lubianych technik związanych z agile.

Drugą praktyką, którą silnie rekomenduję, jest budowa automatycznych testów robotów. Wydawałoby się, że nie ma sensu budować robotów testujących roboty, bo to nadmiarowy wysiłek. Okazuje się, że w coraz bardziej zmieniającym się otoczeniu automatyczne testy pozwalają zaoszczędzić kosztownych przerw w pracy. Często zdarza się, że zmiany w oprogramowaniu pojawiają się nagle. Czasem pozornie niewielkie modyfikacje w jednym miejscu mają poważne konsekwencje w innym. Dzięki automatycznym testom takie anomalie wykrywane są zanim jeszcze trafią do środowisk produkcyjnych. Daje to szansę zespołowi robotycznemu na aktualizację kodu i uniknięcie zatrzymania pracy. Zwinna natura robotów pozwala na to, żeby taki szybko wykryty błąd mógł być równie szybko naprawiony.

Kiedy wsiąść do pociągu, czyli release management

Jednym z większych wyzwań związanych w wytwarzaniem oprogramowania jest synchronizacja wdrożeń zmian pomiędzy wieloma działającymi systemami. Firmy najczęściej optymalizują takie punkty synchronizacji budując tzw. „pociąg release”, co w praktyce oznacza, że co jakiś zdefiniowany odstęp czasu oprogramowanie jest wdrażane na produkcji, czyli pociąg zatrzymuje się na stacji niezależnie, czy ktoś na niej wsiada lub wysiada.

Niestety nawet taki pociąg ma swoje wady. Niektóre zmiany są pilne i należy je wdrożyć pomiędzy stacjami, co bardzo komplikuje tą już niezbyt prostą układankę.

Roboty świetnie nadają się do wdrażania niezależnie od jadącego pociągu release, co powoduje, że kosztowna synchronizacja jest niepotrzebna. Aby to było możliwe należy przede wszystkim zbudować odpowiedni system automatycznego wdrażania kodu, ale również przygotowywać roboty tak, aby działały zarówno ze starą, jak i nową wersją aplikacji, na których pracują. Oczywiście, takie roboty muszą również wykryć moment wdrożenia aplikacji, aby móc zastosować się do zmian. Wymaga to nieco dyscypliny, ale daje doskonałą elastyczność we wdrożeniach robotów.

Wszystko płynie, czyli zarządzanie zmianą

Niestety, nic nie jest dane raz na zawsze. Cyfrowi Współpracownicy również muszą się zmieniać w zależności od zmian aplikacji i procesów, na których pracują – tak przebiega cykl życia robota. Aby ten proces przebiegał bezbłędnie potrzebujemy nie tylko systemu rejestrującego nowe zgłoszenia oraz procesu nadawania odpowiednich priorytetów. Przede wszystkim powinniśmy dysponować repozytorium kodu robotów, żeby mieć pewność, że każdą zmianę wykonujemy na aktualnej wersji robota. Dodatkowo musimy również posiadać odpowiednio odseparowane środowiska deweloperskie i testowe, aby proces testowania był niezależny od działającego produkcyjnie robota.

Czuję, że ktoś mnie podgląda, czyli monitoring

O monitoringu pisałem już jakiś czas temu w artykule „Obsługa robota – jak dbać by nie zaniedbać”, dlatego nie będę powtarzał zawartych w nim rekomendacji. Podkreślę tylko, że nawet najmniejsza instalacja robotyczna nie będzie efektywna, jeśli nie zadbamy o to, aby była automatycznie nadzorowana. Rolą człowieka w procesie powinno być wyłącznie rozwiązywanie wyjątków i to tylko takich, które są nietrywialne i nieszablonowe. Wszystko inne należy oddać w ręce robotów.

Czas powiedzieć żegnam, czyli wycofanie robota

Nawet najlepiej działający robot kiedyś kończy swoje działanie. Zwykle dzieje się to z powodu zaprzestania wykonywania procesu lub jego automatyzacji przy pomocy innych narzędzi niż robotyczne. Należy pamiętać, aby za każdym razem wycofać takiego robota z użytku. Przede wszystkim pozwoli to zaoszczędzić licencji i infrastruktury oraz czasu potrzebnego na utrzymanie robota. Ważne jest, aby zachować całą dokumentację i kod robota. Dzięki temu będzie można go szybko przywrócić do działania, jeśli postanowimy wznowić proces. Dobrą praktyką jest też okresowa ocena sensowności dalszego działania robotów. Czasem okazuje się, że wolumen procesu spada do tak niskich wartości, że dalsze utrzymanie robota może nie być ekonomicznie uzasadnione, mimo że robot nadal może wykonywać swoje zadania. Należy pamiętać, że roboty mają sens tylko wtedy, kiedy ich praca przynosi namacalne korzyści.

Co z tego wynika, czyli podsumowanie

Jak widać nawet pobieżny opis cyklu życia robota może być tematem na dość długi artykuł. Nie oznacza to wcale, że robotyzacja jest trudna lub bardzo kosztowna. Wręcz przeciwnie – dobrze zbudowane procesy wytwarzania i monitoringu robotów powodują, że mogą one być budowane przez osoby niemające wykształcenia lub doświadczenia w IT. Jeśli zadbamy właściwie o to, żeby cykl życia robota był maksymalnie automatyczny, to osiągniemy prawdziwą demokratyzację wytwarzania robotów, czyli każdy będzie mógł zautomatyzować zadania, które najmniej chętnie wykonuje.

Warto podjąć się tej pracy.