Ocena zakresu przebudowy procesu CI/CD

W przypadku prac związanych z potokiem nie ma wersji demonstracyjnej. Proszę zawęzić zakres do „który build można dzisiaj usunąć”, aby umożliwić oszacowanie nakładu pracy.

Przebudowy procesów CI/CD to najgorzej sformułowane zadania w backlogu. 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 cały kwartał, a ten kwartał będzie niewidoczny spoza działu inżynierii.

Sposób, w jaki oszacowanie zawiedzie, jest przewidywalny. Zespół przyznaje ocenę 13, ponieważ „to refaktoryzacja, a więc 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, z którego z nich należy korzystać. Zadanie nie zostało ukończone, ponieważ brakuje definicji ukończenia: potoki nie są „dostarczane”; są one wdrażane, a ich wdrożenie to kwestia odrębna od samego faktu, że „nowe rozwiązanie istnieje”.

O czym się mówi w tym pomieszczeniu

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

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

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 „stworzenie 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 element. Niektóre zadania są banalne (zadanie zostało już skopiowane do nowego potoku; wystarczy usunąć stary plik YAML). Inne 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ć usunięcie na podstawie 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 w płaszczu trenczu.

Pytania, które warto zadać przed głosowaniem

• Co zostanie usunięte po zakończeniu tej historii?
• Jakie zawody nadal opierają się na starym systemie?
• Czy istnieje jakiś odbiorca danych ze starego potoku, o którym nie wiemy, na przykład zewnętrzny zespół lub zaplanowane zadanie?
• Jakie są możliwości przywrócenia poprzedniego stanu, jeśli nowy potok zacznie działać gorzej po usunięciu starego?
• Kto jest autorytetem w kwestii stwierdzenia, że „nowy kanał informacyjny jest źródłem prawdy”?
• Czy ktoś na bieżąco monitoruje, które zadania są wykonywane w starym, a które w nowym systemie, z tygodnia na tydzień?

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 nad potokiem danych przeprowadza się po usunięciu starej wersji. Należy postępować etapami, usuwając kolejne elementy; każdy etap usuwania należy oszacować osobno.

Proszę zapoznać się z artykułem „Podział poziomy a pionowy”, aby dowiedzieć się, dlaczego „budowa nowego systemu” stanowi niewłaściwą oś podziału, oraz z innymi przykładami skutecznych szacunków. Zorganizuj bezpłatną sesję planowania pokerowego, gdy zespół dysponuje już listą elementów do usunięcia.