Koszt dłuższego opóźnienia między opracowaniem a kontrolą jakości

Na moim obecnym stanowisku kontrola jakości stała się wąskim gardłem. Niefortunnie zdarzało się, że funkcje nie były dostępne w bieżącej wersji, aby kontrola jakości mogła zakończyć testy. Oznacza to, że opracowywane funkcje mogą nie zostać przetestowane przez 2-3 tygodnie po rozpoczęciu pracy dewelopera. Wraz z szybszym poruszaniem się deweloperów, ta przerwa czasowa będzie się powiększać.

Ciągle przeglądam moją kopię Code Complete, szukając fragmentu „twardych danych”, który pokazuje, że koszt naprawy usterek rośnie wykładniczo, im dłużej istnieje. Czy ktoś może wskazać mi jakieś badania potwierdzające tę koncepcję? Próbuję przekonać moce, że wąskie gardło QA jest o wiele bardziej kosztowne, niż im się wydaje.

Nie potrzebujesz żadnych referencji, IMHO. Oto, co możesz (a raczej powinieneś ) zrobić:

Oblicz koszt opóźnienia! Załóżmy, że testowanie funkcji trwa 1 tydzień. 2-3 tygodniowe opóźnienie oznacza, że ​​funkcja nie będzie dostępna do co najmniej 4 tygodnia. I to również przy założeniu 100% sukcesu. Dodaj czas ustalania terminu na kolejny tydzień, aby było to około 5 tygodni opóźnienia.

Teraz, jeśli to możliwe, uzyskaj dostęp do oczekiwanego terminu projektu / funkcji. Do kiedy klient tego oczekuje? Czy to się poślizgnie? Jeśli nie, czy w konsekwencji inni się poślizgną? Więc o ile opóźnienie „wydania” będzie w rezultacie opóźnione?

Jaki jest „koszt dla firmy” dla tego wydania, tj. Ile klient oczekuje na tym wydaniu? Jeśli spodziewają się zysku w wysokości 5200 USD rocznie z tego wydania, to co tydzień poślizg kosztuje ich 100 USD utraconych dochodów. To widok klienta. Możesz mieć dostęp do tych danych lub nie, ale warto to wziąć pod uwagę i określić, w jaki sposób opóźnienie może wpłynąć na relację.

Jaka jest strata dla programistów? Gdy programista przejdzie do innych funkcji, poprosisz go o przerwanie cyklu i „naprawienie” poprzedniej funkcji. Jaki jest strata czasu / wysiłku? Przelicz go na koszt firmy, używając wynagrodzenia jako wielokrotności za każdą marnowaną godzinę. Możesz użyć tego do określenia kwoty „zysku / przychodu”, do którego marnuje się „jedzenie”.

To, na co się natknąłeś, można wygodnie określić ilościowo za pomocą „kosztu opóźnienia” - zalecanego przez Dona Reinersteina w Zasadach rozwoju produktu, a także przez Dean Leffingwell w Agile Wymagania oprogramowania. Powinieneś być w stanie poprzeć każde takie twierdzenie czynnikami ekonomicznymi, aby przekonać „mocarstwa wyższe”, których podstawowym językiem jest $$ - musisz mówić w ich języku, aby ich przekonać :)

Bestia szczęścia! (gra słów :)

Naprawdę nie sądzę, aby Code Complete był tutaj odpowiednim materiałem. To nie jest problem z kodem, to problem z procesem i być może problem z zarządzaniem.

Jeśli część twojego procesu jest szczególnie słaba, nadszedł czas, aby rozwinąć teorię ograniczeń :

1. Zidentyfikuj ograniczenie.

   Oznacza to znalezienie najwolniejszej lub najbardziej nieefektywnej części całego procesu. W twoim przypadku to testowanie. Ale jaka część testów? Czy to jest:

   • Przygotowujesz środowisko testowe?
   • Ustalanie, co przetestować?
   • Testy funkcjonalne (akceptacyjne)?
   • Testy regresji?
   • Testy eksploracyjne?
   • Zgłaszanie błędów / usterek z testów?
   • Określanie kroków do odtworzenia błędu?
   • Uzyskujesz wyjaśnienia od programistów lub kierowników projektów?
   • Naprawianie problemów znalezionych na etapie kontroli jakości?

   Są to bardzo różne problemy i wymagają różnych rozwiązań. Musisz zdecydować, który jest najbardziej kosztowny / ważny. Usprawiedliwienie zarządzania nie powinno być trudne, ponieważ wszystkie powyższe działania kosztują czas (pieniądze AKA), a tylko kilka z nich to czas o wartości dodanej.

2. Wykorzystaj ograniczenie.

   Innymi słowy, optymalizuj wokół procesu ograniczania. Nie pozwól, aby testerzy byli bezczynni. Sprowadza się to zasadniczo do:

   • Umieszczanie testerów w zespołach programistów, jeśli jeszcze ich nie ma, dlatego istnieje ciągła pętla sprzężenia zwrotnego z programistami.
   • Częste wdrożenia testowe, więc zawsze jest coś nowego / naprawionego do przetestowania.
   • Szybsza i częstsza komunikacja. Na przykład faworyzuj wiadomości błyskawiczne nad wątkami e-mail.
   • Zapewnienie testerom najlepszych dostępnych narzędzi (szybkie maszyny, wiele monitorów, usprawnione śledzenie błędów itp.)

   Na tym etapie nie chodzi o optymalizację samego procesu testowania (jeszcze), chodzi raczej o zmniejszenie narzutu. Nie marnuj czasu testerów. Wyeliminowanie naprawdę zmarnowanego czasu powinno być również łatwą sprzedażą dla kierownictwa.

3. Podporządkuj inne działania ograniczeniu.

   W tym momencie testerzy są tak wydajni, jak mogą być sami, więc musimy zacząć pożyczać produktywność z innych obszarów:

   • Poinstruuj programistów i personel operacyjny, aby dali testerom pierwszeństwo bez względu na to, nad czym jeszcze pracują.
   • Jeśli nie masz zespołów wielofunkcyjnych, rezerwuj pokój konferencyjny codziennie o ustalonej godzinie, aby testerzy nigdy nie musieli tracić czasu na próby rezerwacji.
   • Odsuń nieco większy procent czasu programisty (i ewentualnie operacji) od pracy nad funkcjami; na przykład, skup się na naprawie błędów, zadłużeniu / refaktoryzacji technologii, sprawdzaniu kodu i testowaniu jednostkowym.
   • Testuj w sposób ciągły i przyrostowy - nie rozwijaj się przez 3 tygodnie, a następnie przekaż testerom. Poproś programistów o natychmiastowe przetestowanie kodu, np. Za pomocą rusztowań lub prototypowych interfejsów użytkownika.

4. Podnieś ograniczenie.

   Jeśli testerzy pracują na pełnych obrotach - zarówno pod względem wydajności, jak i minimalnego obciążenia - i wciąż nie jest wystarczająco szybki, musisz zacząć inwestować więcej w testowanie.

   • Jeśli polegasz na ręcznych wdrożeniach testowych, zautomatyzuj je za pomocą skryptów ciągłej integracji i zarządzania konfiguracją.
   • Jeśli tworzenie planów testów zajmuje dużo czasu, pracuj nad uzyskaniem lepszych kryteriów akceptacji (tj. INWESTUJ ). Większość organizacji początkowo jest w tym bardzo zła.
   • Jeśli testy akceptacyjne trwają zbyt długo, zacznij je automatyzować. Użyj narzędzia takiego jak Cucumber lub FitNesse, lub napisz testy typu xUnit, jeśli musisz. Istnieją również Selenium, Watij i inne narzędzia do automatyzacji przeglądarki, jeśli testowanie interfejsu użytkownika zajmuje dużo czasu.
   • Jeśli testy regresji trwają zbyt długo, zautomatyzuj to również. Jeśli nie można go zautomatyzować, skoncentruj się na poprawie jakości poza bramą, tj. Z jeszcze większym naciskiem na przegląd kodu, testowanie jednostek, narzędzia analizy statycznej itp. Deweloperzy powinni być pewni, że jest bardzo mało faktycznych błędów przed ich przekazaniem do kontroli jakości (wady produktu to inna historia).
   • Jeśli wąskim gardłem są testy eksploracyjne, możesz potencjalnie odroczyć niektóre z nich do czasu wydania lub zlecić firmie testowej wykonanie wysoce równoległych czynności, takich jak testowanie tego samego przepływu pracy w wielu przeglądarkach.
   • Jeśli testerzy nie są w stanie naprawić wielu błędów, rozważ zbudowanie środowiska do testowania wydajności, aby móc zacząć odtwarzać sporadyczne błędy. Lub spróbuj uruchomić automatyczne testy akceptacyjne równolegle i nieprzerwanie przez cały dzień, zachowując szczegółowe dzienniki.
   • Jeśli naprawa błędów zajmuje zbyt dużo czasu, rozpocznij partycjonowanie projektów i / lub poważnie rozważ ponowne przeanalizowanie swoich rozwiązań. Lub, alternatywnie, nie naprawiaj niektórych z nich; nie każdy błąd jest krytyczny, powinieneś być w stanie nadać im priorytet przy pracy nad funkcjami.
   • Jeśli wszystko inne zawiedzie, zatrudnij więcej testerów.

5. Wróć do kroku 1.

Chciałbym powiedzieć, że jest to zdrowy rozsądek, ale niestety tak nie jest, przynajmniej nie w większości organizacji. Jeśli napotykasz duży opór ze strony kierownictwa, nieocenioną techniką jest Mapowanie Strumienia Wartości (technika z Lean Manufacturing), której możesz użyć, aby pokazać, ile czasu i dlatego pieniądze są marnowane każdego dnia, ponieważ kandydat do wydania nie jest w stanie przejść do następnego etapu. Koszt alternatywny jest trudny do zrozumienia, ale jest to jeden z najlepszych sposobów wizualizacji i zademonstrowania go.

A jeśli to nie zadziała ... to może jesteś w dysfunkcyjnej firmie, wyjdź, zanim będzie za późno!

Ale nie rozwiążesz tego problemu, po prostu upuszczając kilka dokumentów na biurku kierownika i prosząc go, aby rzucił pieniądze na problem, ponieważ założą (poprawnie), że rzucanie w nie pieniędzmi może w rzeczywistości go nie rozwiązać, a nawet gorzej. Musisz dostarczyć rozwiązania i na tym właśnie polega ta odpowiedź. Jeśli wprowadzisz ten problem jako „tutaj jest lista sposobów, w jaki możemy zacząć rozwiązywać ten problem, w malejącej kolejności kosztów / korzyści” zamiast „potrzebujemy więcej testerów”, odniesiesz większy sukces.

Strony 29 i 30 mogą zawierać dane, których szukasz, chociaż może być wymagana kontrola.

Zajrzałbym do badań wspomnianych w tym zdaniu na stronie 30:

Dziesiątki firm odkryły, że zwykłe skoncentrowanie się na korekcie wad wcześniej niż później w projekcie może obniżyć koszty i harmonogramy rozwoju o dwa lub więcej czynników (McConnell 2004).

BTW, to twoje pytanie sprawiło, że znów podniosłem książkę, aby ją odświeżyć :-)

Opisujesz wąskie gardło w procesie. Teoria Lean mówi, że w procesie zawsze będzie wąskie gardło, ale jego nasilenie może się znacznie różnić. Jeśli QA zatrudniło jednego dodatkowego, rozwój może stać się wąskim gardłem.

Aby zrozumieć koszt, wyobraź sobie następującą sytuację. Wybrałeś jednego z programistów. Jego praca nigdy nie będzie miała zapewnionej jakości, ale zawsze stanie w kolejce na czas nieokreślony. Wyobraź sobie, że oznaczałoby to, że zapewnianie jakości może zapewnić pracę pozostałych programistów w odpowiednim czasie i nie będzie żadnych kosztów opóźnień.

W takim scenariuszu koszt opóźnienia to koszt wynagrodzenia dewelopera, ponieważ jego praca byłaby zmarnowana.

Powodem, dla którego kłócę się o koszty, a nie wartość wytworzoną przez proces, jest po prostu fakt, że trudniej jest udokumentować wartość procesu, nawet jeśli jest on znacznie lepszy.

Ciągle przeglądam moją kopię Code Complete, szukając fragmentu „twardych danych”, który pokazuje, że koszt naprawy usterek rośnie wykładniczo, im dłużej istnieje. Czy ktoś może wskazać mi jakieś badania potwierdzające tę koncepcję?

Wykładniczy koszt znalezienia błędu wydaje się być oparty na badaniu NIST . Badanie było ankietą zakładającą wyraźne etapy wodospadu:

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( tabela tutaj stąd )

Jednym z celów metodologii tworzenia oprogramowania Agile jest usunięcie tych odrębnych etapów i ograniczenie tych kosztów. Liczby nie mają zastosowania w przypadku stosowania innych metod do wodospadu.

Twój problem nie dotyczy QA, w rzeczywistości, jeśli Twój QA przeprowadza testowanie, opóźnienia są w zasadzie najmniejszym z twoich zmartwień. Proszę pozwolić mi wyjaśnić (ponownie, ponieważ jest to powszechne nieporozumienie w branży programowania) ... Kontrola jakości Zapewnia jakość produktu poprzez nadzorowanie całego SDLC, od wymagań (może wcześniej), poprzez rozwój, weryfikację, wydanie i wsparcie. Testowanie gwarantuje, że w kodzie nie występują żadne oczywiste wady. Istnieje bardzo duża i ważna różnica. Gdybyś miał prawdziwą kontrolę jakości, byliby w całym dziale Test / V&V z pytaniem, dlaczego kosztują czas biznesowy (a tym samym pieniądze) opóźniając wydania, lub cały proces zarządzania projektem, zapewniając, że właściwie zarządzają harmonogramem projektu lub cały proces zarządzania na pewno było wystarczająco dużo testerów do wygenerowania kodu itp ...

Zakładając, że przez QA masz na myśli Test, wróć do pierwotnego pytania. Kod Complete ma rację - koszt wady to czas potrzebny od włożenia do korekty. Wczesne wykrycie jest przydatne tylko wtedy, gdy poprawisz je również wcześnie, ale interpretacja większości ludzi jest błędna.

(Uwaga: gram tutaj jako adwokaci diabłów, nie bierzcie tego dosłownie, ponieważ nic nie wiem o waszej sytuacji) Opóźnienie spowodowane przez wasz dział testowy jest kosztem, absolutnie jednak muszę zapytać, czy jesteście czekając, aż znajdą wady, co robisz - czy nie powinieneś znajdować własnych wad? Być może, gdyby mieli mniej pracy (dzięki wprowadzeniu wyższej jakości przy mniejszej liczbie wad), opóźnienie nie byłoby tak znaczące, a koszt mniejszy - jako menedżer zapytałbym cię, jak zamierzasz zmniejszyć wady w dostarczanym kodzie testuj, ponieważ (w oparciu o argument) te defekty kosztują więcej, jeśli zostaną wykryte w teście.

Również jako menadżer, mogę powiedzieć, że nie jest to praca Testy w poszukiwaniu twoich wad, ich zadaniem jest stwierdzenie, że nie ma żadnych wad - jeśli oczekujesz, że znajdą wady, być może nie wykonałeś wystarczająco dobrze swojej pracy.

Uważaj, jak do tego podchodzisz. Jeśli nie masz rozwiązania tego problemu, prawdopodobnie wypadniesz na drugim miejscu.