-
Jak dobrze budować systemy rządowe?
Właśnie w ostatni weekend kolejny raz wyszły na jaw istotne niedociągnięcia w ważnym państwowym systemie informatycznym – okazało się, że system ePUAP (platforma przez którą obywatele mogą załatwić elektronicznie sprawy urzędowe) nie posiadał możliwości automatycznego przejęcia obsługi przez serwery zapasowe w razie awarii serwerów podstawowych. Wymagało to ręcznej pracy administratorów i w konsekwencji zajęło cały dzień jak ujawniła Minister Cyfryzacji.
Więcej o sprawie można przeczytać na blogu Niebezpiecznik.pl. Czytając tą relację warto zwrócić uwagę na dwie rzeczy.
Po pierwsze audyt tegoż systemu zamówiony przez nową Minister Cyfryzacji (którego fragmenty publikuje Niebezpiecznik.pl) koncentruje się na dokumentacji. Rzecz typowa dla audytorów, którzy najczęściej pochylają się właśnie nad szeroko rozumianymi „kwitami” co nie zawsze pokazuje meritum sprawy. Tak jest i w tym przypadku, bowiem jeśli jakiekolwiek działania naprawcze wymagają wykonania skomplikowanych kroków opisanych w rozlicznych dokumentach to można spokojnie przyjąć, że nawet jeśli owe dokumenty istnieją i opisują te kroki prawidłowo – to i tak będą praktycznie bezużyteczne. Zamiast mnożyć dokumenty należy maksymalnie uprościć wszelkie działania (w czym pomaga jak najdalej idąca ich automatyzacja) a następnie ćwiczyć je w warunkach możliwie zbliżonych do produkcyjnych – lub wręcz na środowisku produkcyjnym (por. Google DiRT). Chodzi o to, by kiedy dzieje się coś złego admini od razu wiedzieli co robić – i umieli to robić niemal z zamkniętymi oczami – a nie przystępowali do wertowania dokumentacji.
Po drugie na pochwałę zasługuje otwartość z jaką Minister Cyfryzacji Anna Streżyńska poinformowała o sytuacji jak i stanie systemu ePUAP (musi on być opłakany, skoro ponoć gdyby nie konieczność zwrotu środków UE uzyskanych na jego budowę najlepiej byłoby go w/g słów pani minister „zaorać”). Jest to w ogóle jedna z tych postaci w nowym gabinecie, która cieszy się szacunkiem środowiska niezależnie od politycznych przekonań, co może cieszyć.
Są to jednak dwie uwagi poboczne wobec meritum problemu, nad którym chcę się pochylić a mianowicie czemu właściwie systemy rządowe są najczęściej drogie i marne. Jak wspomniałem nie jest to przecież pierwsza wpadka tego rodzaju – że tylko wspomnę o systemie (dużo przecież prostszym) który miał policzyć głosy w wyborach samorządowych a po prostu nie działał. I nie jest to wyłącznie domena Polski.
Moim zdaniem głównym źródłem problemu jest sama metoda tworzenia takich systemów. Zły jest bowiem nie tylko sposób ich zamawiania na rynku – zaszyty niestety „na sztywno” w ustawie o zamówieniach publicznych – błędne jest samo założenie, że państwo ważne systemy powinno w ogóle zamawiać od firm jako produkty lub w modelu projektowym.
Przeanalizujmy najpierw obie te rzeczy po kolei a następnie spójrzmy na to jak powinno to wyglądać.
Obecny obyczaj jest taki, że jak państwo potrzebuje jakiegoś systemu to zamawia go „pod klucz” na rynku rozpisując w tym celu przetarg. Najważniejszym problemem tych przetargów jest nawet nie to, że głównym kryterium jest najniższa cena (co nieuchronnie prowadzi do zaniżania oszacowań w dół a następnie patologii podczas realizacji, których symbolem w folklorze Agile jest tzw. „wiewiórkoburger”), ale sam fakt, że przetargi te są uosobieniem modelu kaskadowego (i jedną z jego ostatnich ostoi). W modelu tym zakłada się, że całość systemu ma zostać wyspecyfikowana z góry a następnie dostarczona w całości w jednym momencie – lub co najwyżej w kilku dużych etapach. Prowadzi to nieuchronnie nie tylko do budowania funkcji zbędnych ale i pominięcia funkcji potrzebnych, na które albo nie wpadli twórcy specyfikacji albo też potrzeba których ujawniła się dopiero z czasem. Innymi słowy, model taki gwarantuje, że funkcje systemu będą nieadekwatne i niewystarczające.
A to tylko początek, czubek góry lodowej problemów z tym modelem. Czytelników mojego bloga nie będę zanudzać szerszym wykładem dlaczego model kaskadowy jest nieadekwatny dla budowy skomplikowanych systemów informatycznych – dość się o tym mówi i pisze od lat. Dość podsumować, że mamy tu zły proces, co gorsza mocno umocowany w prawie.
Jakie powinno być zatem właściwie podejście do budowy takiego systemu? Oczywiście zwinne – a więc powinno się ustalić bieżącą listę najważniejszych wymagań wobec systemu, która nie musi być kompletna ale wystarczyć na 2-3 miesiące pracy. Następnie zespoły (początkowo zapewne jeden) powinny przystąpić do budowy systemu w krótkich, 2-3 tygodniowych iteracjach, wydając po każdej z nich kompletny, technicznie gotowy system na serwery produkcyjne. Po osiągnięciu jakiejś bazowej funkcjonalności efekt każdej takiej iteracji powinien być dostępny dla użytkowników (w przypadku ePUAP i innych systemów tego typu oznacza to także ogół obywateli) a używanie dostępnych funkcji powinno być mierzone i analizowane. Użytkownikom należy nadto udostępnić metodę łatwego zgłaszania pomysłów i potrzeb. Prowadzący rozwój systemu wybierałby na tej podstawie rzeczy najważniejsze do realizacji w kolejnej iteracji – i w ten sposób system non-stop poszerzałby swoje możliwości – ale zawsze o rzeczy w danej chwili najbardziej potrzebne. Zasadniczo zredukowałoby to zarówno marnotrawstwo jak i szanse pominięcia jakiejś istotnej dla dużej grupy użytkowników funkcji.
Znowuż, dla osób zaznajomionych z nowoczesnymi metodami zarządzania rozwojem oprogramowania są to rzeczy do znudzenia wręcz oczywiste (jeśli dla kogoś stanowią nowość najwyższy już naprawdę czas zaktualizować swoją wiedzę w tym zakresie – na dobry początek proponuję moją książkę – podręcznik metod z rodziny Agile). Niestety, jak już napisałem w administracji państwowej brak nie tylko wiedzy i świadomości (jakże często decyzje o zakupie systemów podejmują ludzie, którzy nie rozumieją zasadniczych różnic pomiędzy prowadzeniem inwestycji w system informatyczny w stosunku do np. w budowy szpitala) – prawo wręcz zasadniczo utrudnia urzędnikom pracę w ten sposób.
Wszelako jak już zasygnalizowałem powyżej problem tkwi jeszcze głębiej – w samym założeniu, że system tego rodzaju w ogóle musi być zamawiany jako produkt od firmy a nie po prostu organicznie rozwijany przez odpowiedzialną za niego instytucję. Tymczasem to właśnie – rozwijanie go przez ludzi bezpośrednio zatrudnionych przez np. Ministerstwo Cyfryzacji – byłoby absolutnie najlepsze pod każdym względem. Po pierwsze dlatego, że wówczas nic nie stałoby na przeszkodzie by zastosować metody zwinne usuwając wszystkie problemy jakie generuje model kaskadowy. Po drugie dlatego, że wówczas system budowałoby grono informatyków związanych z nim od samego początku – a jak pokazuje doświadczenie dużo łatwiej o zaangażowanie w produkt takiego zespołu niż pracowników firmy będącej dostawcą (albo – najpewniej – poddostawcą dostawcy). Co więcej, nie groziłaby wówczas ani utrata wiedzy o systemie ani możliwości jego stałego rozwoju – a takie ryzyko zawsze wiąże się z ew. upadkiem lub rozwiązaniem się firmy-dostawcy. Po trzecie, tak byłoby taniej gdyż nie trzeba by było płacić niezbędnej marży dostawcy – co mogłoby się albo przełożyć na oszczędności albo umożliwić pozyskanie do zespołów lepszych specjalistów przez zaoferowanie wyższych zarobków.
Sztandarowym projektem, który dobitnie pokazuje przewagę opisanego podejścia nad przetargami na realizację w/g specyfikacji jest projekt FBI Sentinel. Był to projekt budowy centralnego systemu informacji o sprawach, osobach itp. dla agentów FBI. W dużym skrócie po upadku wcześniejszego projektu (system nie działał) wartego miliony i 4 latach trwania kolejnego, w czasie którego Lokheed Martin zdążył spalić kolejne miliony nie dostarczając nic działającego system skończono po prostu ekipami programistów pracującymi w krótkich sprintach (chyba nawet w Scrumie)… w budynku FBI w Waszyngrtonie. Więcej o tym można poczytać tu, tu i tu.
Może się jednak okazać, że brakuje funduszy na zatrudnienie zespołu (przyczynek do szerszej refleksji nad sensownością wydawania pieniędzy przez rząd, który jest w stanie wykładać pieniądze na zupełnie bezsensowne rzeczy ale nie miałby ich na pensje dla grupy fachowców zdolnych zbudować i utrzymać kluczowy dla państwa system? Co najmniej bez sensu). Istnieje wtedy jeszcze jeden sposób na zbudowanie takiego systemu, który byłby skuteczny i zapewniał wysoką jakość rozwiązania: projekt open source. Ministerstwo musiałoby zatrudnić tylko kilku kluczowych developerów, którzy położyliby podwaliny pod system (napisali jego wstępny zrąb) oraz dbaliby o jakość kodu (poprzez głównie akceptowanie lub nie kodu innych ludzi). Następnie należy odwołać się do społeczności informatycznej w Polsce o wsparcie projektu nie finansowo ale wprost kodem. Jestem pewien, że niezależnie od polityki i tego kto aktualnie jest u władzy jest dość zaangażowanych informatyków, by projekt żwawo posuwał się do przodu. Mielibyśmy wówczas społecznie rozwijany system rządowy w modelu open source – coś, co miałoby szansę być ewenementem na skalę światową.
Pojawić się mogą zarzuty, że taki system nie byłby bezpieczny. Trudno się z nimi zgodzić – to właśnie podejście „security through obscurity” czyli bezpieczne, bo nikt nie wie jak to działa było historycznie źródłem największej liczby dziur w bezpieczeństwie. Dobry system oparty o kryptografię powinien oprzeć się atakom pomimo znajomości jego mechanizmów działania pod warunkiem zadbania o klucze kryptograficzne, które przecież nie stanowią części źródeł systemu. Co więcej, fakt weryfikacji mechanizmów przez wielu uczestników projektu powinien zapewnić wykrycie większej liczby potencjalnie zagrażających bezpieczeństwu błędów.
Małe szanse, że mój artykuł dotrze do Pani Minister ale gdyby tak się stało: proszę poważnie rozważyć po pierwsze zastosowanie organicznego rozwoju oprogramowania rządowego przez zatrudnionych wprost przez rząd informatyków a w razie gdyby to nie było możliwe odwołanie się do modelu open source i wsparcia społeczności. Wyjdzie na tym i Ministerstwo i my wszyscy dużo lepiej niż na rozpisaniu kolejnego przetargu na kolejny projekt.
-
Moc etykiet
Dowiedziałem się ostatnio o dość zaskakujących badaniach, które dobitnie pokazują jaki wpływ na postrzeganie ma język.
Mianowicie pewien badacz zauważył, że w starożytnych dziełach nie ma słowa na określenie koloru niebieskiego – a w szczególności nigdzie nie ma wzmianek o tym, by niebo miało jakiś szczególny kolor. Jest to jeszcze ciekawsze, jeśli połączymy to z badaniem pewnego współcześnie istniejącego w Afryce plemienia, które w swoim języku też słowa na określenie niebieskiego nie ma. Jak pokazały eksperymenty (polegające na pokazywaniu na ekranie kwadracików o różnych kolorach i proszeniu o ich rozróżnianie) ludzie z tego plemienia po prostu niebieskiego nie widzą – a ściślej nie rozróżniają od zielonego. Na tej podstawie postawiono dość śmiałą tezę, że starożytne ludy, które zbudowały fundamenty naszej cywilizacji nie tylko nie umiały niebieskiego nazwać, ale wręcz tego koloru nie dostrzegały właśnie dlatego, że nie umiały go nazwać (przeczytaj cały artykuł na ten temat – warto).
Piszę o tym, bo jest to świetny przykład na to jak silnie nasze myślenie kształtuje język, z którego korzystamy. Choć nasze oczy odbierają obiektywnie te same fale elektromagnetyczne, to co w efekcie widzimy wypływa ze świadomości. To spójne z wiedzą o funkcjonowaniu mózgu – w istocie nie widzimy „obiektywnie”, oczami, obraz dopiero kreuje mózg. A to na jakiej podstawie to robi jest mocno ugruntowane kulturowo, w tym oczywiście także przez język – najsilniejszy nośnik skojarzeń i obiektów, które można „zobaczyć”.
Skoro tak dzieje się z tak zdawałoby się obiektywną i prostą rzeczą jak kolory, to w takim razie o ile silniejsze jest samodefiniowane się człowieka poprzez etykiety, pod którymi się postrzega. W tym kontekście takie etykiety jak „tester” czy „programista” (albo „starszy referent”) od razu określają co ich nosiciele robią – a czego nie. Głównym problemem owych etykiet nie jest nawet to, że powodują odruchowe wręcz zawężanie zakresu postrzegania i odpowiedzialności (a ściślej klasyfikowania co jest rzeczą, którą powinienem się zająć i za którą odpowiadam, a co nie), ale to, że w kontekście pracy, w którym działają, niejako spłaszczają człowieka do jednego wymiaru, jednej umiejętności. To z koleji prowadzi nie tylko do silosów ze wszystkimi problemami, jakie one tworzą, nie tylko do poszukiwania lokalnych optymalizacji efektywności (w istocie psujących efektywność całości) ale przede wszystkim do niepełnego wykorzystania możliwości ludzi, którzy tworzą organizację.
Wydawałoby się zatem, że najlepiej byłoby nie nadawać żadnych nazw – po prostu pozbyć się etykiet niczym źródła zła. Przecież w małych firmach (często obecnie znanych pod niekoniecznie poprawnie użytą ale modną nazwą „startup”), gdzie z założenia wszyscy robią to co umieją i co jest w danej chwili potrzebne tak właśnie jest, a stanowiska i związane z nimi etykiety służą głównie do prezentowania się firmy na zewnątrz.
Jednak etykiet nie tak łatwo się pozbyć. W większych organizacjach jak również przy wieloetapowych procesach występuje konieczność jakiegoś nazwania i uporządkowania (zorganizowania) ludzi wykonujących różne prace choćby po to tylko by wiedzieć z czym móc iść do kogo bez konieczności znania wszystkich osobiście. Nadto obiektywnie istnieją też różne specjalizacje i specyficzne umiejętności, których złożenie jest potrzebne by dostarczyć usługę czy zbudować produkt. Niewątpliwie ułatwia i porządkuje tak myślenie jak i komunikację gdy można uprościć opis organizacji do ról i ich interakcji bez konieczności analizowania i opisywanie wielowymiarowego bytu jakim jest człowiek pełniący każdą z tych ról.
Powstaje zatem swego rodzaju sprzeczność – etykiety zawężąją postrzeganie i mają wiele niefajnych skutków ubocznych, wszelako opisanie załogi liczącej paręset osób firmy określeniem „ludzie” nie jest zbyt przydatne. Jak z tej sprzeczności wyjść?
Jednym rozwiązaniem jest to, co proponuje Scrum – w kontekście konkretnego zespołu wszyscy to „deweloperzy”, a pełniona rola zmienia się zgodnie z możliwościami człowieka i potrzebami zespołu. Wszelako jest to jednak „lokalna optymalizacja” – jeśli coś rozwiązuje, to tylko w obrębie jednego zespołu i tylko w obrębie kompetencji i umiejętności bezpośrednio związanych z jego pracą.
Szersze podejście proponuje Holakracja, która wprowadza explicite rozdział pomiędzy rolami a ludźmi. W ujęciu Holakracji organizacja jest stworzona z ról, które mają określone odpowiedzialności i uprawnienia. Ludzie nie są rolami, a jedynie je „animują”. Nie ma zatem relacji jeden-do-jeden między rolą a człowiekiem. Jeden człowiek może animować wiele ról jednocześnie (np. ta sama osoba może jednocześnie animować rolę „programista” jak i rolę „marketer w mediach społecznościowych”) jak również wiele osób może animować jednocześnie jedną rolę (np. trzy osoby animujące rolę „sprzedawca”). Z założenia ról nie tworzy się „dla ludzi” (czyli mając na uwadze konkretną osobę), ale by zaspokoić potrzeby organizacji – nowa rola tworzona jest wtedy, kiedy uważa się, że rozwiąże ona jakąś bolączkę, a nie wtedy kiedy trzeba kogoś zatrudnić czy znaleźć mu miejsce. Dopiero kiedy jest rola zastanawiamy się kto mógłby ją „animować”.
Wdrożenie Holakracji to duże przedsięwzięcie (wdrożyć ją w pełni nie jest łatwo – bagaż formalizmów i konieczność całkowitej zmiany sposobu funkcjonowania powodują, że jest to trudny proces), ale można wykorzystać to podejście do kwestii ról bez zastosowania całości. Wystarczy po prostu przyjąć ten sposób myślenia, ogłaszając go załodze wraz z wyjaśnieniem, a następnie wprowadzić jakiś widoczny sposób przypisywania ludzi do ról, w którym nie trzymamy się relacji „człowiek == rola”.
Można się przy tym wspomóc praktyką „Project Credits” z Management 3.0, która wprowadza dwa równległe systemy etykiet. Jedne to klasyczne „job titles”, które są raczej stałe i których używa się przede wszystkim na zewnątrz po to, by ludziom nie znającym dobrze naszej organizacji łatwiej było zrozumieć czym się mniej-więcej zajmuje dana osoba (a więc z czym można do niej przyjść). Drugie („Project Credits”) to kontekstowe i zmienne nazwy opisujące to, co dana osoba aktualnie robi. Oczywiście, wewnątrz organizacji dużo ważniejsze są te drugie etykiety.
To tylko dwa przykłady – z pewością da się wymyślić jeszcze inne praktyki. Najważniejsze to zerwać z etykietowaniem ludzi trwale opisem ich roli w ten czy inny sposób.
-
Czemu programiści nie chcą testować?
Taka dość typowa historia: w pewnym zespole programiści nie chcą zajmować się testami. Ba, Scrum Master, który jednocześnie jest też programistą przygotował nawet specjalną prezentację na ten temat by opowiedzieć o tym innym Scrum Masterom. Wynikało z niej, że testować ogólnie nie warto, bo programista przecież wie, że to co zrobił działa, więc to dla niego jest stratą czasu a poza tym programiści są od programowania, testów nie lubią. zresztą testy to coś pośledniejszego i oni się źle czują taką gorszą pracę wykonując. Więc nie będą.
Historię tą opowiedział mi niedawno zaprzyjaźniony Agile Coach z pytaniem dość oczywistym: co z takim przypadkiem robić? Oczywiście coś doradziłem (m.in. zasugerowałem szersze pochwalenie się na świecie kolegą Scrum Masterem – programistą, który tworzy bezbłędny kod – ktoś taki to prawdziwy skarb), miło porozmawialiśmy i być może nawet coś pomogłem. Niemniej pozostało poczucie pewnego niedosytu – miałem wrażenie, że w tej rozmowie nie doszliśmy do sedna sprawy.
Analizując przekonanie, że „programista nie powinien zajmować się testami” (względnie, że zajmowanie się nimi jest poniżej jego godności i statusu społecznego) dochodzę do wniosku, że opiera się ono przede wszystkiem na dwóch fałszywych przesłankach.
Pierwsza z nich, to przekonanie, że rolą programisty jest programowanie, a ściślej, że „rolą programisty jest tworzenie kodu”. Takie redukcjonistyczne podejście widzi osobę, która umie programować tylko w jednym wymiarze – tej właśnie jej umiejętności. Redukuje ją więc do biologicznej maszyny, która ma z punktu widzenia organizacji tą właśnie, jedną funkcję. Nie dziwota, że skoro maszyna „programista” umie tylko jedno – „tworzyć kod” – to trzeba ją odpowiednio nastawić, a więc poprzedzić ją maszyną „architekt”, która „zaprojektuje rozwiązanie” oraz dostarczyć jej półproduktu do przetwarzania, co jest zadaniem maszyny „analityk”, która go tworzy pod postacią „specyfikacji”. Po wyjściu z maszyny „programista” stawiamy maszynę „tester”, której zadaniem jest sprawdzić czy to, co zrobiła maszyna „programista” jest zgodne z tym, co wyprodukowała maszyna „analityk”. Wszystko na podobieństwo łańcucha wytwórczego w przemyśle.
Jak łatwo zauważyć wszystko jest zoptymalizowane na takie traktowanie pracownika począwszy już od etapu kształcenia (wąska specjalizacja), poprzez rekrutację (stanowiska opisane zadaniem, jakie ma być wykonywane) a kończąc na metrykach (godziny pracy tj. godziny wykorzystywania umiejętności). Dołóżmy do tego formowanie menedżerów w taki sposób, że każdy z nich niemal instynktownie czuje się zobowiązany do dbania o to, by każda maszyna (zasób) była maksymalnie zajęta – i mamy obraz dysfunkcyjnego mechanizmu, który umacnia to błędne przekonanie – a co za tym idzie jego konsekwencje.
Nie dziwne zatem, że wykształcona w tym kierunku i rozliczana z godzin programowania maszyna „programista” oburza się, gdy miałaby zajmować się czynnościami innych maszyn lub odpowiadać za ich wyniki. Nie dziwne, że osoba obsadzona w roli maszyny „programista” nie czuje się w pełni zaangażowana w produkt czy w całość pracy.
Tymczasem tak naprawdę zadaniem programistów, testerów i w ogóle wszystkich innych jest rozwiązywanie problemów użytkowników poprzez oprogramowanie, a więc dostarczanie użytkownikom nowych możliwości, które są dla nich wartościowe. Wymaga to wielu umiejętności i czynności – samo tworzenie kodu (a więc czynność przypisywana programistom) jest tylko jednym etapem tego procesu. Wśród tych umiejętności poza umiejętnością programowania mamy także umiejętności analityczne (rozumienie problemu) jak i związane z testowaniem oraz wiele innych. Wszystkie one są potrzebne i ważne, bo bez nich nie może powstać kompletny efekt pracy – a nie jest nim działające oprogramowanie, jest nim danie użytkownikowi wartościowych możliwości, których wcześniej nie miał.
Z pewnością jeśli zbierzemy zespół to różni jego członkowie mieć będą owe umiejętności rozwinięte i wyćwiczone w różnym stopniu. Jest to dobre, pod warunkiem, że będą z sobą współpracować w taki sposób by wykorzystać swoje silne strony i zminimalizować słabe, a więc możliwości zespołu były sumą ich możliwości. To zaś możliwe jest jedynie przy wspólnocie pracy (wszyscy razem tworzymy rozwiązanie dla naszego użytkownika/klienta) i odpowiedzialności za produkt. Innymi słowy „testera” równie interesuje poprawność rozwiązania co i „analityka” a programista przejmuje się nie tylko kodem, ale i tym czy ów kod działa oraz czy efekt jego działania spełnia oczekiwania klienta. Łatwiej jest stan taki osiągnąć jeśli patrzymy na zespół nie jako na zbiór odrębnych wyspecjalizowanych „maszyn” ale jako na grupę ludzi o różnych umiejętnościach, którzy wspólnie coś tworzą. Jak sądzę taki stan właśnie mieli na myśli twórcy Scruma kiedy nalegali, by wszystkich członków zespołu nazywać „developer” niezależnie od tego jaką specjalność reprezentują.
Druga fałszywa przesłanka, na której opiera się przekonanie, że „programista nie powinien zajmować się testami” to przekonanie, że „w pracy powinienem (wzgl. powinnam) zajmować się rzeczami przyjemnymi” połączone z brakiem odpowiedzialności za swoją pracę. Nastawienie takie nie jest szczególnie oryginalne, występuje nie tylko w naszej branży, przeciwnie – jest ogólną bolączką społeczną naszych czasów z ich naciskiem na „fun” i endemicznym brakiem zrozumienia dla takich pojęć jak obowiązek.
Temat to – wraz z naszym specyficznym tłem kulturowym – na osobny długi artykuł, dość powiedzieć, że konieczna jest pewna dojrzałość i odpowiedzialność, która powoduje, że wstydzimy się oddać pracę niekompletną. Oprogramowanie, które nie zostało przetestowane jest w sposób ewidentny niekompletne, zbudowane niezgodnie ze sztuką. Profesjonalny, odpowiedzialny programista powinien się tym przejmować i nie uważać, że czynności te go nie obchodzą i nie interesują. Nie powinien uważać, że to jest w porządku, że może oddać coś bo „u mnie działa” a sprawa ew. testów to już zajęcie dla kogoś innego, on jest ponad to.
Warto zauważyć, że w grach zespołowych – a Scrum to ma być „zespołowa gra w rozwój oprogramowania” (stąd nazwa) – choć są specjalności to jednak zawodnicy wychodzą poza nie jeśli jest to konieczne. Na przykład jeśli obrońca znajdzie się w sytuacji dogodnej do oddania strzału na bramkę przeciwnika to to zrobi, a nie będzie się wymawiał że on nie jest od tego specjalistą. Podobnie, napastnik nie będzie obserwował spokojnie z boku akcji drużyny przeciwnej twierdząc, że tą sprawą powinni zająć się obrońcy a jego to nie obchodzi, bo on się obronie źle czuje, pasjonuje go atak.
Ta metafora dość dobrze pokazuje o co chodzi. Nie idzie o to, że istnienie w zespole osób o specjalizacji bardziej ku testom („testerów”) nie ma sensu, przeciwnie, niemniej granica nie powinna być tak ostro zarysowana jak to ma miejsce ewidentnie w umyśle osoby, która zainspirowała ten przydługi artykuł. Innymi słowy nie powinno być podziału w zespole, powinna być współpraca, w ramach której każdy robi to co umie najlepiej – ale w miarę potrzeby także i to, co robi tylko przeciętnie, w ten sposób najlepiej jak umie wkładając swój wysiłek w pracę zespołu w danym momencie i na danym etapie. Oczywiście, jest to trudniejsze niż po prostu powiedzenie, że „ja nie będę tego robił” będące właśnie przejawem braku dojrzałości. W połączeniu z równie fałszywym przekonaniem, że celem metod Agile jest aby pracownikom – a szczególnie programistom – było miło i przyjemnie prowadzi to do wypowiedzi i postaw jak wyżej.
Co zatem należy robić? Po pierwsze usunąć mechanizmy organizacyjne, które mogą wzmacniać pierwsze przekonanie (przede wszystkim skończyć z naciskiem na to, by wszyscy byli zajęci i idiotycznym liczeniem godzin). Po drugie zdecydowanie walczyć z niedojrzałością i nieodpowiedzialnością, najlepiej już na etapie rekrutacji.