Punkty za zadania naprawiania błędów: czy nadaje się do Scruma?

Zastanawiam się tylko, czy powinniśmy przypisać punkty historii do zadań naprawiania błędów, czy nie. JIRA, nasze oprogramowanie kwestie śledzenia, nie ma pola do punktu historia Bug zagadnień typu (to tylko dla Story s i Epic s).

Czy powinniśmy dodać typ błędu do odpowiednich typów problemów w polu Punkty historii ? Jakie są zalety i wady? Czy byłoby odpowiednie dla Scrum?

Idealnie, twoje oprogramowanie powinno być wolne od błędów po każdej iteracji, a naprawianie błędów powinno być częścią każdego sprintu, więc przy przypisywaniu punktów fabularnych należy wziąć pod uwagę pracę wymaganą do naprawienia błędów (tj. Zadanie, które jest bardziej prawdopodobne, powinno powodować błędy przypisać mu więcej punktów historii).

W rzeczywistości jednak błędy cały czas pojawiają się po wdrożeniu, bez względu na to, jak rygorystyczne są Twoje testy; kiedy tak się dzieje, usunięcie błędu to kolejna zmiana, funkcja, jeśli wolisz. W tym kontekście nie ma zasadniczej różnicy między raportem o błędzie a żądaniem funkcji: w obu przypadkach aplikacja wykazuje określone zachowanie, a użytkownik (lub inny interesariusz) chciałby, aby to się zmieniło.

Z perspektywy biznesowej poprawki i funkcje są również takie same, naprawdę: albo robisz to (scenariusz B), albo nie robisz (scenariusz A); oba scenariusze wiążą się z kosztami i korzyściami, a porządny biznesmen po prostu je zważy i pójdzie z tym, co przyniesie im większy zysk (długoterminowy lub krótkoterminowy, w zależności od strategii biznesowej).

Więc tak, z całą pewnością, przypisuj punkty historii do błędów. W jaki inny sposób zamierzasz uszeregować pod względem ważności błędy w stosunku do funkcji oraz błędy przed błędami? Potrzebujesz obu środków rozwojowych w obu przypadkach i lepiej być porównywalnym.

Największym problemem jest to, że poprawki błędów są często trudniejsze do oszacowania: 90% lub więcej faktycznego wysiłku polega na znalezieniu przyczyny; gdy go znajdziesz, możesz podać dokładne oszacowanie, ale prawie niemożliwe jest oszacowanie, ile czasu zajmie wyszukiwanie. Widziałem nawet sporo błędów, w których większość czasu spędziłem na próbach odtworzenia błędu. Z drugiej strony, w zależności od charakteru błędu, często możliwe jest zawężenie wyszukiwania przy pomocy minimalnych badań przed dokonaniem oszacowania.

Szacowanie błędów za pomocą punktów jest z natury trudne, jak już wskazano w innych odpowiedziach. Tak, idealnym rozwiązaniem jest to, że błędy znalezione w funkcji PO zaakceptowaniu sprintu należy uznać za nowe funkcje .

Ta trudność w ocenie punktowej błędów jest jednak jednym z wielu powodów, dla których pakiety oprogramowania Agile PM pozwalają na oszacowanie zadań i błędów w ciągu kilku godzin, ponieważ do opanowania oceny punktowej potrzeba staranności i doświadczenia. Wiele projektów napotyka znaczące problemy z prawidłowym określeniem prędkości, więc wiele projektów zwinnych używa punktów, aby określić, które historie trafiają do sprintu, jednak wykorzystują godziny przy obliczaniu wykresu wydajności .

Wydaje się to sprzeczne z intuicją, ale możliwe do zarządzania, o ile oszacowanie godzin nie jest wykorzystywane jako czynnik określający zobowiązanie do sprintu. Nadmierne zaangażowanie naturalnie doprowadzi do pominięcia lub niekompletności funkcji lub nadgodzin, więc z czasem wszyscy zaangażowani są zmuszeni do poprawy w szacowaniu punktu, w którym to momencie szacowanie godzin na zadaniach i błędach powoli staje się nieistotną miarą.

Nie powinieneś dawać punktów do rozwiązania problemu. Weź pod uwagę fakt, że błąd pochodzi z historii, w której programiści zdobyli już punkty za ukończenie historii. Nie powinien ponownie otrzymywać punktów tam, gdzie właściwie nie powinien był zdobywać punktów na początek.

Naprawianie błędów powinno mieć negatywny wpływ na prędkość. W przeciwnym razie spadająca jakość zostanie nagrodzona niezmienioną lub nawet zwiększoną prędkością!

Być może przydatny link:

http://www.infoq.com/news/2011/01/story-points-to-bugs

Poleciłbym potraktowanie błędu jako historii użytkownika i przypisanie mu kilku punktów. Niekoniecznie napisałbym to w formacie „Jako X, chcę Y, aby Z”, jak to często bywa w opowieściach użytkowników - napisałbym to bardziej jako „Jako X, gdy IY, Z się zdarza, ale Z jest oczekiwanym zachowaniem ”.

Zaletą tego jest to, że pozwala on priorytetowo traktować poprawki błędów obok nowych żądań funkcji. Prawda jest taka, że ​​czasami nowa funkcja jest ważniejsza niż naprawianie błędu. Jednak pozwala również odpowiednio dobrać wymaganą pracę, co pozwala dopasować ją do sprintu, jeśli masz taką możliwość.

Należy pamiętać, że oszacowanie wysiłku wymaganego do naprawienia błędu może być trudne. Może obejmować wiele współdziałających ze sobą elementów, co wymaga znajomości interakcji dużych elementów systemu lub wielu osób do pracy nad poprawką.

Szacowanie historii opiera się na założeniu, że z czasem zespół zdobywa doświadczenie w ich rozwiązywaniu. Dzięki niemu poprawia się dokładność i można ustalić prędkość do pomiaru prędkości zespołu. Idealna metodologia ustalania wiarygodnych prognoz na przyszłe sprinty.

Błędy są faktem dla firmy produkującej oprogramowanie. Chociaż zgadzam się, że wszystkie błędy powinny być wychwytywane podczas tworzenia opowieści, akceptacja, że ​​nie można tego osiągnąć przez cały czas, powinna być czymś, co każda drużyna powinna zaplanować. Zamiast uparcie myśleć, że proces powinien rządzić zespołem, powinno być na odwrót.

Oczywiście błąd lub historia, od strony biznesowej nie ma znaczenia, z czym ma do czynienia zespół. Oba mogą wytworzyć taką samą wartość dla właściciela produktu.

W naszym zespole eksperymentowaliśmy z niektórymi technikami szacowania błędów:

1. Szacowanie całkowicie nieznanych błędów
2. Tylko szacowanie błędów, które zostały już przeanalizowane
3. Przydzielanie czasu na naprawę błędów i nie szacowanie błędów, ale oceniaj je wyłącznie na podstawie wartości biznesowej

Z 1. ponieśliśmy klęskę. W przypadku większości błędów 90% czasu poświęcamy na analizę błędów. Następnie naprawę błędu można oszacować w taki sam sposób, jak historię. Planując błędy w sprincie, popełniliśmy błąd, że nieznany zakres wpływał na rozstrzygnięcie historii aż do momentu, w którym prawie każdy sprint, który wykonaliśmy w ten sposób, zawiódł.

W oparciu o współczynnik oceny 90/10 (analiza do naprawy błędów) technika 2. opcji oznaczała, że ​​musieliśmy zaplanować analizę, która nie była objęta planowaniem sprintu (nauczyliśmy się z opcji 1, ale nie mieliśmy prawdziwego rozwiązania jak kontynuować analizowane błędy). W rezultacie analiza błędów nie została przeprowadzona, ponieważ zamiast tego sprint koncentrował się na planowanych przedmiotach. Zespół nie miał czasu skupić się na błędach z zaległości. Więc w końcu też się nie udało.

Obejmując niepewność, zdecydowaliśmy się teraz na opcję 3. Podzieliliśmy zaległości produktu na zwykłą część historii / zadania, którą zespół może oszacować na podstawie punktów historii i zaległości błędów. W zaległościach dotyczących błędów właściciel produktu klasyfikuje błędy na podstawie wartości biznesowej i bardzo surowej oceny zespołu. Zespół pozwala poświęcić kawałek czasu podczas sprintu, który może poświęcić na skupienie się na błędach. Właściciel produktu nie zna dokładnego wyniku, ponieważ wcześniej nie można było tego zaplanować. Stosunek zaległości błędów do regularnych zaległości można dostosować dla każdego sprintu w zależności od aktualnego statusu każdego zaległości oraz znaczenia i wartości biznesowej treści.

Po wyeliminowaniu niepewności zespół ponownie zwolnił. Sprinty nie były zagrożone przez nieznane błędy. Rozdzielając błędy na inne zaległości, zwiększyliśmy regularne skupienie zespołu na sprincie i sprawiliśmy, że zakończyliśmy błędy, które również miały znaczącą wartość biznesową.

To zależy od tego, czy punkty historii są dla Ciebie odpowiednie. Najpierw spróbuję oszacować błędy, wykorzystując punkty historii. Jeśli to się nie powiedzie, wypróbuj moją opcję 3. Dzięki temu nasz (ponad 30-letni sprint) zespół ponownie skupił się na starszych błędach, które mają wielką wartość biznesową. Uwolniło nas to również od próby dostarczenia czegoś, czego zespół po prostu nie jest w stanie oszacować. Obejmowało to, co nieznane, co zbliżyło nas do rzeczywistości, a także sprawiło, że nasze sprinty odniosły sukces , dostarczając dużą część (na podstawie stosunku błędów do historii) wartości biznesowej poprzez poprawki błędów. Stosowany ostatnio przez nas współczynnik wynosił 50/50.

Muszę się nie zgodzić z najlepszą odpowiedzią dotyczącą przypisywania punktów historii do błędów. Punkty fabularne powinny dotyczyć dostarczenia nowej wartości. Jeśli zamierzasz przypisać punkty do wartości produktu i przedmiotów innych niż wartościowe, równie dobrze możesz po prostu oszacować i śledzić godziny.

Błędy są narzutem na to, co zrobiłeś wczoraj i nie wskazuje na szybkość ukończenia produktu, i nie tworzą też żadnej nowej wartości produktu (pomyśl o tym). Błędy to coś w rodzaju przerwania i wszystkich innych krowich ciast, z którymi musisz sobie radzić co tydzień. Cała idea punktów fabularnych polega na tym, że śledzi / ocenia, kiedy dostarczymy produkt (lub zestaw funkcji). Punkty fabularne są arbitralne i w ten sposób usuwa się z oszacowania wszystkie koszty niezwiązane z wartością. Zasadniczo praca bez wartości jest stała z tygodnia na tydzień, więc jest wbudowana w szybkość zespołu. Zespół przyspieszy, gdy usunie lub zmniejszy pracę bez wartości.

Innymi słowy, dlaczego nawet śledzić punkty błędów? Czyli na koniec dnia wiesz, ile „pracy” wykonał każdy członek? Przestań! Zły manager! :) Zmierz drużynę, a nie gracza. Zachęcaj zespół do samodzielnego zarządzania, jeśli jedna osoba nie ciągnie za sobą. O wiele bardziej skuteczny. Wykonanie przedmiotów z punktu fabularnego nie powinno sprawić, że każdy poczuje się lepiej, ale zespół jako całość powinien poczuć się lepiej, kiedy podejmie zobowiązanie na koniec sprintu. Czy w sporcie cel jest dobry dla zespołu czy osoby? Jeśli osoba gra dla siebie, drużyna przegrywa na dłuższą metę.

Wiesz, ostatecznie nie chcesz wcale używać punktów. Oszacowanie to czas zabrany z pracy. Kiedy drużyna osiągnie maksymalne chi , wcale nie wykorzystuje punktów, ale dokładnie wie, ile przedmiotów może przyciągnąć do sprintu. Opanowali sztukę dzielenia jednostek pracy, których oszacowanie jest marnotrawstwem procesowym.

Niektóre zadania są możliwe do oszacowania, inne nie. W przypadku rzeczy, których nie można oszacować, użyj budżetu.

Naprawa wady nie jest łatwym do oszacowania zadaniem, ponieważ zawiera kilka nieznanych składników. Co powoduje wadę? Po zrozumieniu przyczyny, jak można to naprawić? Jaki wpływ ma ta zmiana na resztę systemu? Ile nowych wad wstrzyknąłeś naprawiając tę ​​wadę?

Należy pamiętać, że przyczyna wady może pochodzić z dowolnego miejsca w cyklu życia oprogramowania - źle zrozumiane lub źle komunikowane wymagania, zły projekt lub błędne założenia, złe kodowanie, złe testowanie, nowa wiedza na temat problemu na podstawie informacji uzyskanych z bieżącej wersji ...

Tworzenie budżetu można wykonać na kilka różnych sposobów w celu naprawy błędów. Oto kilka pomysłów, z których skutecznie korzystałem:

• Użyj danych historycznych (powiedzmy z poprzedniej iteracji), aby pomóc Ci zrozumieć, ile czasu przeznaczasz na naprawę błędów.
• Umieść „bloki” naprawiania błędów (powiedzmy 5 punktów lub 20 godzin) w swoim zaległości i pozwól klientowi wybrać to zamiast opowiadań.
• Wymagaj, aby każdy członek twojego zespołu poświęcił określoną ilość czasu na każdą naprawę wad.

Twoim celem jest usunięcie jak największej liczby wad w przydzielonym budżecie. Omów z klientami strategie ustalania priorytetów zgłaszanych wad. Na przykład, czy sortujesz defekty według ważności, a następnie według priorytetu? Ścisły priorytet? Czy najpierw powinieneś zaatakować „nisko wiszące owoce”? Błędy UI pierwszy?

Ponadto naprawianie błędów nie przynosi wartości. Naprawianie wad jest formą marnotrawstwa. Już zdobyłeś wartość tej funkcji, więc nie powinieneś dostawać „punktów bonusowych” za naprawianie błędów.

Posiadanie budżetu pomaga w planowaniu i nadal zapewnia dokładny obraz prędkości. Budżetuj określoną liczbę punktów do naprawy błędów, podaj budżetowi przybliżony czas na podstawie twoich danych historycznych, a następnie zmiażdż jak najwięcej błędów w wyznaczonym czasie!

Zamiast skupiać się na opowiadaniach, błędach i obowiązkach oraz na punktach, które każdy z nich ma, uważam, że lepiej skupić się na dostarczaniu funkcji dla klienta.

Klienci oczekują, że oprogramowanie będzie działało, a prawdziwą wartość dodają rozwojowi, ulepszeniom i nowym funkcjom, które napędzają rozwój firmy.

Poprawki błędów, jakkolwiek ważne, nie prowadzą firmy do nowych obszarów i nowych klientów (stycznie i ostatecznie może tak, ale nie od razu, co mierzy kierownictwo).

Tak więc punkty najlepiej oglądać z wyższego punktu widzenia prędkości i ile punktów tygodniowo wykonano historycznie dla podobnie ocenianych historii.

Może to prowadzić do zarządzania na podstawie historii osiągnięć, zamiast zwiększania pilnej potrzeby, aby historie z tego tygodnia były kompletne i często stwierdzały, że tak nie jest. Jednak utrata kontroli z góry i zwiększone zaufanie, które tego wymaga, spowoduje, że niektórzy menedżerowie będą z przerażeniem biegać do drzwi.

Używam Pivotal Tracker (mam tylko JIRA, Trak, Trello i inne), a Pivotal Tracker również nie robi punktów za prace domowe lub błędy. Robi się to z tych samych dobrych powodów, które sprawiają, że dzieje się tak również w JIRA, gdy się widzisz.