Zespoły programistyczne mają dziś większą swobodę niż kiedykolwiek wcześniej. Mają dostęp do szerokiej gamy narzędzi, a wiele z nich jest bezpłatnych. Dostępna jest obfitość komponentów open source, które można wykorzystać do tworzenia aplikacji. Co najlepsze, wielu pracodawców zachęca zespoły do samodzielnego konfigurowania systemów programistycznych i metodologii oraz do korzystania z własnych narzędzi.
Swoboda korzystania z narzędzi, metod i technologii, które najbardziej lubisz i najlepiej znasz, prawdopodobnie pozytywnie wpłynie na produktywność twojego zespołu — do momentu, w którym osiągniesz granice jego samowystarczalności.
Unikaj wąskiego gardła w testowaniu
Mój znajomy Jan kierował bardzo kompetentnym zespołem programistycznym w firmie tworzącej oprogramowanie na zamówienie. Doskonale rozumieli, jak działać zwinnie. Mieli jednak problem z jakością. Tak bardzo przyspieszyli cykl wydań, że testowanie stało się wąskim gardłem.
Usunęli to wąskie gardło, pomijając testy. Jan oczywiście rozumiał, co należy zrobić. Pobrał Robot Framework, wykorzystał go do zbudowania niestandardowego środowiska automatyzacji testów dla zespołu i podłączył je do potoku ciągłej integracji. Stopniowo dodawał coraz więcej testów i rozszerzał środowisko o dużą liczbę słów kluczowych wysokiego poziomu, aby ułatwić tworzenie skryptów testowych.
Tymczasem pozostałe zespoły — a było ich mnóstwo — doświadczały podobnych wyzwań i rozwiązywały je na własne sposoby, korzystając z Selenium lub wybranego przez siebie narzędzia.
Zespoły potrzebują środowiska automatyzacji dla wszystkich
Pesymiści twierdzą, że każde rozwiązanie zawiera zalążek nowego problemu. Jan szybko odkrył, że stał się pełnoetatowym inżynierem automatyzacji testów. Owszem, jego biblioteki były łatwe w użyciu — dla niego, a architektura testów była łatwa do zrozumienia — dla niego. W każdym innym zespole znajdował się współpracownik w takiej samej sytuacji. Jeden z nich zmienił pracę. Programistka, która go zastąpiła, postanowiła przepisać wszystko, ponieważ nie podobał jej się sposób zbudowania automatyzacji i trudno było jej go zrozumieć. Gdy coraz więcej zespołów zaczęło zgłaszać te wyzwania swoim menedżerom, pojawiło się oczywiste pytanie: dlaczego między zespołami nie ma spójności?
Trzeba było coś zrobić. Rozwiązanie było oczywiste: utwórzmy scentralizowany zespół automatyzacji testów, który będzie wspierał zespoły programistyczne, zapewniając wszystkim jedno środowisko automatyzacji. W praktyce zespół tworzyli Jan i jeszcze jeden programista. Wtedy właśnie zaczęła się prawdziwa walka.
Udostępniaj metodologię, nie tylko narzędzia
Testy często przestawały działać. To samo dotyczyło środowiska. Zespoły programistyczne miały trudności ze zmianą swoich praktyk tak, aby dopasować je do narzędzi, a zespół odpowiedzialny za narzędzia miał trudności z uwzględnieniem wszystkich tych różnych potrzeb. Złożoność środowiska wciąż rosła. Wąskie gardło w testowaniu przekształciło się w wąskie gardło narzędzi do automatyzacji testów.
Wspólne wewnętrzne narzędzia to piękny pomysł, ale trudno sprawić, by działał. Aby odnieść sukces, narzędziem trzeba zarządzać jak prawdziwym produktem i trzeba je dobrze testować. Paradoksalnie wewnętrzne środowiska automatyzacji testów często zawierają błędy. Istnieje jednak jeszcze większe wyzwanie. Aby na dużą skalę czerpać korzyści ze wspólnych narzędzi, potrzebujesz również wspólnej metodologii.
Historia Jana jest typowa — i jeszcze się nie skończyła. Obecnie rozważają kolejny krok: powrót do autonomicznych zespołów i zaakceptowanie związanych z tym kosztów, większe inwestycje we wspólne narzędzia i ustanowienie spójnej metodologii albo wybór komercyjnego narzędzia i skupienie się wyłącznie na metodologii. Żaden z tych wyborów nie jest błędny, ale każdy z nich będzie miał inne konsekwencje.
