Pracuję z bazą kodu, która ma ponad 500 000 linii kodu. Poważnie potrzebuje refaktoryzacji. Zidentyfikowano wysiłki refaktoryzacyjne, które potrwają dłużej niż normalny dwutygodniowy sprint. Nie można ich podzielić na mniejsze zadania, jak sugerowałem w innych odpowiedziach na tej stronie. Produkt musi działać pod koniec iteracji, a częściowe refaktoryzacja pozostawi system w stanie niezdatnym do użytku, ponieważ zależność między elementami jest straszna. Więc jaki byłby najlepszy sposób na zbliżenie się do tej przeszkody? Ponownie wspominam, że rozbicie go na mniejsze części nie jest opcją, co już zostało zrobione.
Aktualizacja: Wydaje się, że ludzie potrzebują wyjaśnienia, dlaczego nie można tego dopasować do dwutygodniowego sprintu. W sprincie chodzi o coś więcej niż tylko pisanie kodu. Mamy zasady braku kodu bez testów. Ta polityka nie zawsze istniała i znaczna część bazy kodu jej nie ma. Również niektóre z naszych testów integracyjnych są nadal testami ręcznymi. Nie chodzi o to, że samo refaktoryzowanie jest tak duże. Wynika to z faktu, że niewielkie zmiany mają wpływ na wiele części systemu i musimy upewnić się, że te części nadal działają poprawnie.
Nie możemy odłożyć ani przedłużyć sprintu, ponieważ mamy comiesięczne poprawki. Tak więc zmiana rozciągająca się po sprincie nie może zatrzymać innych prac dodawanych do poprawki.
Refaktoryzacja a przeprojektowanie: Tylko dlatego, że nasz proces rozwoju nie jest wystarczająco wydajny, aby poradzić sobie z refaktoryzacją w cyklu dwutygodniowym, nie gwarantuje zmiany nazwy na przeprojektowanie. Chciałbym wierzyć, że w przyszłości moglibyśmy wykonać dokładnie to samo zadanie w ciągu dwóch tygodni, gdy nasz proces ulegnie poprawie. Kod, o którym tu mowa, nie musiał się zmieniać od bardzo dawna i jest dość stabilny. Teraz, gdy kierunek działalności firmy staje się coraz bardziej dostosowywalny do zmian, chcemy, aby ta część podstawy kodu była równie elastyczna jak reszta. Co wymaga refaktoryzacji. Na podstawie odpowiedzi tutaj widać, że brakuje rusztowań niezbędnych do tego, aby refaktoryzacja działała w czasie normalnych sprintów.
Odpowiedź:
Zamierzam wykonać podejście rozgałęzienia i scalenia, które zaproponował Corbin March po raz pierwszy, abyśmy mogli dowiedzieć się więcej o tych obszarach problemowych i jak zidentyfikować brakujące testy. Myślę, że idąc naprzód, powinniśmy zastosować podejście zaproponowane przez Buhb w celu zidentyfikowania obszarów, w których brakuje testów, i najpierw je wdrożyć, a następnie dokonać refaktoryzacji. Pozwoli nam to zachować normalny dwutygodniowy cykl sprintu, tak jak wielu tutaj mówiło, że zawsze powinno być tak w przypadku refaktoryzacji.