Dylemat QA vs. iteracje

W mojej firmie z powodzeniem pracujemy z elastycznymi praktykami - ale bez iteracji. Głównym powodem jest to, że nie możemy znaleźć czystego sposobu, aby zmieścić się w kontroli jakości w cyklu iteracji.

QA rozumiemy jako dodatkową weryfikację pewnej kompilacji (kandydata do wydania), zanim ta kompilacja zostanie wdrożona u klienta. Chodzi o to, aby uniknąć tego, że pojedyncze złośliwe popełnienie zniszczy całe wydanie. Ponieważ nigdy nie wiadomo, który to jest, QA musi poczekać, aż wszystkie funkcje / zatwierdzenia do wydania znajdą się w kompilacji. (Żadne słynne ostatnie słowa „To była tylko drobna zmiana” jest niedozwolone).

Jeśli QA znajdzie błędy w kandydacie do wydania, programiści naprawią je w odpowiedniej gałęzi wydania (i połączą w pień). Kiedy wszystkie błędy zostaną naprawione, wdrażana jest nowa kompilacja do kontroli jakości w celu ponownego przetestowania. Tylko wtedy, gdy nie znaleziono żadnych błędów w określonym kandydacie do wydania, jest on oferowany klientowi do weryfikacji.

Zwykle zajmuje to około dwóch do trzech kandydatów, około tygodnia na wydanie. Czas na napisanie poprawek jest zwykle znacznie krótszy niż wysiłki związane z testowaniem. Aby więc utrzymać programistów w pracy, pracują nad wersją N + 1, podczas gdy QA działa na N.

Bez korzystania z iteracji nie stanowi to problemu, ponieważ możemy nakładać się na pracę dla wydań N i N + 1. Jednak z tego, co rozumiem, nie jest to zgodne z podejściami opartymi na iteracji, takimi jak Scrum lub XP. Wymagają, aby iteracja była zwalniana na końcu, a wszelkie wysiłki związane z testowaniem powinny być włączone do iteracji.

Uważam, że to niekoniecznie prowadzi do jednego z następujących niepożądanych efektów:

(A) Programiści są bezczynni na końcu iteracji, ponieważ QA potrzebuje czasu, aby zweryfikować kandydata do wydania, a prace naprawcze nie w pełni zajmują deweloperów.

(B) Kontrola jakości zaczyna działać już przed przygotowaniem pierwszego kandydata do wydania. Jest to najczęściej zalecane na Stack Exchange. Ale to nie jest to, co moja firma rozumie jako kontrolę jakości, ponieważ nie ma testowanego konkretnego kandydata do wydania. A „drobna zmiana”, która psuje wszystko, wciąż może zostać wprowadzona niezauważona.

(C) Błędy są przenoszone do następnej iteracji. Jest to również zalecane na stosie wymiany. Nie wydaje mi się, żeby to było w ogóle rozwiązanie. Zasadniczo oznacza to, że nigdy nie otrzymujemy zweryfikowanej wersji, ponieważ za każdym razem, gdy wprowadzane są poprawki błędów, nowe, niezweryfikowane zatwierdzenia są również dodawane do tej samej gałęzi.

Czy jest jakieś wyjście z tego dylematu?

QA rozumiemy jako dodatkową weryfikację pewnej kompilacji (kandydata do wydania), zanim ta kompilacja zostanie wdrożona u klienta.

Nie ma nic z natury niezgodnego między tą formą zapewniania jakości a metodologiami opartymi na iteracji, takimi jak Scrum.
W Scrumie zespół dostarcza produkt w cyklu X-tygodniowym swoim klientom. Ważną kwestią jest to, że jeśli zespół programistów zajmuje się Scrum, to ich klientem jest zespół kontroli jakości, a nie użytkownik końcowy produktu.

Jako programista rozważałbym produkt dostarczany do kontroli jakości, jeśli ma on szanse na zaliczenie wszystkich testów. Prawdopodobnie oznacza to, że niektóre testy QA zostały już przeprowadzone na codziennych kompilacjach, ale to, jak wpłynie to na oficjalne testy wydane przez zespół QA, zależy od Twojej organizacji.

W większości rzeczywistych sytuacji agile zatrzymuje się przy dostawie do QA / UAT lub jakkolwiek się nazywa.

Wysiłek przejścia od kontroli jakości do produkcji w środowisku rzeczywistym jest często niedoceniany. W wielu przypadkach wymaga to prawdziwych użytkowników biznesowych w testowaniu, wylogowywania się z prawdziwej linii menedżerów biznesowych, planowania wydania operacji itp. Nie jest to trywialne!

W skrajnych przypadkach oprogramowanie może wymagać certyfikacji przez agencje zewnętrzne lub zostać poddane rygorystycznym testom bezpieczeństwa.

W takich okolicznościach nie można przewidzieć więcej niż jednej wersji na kwartał, z wyjątkiem poprawek błędów.

W przypadku poważnego oprogramowania sytuacja się pogarsza. Dokumentacja musi być sprawdzona i opublikowana. Broszury marketingowe wymagają zmiany. Sprzedawcy muszą być informowani o tym, co sprzedają (nie jest to łatwe zadanie!) Itp. Itd. Naprawdę nie chcesz poddawać się temu biznesowi więcej niż raz w roku.

Bardzo krótkoterminowym rozwiązaniem jest zapewnienie QA dodatkowego czasu po zakończeniu iteracji na zakończenie testów. to znaczy. Jeśli masz dwutygodniową iterację, nie wypuszczaj jej do 3. tygodnia. W każdym razie QA nie będzie miało nic do przetestowania w kierunku następnej iteracji.

Ale uprzedzę cię z góry, co się stanie (po obejrzeniu tego w kilku zespołach): skończysz w sytuacji, gdy po jednej iteracji wykonasz dwutygodniową pracę, kontrola jakości jest przeciążona, przychodzą do ciebie po to cały tydzień kontroli jakości, a po następnej iteracji wykonasz tylko tydzień pracy. W tej iteracji QA nie będzie miało nic do roboty i pomyślisz, że rozwiązałeś problem. Ale w następnej iteracji cykl zaczniesz ponownie.

Tak więc, jak tylko dodasz ten tydzień, aby upewnić się, że Twoje wydanie jest stabilne (bo nauczyłem się jednej rzeczy, że jeśli stracisz wiarę w biznes, Agile będzie wykładniczo trudniejsze do wdrożenia), zacznij od razu na plan długoterminowy.

Kup kopię ciągłej dostawy Jez Humble , przeczytaj ją, , przekaż ją zespołowi. Zainspiruj wszystkich. Następnie zaimplementuj z niego wszystko, co możesz.

Spraw, aby proces kompilacji przebiegał jak najlepiej. Zaimplementuj zasady testów jednostkowych i uruchom je przy każdej kompilacji. Spraw, aby proces wdrażania był najsprytniejszą rzeczą, jaką kiedykolwiek widziałeś. Trzy kliknięcia? Nie dość zręczny.

Gdy to wszystko zrobisz, nie będzie to miało większego znaczenia, jeśli sporadyczny błąd regresji przejdzie. Wiesz dlaczego? Ponieważ będziesz mógł (opcjonalnie) wycofać, naprawić i wdrożyć ponownie, zanim firma się rozpadnie. W rzeczywistości nocny dozorca będzie mógł się wycofać, proces będzie bardzo prosty.

Wiem, co myślisz: nie mamy czasu na to wszystko. Pozwól, że ci powiem. Jeśli przeciążasz kontrolę jakości, wdrażasz zbyt wiele na iterację. Więc nie rób tego. Jeśli już ich nie przeciążasz, zapytaj, dlaczego nie mają jeszcze zautomatyzowanych pakietów testowych. Wkrótce będziesz.

Zrób to wszystko z pełną widocznością dla firmy. Oszacuj niżej i wstrzyknij część tej pracy do iteracji. Lub jeszcze lepiej, podziel go na historie i poproś, aby uszeregowali je priorytetowo, obok wszystkiego innego.

Wyjaśnij im, że a) poprawi stabilność wydania oraz b) poprawi twoją zdolność reagowania na problemy za nich c) kupi większą prędkość później. To rzadka firma, która nie chce takich rzeczy. Z pewnością nie jest to zwinna firma, która ich nie chce, więc jeśli otrzymasz opór, będziesz wiedział, że masz inny problem.

Po ograniczeniu ciągłej dostawy możesz zacząć skracać czas zapewniania kontroli jakości pod koniec iteracji. W interesie wszystkich leży jak najszybsze zrównanie iteracji z powrotem. Być może będziesz miał jeden dzień pod koniec iteracji, w którym musisz wypełnić czas. Już odpowiedziałem, co zrobić z tym w innym miejscu .

Bez korzystania z iteracji nie stanowi to problemu, ponieważ możemy nakładać się na pracę dla wydań N i N + 1.

Wydaje się, że jest problem ze sposobem, w jaki zdecydowałeś, co dokładnie stanowi work for release N.

Z jakiegoś dziwnego powodu (mogę tylko zgadywać, że istnieje pewne nieporozumienie dotyczące poszczególnych przepisów Agile), w jakiś sposób zdecydowałeś, że zwinne podejście nakazuje włączenie wszystkich działań zespołu QA do iteracji.

• ^{Gdyby tak było, przypuszczam, że popularność Agile nie byłaby nawet bliska temu, co widzimy teraz. Nie wyobrażam sobie wielu projektów, które mogłyby „przetrwać” obowiązkowe synchronizowanie iteracji zespołu programistów z cyklami testowania jakości.}

Poniżej jest trochę więcej na zwinności, ale najpierw rozwiążmy work for release N...

Słuchaj, nie ma żadnego ważnego powodu, aby zespół programistów zdefiniował pracę w ten sposób. Przeciwnie, z twojego opisu jasno wynika, że ​​zamiast monolitycznej „jednostki pracy” istnieje kilka takich jednostek, z kamieniami milowymi, które są łatwe do odczucia ...

• ^{Np. Pierwsza „jednostka” jest wskazywana przez wyraźny kamień milowy, gdy kompilacja kandydata jest przekazywana testerom, a kolejne kamienie milowe odpowiadają zmianom związanym z cyklami testów wykonywanymi przez QA itp.}

Zauważ też, że sposób, w jaki definiujesz work for release N nie jest wymuszony przez przepływ pracy w ramach kontroli jakości. Z tego, co opisujesz, wygląda na to, że mają swój (i całkiem rozsądny) harmonogram.

Biorąc pod uwagę powyższe, bardziej realistyczny sposób definiowania jednostek pracy w twoim przypadku może wyglądać następująco:

1. Działania programistyczne do momentu przekazania kompilacji do kontroli jakości
   Release Candidate N
2. Działania rozwojowe związane z pierwszym cyklem testowania jakości
   Release Candidate N patch 1
3. Działania rozwojowe związane z drugim cyklem kontroli jakości
   Release Candidate N patch 2
4. itd., aż do ostatecznej wersji

Powyżej są twoje jednostki pracy, bez względu na to, czy robisz zwinne czy cokolwiek innego.

Są naturalne i wygodne w definiowaniu, śledzeniu i śledzeniu. To również dobrze komponuje się z harmonogramem kontroli jakości, umożliwiając wygodną koordynację wysiłków deweloperów i kontroli jakości.

Jednak z tego, co rozumiem, nie jest to zgodne z podejściami opartymi na iteracji, takimi jak Scrum lub XP. Wymagają, aby iteracja była zwalniana na końcu, a wszelkie wysiłki związane z testowaniem powinny być włączone do iteracji.

Powyżej zrozumienia zgodności z Agile wygląda zasadniczo błędnie i oto dlaczego ...

Założone przez ciebie założenie nie ma nic wspólnego z Agile, jeśli weźmiemy jego filozofię za wartość nominalną, jak wskazuje sama nazwa, jest to podejście, które sprzyja i ćwiczy zwinność .

Z tej perspektywy trzymanie się określonego „stałego” przepływu pracy i ignorowanie, czy jest to wygodne, czy nie, jest po prostu sprzeczne z duchem Agile. Niewolnicze postępowanie zgodnie z „procedurą” prowadzi do praktyk oczernianych tak elokwentnie w Manifeśie Zwinnego Zwolnionego „… mamy obowiązkowe procesy i narzędzia do kontrolowania interakcji tych osób (preferujemy termin„ zasoby ”) .

Więcej na ten temat można znaleźć w odpowiedzi na inne pytanie , cytowane poniżej. Spójrz na notatkę dotyczącą „wydania do wysyłki”, wygląda na to, że OP było mylone w podobny sposób:

trzeba być zwinnym w kwestii samego stosowania zasad zwinnych. Mam na myśli, że jeśli wymagania projektu nie są zwinne (stabilne lub zmieniają się powoli), to po co zawracać sobie tym głowę? Kiedyś zauważyłem, że najwyższe kierownictwo wymusza Scruma w projektach, w których radził sobie doskonale bez niego. Co za marnotrawstwo. Nie tylko nie było żadnych ulepszeń w ich dostarczaniu, ale co gorsza, wszyscy programiści i testerzy byli niezadowoleni.

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 na to, że dobrze wygląda w przypadku, jeśli potrzebne są dalsze testy wysyłkowe - takie rzeczy. Zespół (dev + QA) jest zadowolony, to wszystko.}