Jaki jest przepływ pracy z błędami w zespole Agile / Scrum?

Jaki jest przepływ pracy z błędami w zespole Agile / Scrum?

Oto nasza: - Jeśli błąd jest związany z historią w bieżącym sprincie, naprawimy go. - Jeśli błąd nie jest związany z historią w bieżącym sprincie i nie jest krytyczny, jest on wysyłany do właściciela produktu w celu ustalenia priorytetów. - Jeśli błąd nie jest związany z historią w sprincie i jest krytyczny, naprawiamy go.

Wszystko, co jest związane z pracą w bieżącym sprincie, zostało naprawione, nawet nie uważamy ich za błędy i nie zapisujemy ich jako takich. Uważamy, że coś jest błędem, tylko jeśli jest częścią czegoś, co już uważaliśmy za wykonane.

Kiedy pojawia się nowy błąd, dodajemy go do zaległości i priorytetowo traktujemy go przez naszych interesariuszy. Jeśli mamy czas pozostający w sprincie, mamy tendencję do rozwiązywania łatwiejszych błędów, które mogą mieć niższy priorytet, ale są czymś, co możemy ukończyć w pozostałym czasie.

Zawsze myślałem, że błąd jest po prostu historią, która ma już niepomyślny test, dlatego jest lepiej zdefiniowany niż typowy pierwszy szkic opowiadań dla funkcji.

Więc jeśli jesteś przekonany, że błędy to historie, traktujesz je jak inne historie pod względem szacunków i priorytetów.

Myślę, że najlepszym sposobem podejścia do tego jest ustalenie, co naprawdę chcesz rozważyć błąd.

Wielu programistów nie uważa, że ​​coś, co nie działa zgodnie z przeznaczeniem, nad którym obecnie pracują, nie jest błędem, ponieważ szczerze mówiąc, nie jest to błąd. Jeśli obecnie pracujesz nad czymś, a nadal ma wady, to konkretny błąd nie jest w rzeczywistości kompletny, więc nie ma żadnej wady. Odwrotna sytuacja dotyczy ukończonych prac, jeśli stwierdzisz, że coś jest kompletne i gotowe do testowania / wydania / produkcji, a później znajdziesz defekt w kodzie lub użyciu, to na pewno masz błąd.

Moja firma stosuje następującą metodologię, aby ustalić, kiedy błąd powinien zostać naprawiony:

Jeśli błąd jest krytyczny, jest dodawany do bieżącego sprintu związanego z tym produktem, z odpowiednim priorytetem. Zazwyczaj planujemy w około 10% dodatkowy czas, aby pozwolić na to w sprincie, a także mając dodatkowe rzeczy, których tak naprawdę nie planujemy ukończyć, ale jeśli nie mamy błędów lub coś zostało ukończone szybciej, niż się spodziewaliśmy, możemy wtedy kompletny.

Jeśli błąd nie jest krytyczny, po prostu dodajemy go do zaległości i zwykle uzupełniamy w następnym sprincie.

dlaczego jest to idealny przepływ, jest w nim oczywisty wyciek, a czasem rzeczy, które nie są „krytyczne” z punktu widzenia programowania, mogą wymagać natychmiastowego ukończenia, jeśli kierownictwo zdecyduje, że należy to zrobić wcześniej, niż nam się wydaje zakończony.

Na marginesie uważam, że najlepiej jest wybrać strukturę, a następnie trzymać się jej. Niektóre z największych strat w wydajności zaczynają się pojawiać, gdy zaczynasz robić rzeczy bez struktury. Gdy zaczniesz degradować swoją strukturę, bardzo łatwo będzie zjechać z góry.

To mogło przesadnie odpowiedzieć na twoje pytanie, ale to tylko moje przemyślenia na temat tego, jak należy sobie z tym poradzić.

Wykonujemy bieżące prace związane z wadami. Podobnie jak w przypadku konfiguracji, jeśli istnieje krytyczny problem związany z bieżącą pracą, naprawiamy ją w ramach pracy. W końcu nie można nazwać historii „wykonaną”, jeśli jest z nią związana wada.

W przypadku innych błędów zwykle naprawiamy je, gdy pozwala na to czas. W razie pilnych problemów cofamy niektóre historie i spędzamy czas na naprawianiu błędów, zanim wrócimy do normalnej pracy z funkcjami.

Błędy znalezione podczas Sprintu są tylko częścią rozwoju.

Błędy znalezione po zakończeniu sprintu trafiają do rejestru produktów. Nigdy nie kłócimy się z użytkownikami, jeśli coś jest błędem, ulepszeniem lub zmianą. Jeśli użytkownik chce nazwać go błędem, to dobrze, ale nadal trafia do PB po prostu każdą inną nową pracę.