Oszacowanie kosztów aktualizacji zależności

Poprawki i drobne zmiany to tylko szum. Znaczące zmiany w bibliotekach o liczbie N to N skoków — należy oszacować najgorszy scenariusz, a nie średnią.

Aktualizacje zależności występują w dwóch postaciach, które w wynikach menedżera pakietów wyglądają identycznie. Pierwsza z nich to zestaw poprawek i niewielkich aktualizacji wersji, które zespół powinien zebrać w jedną partię, przetestować za pomocą zestawu testów i scalić w ramach jednego, rutynowego zgłoszenia PR. Taki przypadek ma priorytet 1, czasem 2, a jedynym powodem głosowania nad nim jest potwierdzenie, że zespół zgodził się, iż jest to nudne. Drugi rodzaj: znacząca aktualizacja jednej lub kilku bibliotek, w przypadku której dziennik zmian zawiera sekcję „zmiany powodujące niekompatybilność”, z którą zespół musi się zapoznać. To właśnie ta historia, która kryje się na widoku. Zespół przyznaje jej ocenę 3, twierdząc, że „to tylko aktualizacja”, a trzy sprinty później wdraża ją z oceną 13.

To nie jest aktualizacja frameworka. Aktualizacja frameworka to jedna biblioteka, którą planowali Państwo przez cały kwartał; zespół wie, że jest to projekt. Aktualizacja zależności to dyskretne zgłoszenie serwisowe, które ktoś składa, ponieważ skanowanie bezpieczeństwa wykryło sześć bibliotek, a nikt nie zapoznał się z dziennikami zmian. Pułapką jest rozkład tych zmian: spośród sześciu aktualizacji cztery są nieistotne, jedna dotyczy zmiany nazwy eksportu, a jedna to całkowita przebudowa interfejsu API. Szacunek oparty na średniej z tych zmian jest błędny w obu kierunkach.

O czym się mówi w tym pomieszczeniu

Inżynier A: „To sześć wybojów. Po dwa na każdego. Łącznie 13.”

Nagłówek: „Czy wszyscy są nieletni?”

Inżynier A: „Trzy mniejsze, trzy większe.”

Inżynier B: „Czy ktoś zapoznał się z listą najważniejszych zmian?”

Inżynier A: „…niech tylko sprawdzę.”

Wprowadzenie: „Nie dysponujemy jeszcze szacunkami. Odnotowaliśmy trzy gwałtowne wzrosty”.

Wstęp jest trafny. Nie ma jednej liczby odnoszącej się do tej sytuacji, ponieważ nie ma jednej sytuacji. Drobne problemy stanowią osobną, niewielką kategorię; każda poważniejsza usterka jest osobnym skokiem, dopóki ktoś nie zapozna się z dziennikiem zmian i nie zorientuje się, co nie działa prawidłowo.

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

• Ile jest wybojów oraz jaki jest ich podział na główne, drugorzędne i punktowe?
• Czy ktoś zapoznał się z listami zmian dotyczącymi głównych wersji?
• Czy któreś z nich znajdują się w bibliotekach należących do zespołu, a nie do dostawców?
• Czy istnieje konflikt zależności przechodniej, który powoduje, że muszą one wystąpić jednocześnie?
• Jakie są możliwości przywrócenia poprzedniej wersji, jeśli jedna z aktualizacji spowoduje awarię środowiska produkcyjnego?
• Czy zespół ds. bezpieczeństwa ma wyznaczony termin, czy też jest to dług techniczny?

Jeśli odpowiedź na pytanie „czy ktoś zapoznał się z listą zmian” brzmi „nie”, to oszacowanie nie jest realistyczne. Proszę przewidzieć ograniczony wzrost nakładu pracy dla każdej większej aktualizacji, zidentyfikować rzeczywiste usterki, a następnie ponownie oszacować nakład pracy związany z wdrożeniem w oparciu o uzyskane informacje.

Nie należy szacować aktualizacji bibliotek poprzez liczenie zmian wersji. Najpierw należy zapoznać się z dziennikami zmian, a dopiero potem oszacować znalezione informacje.

Więcej informacji na temat wariantu dotyczącego aktualizacji do nowej wersji głównej w ramach jednej biblioteki można znaleźć w artykule Szacowanie kosztów aktualizacji frameworka, a inne przykłady praktycznych szacunków są dostępne tutaj. Rozpocznij bezpłatną sesję planowania pokerowego po tym, jak w ramach sesji spike ustalono, co faktycznie ulegnie zmianie.