Jak uwzględnić błąd związany z iteracją?

Scrum wdrożyliśmy całkiem pomyślnie przez ostatnie 5 miesięcy. Choć jesteśmy 3 tygodni od PROD bez kiedykolwiek robi żadnego testu integracji end-to-end. AUĆ! Potrzebuję pomocy. Nie zajmując się przyczynami (w TYM punkcie), musimy teraz zaplanować bieżącą iterację, która składa się z drobnych ulepszeń i WIELE wciąż nieznanych poprawek. Jak rozliczasz się z tym scenariuszem? Jak zaplanujesz swoją iterację, aby naprawić błędy, które jeszcze nie zostaną znalezione?

Scrum czy nie, naprawianie błędów jest w zasadzie niemożliwe do przewidzenia. Uważam, że najlepsze, co możesz zrobić, to:

• Rozpocznij test natychmiast, bez wstępnego oszacowania, kiedy to zostanie zrobione.
• Po wykryciu każdego błędu wykonaj wstępną analizę do punktu, w którym możesz go oszacować.
• Oszacuj błąd i zdecyduj, czy należy go naprawić i czy trzeba go naprawić w początkowej wersji.
• Jeśli trzeba to naprawić, dodaj go do iteracji.
• Wykreśl wykres wypalenia. W pewnym momencie zacznie się zmniejszać, co oznacza, że ​​nie znajdziesz już błędów szybciej, niż uda ci się je naprawić. W tym momencie będziesz mógł podać przybliżone oszacowania (i stopniowo bardziej precyzyjne), kiedy będzie można dokonać wydania.

Następnie upewnij się, że następnym razem zaczniesz testować wcześnie i naprawisz błędy podczas pracy. Wszystkie rozsądne metodologie, zwinne lub nie, wymagają naprawy znanych błędów przed przejściem do nowych funkcji. Powinieneś także wziąć pod uwagę, ile czasu poświęcono na naprawę każdej funkcji, abyś mógł poprawić swoje oszacowanie dotyczące implementacji funkcji w stanie debugowania w przyszłości.

Oszacowanie i bugfixing są ładnie objęte Joel Spolsky w Evidence Based Scheduling i Hard-dupą Bug Fixin' . To nie jest związane ze Scrumem, ale myślę, że jest wystarczająco ogólne, że ma to zastosowanie.

Jak uwzględnić błąd związany z iteracją? Jak zaplanujesz swoją iterację, aby naprawić błędy, które jeszcze nie zostaną znalezione?

Odnośnie „iteracji naprawiania błędów”. Znalezione błędy nie powinny być traktowane inaczej niż historie. Współpracuj z zespołem, aby oszacować wysiłek (punkty historii), aby naprawić każdy błąd i współpracuj z właścicielem / klientem produktu, aby zdecydować, czy błąd powinien przejść do następnej iteracji.

Odnośnie „błędów, które jeszcze nie znaleziono”. Najlepiej, aby zespół znajdował i naprawiał problemy przy każdej iteracji. Jeśli nie, omów to na następnej retrospektywie. Jeśli jakość produktu jest tak niska, że ​​wydanie nie jest możliwe, natychmiast przenieś swoje najlepsze „ wyszukiwarki błędów ” do znajdowania błędów (nie naprawiania). Jeśli jakość jest wystarczająco wysoka, aby zapewnić wersję beta wybranym użytkownikom - zrób to. Jeśli nie możesz, to przynajmniej dostarczaj na żywo prezentacje użytkowników omawiające słabe obszary, które według Ciebie wymagają poprawy.

Nie planujemy „iteracji naprawiających błędy”, ale planujemy iteracje testów systemowych przed każdym wydaniem. Test systemu to testy integracyjne, regresyjne i testowe na wszystkich częściach produktu. Testerzy testują produkt (dość duży starszy system), a programiści naprawiają wszelkie znalezione błędy. Jeśli nie zostaną znalezione żadne błędy, albo zaczynamy sprawdzać harmonogramy funkcji dla następnego projektu, albo pracujemy nad ulepszeniami wewnętrznymi.

Obecnie planujemy sześć tygodni testów systemu po zamrożeniu kodu (dla projektu pięciomiesięcznego, w tym test systemu), aby upewnić się, że wszystko działa. Jest to dodatek do wszystkich testów przeprowadzanych podczas iteracji implementacyjnych.

Musisz zdefiniować zestaw kryteriów „wydania”. Mogą one obejmować:

• Średni czas między awariami
• Liczba znalezionych wad dziennie
• Istotność stwierdzonych wad na dzień
• Liczba zaległych wad

itp.

Następnie na końcu każdej iteracji, w której niektóre osoby testują (ręcznie lub pisząc testy automatyczne), a inne naprawiają sprawdzanie, czy spełniasz kryteria. Jeśli masz, zwolnij, jeśli nie, to przejdź do kolejnej iteracji.

Powinna istnieć możliwość zastąpienia tego, a często surowe liczby nie przedstawiają realistycznego obrazu aplikacji. Możesz mieć kilka naprawdę poważnych wad, ale ujawniają się one tylko w rzadkich warunkach, z którymi możesz żyć w krótkim okresie.

Jednym ze sposobów jest napisanie historii do testów integracyjnych, podczas których piszesz nowe historie dla znalezionych błędów, a następnie naprawiasz błędy w następnej iteracji.

Innym sposobem na zrobienie tego jest napisanie historii „Napraw błędy znalezione w testach integracyjnych”. Z poprzednich wersji powinieneś mieć pojęcie o tym, ile problemów zwykle się znajduje i jak trudno je naprawić, dzięki czemu możesz przypisywać punkty historii na podstawie tej wiedzy. Możesz podzielić go na komponenty, jeśli to ułatwi zarządzanie. Zawsze jest w tym nieunikniona niepewność. Dodaj kilka dodatkowych punktów historii, aby to uwzględnić.

Prawdopodobnie z opóźnieniem zdałeś sobie sprawę, że najlepszym sposobem jest włączenie drobnych testów integracyjnych do każdej iteracji, jeśli to możliwe. Gratulujemy rozpoznania tego i odrobiny usprawnienia procesu do następnego wydania.