Przykłady obliczeń z rozwiązaniami
Prawdziwe scenariusze są uwzględniane w rozmowach dotyczących szacowania od początku do końca — logowanie, płatności, migracje, skoki obciążenia — a także w pytaniach, na które należy uzyskać odpowiedzi, zanim ktokolwiek zagłosuje na konkretną wartość.
Jak oszacować zakres funkcji logowania: ukryte aspekty — resetowanie hasła, uwierzytelnianie dwuskładnikowe (2FA), federacja, ograniczanie częstotliwości, sesje — oraz pytania, na które należy odpowiedzieć przed rozpoczęciem głosowania.
Jak oszacować nakład pracy związany z integracją SSO: sedno sprawy leży poza Państwa kodem źródłowym, a mianowicie w specyfice dostawcy tożsamości. Pytania, na które należy odpowiedzieć przed ustaleniem szacunkowej wartości.
Jak oszacować koszty integracji systemu płatności: środowisko testowe a środowisko produkcyjne, zwroty środków, webhooki, idempotencja, zakres zgodności z PCI. Rozmowa, którą należy przeprowadzić, zanim ustalona zostanie jakakolwiek kwota.
Jak oszacować funkcjonalność wyszukiwania: trafność, ranking, filtrowanie oraz to, kto jest właścicielem indeksu. Pytania, dzięki którym „dodanie paska wyszukiwania” staje się rzeczywistym oszacowaniem.
Jak oszacować wymagania dotyczące systemu powiadomień: kanały, preferencje, eliminacja duplikatów i gwarancje dostarczenia. Dlaczego „wysłanie wiadomości e-mail” niepostrzeżenie przeradza się w sześciotygodniowy projekt.
Jak oszacować proces przesyłania pliku: limity rozmiaru, skanowanie antywirusowe, możliwość wznowienia przesyłania, przechowywanie i okres przechowywania. Funkcja „przeciągnij i upuść” to najłatwiejsza część; prawdziwe wyzwanie kryje się pod powierzchnią.
Jak oszacować wymagania dotyczące pulpitu nawigacyjnego: źródła danych, częstotliwość odświeżania, strefy czasowe, możliwość drążenia danych, uprawnienia. Sam wykres jest prosty; prawdziwą pracą jest stworzenie leżącego u jego podstaw potoku danych.
Jak oszacować test niestabilny: dlaczego potrzebne są dwa oszacowania, a nie jedno, oraz dlaczego wyznaczenie ram czasowych jest lepszym rozwiązaniem niż spieranie się o punkty, gdy odpowiedź zależy od tego, co się odkryje.
Jak oszacować błąd, którego nie da się odtworzyć: nie da się oszacować nakładu pracy związanego z naprawą, a jedynie nakładu pracy związanego z poszukiwaniem przyczyny. Jak wyznaczyć ramy czasowe dla dochodzenia zamiast głosować nad zadaniem, którego nikt nie może zobaczyć.
Jak oszacować spadek wydajności: praca ta polega głównie na diagnozie, a nie na samym usunięciu usterki. Jak oszacować skalę problemu, gdy przyczyna jest nieznana, a zagrożony jest wskaźnik SLO.
Jak oszacować błąd zgłoszony przez klienta: o wielkości zadania decyduje opis zawarty w zgłoszeniu. Jak odróżnić poprawkę składającą się z jednej linii od działania, które pochłonie cały sprint.
Jak oszacować czas migracji bazy danych: uzupełnianie danych, czas trwania blokady, wdrażanie i przywracanie. Polecenie „Dodaj kolumnę” to jedna linijka kodu SQL; szacunkowy czas to mniej więcej jedna sekunda.
Jak oszacować czas migracji danych: przenoszenie danych między systemami, uzgadnianie danych i przełączenie. Przetwarzanie trwa godzinę; czyszczenie danych trwa kwartał.
Jak oszacować nakład pracy związany z aktualizacją frameworka: dlaczego zmiana wersji głównej to projekt, a nie zgłoszenie, oraz jak podzielić go na zadania, których nakład pracy można faktycznie oszacować.
Jak oszacować nakład pracy związany z aktualizacją zależności: długotrwały wzrost, za którym kryje się N skoków w jednym zgłoszeniu. Najpierw zapoznaj się z dziennikami zmian, a następnie oszacuj znalezione elementy.
Jak oszacować nakład pracy związany z przebudową procesu CI/CD: w przypadku prac nad potokiem nie ma wersji demonstracyjnej, więc należy podzielić zadania na części, które można usunąć. Zadanie trwające cały kwartał, które figuruje w rejestrze zadań jako refaktoryzacja.
Jak oszacować koszty wymiany API innego dostawcy: luki semantyczne, równoległe działanie oraz założenia wynikające ze specyfiki dotychczasowego dostawcy. Nowe API wydaje się jedynie identyczne.
Jak oszacować wdrożenie ograniczeń przepustowości: progi, okresy testowe, komunikacja z klientami. Sam kod zajmuje pół dnia; prawdziwym wyzwaniem jest ustalenie limitów, na które nikt nie będzie miał zastrzeżeń.
Jak oszacować zakres zmian w systemie projektowym: wdrażanie tokenów, ścieżki wycofywania, zasięg narzędzia Codemod oraz 200 miejsc wywołania, w których wykorzystywany jest stary komponent. Proszę oszacować skalę zmian w dalszych etapach procesu.
Jak oszacować nakład pracy związany z poprawką dotyczącą dostępności: problemy z dostępnością to funkcje, których nie wprowadzono przy pierwszym wydaniu. Dlaczego należy oszacować skalę problemu, a nie pojedynczy przypadek.
Jak oszacować wdrożenie flagi funkcji: etapy procentowe, mechanizmy awaryjne, wskaźniki kontrolne oraz porządkowanie, którego nikt nie planuje. Flaga to niewielki produkt, a nie zwykłe wdrożenie.
Jak oszacować „spike” badawczy: „spike” to przedział czasowy z określonym rezultatem, a nie zadanie. Jak zapobiec sytuacji, w której „spike” po cichu przekształci się w pracę, która pierwotnie miała zostać uwzględniona w zakresie projektu.
Jak oszacować prototyp: jest to produkt stworzony w celu zdobycia wiedzy, a nie do użytku. Jak zapobiec sytuacji, w której kod przeznaczony do wyrzucenia stanie się kodem produkcyjnym, którego nikt nie planował.
Jak oszacować eksperyment z zakresu uczenia maszynowego: to badania połączone z inżynierią — model jest prosty, a prawdziwą pracą jest praca z danymi. Jak określić wielkość budżetu, a nie prognozę.