Jak rozpoznać sztuczną zwinność?

Na co zwracać uwagę, jeśli chcemy faktycznie uzyskać wartość ze zwinności? Jak rozpoznać sztuczną zwinność i jakie sygnały ostrzegawcze mogą wskazywać, że Agile w Twoje firmie nie działa, jak należy.

Odpowiedzi na te pytania rozwiniemy w tym artykule, a punktem odniesienia jest dla nas materiał „How to detect Agile BS”, stworzony przez Radę ds. Innowacji, mieszczącą się przy Departamencie Obrony USA. Dodamy do nich własne komentarze bazujące na naszym doświadczeniu, gdyż sami widzimy, że jest wiele firm, które deklaruje pracę zgodną z Agile, jednak brakuje u nich wielu krytycznych elementów niezbędnych w podejściu zwinnym.

Sztuczna zwinność – 6 sygnałów ostrzegawczych

Na wstępie dodajmy, że autorzy dokumentu często posiłkują się przykładami związanymi z wojskiem lub odnoszą się do niego. Wynika to z prostego faktu, że są oni związani z Departamentem Obrony.

1. Nikt z zespołu nie rozmawia i nie obserwuje użytkowników produktu w akcji

Odnosząc się do wojskowych przykładów, wyobraź sobie prawdziwych żołnierzy, którzy na polu walki albo w realiach ćwiczeń na poligonie korzystają z karabinu. 

Zwinność jest wtedy, gdy zespół projektowy faktycznie obserwuje i ma możliwość bezpośredniego kontaktu z użytkownikiem swojego rozwiązania. 

Ważne jest, aby opierać się pokusie rozmawiania z jakimś reprezentantem czy kierownikiem użytkownika, tylko z faktycznym użytkownikiem naszego rozwiązania. Możesz nawet zrobić mały eksperyment i najpierw porozmawiać z przedstawicielem użytkownika, a potem z użytkownikiem. Zobaczysz, jak diametralnie zmieni się Twoja perspektywa patrzenia na produkt i problem, jaki chcesz rozwiązać. Jest to nie do zastąpienia. 

Podobnie sprawa wygląda, gdy tylko Product Owner rozmawia i obserwuje użytkownika, a cała reszta zespołu otrzymuje relacje z drugiej ręki. Każdy taki pośrednik między członkami zespołu to ryzyko zaburzenia przekazu i efektu głuchego telefonu.

2. Końcowi użytkownicy produktu nie uczestniczą w procesie wytwarzania 

Punkt ten, podobnie jak poprzedni odnosi się do użytkowników końcowych, jednak tu autorzy kładą nacisk na włączaniu użytkowników ich do procesu projektowego.

Różnica między obserwacją, jak użytkownik korzysta z produktu, a zaangażowanie go w proces wytwórczy jest znacząca. Możliwość pokazania użytkownikowi produktu na wczesnym etapie jego tworzenia i otrzymanie informacji zwrotnej oraz wspólne szukanie najlepszego rozwiązania to bardzo sensowne podejście.

Użytkownik będzie tu po prostu współtwórcą rozwiązania. Dobrym pomysłem może być też zaproszenie do projektu (np. w ramach warsztatu) jakiegoś przedstawiciela klienta z naszej firmy, może być to np. pracownik call center. Oczywiście, nie będzie to, to samo, co współpraca bezpośrednio z użytkownikiem końcowym, jednak zawsze to lepsze rozwiązanie, niż brak tej perspektywy odbiorcy naszego rozwiązania.

3. Brak ciągłej informacji zwrotnej od użytkowników do zespołu wytwórczego 

Trzeci punkt nadal porusza kwestię użytkownika i podkreśla, że pojedyncze interakcje z nim się nie liczą, zwłaszcza jeśli są tylko podczas startowania projektu czy inicjatywy. 
Chodzi o sytuację, w której zespół projektowy nie ma dostępu do informacji zwrotnej przez cały okres procesu wytwórczego. A to powinna być naturalna kolej rzeczy, że w realiach produktowych mamy kolejne wersje, kolejne iteracje, kolejne przyrosty, kolejne prototypy, które są ciągle rozwijane i doskonalone na bazie bieżącego feedbacku, który jest dostarczany w sposób ciągły.

4. Zrealizowanie z góry zdefiniowanych wymagań jest ważniejsze niż dostarczenie na rynek czegoś wartościowego

Jeśli rozłożymy to zdanie na części to pierwsze, to:

• „z góry zdefiniowane” – czyli przygotowany przez kogoś jakiś zakres, jakaś dokumentacja czy analiza, która powinna zostać zrealizowana w konkretnej formie,
• dalej mówimy o wymaganiach, które mogą uśpić czujność zespołu deweloperskiego i stać się istotniejsze niż to, co faktycznie możemy dostarczyć na rynek – wartościowy i użyteczny produkt, rozwiązujący problemy użytkowników. 

Wcześniejsze punkty skupiały się mocno na użytkowniku, ten natomiast wskazuje na to, że powinniśmy być gotowi na pojawiające się zmiany w trakcie życia naszego projektu czy produktu z uwagi na napływającą informację zwrotną.

Jest bardzo niebezpieczne zwłaszcza przy większych przedsięwzięciach, gdy ktoś ustala jakiś zakres, obowiązkowe punkty, ktoś definiuje cechy produktu i określa plan prac. My z kolei kompletnie gubimy koncepcję szybkiego prototypowania, szybkiego dostarczenia MVP, czy jakiejkolwiek formy wczesnego dostarczenia, chociaż cząstkowej wartości. 

Przenosząc to na realia przykładu z karabinem, możemy wpaść w pułapkę wymyślenia genialnego projektu, który uwzględnia wszystkie możliwe wymogi, wszystkie możliwe warianty, wszystkie możliwe kombinacje. To z kolei powoduje, że całe to przedsięwzięcie wybudowania takiego karabinu będzie niezwykle rozwleczone w czasie. Zamiast poszukania jakiejś prototypowej wersji, która pozwoli szybko przetestować produkt w realnych warunkach i odkryć np. że z karabinka wypada magazynek na pociski, albo kolba jest jakaś wyjątkowo niefortunnie niewygodna.

5. Interesariusze projektu działają w izolacji od siebie 

Przedostatni punkt mówi o perspektywie interesariuszy. Tu musimy zaznaczyć, że raport mówi o interesariuszach w trochę innym znaczeniu, niż możemy być przyzwyczajeni, gdy patrzymy np. na świat perspektywą Scruma. 

Tutaj interesariuszem projektu mogą być developerzy, testerzy, osoby odpowiedzialne za bezpieczeństwo, osoby odpowiedzialne za zakupy, jacyś dostawcy, końcowi użytkownicy. Zatem interesariuszami są wszystkie osoby zaangażowane w projekt, które mają bezpośredni udział w działaniach i od których część działań zależy.

Trzeba mieć też na uwadze, że nie wystarczy zdefiniowanie wszystkich interesariuszy w raporcie i zaproszenie ich na kick off. Może to wywołać błędne poczucie, że wszyscy są poinformowani i wszyscy wiedzą, co mają robić. Jednym z fundamentów pracy zwinnej jest bliska i częsta współpraca wszystkich zainteresowanych. Dzięki temu unikamy sytuacji, w której, kiedy próbujemy połączyć w całość kawałki wykonane przez każdego samodzielnie bez kontaktowania się z innymi, a okazuje się, że nie otrzymujemy tego, czego byśmy się spodziewali. 

6. Ręczne procesy są tolerowane w sytuacjach, gdy mogą i powinny być zautomatyzowane 

Automatyzacja ta może dotyczyć różnych obszarów, np. testów czy procesu integracji, jeśli chodzi o wytwarzanie oprogramowania lub proces przesuwania gotowych rozwiązań ze środowisk testowych na środowiska produkcyjne. Pozwala to zdjąć ciężar wykonywania wielu zajęć w sposób manualny. 

Często obserwujemy, że zespoły mają świadomość, że brakuje im testów automatycznych, ale z ze względu na poczucie, że jest tyle do zrobienia, to za każdym razem decydują się na zrobienie ich w sposób manualny. Być może zyskują trochę czasu, ale patrząc na to długoterminowo, to tracą na takim podejściu. Inwestycja odrobiny czasu w testy automatyczne pozwoliłaby w przyszłości testować kolejne kawałki produktu w sposób automatyczny, dzięki czemu szybko odzyskano by zainwestowany wcześniej czas. Mniejsze byłoby też ryzyko pominięcia jakiś aspektów, co może mieć miejsce przy testach manualnych.

Szczególnie uderzające jest słowo “tolerowane”, które wskazuje na to, że cała organizacja jest z tym ok, że rzeczy, które mogłyby być zautomatyzowane, wciąż wykonywane są ręcznie. Można powiedzieć, że jest przyzwolenie na mniejszą efektywność i niższy standard jakości. Na szczęście coraz więcej firm widzi korzyści płynące z automatyzacji i inwestuje zarówno w odpowiednie kompetencje, jak i w infrastrukturę umożliwiającą jej wdrożenie.

Czy zgadzasz się z tymi 6 punktami wskazującymi na sztuczną zwinność? A może dodałbyś/dodałabyś coś od siebie? 

Dodatkowe materiały

• “How to detect Agile BS”

Transkrypcja podcastu „Jak rozpoznać sztuczną zwinność?”

Jacek: W dzisiejszym odcinku skupimy się na tym, jak rozpoznać sztuczną zwinność. Punktem odniesienia dla nas będzie materiał, który został stworzony przez Radę ds. Innowacji mieszczącej się przy Departamencie Obrony USA. Dokument nazywa się „How to detect Agile BS” i wskazuje obszary, na które warto zwrócić uwagę, jeżeli chcemy poważnie myśleć o uzyskiwaniu wartości ze zwinności.

Kuba: Materiał, o którym Jacek mówi, nie jest zbyt popularny, natomiast może być bardzo ciekawą formą kubła zimnej wody na temat tego, co potocznie jest nazywane, czy gdzieś kryje się pod buzz wordem Agile. Chcemy, żeby ten odcinek był swoistym ukłuciem, które pozwoli Ci przemyśleć, czy Twój zespół, czy Twoja firma, czy Twoja część struktury korzysta ze zwinności, w tym najgłębszym, najpełniejszym rozumieniu tego słowa czy rozumieniu tego nurtu. Wiele firm, wiele projektów, wiele produktów deklaruje, że rozwija się z wykorzystaniem Agile’a, ale tych elementów, które w tym odcinku wymienimy, bardzo często brakuje i tak naprawdę są to braki krytyczne. 

Jacek: Przytoczymy kluczowe sygnały ostrzegawcze przygotowane przez autorów materiału. Będzie ich sześć i dodamy do tego nasz komentarz. 

Kuba: Ale, zanim zaczniemy 6 sygnałów ostrzegawczych, przypominamy, że jeżeli chcesz pogłębić wiedzę jeszcze bardziej, niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep

Jacek: I przechodzimy do punktów wskazanych w raporcie. O czym mówi pierwszy punkt raportu Kuba?

Kuba: Pierwszy punkt mówi, nikt z zespołu nie rozmawia i nie obserwuje użytkowników produktów akcji. Tutaj jest ten wyjątkowo istotny smaczek, że jest to materiał zbudowany przez grupę związaną z Departamentem Obrony. I tak w ogóle Departament Obrony jest znany ze swojej inspiracji tego, czym Agile powinien być w bardzo poważnych projektach. Mówimy tu o realiach samolotów, wyposażenia nowoczesnego pola walki. I w tym kontekście warto to dopowiedzieć, że mówimy tutaj o faktycznych użytkownikach naszego rozwiązania. Tutaj w materiale jest wprost powiedziane software, ale myślę, że możemy to traktować rozszerzając o faktycznych użytkowników. No i przykład ten wojskowy, no to będziemy do niego wracać. Będę na parę sposobów przytaczał. Ale wyobraźmy sobie, że mówimy tu o prawdziwych żołnierzach, którzy w realiach albo faktycznego pola walki, albo w realiach ćwiczeń na poligonie korzystają na przykład z karabinu. I tutaj punkt o tym, że zwinność jest wtedy, gdy zespół twórczy, zespół projektowy faktycznie widzi, rozmawia, ma możliwość bezpośredniego kontaktu z użytkownikiem naszego rozwiązania. 

Jacek: I warto tutaj zwrócić uwagę, żeby opierać się pokusie rozmawiania z jakimś reprezentantem, przedstawicielem, liderem, kierownikiem, kimś, kto będzie dla nas taką pokusą pod tytułem – może nie musimy rozmawiać z tą faktyczną osobą, która korzysta z naszego produktu. Może lepiej porozmawiajmy z kimś, kto wie, albo może ktoś, kto zagreguje pewną wiedzę i na pewnym oczywiście uproszczeniu, czy uogólnieniu opowie nam, jakie są problemy. Mogę tu powiedzieć za siebie za każdym razem, kiedy jako programista miałem okazję rozmawiać z osobą, która używa produktu, który tworzę, no to były to doświadczenia zmieniające moją perspektywę na temat tego, jaki w ogóle problem chcemy rozwiązać. I moim zdaniem nie jest to do zastąpienia. Nie doświadczymy tego, jeżeli posłuchamy opowieści osoby, która w pewnym sensie już z drugiej ręki opowie nam, jak to wygląda w akcji. Moim zdaniem to trzeba zobaczyć. Tego trzeba doświadczyć. Jest to bardzo takie empatyczne doświadczenie. 

Kuba: I specjalnym typem takiego zaburzenia zwinności, o której tu mówimy, może być też bazowanie na pośrednictwie Product Ownera. Product Owner w naszym zespole rozmawia i obserwuje użytkownika, a cała reszta zespołu już zdaje się na relacje z drugiej ręki. Każdy pośrednik między członkami zespołu, którzy mogą wyciągać swoje własne wnioski na bazie swoich własnych obserwacji użytkownika, klienta czy odbiorcy, ktokolwiek jest to w naszym kontekście, każdy taki etap pośredni to będzie potencjał na wszystkie błędy czy pułapki efektu głuchego telefonu. 

Jacek: Drugi punkt wskazany w raporcie brzmi – końcowi użytkownicy produktu nie uczestniczą w procesie wytwarzania. Jest to punkt, który nadal dotyczy użytkowników. Jednak w przeciwieństwie do punktu pierwszego, tutaj bardziej mówimy o włączaniu faktycznych użytkowników produktu w proces wytwarzania. Różnica jest dosyć znacząca, bo jednorazowa okazja zobaczenia, jak użytkowany produkt czy nawet wielokrotna okazja, żeby zobaczyć, jak to wygląda w praktyce, to jednak jest nieco inne doświadczenie, gdy porównamy je do sytuacji, w której w procesie wytwarzania, czyli na bardzo wczesnym etapie, jesteśmy w stanie, bądź ramię w ramię z użytkownikiem podejmować pewne decyzje produktowe, bądź na bardzo wczesnym etapie. Mam na myśli na etapie, kiedy jeszcze większość rzeczy określilibyśmy jako rozgrzebane. Pokazać to użytkownikowi, usłyszeć informację zwrotną i wspólnie dojść do rozwiązania, które na ten moment dla tej pary współtworzącej będzie po prostu najsensowniejsze rozwiązaniem. 

Kuba: Ja wrócę do tego przykładu z grupą rozwijającą jakiś nowoczesny karabin. W tym punkcie mamy na myśli to, że faktyczni reprezentanci końcowego użytkownika, np. jacyś doświadczeni żołnierze działają, współdziałają na bieżąco z zespołem projektowym w czasie prototypu, w czasie jakiejś rozmowy o różnych możliwych udogodnieniach i są na wyciągnięcie ręki. Są tak naprawdę współtwórcami rozwiązania, a nie tylko osobami, z którymi kiedyś porozmawialiśmy, albo może kiedyś jeszcze do nich wrócimy. Nie tutaj Ten etap prawdziwa, głęboka, najbardziej zaawansowana zwinność to jest to, że w ramach zespołu projektowego mamy bezpośredni dostęp i możliwość zaangażowania, uczestnictwa w procesie przedstawicieli użytkownika końcowego. I nawet na próbę wyjdę z tej metafory czy analogii wojennej, czy wojskowej. W realiach wielu organizacji jest to jak najbardziej wykonalne, żebyśmy poprosili pracownika call center, osoby odpowiedzialne za jakiś proces, który właśnie cyfryzujemy, czy w ogóle jakiegoś typowego przedstawiciela klienta do tego, żeby w ramach jakichś warsztatów, w ramach jakichś działań planistycznych, po prostu wciągnąć do środka, do projektu. To oczywiście zawsze trzeba zorganizować, ale brak tego efektu może powodować, że bazujemy na naszych domysłach, a nasze produkty są takie z jakąś pułapką myślenia. Rzutowaniem tego, co my myślimy, że jest potrzebne, a nie tym, co jest naprawdę potrzebne. 

Kuba: Trzeci punkt w raporcie nadal mówi o użytkowniku. I tutaj jest przestroga, która brzmi brak ciągłej informacji zwrotnej od użytkowników do zespołu wytwórczego. Przenosząc to na realia tego przykładu z karabinem, chodzi o sytuację, w której zespół projektowy nie ma dostępu do informacji zwrotnej przez cały czas procesu tworzenia. A w realiach takich produktowych to dosyć naturalne jest to, że te kolejne wersje, kolejne iteracje, kolejne przyrosty, kolejno jakieś tam wersje beta, prototypy, one są ciągle rozwijane i doskonalone na bazie bieżącego feedbacku, który jest ciągły. Tutaj nie ma tego momentu, że już mamy wszystkie informacje. Już lepiej nie prośmy o te informacje od tych odbiorców. No i tutaj to już się przewija przez te trzy punkty. Prawdziwy, ostateczny użytkownik, a nie jakiś pośrednik. I tu też jest ważny akcent na to, że ta informacja ma być w trybie ciągłym, tak żeby ciągle ten produkt doskonalić. 

Jacek: Kolejny punkt brzmi, zrealizowanie z góry zdefiniowanych wymagań jest ważniejsze niż dostarczenie na rynek czegoś wartościowego. Czyli jeżeli obserwujemy takie zachowanie u nas, to na pewno jest to sygnał ostrzegawczy. Rozbierając to zdanie na części pierwsze z góry zdefiniowane, czyli ktoś przygotowuje jakiś zakres, jakąś dokumentację, analizę, jakiś materiał, który w tej konkretnej formie powinien zostać zrealizowany. Idąc dalej, mówimy tutaj o wymaganiach, czyli nawet jak po polsku posłuchamy, jak brzmi to słowo, to ono wskazuje na to, że to jest wymagane, że to powinno być, co być może uśpi czujność zespołu deweloperskiego. No jakby i to wszystko staje się istotniejsze niż to, co faktycznie możemy dostarczyć na rynek. Czyli zgodność z tym, co wyprodukowaliśmy w kontekście tego, co mieliśmy w dokumentacji, nie powinna być istotniejsza od tego, żeby dostarczyć coś wartościowego, co faktycznie może być użyteczne dla użytkowników i rozwiązywać jakiś problem na jak najwcześniejszym etapie. Wcześniejsze punkty mocno mówiły o użytkowniku, więc tak naprawdę powinniśmy już go mieć gdzieś w obrębie naszego produktu. Natomiast ten punkt wskazuje na to, że powinniśmy być gotowi na to, że zmiana ze względu na to, że chcemy słyszeć informację zwrotną, będzie się pojawiać w trakcie życia naszego projektu czy produktu. 

Kuba: Zwłaszcza większe przedsięwzięcia. Czy to jest duży projekt, czy to jest jakiś produkt, który planowany jest już od razu jako duży, może niebezpiecznie mocno wpadać w tę pułapkę, o którym mówi ten punkt z raportu? Ktoś ustala zakres, ktoś ustala jakieś obowiązkowe punkty, ktoś definiuje jakieś cechy produktu, które powodują, że ten produkt będzie taki wspaniały. I to wszystko zaczyna stawać się jakimś takim obciążeniem. Robimy projekt, produkt, który będzie rozwijany przez najbliższy rok, dwa albo jeszcze więcej. I kompletnie gubimy koncepcję szybkiego prototypowania, szybkiego dostarczenia jakiegoś MVP, jeśli możemy użyć tutaj tego skrótu, czy jakiejkolwiek formy wczesnego dostarczenia, chociaż cząstkowej wartości. I przenosząc to na realia tego przykładu z karabinem, to może być taka duża pułapka przemyślenia jakiegoś takiego genialnego pomysłu, który rozpisuje wszystkie możliwe wymogi, wszystkie możliwe warianty, wszystkie możliwe kombinacje, które powodują, że całe to przedsięwzięcie wybudowania takiego karabinu będzie niezwykle rozwleczone w czasie. Zamiast poszukania jakiejś prototypowej wersji, która być może na wczesnym etapie realizuje tylko jakąś część wymogów, na razie nie będzie doczepianej latarki doświetlającej w nocy, ale za to szybko będzie można to przetestować w realnych warunkach i odkryć na przykład, że wypada z karabinka magazynek na pociski, albo kolba jest jakaś wyjątkowo niefortunnie niewygodna. Więc tutaj koncepcja szybkiego dostarczenia, chociaż części, jako coś kompletnie przeciwstawne realizacji z góry zdefiniowanych, z góry zaplanowanych wszystkich cech, ficzerów czy wymagań w ramach danego produktu. 

Kuba: Przedostatnia przestroga. Sygnał ostrzegawczy o tym, że możemy mówić o sztucznej zwinności, jest zupełnie z innej perspektywy. Perspektywy interesariuszy projektu. Przestroga brzmi, interesariusze projektu działają w izolacji od siebie. I to jest bardzo ważne doprecyzowanie, że raport mówi o interesariuszach w takim znaczeniu trochę innym, niż możemy być przyzwyczajeni, gdy patrzymy np. na świat perspektywą Scruma. Tutaj dosłownie w raporcie po przecinku są wymienione takie perspektywy, że interesariuszem projektu mogą być developerzy, testerzy, osoby odpowiedzialne za bezpieczeństwo, osoby odpowiedzialne za zakupy, jacyś dostawcy, końcowi użytkownicy. Więc to jest takie rozszerzające zrozumienie interesariuszy jako osoby wszystkie zaangażowane w projekt, osoby, które mają bezpośredni udział w działaniach, osoby, od których część działań zależy. I tu jest bardzo silna przestroga, którą też jest moim zdaniem ważnym ukłuciem, czy działania, które są podejmowane w ramach zwinnego projektu, czy w ramach rozwoju produktów w zwinny sposób, czy one realizowane są w ścisłym współdziałaniu wszystkich możliwych interesariuszy, ekspertów, członków zespołu, członków zespołu rozszerzonego? Czy może niestety jest efekt każdy sobie rzepkę skrobie, czyli programiści robią swój kawałek, testerzy trochę równolegle, a trochę w izolacji od nich robią swoje rzeczy. Może jest szereg innych osób, od których zależy sukces projektu, które są kompletnie niezwiązane z tym, jak działamy jako zespół.

Jacek: I myślę, że tutaj  to jest taka delikatna różnica. Możemy mieć dobrze zdefiniowanych interesariuszy, tak jak definiuje to raport i mieć złudne poczucie, że przecież zrobiliśmy kick off. Wszyscy są poinformowani, wszyscy wiedzą, co mają zrobić, to po prostu zróbmy. Natomiast jednak jednym z fundamentów pracy zwinnej jest bliska współpraca, częsta współpraca. Co powoduje, że to takie bezpieczne funkcjonowanie tylko na swoim kawałku, na zasadzie odpowiadam od punktu A do punktu B i właściwie w punkcie C mnie nie interesuje, jest zaproszeniem do kłopotów, do porażek, do sytuacji, w których będziemy musieli pewną pracę wykonywać podobnie. No bo nagle się okaże, że pomimo takiego błogiego poczucia, że bardzo dobrze się dogadaliśmy, to nagle, kiedy próbujemy to połączyć w całość, to się okazuje, że rzeczy nie działają tak, jak byśmy oczekiwali. 

Jacek: Drugie zagrożenie może wynikać też bardzo mocno z tego, że jeśli w naszych działaniach będzie potrzebna zmiana, to może się nagle okazać, że pierwotne plany na współpracę między tymi różnymi zaangażowanymi podgrupami czy jakimiś autonomicznymi jednostkami nagle się sypią. Czyli współpracujemy dobrze ze sobą tylko pod warunkiem, że wszystko idzie zgodnie z planem. A w działaniach zespołów zwinnych, projektów zwinnych, to zgodnie z planem wcale nie jest mile widziane, na co wskazywały też te poprzednie przestrogi. Feedback od użytkowników, realizacja jakichś zmian, będzie wymagała też ścisłej współpracy pomiędzy różnymi stronami w projekcie. 

Jacek: Ostatni punkt wskazany przez autorów raportu brzmi, ręczne procesy są tolerowane w sytuacjach, gdy mogą i powinny być zautomatyzowane. I ta automatyzacja może dotyczyć różnych obszarów. To może być automatyzacja testów czy automatyzacja np. procesu integracji, jeśli chodzi o wytwarzania oprogramowania czy też procesu przesuwania gotowych rozwiązań ze środowisk testowych czy przedprodukcyjnych na faktyczne środowiska produkcyjne. No i oprócz tego cała masa innych obszarów, które można w jakiś sposób zautomatyzować i zdjąć trochę ciężar wykonywania tych zajęć w sposób manualny. Takim przykładem, który dosyć często obserwuję, są właśnie automatyczne testy, gdzie często zespoły wiedzą, że tych testów automatycznych brakuje, ale ze względu na poczucie, że jest tyle do zrobienia, to może kolejny raz zróbmy je w sposób manualny. W sensie nie inwestujmy czasu w to, żeby je zautomatyzować. Co powoduje, że wprawdzie zyskujemy trochę czasu, ale tak naprawdę nie czynimy żadnej inwestycji na przyszłość po to, żeby kolejne momenty, kiedy chcemy przetestować jakiś kawałek naszego produktu, żeby to już działo się automatycznie, przez co odzyskalibyśmy czas potrzebny na manualne przeklikiwanie się wyklikiwanie. I podejrzewam też, że bylibyśmy w stanie skorelować to też z podniesieniem jakości. No bo jednak te procesy automatyczne myślę, że mają mniejszą szansę, żeby o czymś zapomnieć.

Jacek: I w brzmieniu tej ostatniej rekomendacji szczególnie uderza mnie słowo tolerowane. Czyli tutaj jest pewien sygnał o tym, że cała organizacja, cała struktura projektu grupy rozwijającej produkt jakby jest OK. Z tym, że są pewne rzeczy, które mogłyby być zautomatyzowane i dawać mnóstwo konkretnych, kolejnych korzyści. Właśnie efektywność kolejnych kroków w procesie, upewnienie się co do standardu jakości. Też pewien rodzaj efektów korzystnych akurat przy okazji automatyzacji związanej z wytwarzaniem oprogramowania. Jakaś powtarzalność, jakieś przemyślenie architektury, mnóstwo korzyści i te korzyści są pomijane. I akceptuje się to, że wykonuje się mnóstwo ręcznej pracy, ryzykując jakość, ryzykując jakieś opóźnienia, czy niestety też sprowadzając całą grupę do takiego niebezpiecznego dylematu, czy może takiego rozważania pewnej decyzji, że może np. rzadziej integrujemy nasze rozwiązanie, rzadziej wdrażajmy, rzadziej wydawajmy kolejne wersje na rynek. No bo to jest duże obciążenie nakładu pracy, żeby powtórzyć wszystkie te manualne czynności. Na szczęście jesteśmy już w XXI wieku i te czynności się automatyzuje i należy w to zainwestować. Zainwestować w kompetencje, zainwestować w narzędzia, zainwestować w infrastrukturę, ale mieć taką możliwość. Zespoły wykonujące czynności manualne, które powinny być zautomatyzowane, w najlepszym razie nie są tak zwinne, jak być powinny, a być może w ogóle nie są z tego powodu zwinne. 

Jacek: Przeszliśmy po sześciu punktach, które zostały wskazane w raporcie i na koniec podsumujemy te punkty w jednej wypowiedzi. 

Kuba: Jak rozpoznać sztuczną zwinność? Nikt z zespołu nie rozmawia i nie obserwuje użytkowników produktu w akcji. Końcowi użytkownicy produktu nie uczestniczą w procesie wytwarzania. Brak ciągłej informacji zwrotnej od użytkowników do zespołu wytwórczego.

Jacek: Zrealizowanie z góry zdefiniowanych wymagań jest ważniejsze niż dostarczenie na rynek czegoś wartościowego. Interesariusze projektu działają w izolacji od siebie i ręczne procesy są tolerowane w sytuacjach, gdy mogą i powinny być zautomatyzowane. 

Kuba: Jeśli masz w swojej firmie potrzeby przeprowadzenia szkoleń lub warsztatów, polecamy się Twojej uwadze. W odróżnieniu od otwartych szkoleń z katalogu dopasowujemy zakres materiału do potrzeb, które diagnozujemy wspólnie z organizatorem. Zarezerwuj budżet, zaplanuj działania rozwojowe i odezwij się do nas porzadnyagile.pl/kontakt, jeśli możemy pomóc w Twojej sytuacji. 

Jacek: Wszystkie notatki do tego odcinka artykułu, transkrypcja oraz zapis wideo naszej rozmowy znajdziesz na stronie porzadnyagile.pl/99.

 Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek.

 Jacek: Dzięki Kuba. 

Kuba: I do usłyszenia wkrótce.