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.
development-process
qa
Neil N.
źródło
źródło
Odpowiedzi:
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 :)
źródło
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ń :
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:
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.
Wykorzystaj ograniczenie.
Innymi słowy, optymalizuj wokół procesu ograniczania. Nie pozwól, aby testerzy byli bezczynni. Sprowadza się to zasadniczo do:
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.
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:
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.
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.
źródło
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:
BTW, to twoje pytanie sprawiło, że znów podniosłem książkę, aby ją odświeżyć :-)
źródło
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.
źródło
Wykładniczy koszt znalezienia błędu wydaje się być oparty na badaniu NIST . Badanie było ankietą zakładającą wyraźne etapy wodospadu:
( 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.
źródło
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.
źródło