Oszacowanie kosztów aktualizacji zależności

Poprawki i zmiany pomniejsze to tylko szum. Zmiany znaczące w N bibliotekach 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 zmian wersji, które zespół powinien zebrać w jedną partię, przetestować za pomocą zestawu testów i scalić w ramach jednego, rutynowego zgłoszenia PR. Zgłoszenie to ma priorytet 1, czasem 2, a jedynym powodem głosowania nad nim jest potwierdzenie, że zespół zgodził się co do tego, iż jest ono 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.

Nie jest to 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 stanowi całkowitą przebudowę 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: „…proszę pozwolić mi to sprawdzić.”

Wstęp: „Nie dysponujemy jeszcze szacunkami. Odnotowaliśmy trzy skoki”.

Wstęp jest trafny. Nie ma jednej liczby odnoszącej się do tej sytuacji, ponieważ nie ma jednej sytuacji. Drobne problemy są traktowane jako osobna, niewielka pozycja; każda poważniejsza usterka stanowi odrębny skok, dopóki ktoś nie zapozna się z dziennikiem zmian i nie ustali, co powoduje awarię.

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

• Ile jest poprawek oraz jaki jest ich podział na główne, pomniejsze i poprawki 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 wymusza ich jednoczesne wystąpienie?
• Jakie są konsekwencje 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 ustalenia.

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

Proszę zapoznać się z oszacowaniem kosztów aktualizacji frameworka w wariancie opartym na jednej bibliotece i nowej wersji głównej, a także z innymi przykładami praktycznych oszacowań. Proszę zorganizować bezpłatną sesję „planning poker” po tym, jak w ramach sesji „spike” ustalono, co faktycznie ulegnie zmianie.