Oszacowanie zakresu przebudowy procesu CI/CD

W przypadku prac związanych z potokiem nie ma wersji demonstracyjnej. Proszę dokonać podziału według kryterium „którą kompilację można dzisiaj usunąć”, aby umożliwić oszacowanie nakładu pracy.

Przebudowy procesów CI/CD to najgorzej sformułowane zadania w rejestrze zadań. Nie ma tu żadnego rezultatu widocznego dla użytkownika, żadnej prezentacji ani zrzutu ekranu, który można by umieścić w informacjach o wydaniu. Praca ma charakter strukturalny: zastąpienie jednego potoku innym, migracja systemu kompilacji, konsolidacja trzech narzędzi do uruchamiania testów w jedno oraz przejście z ręcznie napisanego skryptu powłoki na prawidłowy plik przepływu pracy. Zespół zdaje sobie sprawę, że prace te muszą zostać wykonane. Zespół wie również, że zajmie to jeden kwartał, a ten kwartał będzie niewidoczny dla osób spoza działu inżynierii.

Sposób, w jaki oszacowanie zawiedzie, jest przewidywalny. Zespół przyznaje ocenę 13, ponieważ „to refaktoryzacja, a to duże przedsięwzięcie”. Po trzech sprintach stary potok nadal działa równolegle z nowym, dwa systemy są częściowo skonfigurowane, a każdy inżynier ma inny model mentalny dotyczący tego, którego z nich należy używać. Zadanie nie zostało ukończone, ponieważ brakuje definicji ukończenia: potoki nie są „dostarczane”; są one wdrażane, a wdrożenie to kwestia odrębna od samego „istnienia nowej funkcji”.

O czym się mówi w tym pomieszczeniu

SRE: „Musimy odejść od starego schematu. Dwa sprinty”.

Wstęp: „Jaka jest definicja zakończenia?”

SRE: „…ten nowy działa.”

Wstęp: „Ten nowy model sprawdza się już w połowie naszych zadań”.

Backend: „Jednak stara wersja nadal działa dla drugiej połowy.”

Wstęp: „Zgadza się. Zatem zakończymy, gdy będziemy mogli usunąć stary plik”.

O to właśnie chodzi. Zadaniem nie jest „zbudowanie nowego potoku”; zespół prawdopodobnie stworzył go już kilka miesięcy temu w ramach projektu realizowanego w wolnym czasie. Istotą zadania jest „usunięcie starego potoku”. Dopóki stary system kompilacji nie zostanie usunięty, przebudowa nie jest zakończona; stanowi on równoległą infrastrukturę, która generuje wszystkie koszty, nie przynosząc żadnych korzyści. Określenie tego zadania jako usunięcie, a nie utworzenie, daje zespołowi definicję zakończenia, nad którą może przeprowadzić głosowanie.

Jak to pokroić

Proszę sporządzić wykaz zadań nadal uruchomionych w starym systemie. W odniesieniu do każdego zadania: co należałoby zrobić, aby usunąć jego starą wersję? To stanowi osobny przypadek. Niektóre z nich są trywialne (zadanie zostało już skopiowane do nowego potoku; wystarczy usunąć stary plik YAML). Niektóre wymagają znacznego nakładu pracy (zestaw testów zawiera na stałe zakodowaną ścieżkę; etap wdrażania zależy od starej zmiennej środowiskowej). Każde usunięcie stanowi niewielki element, który zespół może wdrożyć i zaprezentować. „Usunęliśmy plik Jenkinsfile dla usługi uwierzytelniania” to wynik, który można zaprezentować.

Każde usunięcie można oszacować w zwykły sposób: najpierw należy zidentyfikować niewiadome (czy to zadanie ma odbiorców, o których nie wiemy?), a następnie oszacować zakres usunięcia w odniesieniu do referencyjnego usunięcia, które zostało już wdrożone. Większość fragmentów mieści się w przedziale 2 lub 3 punktów. Zadanie oznaczone jako „13, refaktoryzacja, duże” w rzeczywistości składało się z piętnastu elementów o wartości 2 oraz jednego o wartości 3.

Pytania, które warto zadać przed oddaniem głosu

• Co zostanie usunięte po zakończeniu tej historii?
• Jakie zawody nadal opierają się na starym systemie?
• Czy istnieje jakiś odbiorca starego potoku, o którym nie wiemy, na przykład zespół zewnętrzny lub zaplanowane zadanie?
• Jakie są działania naprawcze w przypadku, gdyby nowy potok przestał działać poprawnie po usunięciu starego?
• Kto jest autorytetem w kwestii twierdzenia, że „nowy kanał informacyjny jest źródłem prawdy”?
• Czy ktoś na bieżąco śledzi, które zadania są wykonywane w starym, a które w nowym systemie?

Jeśli odpowiedź na pytanie „co zostanie usunięte” brzmi „w tym sprincie nic”, oznacza to, że zespół nadal znajduje się w fazie infrastruktury równoległej, a zadanie nie spełnia kryteriów gotowości.

Prace związane z potokiem danych przeprowadza się po usunięciu starej struktury. Należy usuwać elementy pojedynczo, szacując nakład pracy dla każdego z nich z osobna.

Proszę zapoznać się z porównaniem podziału poziomego i pionowego, aby dowiedzieć się, dlaczego „stworzenie nowego systemu” stanowi niewłaściwą oś podziału, a także z innymi przykładami skutecznych szacunków. Gdy zespół sporządzi już listę elementów do usunięcia, proszę zorganizować bezpłatną sesję planowania pokerowego.