Czy losowo kodowanie jest dozwolone w scrum

tło

• Mój zespół używa scrum
• Obecnie nie mam przypisanego zadania
• W zaległości nie ma już oczekujących zadań
• Dzisiaj jest dzień pracy dla mojego klienta.

Nie mając dziś wielu rzeczy do zrobienia, chciałem zacząć refaktoryzować kod, który wciąż widzę w projekcie, nad którym pracuję, ale obecnie nie jestem przydzielony do żadnego zadania sprintu, aby wykonać refaktoryzację na dużą skalę.

Czy w Scrumie jest w porządku, jeśli zacznę losowo refaktoryzować kod, który mam i nie napisałem, co zawsze mi przeszkadza, ale nie mam czasu na inne dni, aby go naprawić z powodu innych zadań?

Co z innymi dniami, kiedy mam wolny czas między sprintami.

Tak naprawdę wierzę w ciągłe refaktoryzowanie. Zawsze robię to na fragmentach kodu, nad którymi pracuję, gdy przypisuję im historię, ale co z innym kodem, który widzę, ale który nie jest obecnie związany z tym, nad czym pracuję w tym momencie?

Naprawdę nie zamierzam atakować innych odpowiedzi, ale czy nikt inny nie pisze tutaj automatycznych testów? Oto fajna lektura Martina Fowlera dla każdego, kto robi Scrum bez odpowiednich praktyk inżynierii oprogramowania. Robert C. Martin również dużo tu o tym mówi .

Tak więc, na moją odpowiedź ... Krótko mówiąc, wygląda to tak:

Tak, „losowy” kod refaktoryzacji jest dozwolony w Scrumie , o ile zespół zdecyduje, że należy to zrobić. (W końcu jest samoorganizujący się)

A teraz długa odpowiedź:

Oczywiste jest, że pozostawianie coraz większego technicznego długu po każdym sprincie jest receptą na katastrofę. Wkrótce wszyscy zwolnią, gdy kod będzie bałaganem; każda zmiana będzie trudniejsza do wprowadzenia, ponieważ kod jest tak splątany i nieuporządkowany, że znalezienie miejsc do zmiany zajmuje więcej czasu niż faktyczna zmiana. Jest jeszcze gorzej, jeśli musisz dokonać zmiany w dużym i nieporządnym module, o którym nic nie wiesz, niemożliwym jest uzyskanie / utrzymanie wydajności podczas dodawania / przełączania ludzi w projekcie i tak dalej.

Jeśli zespół chce utrzymać stałą prędkość, musi być w stanie utrzymać czystą bazę kodu, aby stale zwiększać oprogramowanie. Refaktoryzacja jest obowiązkową praktyką, jeśli chcesz zachować szybkość przez cały cykl życia projektu, a jeśli chcesz zmniejszyć ryzyko dodania / zmiany osób w projekcie, a jeśli chcesz mieć możliwość wprowadzania zmian w modułach, nic nie wiesz o, i tak dalej.

Jednak refaktoryzacja jest bardzo niebezpieczną czynnością. Powtarzam - to bardzo niebezpieczne działanie. To znaczy, chyba że masz wystarczającą liczbę testów, aby móc bezpiecznie i swobodnie zmieniać bazę kodu. Jeśli możesz po prostu nacisnąć przycisk, aby sprawdzić, czy nic się nie zepsuło, refaktoryzacja staje się bardzo bezpieczną czynnością; tak bezpieczne, że jest to część cyklu TDD , czyli praktyki, która pozwala przede wszystkim na stworzenie takiego zestawu testów.

Ponieważ jednak zespoły w Scrumie organizują się samoczynnie, ostatecznie zespół musi zdecydować, co należy zrobić. Mam nadzieję, że przedstawiłem ci argumenty na wypadek, gdybyś musiał kogoś przekonać. (Zwróć szczególną uwagę na linki w pierwszym akapicie i każdy inny artykuł, na który wskazują)

Scrum tak naprawdę nie mówi nic o refaktoryzacji.

Scrum mówi, że jeśli nie masz żadnych zadań w sprincie do pracy, powinieneś wesprzeć resztę swojego zespołu, aby osiągnąć cel sprintu. Nawet jeśli oznacza to przyniesienie im kawy.
Jeśli Twój zespół zgadza się, że refaktoryzacja kodu jest najlepszym sposobem, w jaki możesz go wesprzeć (i obejmuje to infrastrukturę zapewniającą, że refaktoryzacja nie wprowadzi zbyt wielu nowych błędów), to na pewno idź.

Powiedziałbym nie, nie jest. Jest to niezależne od rodzaju pracy (refaktoryzacja itp.).

Przynajmniej zadania powinny zostać utworzone i wprowadzone do bieżącego sprintu. Celem śledzenia czasu jest uchwycenie twojej prędkości, aby móc skutecznie planować przyszłe sprinty. Jeśli pracujesz nad rzeczami bez ich śledzenia, wpłyniesz na prędkość i z czasem nie poprawi się, tak jak to ma miejsce przy odpowiednim śledzeniu (prawdopodobnie nie będziesz mieć wystarczająco dużo pracy, ponieważ twoja przewidywana prędkość jest mniejsza niż rzeczywista prędkość ).

Jeśli chodzi o samą refaktoryzację, mogę przejść na ten temat z tyradą, ale nie zrobię tego, ponieważ nie sądzę, że jest to podstawowe pytanie, na które próbujesz odpowiedzieć.

Powiem też „nie”. Ponowne faktoring często prowadzi do niezamierzonych błędów, jeśli nie jest zarządzany we właściwy sposób.

Jako GM okresowo umieszczałem każdego w innym projekcie i spędzałem tydzień na przeglądaniu kodu / przefaktorowaniu / zmianie nazwy i egzekwowaniu konwencji dotyczących projektu. Te sprinty ponownego faktorowania prawie zawsze miałyby charakter kosmetyczny. Wszelkie funkcjonalne faktoring zostanie zaplanowane z wyprzedzeniem i będzie angażować pierwotnego programistę.

Ponowne faktoring funkcjonalny powinien być zawsze planowany i koordynowany w ramach procesu scrum, aby można było śledzić czas, a wszyscy niezbędni członkowie zespołu byli dostępni do zatwierdzenia procesu. Jeden programista nie powinien rezygnować ze zmiany kodu napisanego przez inną ścieżkę, ponieważ najprawdopodobniej po prostu zepsuje bieżący sprint dla wszystkich. Zwłaszcza jeśli chodzi o czas scalania kodu.

Jeśli jest to projekt, którego jesteś jedynym opiekunem i to twój własny wolny czas, może być inaczej, zakładając, że podejmiesz kroki, aby nie powodować niepotrzebnych opóźnień w bieżącym sprincie.

W razie wątpliwości zapytaj swojego kierownika.

EDYCJA: Chciałbym również wspomnieć, że dany fragment kodu, który ci się nie podoba, może mieć z nim określony cel wydajnościowy. Może ci się to nie podobać, ale może być szybsze niż cokolwiek, co możesz zbudować, które pasuje do tego, jak chcesz go używać. To kolejny powód, dla którego ponowne faktoring funkcjonalny zawsze powinien być procesem zarządzanym.

Scrum nie mówi nic o refaktoryzacji (patrz wykład Roberta C. Martina, „Ziemia, o której zapomniał”).

W Scrumie zadania dotyczą funkcji oprogramowania określonych przez klienta, a nie technicznych długów spłacanych przez refaktoryzację. Są to całkowicie różne poziomy abstrakcji. Klient w większości nie jest w stanie ocenić konieczności.

Scrum to statystyczne zarządzanie projektami. Aby uzyskać miarodajne miary „jak długo to trwa”, musisz znać wydajność (wydajność na sprint). Porównujesz oszacowanie i rzeczywisty czas trwania cechy dla co najmniej więcej niż 1 sprintu, aby dostać się do statystyki. Polecam 5 sprintów. Ale to zależy od twojego zespołu.

Najważniejsze jest, aby miary były miarodajne i porównywalne, aby umożliwić każdą prognozę. Nie będzie tak w przypadku spadku wydajności z powodu długów technicznych.

Jeśli nadal myślisz o refaktoryzacji zadań, masz dwa problemy: 1. Klient, który nie rozumie, dlaczego musi zaakceptować zadanie, które nie stworzy nowej funkcji 2. Całkowicie zniekształcasz statystyki, a tym samym swoją zdolność do prognozowania gdy nagle zmieniasz inną zmienną, która nie była brana pod uwagę w poprzednich sprintach

W obu przypadkach naruszasz ideę scrum, gdy chcesz rozmawiać o funkcjach z klientem ORAZ robić wiarygodne prognozy na „Jak długo to zajmie?” w sposób statystyczny. Aby być bezpiecznym, musisz utrzymywać bazę kodu w stałej (być może wysokiej) jakości.

Refaktoryzacja jest w większości przypadków zadaniem podziemnym. „Wielkie” refaktoryzacje oznaczają, że „małe” refaktoryzacje nie były przetwarzane w przeszłości.

Ostatnia uwaga: jeśli dokonujesz refaktoryzacji, upewnij się, że masz testowany komponent, refaktoryzujesz. Och, nie masz testów? Wykonaj zadanie, aby napisać testy. Twój klient z przyjemnością dowie się, że oprogramowanie, którego obecnie używa, nie ma wystarczającej liczby testów ...

Trzymaj techniczne rzeczy z dala od klienta i wykonuj swoją pracę jako profesjonalny programista.

Oto jedno podejście: rób oba!

Refaktoryzacja jest często podatna na błędy lub bardziej czasochłonna, niż pierwotnie oszacowano, jak wskazuje @misterbiscuit.

Zastanów się więc nad próbą zrobienia tego lub przeciągnięcia. Na tym etapie nie należy ubiegać się o zgodę ani reklamować się.

Następnie spróbuj dołączyć go przez jeden z dwóch kanałów:

• istniejący bilet, który dotyka tego samego kodu / funkcji, w którym można rozsądnie go owinąć. Rozsądnie, jak uzgodniono z innymi członkami zespołu.
• cały bilet do przeglądu przy następnym przygotowaniu biletu (lub cotygodniowym spotkaniu itp. w przypadku wodospadu). W tym momencie możesz to uzasadnić.

Po uzyskaniu rzeczywistego wpisowego możesz spróbować zastosować lub powtórzyć swój skok, a faktyczny kod zostanie scalony z gałęzią mainline (master itp.).

Będzie to miało kilka zalet:

• Wszystkie kody w tym samym procesie są poddawane testom, kontroli jakości w potoku wydania itp.
• Otrzymujesz formalne wykupienie, w tym od kierownika produktu, że refaktoryzacja jest częścią rzemiosła, a nie czymś, co trzeba „zakraść” na wakacje. Zadaj sobie pytanie, dlaczego nie wkradasz się do rzeczywistej funkcji, która może pomóc w perspektywie.
• Możesz poprosić o parowanie, przegląd kodu, qa, devops i wszystkie inne wsparcie, które może być potrzebne do zmiany kodu faktoringu. Wszystko będzie oficjalne, zgodnie z Polityką i Procedurą oraz powyżej.
• Jeśli jesteś spółką publiczną z zachowaniem zgodności z SOX, prawdopodobnie chcesz / musisz wykonać tego rodzaju formalny proces (tj. Udokumentować go, a następnie postępować zgodnie z nim).
• Uzyskujesz lepszą reputację zarówno dzięki menadżerowi produktu (zmiana została wprowadzona szybko), jak i zespołowi programistów (baza kodów została ulepszona).
• Organizacja stara się dbać o jakość kodu, która jest dobra z punktu widzenia produktywności, morale, utrzymania pracowników i wielu innych powodów.
• Wpływ na prędkość projektu można łatwiej śledzić, jeśli uwzględni się całą pracę. Można nie wyznaczać żadnych punktów, ponieważ sama obecność może być wykorzystana do zmiany prędkości.
• Deweloperzy prawdopodobnie zobaczą narzędzia zachęcające do łatwiejszych recenzji kodu, takie jak Rybie Oko, Github itp.
• Programiści częściej znają podstawowe standardy (czasem udokumentowane, a czasem nie), które ułatwiają dzielenie się kodem, a tym samym refaktoryzację. Czasami duża część refaktoryzacji polega na wybraniu stylu, a następnie szerokim zastosowaniu go (zastępując mieszankę podejść jednym).

Ostatni komentarz: Unikaj, aby kierownik produktu słyszał słowo „losowy”. Mogą reagować bardziej przychylnie dzięki „ukierunkowanemu, strategicznemu ulepszeniu kodu”. Lub dodatek Service Pack dla aplikacji. Lub w jakimkolwiek języku zapewniasz zasięg.

Losowe refaktoryzacja nie ma sensu. Sensowne jest refaktoryzowanie kodu, który zapewni najwięcej korzyści. To znaczy :

• naprawienie problemu projektowego lub architektury
• poprawa wdrożenia

Czy w Scrumie jest w porządku, jeśli zacznę losowo refaktoryzować kod, który mam i nie napisałem, co zawsze mi przeszkadza, ale nie mam czasu na inne dni, aby go naprawić z powodu innych zadań?

Z tej odpowiedzi :

Utrzymywanie kodu w utrzymaniu musi być elementem na twojej liście rozwijanej (jeśli używasz Scruma). Jest tak samo ważny jak nowy rozwój. Choć może nie wydawać się „widoczny dla użytkownika”, ignorowanie go zwiększa zadłużenie techniczne. W miarę upływu czasu, gdy zadłużenie techniczne rośnie na tyle, że brak możliwości utrzymania twojego kodu spowalnia rozwój, opóźnienia w rozwoju nowych funkcji będą widoczne dla klientów.

W mojej poprzedniej pracy mieliśmy pewien scrum z większymi sprintami (2-3 miesiące). Ponieważ mieliśmy pewne opóźnienia między sprintami (1 miesiąc), wykorzystaliśmy ten czas do analizy oprogramowania i zmiany kodu.