Obsługa „powiązanej” pracy w ramach jednego zwinnego elementu pracy

Jestem członkiem zespołu projektowego złożonego z 4 programistów, w tym mnie. Od dłuższego czasu dyskutujemy o tym, jak poradzić sobie z dodatkową pracą, która pojawia się w ramach jednego elementu pracy.

Ta dodatkowa praca to zwykle rzeczy nieco związane z zadaniem, ale nie zawsze konieczne do osiągnięcia celu przedmiotu (może to być opinia). Przykłady obejmują między innymi:

• refaktoryzacja kodu zmienionego przez element pracy
• kod refaktoryzacji sąsiadujący z kodem zmienionym przez element
• przebudowując większy obszar kodu wokół biletu. Na przykład, jeśli element wymaga zmiany jednej funkcji, zdajesz sobie sprawę, że cała klasa może zostać ponownie wykonana, aby lepiej uwzględnić tę zmianę.
• ulepszenie interfejsu użytkownika w właśnie zmodyfikowanym formularzu

Kiedy ta dodatkowa praca jest niewielka, nie mamy nic przeciwko. Problem polega na tym, że ta dodatkowa praca powoduje znaczne rozszerzenie elementu poza pierwotne oszacowanie punktu cechy. Czasami 5-punktowy przedmiot zajmuje 13 punktów. W jednym przypadku mieliśmy 13-punktowy przedmiot, który z perspektywy czasu mógł wynosić 80 punktów lub więcej.

W naszej dyskusji krążą dwie opcje, jak sobie z tym poradzić.

1. Możemy zaakceptować dodatkową pracę w tym samym elemencie pracy i zapisać ją jako błędne oszacowanie. Argumenty za tym to:

   • Planujemy „dopełnienie” na końcu sprintu, aby uwzględnić tego rodzaju rzeczy.
   • Zawsze zostawiaj kod w lepszej formie niż go znalazłeś. Nie melduj się w pracach na wpół ocenianych.
   • Jeśli zrezygnujemy z refaktoryzacji na później, trudno jest zaplanować i może się nigdy nie skończyć.
   • Jesteś teraz w najlepszym „mentalnym” kontekście, aby poradzić sobie z tą pracą, ponieważ jesteś już w talii głęboko w kodzie. Lepiej jest usunąć go z drogi teraz i być bardziej wydajnym niż stracić ten kontekst, gdy wrócisz później.

2. Rysujemy linię dla bieżącego elementu pracy i mówimy, że dodatkowa praca przechodzi do osobnego biletu. Argumenty obejmują:

   • Posiadanie osobnego biletu pozwala na nową wycenę, więc nie okłamujemy siebie, ile punktów tak naprawdę jest, ani nie musimy przyznać, że wszystkie nasze oceny są okropne.
   • „Padding” sprintu jest przeznaczony do nieoczekiwanych wyzwań technicznych, które stanowią bezpośrednie przeszkody w spełnieniu wymagań dotyczących biletów. Nie jest przeznaczony do przedmiotów ubocznych, które są po prostu „ładne”.
   • Jeśli chcesz zaplanować refaktoryzację, po prostu umieść go w górnej części zaległości.
   • Nie ma sposobu, aby właściwie uwzględnić te rzeczy w oszacowaniu, ponieważ wydaje się to nieco arbitralne, gdy się pojawia. Kontroler kodu może powiedzieć „te elementy sterujące interfejsu użytkownika (których tak naprawdę nie zmodyfikowałeś w tym elemencie pracy) są nieco mylące, czy możesz to naprawić?” co jest jak godzina, ale mogą powiedzieć: „Cóż, jeśli ta kontrola dziedziczy teraz od tej samej klasy podstawowej, co pozostałe, to dlaczego nie przeniesiesz całego tego (setki wierszy) kodu do bazy i nie przeszukasz wszystkich tych rzeczy , zmiany kaskadowe itp.? ” A to zajmuje tydzień.
   • „Zanieczyszcza miejsce zbrodni”, dodając do zgłoszenia niepowiązaną pracę, dzięki czemu nasze pierwotne szacunki punktów fabularnych są bez znaczenia.
   • W niektórych przypadkach dodatkowa praca opóźnia odprawę, powodując blokowanie między programistami.

Niektórzy z nas mówią teraz, że powinniśmy zdecydować się na odcięcie, na przykład, jeśli dodatkowe rzeczy są mniejsze niż 2 FP, to idzie w tym samym bilecie, jeśli jest więcej, uczyń to nowym biletem.

Skoro mamy tylko kilka miesięcy, aby używać Agile, jaka jest opinia wszystkich bardziej doświadczonych weteranów Agile tutaj, jak sobie z tym poradzić?

Sprawne planowanie i historie użytkowników koncentrują się na zapewnianiu wartości i przejrzystości interesariuszom projektu i użytkownikom oprogramowania. Jest to dobra rzecz, ale nie zastępuje ona, nie powinna zastępować ani obniżać znaczenia dobrych wytycznych architektonicznych, zarządzania projektami, dobrych praktyk rozwojowych i utrzymywania zadłużenia technicznego.

Agile nie radzi sobie dobrze z tym ostatnim, ponieważ nie było zamierzone jako odpowiedź na te problemy i problemy techniczne.

Wiedząc, że bardzo się nie zgadzam, że zadania refaktoryzacji, obsługa długów technicznych i prace projektowe powinny uwzględniać osobne historie użytkowników w danym sprincie. Są to jedynie zadania, które deweloper może podjąć, aby pomóc w opracowaniu historii użytkownika dla tego sprintu.

Pamiętaj, że Zadanie to dowolna jednostka przypisywalnej pracy, która pomaga przenieść historię użytkownika do ukończenia w ramach wytycznych architektonicznych i utrzymać dobre praktyki projektowania i rozwoju oprogramowania jako całości.

Dlatego szacowanie godzin powinno dotyczyć zadań, a nie historii użytkowników. Dlatego też niektóre zadania mają kluczowe znaczenie dla ukończenia wielu historii użytkowników.

Czerwony, zielony, refaktor. Taki jest zakres pojedynczego elementu pracy. Napisz niepomyślny zestaw testów obejmujący zakres zmian, koduj minimalną wymaganą ilość do zaliczenia testu, a następnie refaktoryzuj, aby spełnić standardy kodowania, jednocześnie przechodząc testy. Wszystkie trzy z tych kroków są wymagane; nie możesz kodować rozwiązania, dopóki nie zdefiniujesz problemu, jeśli dokonujesz refaktoryzacji, pisząc wiersz kodu, niezmiennie naruszasz YAGNI, ale jeśli nie przejdziesz się za sobą i zrefakturujesz po zdaniu testów, z definicji poniesiesz dług techniczny że w końcu będziesz musiał spłacić.

Biorąc pod uwagę tę definicję i jej przestrzeganie, 5-wskaźnikowy, który okazuje się 13-wskaźnikowy, był błędnym oszacowaniem. To, co uważasz za refaktoryzację, prawdopodobnie bardziej przypominało restrukturyzację; musiałeś zreorganizować dość znaczny obszar bazy kodu, aby nowa funkcjonalność została uwzględniona w zrozumiały i łatwy do utrzymania sposób. Zazwyczaj oznacza to, że zespół nie rozumie ogólnej przyszłej ścieżki rozwoju, co prowadzi do bardzo prostego wdrożenia w poprzedniej iteracji, kiedy to ostatecznie będzie wymagało bardzo SOLIDNOŚCI. Lepsza komunikacja między BA i PM, którzy wiedzą, co znajduje się w dalszej części zaległości, a zespołem programistów, który zasadniczo koncentruje się na bieżącym sprincie, może to złagodzić. Alternatywnie, ta historia ujawniła dużą ilość długu technicznego zaciągniętego w przeszłości, i po prostu dogonił zespół. Lepsze procesy przeglądu kodu, oprócz lepszej wiedzy pojęciowej na temat wzorców projektowych i ogólnej przyszłej ścieżki projektu, mogą pomóc ograniczyć takie przypadki.

Należy pamiętać, że refaktoryzacja jest pracą „nie idealną”. W Agile SCRUM zadania są szacowane w „idealnych godzinach”; to znaczy liczba godzin spędzonych bezmyślnie na pisaniu zupełnie nowego kodu, który nigdy nie istniał, i stanowi podstawę funkcji projektu. 8-godzinny dzień programisty może realistycznie mieć tylko 5 idealnych godzin; czasami możesz liczyć na 6, szczególnie w „odcinku” projektu, w którym zespół naprawdę nuci. Refaktoryzacja lub cofanie się i wprowadzanie zmian, które nie wpływają na funkcjonalność projektu, ale poprawiają bazę kodu w inny sposób, nie jest idealną pracą, podobnie jak planowanie, projektowanie, komunikacja, przegląd, przerwy lub techniczne przestoje. Poza przestojami technicznymi ważna jest nieidealna praca, ale nie robi ona postępów w oczach właściciela produktu.

Tak więc, pod warunkiem, że refaktoryzacja nie podwoi faktycznie spędzonych godzin, pewnej ilości pracy refaktoryzacyjnej należy się spodziewać, jeśli oszacujesz ją w idealnych godzinach. Powiedzmy, ponieważ nie wiem dokładnie, jak skalibrowana jest skala punktowa twojego zespołu, że 5-wskaźnikowy odpowiednik to jeden idealny tydzień programisty lub około 25 idealnych godzin. Ta 5, która zmieniła się w 13 (więcej niż dwa tygodnie programistów w tej samej skali), jest powodem do pewnej retrospekcji na temat tego, co spowodowało, że złożoność wzrosła. Być może baza kodów nie wymagała tak dużego refaktoryzacji, jak w rzeczywistości zrobiono, być może spora część długu technicznego zgromadziła się bez wiedzy zespołu, który musiał zostać rozwiązany, aby nowe funkcje działały,

W alternatywnym wszechświecie wyobraźmy sobie, że 5 oszacowany w idealnych godzinach stał się 7 (~ 35 godzin) na podstawie rzeczywistych godzin, ponieważ potrzebowałeś 10 godzin dodatkowego refaktoryzacji, aby umieścić nowy kod i niektóre poprzednie bity we właściwym wzorcu architektura projektowa. W takim przypadku dodatkowa kwota mieści się w „luce” między idealną a całkowitą liczbą godzin w ciągu dni, w które fabuła miała zająć. Jako kierownik projektu nazwałbym 5, które stało się 7, rozsądnym szacunkiem i ruszyłem dalej.

Punkty opowieści są oszacowaniem względnej złożoności danej historii użytkownika. Wygląda na to, że używasz punktów opowieści, aby powiedzieć, że zajmie to X osobiście dni / godzin. Zamiast tego dąż do dwóch celów

1. Podziel historie, dopóki nie znajdą się w stałym zakresie (3, 5 lub 8 punktów)
2. Załóżmy, że historia obejmuje wszelkie niezbędne refaktoryzacje

Z czasem da ci to podstawową wartość prędkości. Każda pięciopunktowa opowieść nie zajmie tyle samo czasu co inne, ale średnia prędkość na sprint (ile punktów historii może ukończyć drużyna) będzie spójna.

Martwienie się o to, ile czasu zajmie konkretna historia, przynosi efekty odwrotne do zamierzonych. Szacunki uśredniają się tylko w stosunku do objętości konsekwentnie wielkości (IE jeden wskaźnik 5 może potrwać nieco dłużej z powodu refaktoryzacji, ale czerpiesz korzyści z tego wysiłku na pokrewnym).

Powinno być względne ograniczenie tego, ile mieści się w oryginalnym elemencie pracy, a ile jest czegoś innego. Historie użytkowników są punktami wyjścia do dyskusji, a zatem mogą istnieć wszelkiego rodzaju elementy lunety, które można ustalić podczas sprintu podczas pracy nad historią.

Może się zdarzyć, że w planowaniu sprintu historia może zostać dodana do dodatkowych kryteriów, aby uniknąć „pełzania zakresu”, co może się zdarzyć, gdy użytkownik chce nowego formularza, a następnie 101 zmian w tym formularzu, które nie są realistyczne skończ czasem w 2-tygodniowym sprincie.

Drugą stroną, o której należy pamiętać, jest to, ile zyskuje się dzięki tej dodatkowej pracy. Może być mnóstwo możliwych refaktoryzacji, które można by zrobić, ale ile korzyści może przynieść ktoś za całą tę pracę? W tym miejscu muszą istnieć pewne wytyczne, które pomogą utrzymać zespół w dobrej pracy, ale nie zgubić się w próbach udoskonalenia kodu.