Czy powinniśmy przestać próbować robić zwinnie, jeśli kontrola jakości zajmuje 12 tygodni?

Ktoś w mojej firmie niedawno zaproponował zmiany w naszym podstawowym produkcie, które zdaniem naszych menedżerów powinny uruchomić to, co, jak sądzę, moja firma uważa za pełny cykl kontroli jakości (tj. Testowanie całego pakietu produktów od podstaw). Najwyraźniej nasza kontrola jakości zajmuje 12 tygodni, aby wykonać pełny cykl kontroli jakości naszego produktu. Mój problem polega na tym, że staramy się rozwijać Agile (choć moim zdaniem w większości na wpół oceniany). Zrobimy cały zestaw sprintów, a następnie wydamy wydanie, które, jak sądzę, zajmie wieczność. Pytanie naprawdę brzmi: czy nasza kontrola jakości zajmie 12 tygodni, czyż nie powinniśmy po prostu rezygnować z prób zwinności? Po co, u diabła, warto próbować robić Agile w takiej sytuacji?

Cóż, bezpośrednia odpowiedź na twoje pytanie brzmi Mu. Obawiam się - po prostu nie ma wystarczających szczegółów, aby dobrze poinformować, czy powinieneś przestać próbować.

Jedyną rzeczą, którą jestem całkiem pozytywnie nastawiony, jest to, że poziom zwinności powinien być napędzany potrzebami klientów / rynku (o których nie poinformowałeś).

• ^{Na przykład, jako użytkownik IDE, cieszę się, że mogę uaktualnić do nowej wersji raz, a może dwa razy w roku i nigdy się nie spieszy. To znaczy, jeśli ich cykl wydawania wynosi 3 miesiące ( 12 tygodni ), jestem z tego całkowicie zadowolony.
   
  Z drugiej strony mogę sobie łatwo wyobrazić, powiedzmy, że firma zajmująca się obrotem finansowym zbankrutuje, jeśli oprogramowanie zajmie więcej niż miesiąc, aby dostosować swoje oprogramowanie do zmian rynkowych - w tym przypadku 12-tygodniowy cykl testowy byłby drogą do piekła. Teraz - jakie są twoje potrzeby w tym zakresie?}

Inną rzeczą do rozważenia jest to, jaki poziom jakości jest wymagany, aby zaspokoić potrzeby klienta / rynku?

• ^{Przykładowo - w firmie, w której kiedyś pracowałem, stwierdziliśmy, że potrzebujemy nowej funkcji w produkcie licencjonowanym od jakiegoś dostawcy oprogramowania. Bez tej funkcji cierpieliśmy dość mocno, więc tak, naprawdę chcieliśmy, aby były zwinne i dostarczyły aktualizację w ciągu miesiąca.
   
  I tak, wydawali się zwinni i tak, wydali tę aktualizację w ciągu miesiąca (jeśli ich cykl kontroli jakości wynosi 12 tygodni, prawdopodobnie po prostu ją pominęli). A nasza funkcja działała doskonale - nie powinniśmy być szczęśliwi? Nie! odkryliśmy błąd regresji showstopper w niektórych funkcjach, które wcześniej działały dobrze - więc musieliśmy trzymać się starszej wersji.
   
  Minął kolejny miesiąc - wydali kolejną nową wersję: naszą funkcjębył, ale był tam również ten sam błąd regresji: ponownie nie zaktualizowaliśmy. I kolejny miesiąc i jeszcze jeden.
   
  Ostatecznie byliśmy w stanie ulepszyć zaledwie pół roku później tak bardzo ze względu na ich zwinność.}

Teraz przyjrzyjmy się bliżej tym 12 tygodniom , o których wspominasz.

Jakie opcje rozważałeś, aby skrócić cykl kontroli jakości? jak widać z powyższego przykładu, zwykłe pominięcie go może nie dać ci tego, czego oczekujesz, więc lepiej być, cóż, zwinny i rozważ różne sposoby rozwiązania tego problemu.

Czy na przykład zastanawiałeś się, jak poprawić testowalność swojego produktu?

A może zastanawiałeś się nad rozwiązaniem brutalnej siły, aby po prostu wynająć więcej QA? Jakkolwiek wygląda to prosto, w niektórych przypadkach tak naprawdę należy. Widziałem niedoświadczone kierownictwo próbujące rozwiązać problemy z jakością produktu, na oślep zatrudniające coraz więcej starszych programistów, w których średnia para profesjonalnych testerów. Całkiem żałosne.

Ostatni, ale nie mniej ważny - myślę, że należy zwinnym w kwestii stosowania zasad zwinności. Chodzi mi o to, że jeśli wymagania projektu nie są zwinne (stabilne lub zmieniają się powoli), to po co? Kiedyś zauważyłem, że najwyższe kierownictwo wymusza Scrum w projektach, w których doskonale sobie radzi. Co za marnotrawstwo. Nie tylko nie było żadnych ulepszeń w ich dostarczaniu, ale co gorsza, wszyscy programiści i testerzy byli niezadowoleni.

aktualizacja na podstawie wyjaśnień zawartych w komentarzach

Dla mnie jedną z najważniejszych części Agile jest możliwość wydania na końcu każdego sprintu. To sugeruje kilka rzeczy. Po pierwsze, należy przeprowadzić poziom testowania, aby upewnić się, że nie występują żadne przeszkody, jeśli uważasz, że możesz udostępnić wersję kompilacji klientowi ...

Wydaje się, że można wysłać . Hm Hmmm. Zastanów się nad dodaniem jednego lub dwóch składników Lean do koktajlu Agile. Mam na myśli, że jeśli nie jest to potrzeba klienta / rynku, oznacza to jedynie marnotrawstwo (testowania) zasobów.

Po pierwsze, nie widzę nic przestępczego w traktowaniu wydania Sprint jako tylko punktu kontrolnego, który zadowala zespół.

• ^{dev: tak, że wygląda się wystarczająco dobrze, aby przejść do testerów; QA: tak, wygląda to wystarczająco dobrze, jeśli potrzebne są dalsze testy wysyłkowe - takie rzeczy. Zespół (dev + QA) jest zadowolony, to wszystko.}

... Najważniejszym punktem, który podałeś, był koniec odpowiedzi w zakresie niestosowania zwinności, jeśli wymagania nie są zwinne. Myślę, że to jest na miejscu. Kiedy zaczęliśmy działać zwinnie, mieliśmy to ustawione, a okoliczności miały sens. Ale od tego czasu wszystko zmieniło się dramatycznie i trzymamy się procesu, w którym może to już nie mieć sensu.

Dokładnie tak. Również z tego, co opisujesz, wygląda to tak, jakbyś osiągnął stan (dojrzałość zespołu / kierownictwa i relacje z klientem), co pozwala ci używać regularnego iteracyjnego rozwoju modelu zamiast Scruma. Jeśli tak, to możesz również wiedzieć, że z mojego doświadczenia wynika, że ​​takie regularne iteracje wydawały się bardziej produktywne niż Scrum. Znacznie bardziej produktywny - po prostu było o wiele mniej kosztów ogólnych, po prostu o wiele łatwiej było skupić się na rozwoju (dla QA odpowiednio skupić się na testowaniu).

• ^{Zwykle myślę o tym w kategoriach Ferrari (jako zwykła iteracja) vs Landrover (jako Scrum).
   
  Podczas jazdy autostradą (a wydaje się, że twój projekt dotarł do tej autostrady ) Ferrari pokonuje Landrovera.
   
  Jest to teren, na którym trzeba jeepa, a nie samochodu sportowego - to znaczy, jeśli twoje wymagania są nieregularne i / lub jeśli praca zespołowa i zarządzanie nie są tak dobre, musisz wybrać Scrum - po prostu dlatego, że próbujesz jeździć regularnie utknął - jak Ferrari utknie w terenie.}

Nasz pełny produkt składa się z wielu mniejszych części, z których wszystkie mogą być ulepszane niezależnie. Myślę, że nasi klienci bardzo chętnie aktualizują te mniejsze komponenty znacznie częściej. Wydaje mi się, że powinniśmy być może skupić się na wydaniu i kontroli jakości tych mniejszych komponentów na końcu sprintu ...

Powyżej brzmi jak dobry plan. Raz pracowałam w takim projekcie. Wydawaliśmy comiesięczne wersje z aktualizacjami zlokalizowanymi w małych komponentach niskiego ryzyka, a podpisywanie ich pod kątem jakości było tak proste, jak to tylko możliwe.

• ^{Jedną rzeczą, aby pamiętać o tej strategii jest stworzenie dającej się przetestować weryfikację, czy zmiana jest zlokalizowana gdzie oczekiwano. Nawet jeśli dojdzie do porównania plików po kawałku dla składników, które się nie zmieniły, idź, bo inaczej nie dostaniesz go dostarczony. Rzecz w tym, że to QA odpowiada za jakość wydania, a nie my, programiści.
   
  Problemem głowy testera jest upewnienie się, że nieoczekiwane zmiany nie prześlizgną się - ponieważ szczerze mówiąc, jako programista mam wystarczająco dużo innych rzeczy, aby się tym martwić, jest to dla mnie ważniejsze. Z tego powodu oni (testerzy) naprawdę naprawdę potrzebują solidnego dowodu, że wszystko jest pod kontrolą dzięki wydaniu, które testują do wysłania.}

Och, czuję twój ból. Aby to zadziałało, musisz wprowadzić kilka poważnych zmian w zespole kontroli jakości.

Radzę podzielić zespół na trzy zespoły:

Testowanie funkcji - szybki zwrot z testowania nowych rozwiązań.

Testy regresji - W pełni przetestuj produkt, zanim wyjdzie on z domu. Nie powinno to zająć 3 miesięcy, nawet po zmniejszeniu liczebności drużyny, ponieważ większość błędów znajdzie pierwszy zespół.

Testy automatyczne - pisanie pełnego zestawu testów regresji w celu przyspieszenia pracy zespołu testującego regresję.

Trzecia drużyna to bonus, ale jeśli nie możesz mieć dwóch pierwszych drużyn, równie dobrze możesz być wodospadem.

Tytułem ilustracji:

Pamiętaj, że Twój zespół kontroli jakości prawdopodobnie pracuje poza kręgiem (ATDD), a ty pracujesz w nim.

Myślę, że takie działanie jest w porządku; jeśli możesz udowodnić w swoich automatycznych testach, że spełniasz wymagania klienta na każdym sprincie, możesz zezwolić QA na wykonanie ich testów w czasie wolnym i przyjść do ciebie z wadami, które możesz następnie przepracować do następnego sprintu.

Wygląda na to, że masz problem z definicją ukończenia.

Biorąc pod uwagę, że twoja grupa ds. Kontroli jakości ma charakter zewnętrzny i bierze udział wyłącznie w wersjach wydawanych przez klientów, nie możesz na nich polegać w celu uzyskania terminowej informacji zwrotnej na temat problemów. Oznacza to, że jeśli chcesz uzyskać szybką informację zwrotną, będziesz musiał przeprowadzić pewien test „na miejscu” dla zespołu.

Traktuj grupę QA tak, jakby nie istniała. Działaj, jeśli Twoja wersja pod koniec sprintu zostanie wdrożona w Twoim najbardziej krytycznym środowisku następnego dnia. Oprogramowanie nie jest gotowe, dopóki nie będzie gotowe, aby przejść do klientów.

Kontrola jakości nie powinna niczego znaleźć.

Będzie trudniej się do niego dostać. Prawdopodobnie będziesz miał kilka rzeczy, które przekradną się przez kilka pierwszych razy. Zautomatyzowani testy akceptacyjne i testy „regresji” są tutaj twoimi najlepszymi przyjaciółmi. TDD pomoże ci zbudować duże części takich pakietów. Powinieneś być w stanie szybko wiedzieć, czy coś zepsułeś.

Czy masz przedstawiciela klienta / właściciela produktu, który może zobaczyć dane wydanie przed przeprowadzeniem kontroli jakości i dać ci autorytatywną opinię? Jeśli tak, możesz wykonywać zwinne metody i czerpać z nich większość korzyści, traktując kontrolę jakości jako drugorzędne, nieco powolne źródło informacji zwrotnej. Wydanie będzie „oficjalnie gotowe” dopiero po zakończeniu kontroli jakości, ale nie będziesz musiał czekać na nie przed rozpoczęciem następnego.

Ale jeśli zasady firmy mówią, że klient nie może zobaczyć wydania przed przeprowadzeniem kontroli jakości, możesz prawie zapomnieć o zwinności, dopóki nie zmienisz tych reguł.

Opisany proces nie jest procesem zwinnym. Zespoły, które mają wysoki stopień zwinności, są w stanie dostarczać niezawodne i możliwe do uwolnienia kompilacje podczas każdego sprintu. W większości sprawnych implementacji funkcja zapewniania jakości jest wbudowana w sprawny zespół, pomagając osiągnąć ten cel.

Jeśli Ty, lider projektu, właściciel produktu i programiści nie współpracujecie i nie macie planu usprawnień (retrospektywy), nazwijcie swój proces czymś innym i przejdźcie dalej. Nie wydaje się, że problemy twoich zespołów są z winy menedżerów lub kontroli jakości. Wydaje się, że reagują na jakiś problem systemowy wychodzący z organizacji rozwoju. Nie wszystko stracone, jeśli zespół jest gotowy wziąć na siebie odpowiedzialność i rozpocząć współpracę z interesariuszami.

Możesz spróbować trzech rzeczy. Po pierwsze, upewnij się, że każdy interesariusz ma zwięźle określone role i że każda osoba rozumie swoją odpowiedzialność. Po drugie, ustabilizuj kompilację, a następnie wyloguj się z kontroli jakości bez wprowadzania dalszych zmian. Po trzecie, instytut automatyzacji testów. Zespół QA pokocha cię za to.

Szkoda, że ​​sprzężenie zwrotne trwa tak długo, ale nie sądzę, aby warto było zwinąć. Pod koniec sprintu (lub kilku) wypuszczasz produkt, który jesteś pewien, że może zostać wprowadzony na rynek. Dla twojego zespołu zwinność zapewnia możliwość skupienia się na pracy do wykonania i utrzymania produktu w stanie gotowości do wydania. Gdy QA znajdzie problemy, sugeruję, aby utworzyć raporty błędów dla tych problemów i rozwiązać je w następnym sprincie (jeśli mają wystarczająco wysoki priorytet).

Nasze testy w terenie trwają 8 tygodni, a ponadto jesteśmy zależni od zewnętrznych producentów. Mimo to, działając zwinnie, jesteśmy w stanie skupić się na pracy i szybko stworzyć nową wersję, gdy zajdzie taka potrzeba.

Problem leży (w twoich oczach) w dziale kontroli jakości. Czy można tam rozwiązać problem? Omówiłeś to?

12 tygodni jest długie, ale mam nadzieję, że w tym czasie QA może dostarczyć informacji zwrotnych i raportów o błędach (a nie po trzech miesiącach).

Dzięki temu nadal możesz reagować na najważniejsze problemy w zwinny sposób i możesz naprawić wiele, jeśli nie wszystkie, zanim jeszcze skończą!

Co robią ludzie odpowiedzialni za kontrolę jakości podczas wykonywania wielu sprintu? Wygląda na to, że czują potrzebę przetestowania wszystkiego po każdej zmianie (dlatego czekają na całą masę zmian).

Zespół programistów jest sprawny, ale reszta firmy nie.

Ktokolwiek jest odpowiedzialny za kontrolę jakości, albo nie wie, co robi, albo wykonał sztuczkę umysłu Jedi na wyższym kierownictwie i wolno mu poświęcić słodki czas. Jak kontrola jakości może trwać dłużej niż programowanie?