blog.testowka.pl

Bardzo często na wszelkiego rodzaju szkoleniach z metodyk i zarządzania projektami mówi się o tak zwanych wąskich gardłach, niestety bardzo rzadko ktokolwiek wspomina o tym co należy zrobić, gdy takie wąskie gardło już znajdziemy.
Żeby lepiej ugryźć ten temat przeanalizujmy potencjalny sposób przyspieszenia prac w projekcie – próba zwiększenia efektywności na każdym z etapów wytwarzania oprogramowania. Wielu managerów skupia się na tym by poszczególne zespoły, członkowie zespołów zwiększały swoją efektywność przez co dążą do zwiększenie efektywności całkowitej pracy nad projektem. Jeśli praca na wszystkich etapach przebiega równomiernie (nie mamy istotnych wąskich gardeł) zwiększenie wydajności w każdym etapie spowoduje zasadnicze przyspieszenie prac w całym projekcie. Niestety wystarczy już jedno wąskie gardło by pomimo zwiększenia efektywności na wszystkich innych etapach skutecznie spowolnić pracę w całym projekcie (zakładając względnie równomierny wzrost efektywności na każdym etapie, zwiększenie efektywności na etapie będącym wąskim gardłem niczego nie zmieni, gdyż nadal będzie to wąskie gardło).

Zastanówmy się może skąd się biorą wąskie gardła. Najczęstszą przyczyną powstawania wąskich gardeł jest niedobór zasobów (pracowników, technologi, wiedzy) na jednym z etapów projektu i/lub nadmiar w innych częściach zespołu/projektu. Niektóre zadania po prostu wymagają znacznie więcej czasu niż inne – np. wymyślenie i zaimplementowanie skomplikowanego algorytmu szyfrującego jest trudniejsze i bardziej czasochłonne niż zdefiniowanie wymagań dla takiego algorytmu.

Istnieje wiele różnych sposobów wykrywania wąskich gardeł, jednym z nich jest np. tablica kanbanowa z wprowadzonymi limitami zadań znajdujących się w poszczególnych fazach produkcji. Różne inne sposoby monitoringu, nadzoru pracy, monitorowania postępów, mierzenia czasu pracy etc. także bywają pomocne przy lokalizowaniu wąskich gardeł.

Dobrze dajmy na to, że już znaleźliśmy wąskiego gardło:
Załóżmy że mamy zespół składający się z 4 programistów i jednego testera. Zastosowaliśmy tablicę kanbanową z limitami odpowiedni 4 zadania w develompencie i 1 zadanie w fazie testowania w tym samym czasie (przydział naturalny – badania pokazują, że ludzie są najefektywniejsi gdy pracują nad jednym zadaniem – jednowątkowo). Okazuje się, że programiści (jako zespół) znacznie szybciej kończą swoje zadania niż tester jest w stanie je przetestować. Średnio czas zaprogramowania funkcjonalności okazał się dwukrotnie dłuższy niż czas jej przetestowania co w efekcie spowodowało, że tester miał dwa razy więcej zadań niż mógł przetestować.
Pobawmy się w dosyć śmieszną pseudo matematykę, żeby lepiej zobrazować problem.

Na tym etapie dokonano pewnych zmian, które miały na celu zwiększyć wydajność pracy każdego z członków zespołu o 50% – wdrożenie się udało. Zobaczmy więc jak wygląda sytuacja po zwiększeniu efektywności. Dzięki temu rozwiązaniu teraz tester mógł przetestować trzy zadania w tym samym czasie co wcześniej dwa, niestety tym samym programiści byli w stanie dostarczyć o połowę więcej zadań do testów niż poprzednio przez co wąskie gardło nadal pozostało wąskim gardłem.

Poszukajmy więc alternatyw…
Niestety mamy ograniczony budżet i nie możemy pozwolić sobie na zatrudnienie większej liczby osób.
Widzimy, że mamy za dużo programistów a za mało testerów, może więc powinniśmy jednego z programistów w razie potrzeby wykorzystywać jako testera, chwilowo zmniejszy to ilość dostarczanych funkcjonalności i tym samym pozwoli na przyspieszenie etapu testowania – wąskie gardło będzie odrobinę szybsze, może nawet całkowicie zniknie – super – udało się. Ale zaraz, teraz jeden z programistów stał się testerem – coś tu jest nie tak – przecież płacimy temu gościowi za programowanie a nie za testowanie, on sam pewnie też to dosyć szybko zauważy i zapewne jego morale spadną, a w rezultacie może nawet zmieni pracę bo nikt nie chcę pracować dla pracodawcy, który nie wywiązuje się z zawartych umów, a w jego umowie jasno było napisane, że jest programistą a nie testerem. (evil: A niech się zwalnia – w jego miejsce zatrudnimy testera
Kolejnym sposobem na zlikwidowanie wąskiego gardła mogło by być spowolnienie pracy programistów. TAK – SPOWOLNIENIE! Ale jak to?! Przecież w zarządzaniu chodzi o zwiększanie efektywności, przyspieszanie, dostarczanie produktu na czas etc. Otóż nie zawsze, efektywność okazuje się być bez znaczenia w miejscach nie będących wąskim gardłem [Cockburn 2008]. Jeśli już mamy wąskie gardła, to zwiększenie efektywności w innych miejscach w niczym nam nie pomoże, wręcz przeciwnie może spowodować jeszcze większe straty np. wzrost frustracji testerów spowodowany nadmiarem zadań i nierealnymi terminami, konflikty pomiędzy testerami a resztą zespołu spowodowane naciskami ze strony tych drugich na szybsze wykonywanie zadań testerskich, mniejsza dokładność testów w celu przetestowania większej ilości funkcjonalności itd.

Co zatem należy zrobić?
Jeśli mamy już sytuację jak opisaną powyżej to warto zastanowić się nad tym dlaczego praca testerów zajmuje tyle czasu i co zrobić by ją przyspieszyć. Żeby przeanalizować ten problem trzeba by sięgnąć do korzeni – po co jest testowanie? Testowanie służy odnalezieniu błędów. Dlaczego testujemy? Testujemy, gdyż zakładamy że dostarczona funkcjonalność zawiera błędy. Z powyższej toku myślowego wynika, że jednym ze sposobów rozwiązania problemu wąskiego gardła z powyższego przykładu mogło by być dostarczanie do testów funkcjonalności o wyższej jakości. Jak to zrobić? Sposobów jest wiele – począwszy od dbania o jakość od samego początku np. poprzez zastosowanie TDD co także zwiększy pokrycie kodu testami automatycznymi dzięki czemu zmniejszy się czas testów regresyjnych, skończywszy na poświęceniu większej uwagi planowaniu i zrozumieniu wymagań przez programistów, czy też zastosowanie wielu innych dobrych praktyk programistycznych takich jak na przykład Code Review. Zastosowanie któregoś z powyższych rozwiązań niesie ze sobą podwójne korzyści: programiści muszą poświęcić więcej czasu na pisanie testów, planowanie, analizę, dzięki czemu wąskie gardło testerskie nie zapycha się, a także wzrasta jakość kodu i funkcjonalności, przez co zmniejsza się ilość poprawek i re-testów, dzięki czemu tester ma więcej czasu. Kolejnym bardzo ważnym aspektem takiego rozwiązania jest także wzrost zaufania testerów do produktów dostarczanych przez programistów (czasem bywa to zgubne, niemniej jednak w większości przypadków skutkuje polepszeniem atmosfery, lepszą komunikacją i ostatecznie większą ilością sukcesów).

Powyższy opis problemu i propozycja jego rozwiązania dotyczyły wąskiego gardła na etapie testowania, ale zasada jest dosyć ogólna – nie należy zwiększać efektywności w miejscach które nie są wąskimi gardłami (może to np. dotyczyć sytuacji gdy 7 programistów okupuje jednego DBA – wtedy też należy programistów zmusić do przeprowadzania analizy problemów po ich stronie, a do DBA kierowania tylko próśb o podjęcie ostatecznych decyzji w rozpracowanych wcześniej problemach, lub próśb o pomoc w sytuacjach krytycznych). Oczywiście jeśli nie ma wąskich gardeł, lub wszystkie zlikwidowaliśmy możemy dalej pracować nad równomiernym wzrostem efektywności pamiętając o tym by nie stworzyć kolejnych newralgicznych punktów w naszym procesie.

Warto też pamiętać o wąskich gardłach przy budowaniu budżetu projektu, czy też zatrudnianiu nowych pracowników.

Zapraszam na webinarium które poprowadzę w najbliższą środę (20-10-2010) o godzinie 13.00 w ramach cyklicznych e-seminariów Polskiej Grupy Scrum.

Zapisy na www.scrum.org.pl.

Temat spotkania ponownie związany z automatyzacją testów. Postaram się przybliżyć samą idee automatyzacji oraz zademonstrować kilka dobrych praktyk ułatwiających życie każdego testera. Nie zabraknie również rozwinięcia podstawowych zasad Continous Integration, oraz wskazówek jak testować w projektach Agile’owych.