Utrzymanie zwinności dzięki zasadom zero błędów / usterek

W naszym projekcie pracujemy w metodyce zero-bug (aka zero-defect). Podstawową ideą jest to, że błędy mają zawsze wyższy priorytet niż funkcje. Jeśli pracujesz nad historią i ma ona błąd, należy ją rozwiązać, aby historia została zaakceptowana. Jeśli podczas sprintu dla starszej historii zostanie znaleziony błąd, musimy umieścić go w naszym dzienniku zaległości i rozwiązać - najwyższy priorytet.

Powodem, dla którego mówię „rozwiązać”, jest to, że nie zawsze naprawiamy błąd. Czasami deklarujemy, że „nie naprawi się”, ponieważ nie jest to takie ważne. W sumie brzmi świetnie. Wysyłamy produkty wysokiej jakości i nie nosimy „garbu” w postaci ogromnej liczby zaległych błędów.

Ale nie jestem pewien, czy to podejście jest prawidłowe. Zwykle zgadzam się, że zawsze musimy jak najszybciej naprawić poważne błędy i musimy usunąć nieciekawe błędy. Ale co z błędami, które są ważne, ale nie tak ważne jak nowe funkcje? Wydaje mi się, że należy je zaliczyć do zaległości z odpowiednim priorytetem.

Podam przykład, aby był jaśniejszy - w moim projekcie pracujemy z interfejsem użytkownika napisanym fleksją. Mamy ekran kreatora, który otwiera się w tym samym rozmiarze dla każdej rozdzielczości ekranu. Okazuje się, że kiedy rozszerzamy okno kreatora, jedna ze stron nie wygląda dobrze (istnieje pionowy pasek przewijania, który nie znika, chociaż kreator może teraz prezentować wszystko i nie wymaga paska przewijania). Myślę, że ten błąd jest brzydki. Jestem pewien, że MUSI to zostać naprawione. Ale mamy napięty harmonogram i mamy wiele funkcji, których obawiamy się, że nie zrobią cięcia i nie wejdą do wydania. Czuję, że możemy żyć z takim błędem. Trzeba to naprawić, ale ma niższy priorytet niż inne funkcje (więc na wypadek, gdybyśmy nie byli w stanie go ukończyć, przynajmniej nie pominęliśmy ważniejszych funkcji). Ale,

Bardzo chciałbym usłyszeć opinie o tym, jak radzić sobie z błędami, których nie chcę oznaczać jako „nie da się naprawić”, ale także nie są one najważniejsze.

Naprawianie błędów przed napisaniem nowego kodu jest w rzeczywistości jednym z dwunastu punktów testu Joela . Joel wyjaśnia również, dlaczego jest to konieczne:

Ogólnie rzecz biorąc, im dłużej czekasz na naprawę błędu, tym bardziej kosztowne (czas i pieniądze) jest naprawa.

Masz wybór:

• Albo wdrożysz wysoce wymaganą funkcję i opóźnisz naprawienie błędu, co nieuchronnie zwiększy koszt jego naprawy,

• Lub naprawisz teraz błąd, biorąc pod uwagę, że klienci będą rozczarowani, że tak wolno dostarczasz funkcję, której tak bardzo potrzebują.

Jeśli błąd nie jest bardzo ważny, podczas gdy funkcja jest, kierownictwo będzie skłonne poprosić o jej wdrożenie, a następnie napraw błąd. Z biznesowego punktu widzenia jest to całkowicie uzasadniony wybór, o ile kierownictwo wyraźnie rozumie konsekwencje, tj. Trudniej byłoby naprawić błąd później niż teraz.

Trzymanie się „żadnych nowych funkcji do czasu usunięcia wszystkich błędów” może nie być najlepszym wyborem biznesowym. Wspomniałeś już o jego ograniczeniach, więc nie musisz tego wyjaśniać.

Biorąc to pod uwagę, ryzyko związane z wdrożeniem bardzo ważnych funkcji przed naprawieniem drobnych błędów wiąże się z pewnym ryzykiem: gdzie ustalić granice? Czy funkcja wymagana przez 1 000 klientów jest ważniejsza niż błąd napotkany przez 100 klientów? Jak ocenić, czy daną funkcję należy wykonać przed naprawieniem danego błędu?

Bez ścisłych zasad i jeśli kierownictwo nie rozumie dobrze procesu rozwoju, za kilka lat możesz zobaczyć siebie z zaległymi błędami, które uznano za niewystarczająco ważne, aby można je było naprawić przed kolejną wymyślną funkcją.

Oprócz nurkowania w szczegółach swojej sytuacji na niskim poziomie, lepiej upewnij się, że masz podstawowe, podstawowe rzeczy.

W związku z tym uważam, że bardzo ważne jest, aby wspomnieć, że wspomniana polityka: „błędy mają zawsze wyższy priorytet niż funkcje”, szczególnie słowo to zawsze odbiega od co najmniej dwóch z czterech zasad określonych w Manifeście Agile :

Osoby i interakcje dotyczące procesów i narzędzi

Reagowanie na zmianę po wykonaniu planu

Nie nalegam, abyś zmienił politykę, ponieważ głęboko wierzę, że trzeba być zwinnym w kwestii samego stosowania zasad zwinnych.

Ale powinieneś być przynajmniej świadomy, kiedy zbaczasz i zrozumieć, czy i jak odstępstwo jest uzasadnione . Mówiąc najprościej, lepiej upewnij się, że to, co nazywasz „zwinnym”, nie popada w bezsensowną podróbkę, tak elokwentnie ujęte w Manifeśie Zwinnego Zwinnego :

Osoby i interakcje między procesami i narzędziami,
a my mamy obowiązkowe procesy i narzędzia do kontrolowania interakcji tych osób (preferujemy termin „zasoby”)

Oprogramowanie działające na obszernej dokumentacji,
o ile oprogramowanie to jest kompleksowo udokumentowane

Współpraca z klientami w zakresie negocjacji umów
w ramach ścisłych umów, oczywiście, i podlega rygorystycznej kontroli zmian

Reagowanie na zmianę w następstwie planu,
pod warunkiem, że istnieje szczegółowy plan reagowania na zmianę i jest on ściśle przestrzegany

Ze względu na kompletność nie tylko zwinne zasady odbiegają od zasad zero błędów.

W projektach nie zwinnych, w których brałem udział, powszechnie uważano, że ... niemądrze jest poświęcać czas programistom na naprawianie błędów, które nie są wystarczająco ważne, aby uzasadnić opóźnienie wydania funkcji o wysokim priorytecie.

Z tego powodu zarząd zwykle spędzał (być może dokładniej byłoby powiedzieć, że zainwestował ) pewne wysiłki w podejmowaniu decyzji, jakie błędy mogą czekać na następną wersję.

• ^{Czy przypadkiem pracujesz nad oprogramowaniem o znaczeniu krytycznym? Pytam, ponieważ w tym przypadku zasada zero błędów ma sens i jest warta naruszenia zasad agile / non agile / cokolwiek. Chociaż w tym przypadku trudno mi sobie wyobrazić sprawny proces.}

Wiesz, chyba że pracujesz nad oprogramowaniem o znaczeniu krytycznym, zaleciłbym dokładniejszą ocenę umiejętności i zdolności myślenia twojego kierownictwa.

Mam na myśli, z tego, co opisujesz, wygląda raczej na to, że po prostu nie są w stanie poprawnie ustalić priorytetów błędów i funkcji. Jeśli tak jest, jeśli nie są w stanie poradzić sobie z tak stosunkowo rutynowym zadaniem, to czego jeszcze nie są w stanie? Zapewniając konkurencyjne wynagrodzenie? możliwości rozwoju kariery? warunki pracy?

Jak słusznie wskazujesz, zasada zero błędów ma ryzyko, że niekrytyczne problemy zostaną zignorowane lub wrzucone pod dywan, ponieważ teraz nie jest najlepszy czas na ich rozwiązanie.

Po zgłoszeniu nowego problemu możesz podjąć trójstronną decyzję:

1. Jest to prawdziwy błąd i powinien zostać naprawiony jak najszybciej: umieść na górze zaległości
2. To prawdziwy błąd, ale nie jest krytyczny dla działania aplikacji: zmień go w zwykłą historię i pozwól właścicielowi produktu nadać jej priorytet.
3. To nie jest błąd, ani duplikat, ani nie warto próbować go rozwiązać: odrzuć z odpowiednim powodem.

W ten sposób mniej ważne kwestie nie zostaną całkowicie zapomniane, ale nie zmuszają również wszystkich nowych błyszczących funkcji do następnego sprintu. „Przekształć to w historię” jest po to, aby kierownictwo mogło nadal twierdzić, że przestrzegasz zasad zero błędów, a właściciel produktu powinien być w stanie zrównoważyć wagę problemu z ważnością funkcji zaległości.

Zauważ, że dzięki tej procedurze problemy takie jak pasek przewijania, o którym wspomniałeś, mogą nadal nie zostać rozwiązane pod koniec projektu, ale było tak, ponieważ nikt nie uważał, że jest to wystarczająco ważne (w tym klienci), a nie dlatego, że nie było czas znalezienia problemu.

Podoba mi się twój plan, jednak, jak już zidentyfikowałeś, wymaga tylko drobnych poprawek, aby działał - Jak zauważyłeś, rzeczywistość jest często nową funkcją, która poprawia naprawę błędu .....

Moją sugestią jest wymuszenie zwiększenia priorytetu błędu przy każdym sprincie. Powiedzmy, że masz błąd na poziomie 5 (skala 1-wysoka, 5 = niska). Zaczyna się jako 5, 4 sprinty później, jest to błąd poziomu 1. Jednak zestawem umysłów potrzebnym do obliczenia priorytetu jest „Bieżący priorytet - liczba sprintu”, a nie „Zwiększ priorytet zaległych błędów na końcu każdego sprintu” - zapobiega to resetowaniu priorytetu do niskiego w celu dalszego jego odraczania.

Błędy poziomu 1 należy rozwiązać w kolejnym sprincie ......

Jest prosty do wyjaśnienia, łatwy do wdrożenia ....

Teraz, aby uwzględnić propozycje, może inna stawka. Po pewnym czasie żądanie musi zostać rozpatrzone - wykonane lub odrzucone, zapobiegając zaległościom funkcji, które nie mają wartości ......

Wpadasz w kłopoty, gdy starasz się być zbyt dosłowny lub nieugięty w rozwoju oprogramowania, ponieważ wszyscy naprawdę chcemy, aby rzeczy były wycięte i wysuszone. Błędy powinny zostać naprawione przed dodaniem nowych funkcji, ale nadal rozważałbym znaczenie każdego z nich przy podejmowaniu tej decyzji wraz z zakresem problemu. Istnieją wyjątki od wszystkiego.

Niektóre aplikacje są tak duże, że mają sekcje, które w ogóle nie są powiązane. Nie rozumiem, dlaczego każda nowa funkcja modułu rozrachunków z dostawcami musi zostać wstrzymana, ponieważ w interfejsie GUI świadczeń pracowniczych jest kilka irytujących błędów. Jeśli w dziale zakupów na stronie internetowej firmy pojawiło się jakieś irytujące działanie GUI, napraw to, ale wiele błędów może wymagać usunięcia, jeśli dodana funkcja jest wynikiem dodatkowego bezpieczeństwa, potrzeb biznesowych, a zwłaszcza zmian w przepisach.

Oprócz dużej rozbieżności w czasie i zasobach potrzebnych do ukończenia jednego z nich, najlepiej uzyskać wkład użytkowników / klientów. Jeśli mogą żyć z błędem, jeśli oznacza to uzyskanie nowej funkcji, dodaj tę funkcję. Celem powinno być unikanie gromadzenia się błędów, aby mieć przerwę. W pewnym momencie wiele małych problemów staje się poważnymi.

Pisanie testów, aby pokazać błąd podczas uruchamiania testu, to dobry początek do naprawy błędów. Ale kiedy próbujemy naprawić błędy, które mają najmniejszy priorytet, powinniśmy pomyśleć dwa razy, zanim przejdziemy do tego. Nie chciałem pominąć naprawy. Ale możemy użyć niekrytycznych zasobów, aby naprawić te błędy. Powiedzmy, że w moim zespole szkolimy nowe zasoby z najmniejszymi priorytetami błędów na liście błędów. W ten sposób mamy szansę wyszkolić nowy zasób, a także dać mu cień pewności, że poprawili swoje wejście do aplikacji. To z pewnością sprawi, że będą się zgłaszać do następnego priorytetowego zadania.

Mam nadzieję że to pomoże :)