Najlepsze sposoby na dopasowanie naprawiania błędów do procesu Scruma? [Zamknięte]

Uczyłem się i czytałem o Scrumie w ciągu ostatnich kilku dni oraz czytałem o planowaniu sprintu i zadaniach. Jeden problem, który przyszedł mi do głowy, to sposób radzenia sobie z błędami w Scrumie. Henrik Kniberg wymienia kilka sposobów radzenia sobie z tym problemem w swojej bardzo ładnej książce Scrum and XP from the Trenches :

1. Właściciel produktu drukuje elementy Jira o najwyższym priorytecie, przenosi je na spotkanie dotyczące planowania sprintu i umieszcza na ścianie wraz z innymi historiami (w ten sposób pośrednio określając priorytet tych elementów w porównaniu z innymi historiami).
2. Właściciel produktu tworzy historie odnoszące się do elementów Jira. Na przykład „Napraw najbardziej krytyczne błędy raportowania w zapleczu, Jira-124, Jira-126 i Jira-180”.
3. Uważa się, że naprawianie błędów znajduje się poza sprintem, tj. Zespół utrzymuje wystarczająco niski współczynnik skupienia (na przykład 50%), aby mieć czas na naprawienie błędów. Zakłada się wtedy po prostu, że zespół poświęci określoną ilość czasu podczas każdego sprintu na naprawianie błędów zgłoszonych przez Jira
4. Umieść backlog produktu w Jira (czyli porzuć Excel). Traktuj błędy jak każdą inną historię.

Czy to naprawdę jest coś, o czym należy decydować na podstawie projektu, czy też są lepsze rozwiązania? Potrafię wymyślić problemy związane z każdym z tych podejść. Czy istnieje hybryda pochodząca z tych podejść, która działa najlepiej? Jak sobie z tym radzisz w swoich projektach?

To bardzo dobre pytanie i mam kilka spostrzeżeń co do różnych podejść do tego problemu.

1. Równe traktowanie wszystkich błędów za pomocą zaległych elementów może wydawać się dobrym pomysłem w teorii (praca śledzona w jednym miejscu), ale nie działa dobrze w praktyce. Błędy są zwykle niskiego poziomu i są liczniejsze, więc jeśli utworzysz indywidualną historię użytkownika dla każdego błędu, wówczas „prawdziwe” historie zostaną wkrótce przesłonięte.
2. Wyraźny czas w każdym sprincie zarezerwowany na poprawki jest w porządku, jeśli jest wykonywany w sposób widoczny dla właściciela produktu. O błędach należy wspominać podczas codziennego scrumu, a dyskusja o naprawionych błędach powinna odbywać się podczas przeglądu sprintu. W przeciwnym razie właściciel produktu nie będzie wiedział, co się dzieje w projekcie.
3. Umieszczenie całego backlogu w narzędziu do śledzenia błędów prowadzi do tego samego zestawu problemów, co w 1. Ponadto większość narzędzi do śledzenia błędów nie jest zaprojektowana z myślą o Scrumie i używanie ich w tym celu może być bolesne.

Rozwiązaniem, które uznaliśmy za najbardziej satysfakcjonujące, było umieszczenie jednej historii użytkownika o nazwie „Bilety” lub „Błędy” podczas każdego sprintu. Następnie taką historię można podzielić albo na niskopoziomowe zadania opisujące konkretny błąd (jeśli jest znany podczas planowania) lub meta-zadania rezerwujące określoną liczbę godzin na ogólne naprawienie błędów. W ten sposób właściciel produktu ma wgląd w proces, a wykres wypalania odzwierciedla postęp.

Pamiętaj tylko, aby bezlitośnie zamykać wszystkie „błędy”, które są faktycznie nowymi funkcjami i tworzyć dla nich nowe pozycje w rejestrze. Upewnij się również, że naprawiłeś wszystkie błędy zgłoszone w bieżącym sprincie przed zakończeniem sprintu, aby uznać sprint za zakończony.

Właściwie myślę, że najlepiej jest odpowiedź przez jpeacock z tym pytaniem Do policzyć godziny spędzone nad poprawkami do scrum?

Zacytuję to:

• Jeśli błąd jest łatwy / szybki do naprawienia (jedna linijka itp.), Po prostu go napraw.
• Jeśli błąd nie jest trywialny i nie jest blokerem, dodaj go do zaległości.
• Jeśli błąd blokuje, dodaj zadanie (do bieżącego sprintu), aby uchwycić pracę wymaganą do jego naprawienia i zacznij nad nim pracować. Wymaga to przeniesienia czegoś innego (z bieżącego sprintu) do zaległości w celu uwzględnienia nowych godzin, ponieważ całkowita liczba dostępnych godzin nie uległa zmianie.

Pierwszym krokiem jest zdefiniowanie, czym jest błąd. Uczę, że błąd jest błędem tylko wtedy, gdy jest to funkcjonalność, która nie działa w produkcji zgodnie z przeznaczeniem / projektem. Stają się one PBI typu błędów, które mają być traktowane priorytetowo przed nowym rozwojem. Brakująca funkcjonalność w produkcji jest Cechą i staje się normalną pozycją w rejestrze produktu. Każdy wadliwy kod znaleziony podczas sprintu jest uważany za niekompletną pracę, a ponieważ nie przechodzisz do następnej historii, dopóki bieżąca nie zostanie ukończona; śledzenie tych błędów w sprincie nie jest konieczne, ponieważ zespół zawsze pracuje nad naruszającym kodem. Karteczki samoprzylepne mogą być tutaj bardzo przydatne do szybkich przypomnień między członkami zespołu. Naprawianie zepsutego kodu zawsze ma pierwszeństwo przed pisaniem nowego kodu.

Zapasy to marnotrawstwo. Śledzenie błędów to inwentaryzacja. Śledzenie błędów to marnotrawstwo.

Równe traktowanie wszystkich błędów za pomocą zaległych elementów może wydawać się dobrym pomysłem w teorii (praca śledzona w jednym miejscu), ale nie działa dobrze w praktyce. Błędy są zwykle niskiego poziomu i są liczniejsze, więc jeśli utworzysz indywidualną historię użytkownika dla każdego błędu, wówczas „prawdziwe” historie zostaną wkrótce przesłonięte.

Jeśli masz o wiele więcej błędów niż funkcji, musisz popracować nad swoimi praktykami inżynierskimi. To zapach, że coś innego jest nie tak, a śledzenie nie jest odpowiedzią. Kop głębiej. Właściwie robaki zawsze śmierdzą. Nie są fajne, a jeśli masz ich dużo, musisz znaleźć przyczyny źródłowe, wyeliminować je i przestać skupiać się na śledzeniu błędów.

Nie śledź usterek na liście, znajdź je i napraw - Mary Poppendieck

Rzeczywiście, jeśli zapasy są marnotrawstwem, co z inwentarzem defektów ...

Dlatego zawsze staram się wdrażać mentalność Stop-the-Line z programowaniem opartym na testach i ciągłą integracją, abyśmy mogli znaleźć i naprawić większość usterek zamiast umieszczać je na liście przeróbek.

A kiedy usterki przechodzą, naprawiamy je przed napisaniem nowego kodu (historie z błędami i tak się nie kończą). Następnie staramy się naprawić nasz proces, aby był bardziej odporny na błędy i wykrywał usterki w momencie ich wystąpienia.

Nie ma jednego uniwersalnego rozwiązania, a każdy projekt jest inny. Błędy można również podzielić na kategorie od krytycznych do mało wartych naprawiania.

O ile nie jest to krytyczne dla działania systemu, wolę, aby błędy stały się kartami historii. To sprawia, że ​​priorytet rozwoju funkcji względem naprawiania błędów jest naprawdę wyraźny. W scenariuszu, w którym poprawki błędów są uważane za „poza sprintem”, naprawianie błędów może zmierzać w kierunku naprawiania naprawdę trywialnych błędów, podczas gdy naprawdę ważne funkcje biznesowe nie są opracowywane.

Przeszliśmy przez kilka permutacji, zanim ustawiliśmy błąd jako podejście fabularne. Wypróbuj różne rzeczy i odtwarzaj je na spotkaniach zespołu retro.

W naszym przypadku (rozwój od podstaw, 2-3 deweloperów) znalezione błędy są zapisywane, wyraźnie oznaczane jako błąd i na podstawie ich wagi są przypisywane do następnej iteracji lub pozostawiane w backlogu. W przypadku krytycznych i pilnych błędów są one dodawane do bieżącej iteracji.

Nie wiem, dlaczego coś tak prostego jak naprawianie błędów jest skomplikowane z regułami. Scrum ma bardzo niewiele reguł, pamiętasz? Każda funkcja, wsparcie, rekomendacja czy defekt jest problemem w Scrumie, nie ma żadnego rozróżnienia. Tak więc, jak mówi przewodnik po Scrumie: zadania w Sprincie nigdy nie są ograniczone do tego, co zdecydujesz podczas spotkania planującego, Codzienny Scrum pomaga ludziom omawiać „przeszkody” na ich drodze.

Czemu?

Dlatego dyskutujecie i myślicie racjonalnie jako zespół, jeśli chcecie, aby defekt, tj. Problem z zaległościami, trafił do PBI lub pozostał w tym Sprincie i dostarczył go ...

Lepsze pytanie brzmi: jak przestać tworzyć błędy w fazie rozwoju? zobacz -> http://bit.ly/UoTa4n

Jeśli identyfikujesz i dokumentujesz błędy, będziesz musiał je segregować i naprawiać w przyszłości. Prowadzi to do „sprintów stabilizacyjnych”, czyli jednego całego sprintu tylko po to, aby naprawić błędy. Możesz też dodać je z powrotem do listy zadań i nadać im priorytety w ramach jakiegoś przyszłego sprintu. Oznacza to również, że dostarczysz i spodziewasz się podpisania i wypuszczenia oprogramowania ze znanymi błędami (P3 i P4, czyli kosmetyczne i drobne).

To nie jest naprawdę zwinne?

W naszym projekcie przedstawiłem pomysł, aby co trzeci sprint wprowadzać krótki sprint z naprawą błędów. Nasze obecne sprinty trwają trzy tygodnie.

Chodzi o to, że pozwoli to wszystkim programistom skupić się na wspólnym naprawianiu błędów, pozwoli skupić się tylko na nowych historiach w regularnych sprintach i będzie regularnie skupiać się na zmniejszaniu zadłużenia technologicznego.

Poprawki błędów zostaną pogrupowane w odpowiednie historie i uszeregowane według priorytetów. Nacisk nie kładzie się na dobór rozmiaru przed sprintem, ponieważ deweloperzy zmagają się z poprawkami błędów bez utknięcia w zrozumieniu natury wady.

Czy ktoś spróbował tego lub ma jakieś uwagi na temat tego, jak ich zdaniem może to działać?

Pozdrawiam, Kevin.