Szacowanie kosztów czasu w bazie kodu starszego typu

Ostatnio zacząłem pracować nad projektem, w ramach którego migrowana jest bardzo stara aplikacja monolityczna do architektury opartej na mikrousługach.

Podstawowa baza kodu jest bardzo nieuporządkowana („kod spaghetti”) i często pozornie prosta funkcja (np. O nazwie „multiplyValueByTen”) później ujawnia się jako „tysiące linii kodu weryfikacyjnego obejmującego 10 tabel na 3 różnych schematach”.

Teraz mój szef (słusznie) prosi mnie o oszacowanie, ile czasu zajmie napisanie funkcji X w nowej architekturze. Ale mam trudności z przedstawieniem realistycznego oszacowania; często bardzo nie doceniam tego zadania z powodów, które przedstawiłem powyżej i zawstydzam siebie, ponieważ nie mogę ukończyć na czas.

Wydaje się, że rozsądne wydaje się, aby naprawdę zagłębić się w kod, zanotować każdą gałąź i wywołania innych funkcji, a następnie oszacować koszt czasu. Ale tak naprawdę istnieje niewielka różnica między dokumentowaniem starego kodu a faktycznym zapisywaniem nowej wersji.

Jak powinienem podejść do takiego scenariusza?

Chociaż doskonale rozumiem, jak działa refaktoryzacja starszego kodu, moje pytanie nie dotyczy „jak zrobić refaktoryzację / przepisać?” ale o udzieleniu realistycznej odpowiedzi na pytanie „ile czasu zajmie refaktoryzacja / przepisanie części X?”

Przeczytaj „Czysty koder” Boba Martina (i „Czyść kod”, gdy jesteś przy nim). Poniższe informacje pochodzą z pamięci, ale zdecydowanie sugeruję zakup własnej kopii.

To, co musisz zrobić, to średnia ważona trzypunktowo. Dokonujesz trzech szacunków dla każdego kawałka pracy:

• najlepszy scenariusz - zakładając, że wszystko pójdzie dobrze (a)
• najgorszy scenariusz - zakładając, że wszystko pójdzie nie tak (b)
• rzeczywiste zgadywanie - co Twoim zdaniem prawdopodobnie zajmie (c)

Twoja ocena to wtedy (a + b + 2c) / 4

• Nie, to nie będzie dokładne. Istnieją lepsze sposoby szacowania, ale ta metoda jest szybka, łatwa do zrozumienia i łagodzi optymizm, rozważając najgorszy przypadek.
• Tak, będziesz musiał wyjaśnić swojemu przełożonemu, że nie znasz kodu i że jest to zbyt nieprzewidywalne, abyś mógł dokonać dokładnych i dokładnych oszacowań bez konieczności długiego sprawdzania kodu za każdym razem, aby poprawić oszacowanie (zaoferuj to, ale powiedz, że potrzebujesz n dni, aby dokładnie oszacować, ile jeszcze to zajmie). Jeśli jesteś „JuniorDev”, powinno to być akceptowalne dla rozsądnego menedżera.
• Powinieneś także wyjaśnić swojemu przełożonemu, że twoje szacunki są uśredniane, w oparciu o najlepszy przypadek, najgorszy przypadek i prawdopodobny przypadek oraz podać im swoje dane liczbowe, co również daje im słupki błędów.
• NIE negocjuj szacunków - jeśli twój menedżer próbuje użyć najlepszego przypadku dla każdego oszacowania (są głupcami - ale spotkałem się z podobnymi), a następnie zastrasz / zmotywuj cię do próby dotrzymania terminu, cóż, oni Czasem będę rozczarowany. Wyjaśniaj uzasadnienie szacunków (najlepszy przypadek, najgorszy przypadek i prawdopodobny przypadek) i zbliżaj się do średniej ważonej przez większość czasu i powinieneś być w porządku. Ponadto, na własne potrzeby, zachowaj arkusz kalkulacyjny swoich szacunków i dodaj swoje dane rzeczywiste po zakończeniu. To powinno dać ci lepszy pomysł na dostosowanie swoich szacunków.

Edytować:

Moje założenia, kiedy odpowiedziałem na to:

1. OP jest młodym programistą (na podstawie wybranej nazwy użytkownika). Jakakolwiek udzielona rada nie pochodzi zatem z perspektywy kierownika projektu lub kierownika zespołu, od którego można oczekiwać, że będzie w stanie przeprowadzić bardziej wyrafinowane oszacowania w zależności od dojrzałości środowiska programistycznego.
2. Project Manager stworzył plan projektu składający się z dość dużej liczby zadań, których wykonanie zaplanowano na kilka miesięcy.
3. OP jest proszony o podanie szeregu szacunków dla zadań, do których są przypisani przez swojego Kierownika Projektu, który chce rozsądnie dokładnej liczby (nie krzywej prawdopodobieństwa :)) do uwzględnienia w planie projektu i wykorzystania do śledzenia postępów.
4. OP nie ma tygodni na sporządzenie każdego oszacowania i został wcześniej spalony przez podanie nadmiernie optymistycznych oszacowań i chce bardziej dokładnej metody niż trzymanie palca w powietrzu i mówienie „2 tygodnie, chyba że kod jest wyjątkowo tajemniczy, w którym to przypadku 2 miesiące albo więcej".

Trzypunktowa średnia ważona działa dobrze w tym przypadku. Jest szybki, zrozumiały dla nietechnicznych i na podstawie kilku szacunków powinien osiągnąć średnią zbliżoną do dokładności. Zwłaszcza jeśli OP skorzysta z mojej rady na temat prowadzenia ewidencji szacunków i faktów. Gdy wiesz, jak wyglądają „najgorszy przypadek” i „najlepszy przypadek” w świecie rzeczywistym, możesz wprowadzić wartości rzeczywiste do swoich przyszłych szacunków, a nawet skorygować prognozy dla kierownika projektu, jeśli najgorszy przypadek jest gorszy, niż ci się wydawało.

Zróbmy sprawdzony przykład:

• Najlepszy przypadek, z najszybszych doświadczeń, jakie zrobiłem naprawdę prosty, był tygodniowy początek do końca (5 dni)
• Najgorszy przypadek, z doświadczenia, był taki czas, że wszędzie były linki i zajęło mi to 6 tygodni (30 dni)
• Rzeczywiste oszacowanie, prawdopodobnie zajmie mi to 2 tygodnie (10 dni)

5 + 30 + 2x10 = 55

55/4 = 13,75, co mówisz swojemu PM. Może zaokrąglisz do 14 dni. Z biegiem czasu (np. Dziesięć zadań), powinno się uśredniać.

Nie bój się dostosowywać formuły. Może połowa zadań kończy się koszmarami, a tylko dziesięć procent jest łatwych; więc dokonujesz oszacowania a / 10 + b / 2 + 2c / 5. Ucz się z własnego doświadczenia.

Uwaga: nie przyjmuję żadnych założeń dotyczących jakości premiera. Zły premier krótko oceni planszę projektową, aby uzyskać zgodę, a następnie nęka zespół projektowy, aby spróbować osiągnąć nierealistyczny termin, do którego się zobowiązali. Jedyną obroną jest prowadzenie rejestru, aby można było zobaczyć, jak podajesz swoje szacunki i zbliżasz się do nich.

To może być dobry moment na wprowadzenie quasi-zwinnego podejścia. Jeśli zamiast szacowania pod względem godzin / dni przypisałeś skalę typu Fibonacciego i nadałeś każdemu zadaniu wartość na podstawie jego wielkości:

• 0 - natychmiastowe
• 0,5 - szybka wygrana
• 1 - prosta zmiana
• 2 - kilka prostych zmian
• 3 - trudniejsze
• 5 - wymaga zastanowienia
• 8 - znaczna ilość pracy
• 13 - duża część pracy, którą prawdopodobnie trzeba rozbić
• 20 - ogromny kawałek pracy, który zdecydowanie należy rozbić

Potem, gdy oszacujesz kilka takich zadań, pracujesz nad nimi. W zwinnym środowisku rozwijasz „prędkość”, która jest miarą tego, ile punktów osiągniesz, powiedzmy, w ciągu tygodnia. Po ukończeniu kilku tygodni testów i nauki (możesz to sprzedać swojemu kierownikowi w ramach procesu - „Potrzebuję kilku tygodni testów i nauczyć się rozumieć proces szacowania”), będziesz bardziej pewni, ile punktów możesz przeforsować w każdym tygodniu i dlatego możesz łatwiej przełożyć swoje oszacowanie punktów na czas.

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibonacci-sequence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker

To nie jest naprawdę zwinne, ponieważ nie wymagałoby to ceremonii, ale PO rozumiem, że jest on sam. Mam nadzieję, że takie podejście może dać bardziej pewne szacunki.

Pierwszą rzeczą, którą robisz, jest rozpoczęcie gromadzenia danych o tym, ile czasu zajmuje teraz zrobienie czegokolwiek. Im więcej danych masz na temat wydajności swojego zespołu, tym lepiej. Będzie wszędzie, ale nie martw się tym teraz. To prawda i musisz pokazać swojemu szefowi rzeczywistość.

Potem kupisz kilka książek.

1. Ocena oprogramowania: Demystifying the Black Art autorstwa Steve McConnell
2. Skutecznie współpracuje ze starszym kodem Michaela Feathersa

Książka McConnella powie ci, abyś zaczął gromadzić dane, a następnie wyjaśnił, jak je wykorzystać, aby uzyskać dokładniejsze dane szacunkowe. Zawsze podawaj 3-punktowy kosztorys! Zawsze. Pamiętaj o zaznaczeniu części książki, które mówią o tym, jak niska jakość kodu wpłynie na twoje oszacowania. Pokaż je swojemu szefowi.

Wyjaśnij, że jeśli dokładne szacunki są ważne dla firmy, musisz zacząć stosować rzeczy, których uczysz się z książki Feather. Jeśli chcesz iść szybko, płynnie i przewidywalnie, musisz zacząć refaktoryzować kod i umieścić go w uprzęży testowej. Byłem dokładnie tam, gdzie jesteś. Czas rozwoju jest całkowicie nieprzewidywalny, ponieważ nie masz pojęcia, co możesz złamać, prawda? ... Tak. Umieść go w uprzęży testowej. Serwer CI do uruchomienia tych testów również nie zaszkodzi.

Na koniec wyjaśnij swojemu szefowi, że przez pewien czas będzie jeszcze trochę nieprzewidywalnie. Prawdopodobnie za kilka lat, ale ten rozwój będzie łatwiejszy z dnia na dzień, a szacunki będą dokładniejsze, gdy będziesz mieć więcej danych i kod będzie lepszy. To długoterminowa inwestycja dla firmy. Przeszedłem przez to niedawno, zajęło prawie 2 lata, aby stać się w większości przewidywalnym.

Wiem, że mówiłem więcej o ulepszaniu kodu niż szacowaniu, ale twarda prawda jest taka, że ​​twoje szacunki będą marne, dopóki nie poskromisz starszej bazy kodu. W międzyczasie użyj historycznych wyników, aby zmierzyć, jak długo to potrwa. W miarę upływu czasu będziesz musiał wziąć pod uwagę, czy już dostosowałeś kod do specyfikacji w swoich szacunkach.

Teraz mój szef słusznie pyta mnie, ile czasu zajmie napisanie funkcji X w nowej architekturze. Ale mam trudności z przedstawieniem realistycznego oszacowania; często nie doceniam tego zadania z powodów, które przedstawiłem powyżej i zawstydzam siebie, ponieważ nie mogę skończyć na czas.

Być może myślisz w polu przedłożenia jednego oszacowania. Muszę pracować w starszym kodzie, a kiedy dokonuję bardziej formalnego oszacowania, zwykle robię dwa lub trzy :

1. Podstawowa ocena - przy założeniu, że muszę poświęcić trochę czasu na kopanie, ale architektura pozwala na zmiany, których chcemy
2. Angelic Estimate - zakłada, że ​​wszystko jest przejrzyste / łatwe do znalezienia i muszę jedynie wprowadzić drobne zmiany (to jest ta, którą czasami pomijam ... szczególnie, jeśli wiem, że w konkretnej bazie kodu są tylko diabły)
3. Abyssal Estimate - zakłada, że ​​podstawowa struktura starszego kodu jest niezgodna z żądaną funkcją i będę musiał dokonać poważnego refaktoryzacji, aby wszystko działało

Wszystkie trzy szacunki biorą pod uwagę, jak trudna jest ta funkcja sama w sobie, wszelkie doświadczenia, jakie miałem z tą ogólną bazą kodu, i moje przeczucie co do zmiany (które moim zdaniem może być dość dokładne)

Po tym, jak te szacunki się pojawią, na bieżąco informuję mojego kierownika, z którym, jak wygląda, mamy do czynienia. Jeśli okaże się, że patrzymy na funkcję otchłani, być może będziemy musieli ją poświęcić - tak się stało. Jeśli twój szef nie może zaakceptować, że istnieją pewne cechy otchłani dla danej części starszego kodu, to życzę im powodzenia, ponieważ będą mieli bardzo trudne i frustrujące życie.

Kiedy napotkałem tego rodzaju problem, polegałem na podawaniu zakresów w moich szacunkach. Nie udało mi się powiedzieć szefom, że „trudno jest dokonać dobrych szacunków poza tym mankietem w tej bazie kodu. Jeśli poprosisz o jedną, będzie to bardzo szeroka ocena”. Podałem raz „szacunkowo 3 dni do 3 lat”. Nie trzeba dodawać, że nie był to popularny szacunek, ale to właśnie podałem.

Kluczem do tego jest porozumienie, że będę aktualizować swoje prognozy w miarę postępu prac. Więc jeśli powie mi się „Wdrażaj XYZ, ile to zajmie?” moja odpowiedź może brzmieć „gdzieś pomiędzy dniem a 4 miesiącami. Jeśli jednak pozwolisz mi spojrzeć na kod przez kilka godzin, mogę zmniejszyć niepewność w tym oknie”. Potem patrzę na kod i wracam z „2 do 4 tygodni”. To wciąż nie jest idealne okno, ale przynajmniej jest to coś, czym można zarządzać.

Jest na to kilka kluczy:

• Przekonać szefa, że szacunki te są lepiej traktowane jako rozmowy, ponieważ będzie dowiedzieć się więcej o tym, co zadanie wygląda podczas pracy go. Jest to okazja dla twojego szefa, aby uzyskać informacje, których nie otrzymaliby, gdyby poprosił tylko o jedną wycenę.
• Oferuj opcje dotyczące tego, jak posunąć się do przodu, która prędkość rozwoju kodu handlowego vs. poprawiać szacunki. Daj im dodatkowe pokrętło, które mogą obrócić. Czasami szefowie wiedzą, że zadanie musi zostać wykonane, a oni potrzebują jedynie szacunkowego wyniku. Innym razem sprawdzają zalety i wady zadania, a umiejętność poprawiania szacunków jest cenna.
• Jeśli to możliwe, zaoferuję również bonusy synergiczne. Często istnieją ulepszenia architektoniczne, które przyniosłyby korzyści wielu zadaniom. Jeśli mam 10 zadań, z których wszystkie zajmą „teraz 1-2 miesiące, ale przy aktualizacji X zajmie to 2 tygodnie”, łatwiej sprzedać te 20 tygodni, które mogą zająć dla aktualizacji X.

Jeśli mam szefa, który nie czuje się dobrze z otrzymywaniem zakresu, który jest aktualizowany w miarę upływu czasu, dam mu jeden numer i moją metodologię. Moja metodologia to połączenie ogólnej zasady, którą powiedziano mi jako młodemu deweloperowi, oraz prawa Hofstadera .

Oszacuj, jak długo Twoim zdaniem powinno to zająć zadanie, a następnie podnieś czterokrotnie tę liczbę i podaj ją jako swoją ocenę.

i

Prawo Hofstadtera: „Zawsze trwa dłużej niż się spodziewasz, nawet jeśli weźmiesz pod uwagę prawo Hofstadtera”.

Wydaje się, że rozsądne wydaje się, aby naprawdę zagłębić się w kod, zanotować każdą gałąź i wywołania innych funkcji, a następnie oszacować koszt czasu. Ale tak naprawdę istnieje niewielka różnica między dokumentowaniem starego kodu a faktycznym zapisywaniem nowej wersji.

To jest rozwiązanie twojego problemu. Nie możesz oszacować, jeśli nie masz żadnych wymagań. Powiedz szefowi, że musisz to zrobić, zanim zaczniesz kodować. Po kilku funkcjach i modułach możesz odkryć, że wszystkie zostały konsekwentnie zakodowane (w tym przypadku źle), więc masz podstawę do ustalenia przyszłych oszacowań. Upewnij się, że dostosujesz swoje oszacowanie, jeśli odkryjesz, że kodowanie się pogarsza.

Zdaję sobie sprawę, że twój szef chce oszacowania, ale nie wiedząc, jak te informacje są wykorzystywane, nie wiemy, jak dokładne powinny być twoje oszacowania. Porozmawiaj z nim i dowiedz się. Jeśli potrzebuje tylko numeru, aby podać swojemu szefowi, możesz nieznacznie zawyżać szacunki i podać liczbę. W przypadku klientów oczekujących na zapłacenie za Twój kod, dopóki nie zostanie to zrobione, upewnij się, że ustalono, czy sztywne terminy płatności przyniosą znaczące przychody.

W takiej sytuacji nie sądzę, aby można było podać dobre oszacowania. Podstawowym problemem jest to, że często dużą częścią tego jest zastanawianie się, co należy zrobić.

Zajmuję się takimi przypadkami, podając oszacowanie oparte na tym, co wydaje się pociągać za sobą, ale z wgłębieniem, że prawdopodobne są niespodzianki. Chociaż nie musiałem zbytnio radzić sobie ze starszym kodem, miałem kilka bardzo nieprzyjemnych niespodzianek związanych z wprowadzaniem danych - widziałem, jak kilka godzin zmienia się w kilka tygodni, a raz w to jest niemożliwe (po znaczne kopanie Doszedłem do wniosku, że nie mam wystarczającej ilości danych w pewnym przypadku, wracając do tablicy kreślarskiej.) Na szczęście mój szef rozumie, kiedy podam takie szacunki.

Oszacowanie to umiejętność, której niektórzy nigdy się nie uczą. Nie czyni cię jednak bezużytecznym jako programista, nawet jeśli nie możesz podać dobrych oszacowań. Może koledzy z zespołu lub kierownictwo uzupełnią luki. Jestem w tym okropny, wciąż większość zespołów lubiła ze mną współpracować. Zachowaj spokój, połącz siły i kontynuuj refaktoryzację.

Dług techniczny daje ci miłe małe wyzwania, ale pamiętaj, że firma / zespół, który ostatecznie zaciągnął dług, będzie nadal generował dług, chyba że nastąpią zmiany w duchu zespołu lub kierownictwie. Kod po prostu odzwierciedla problemy społeczne, więc skup się na prawdziwych problemach.

Wykorzystaliśmy heurystykę do oszacowania cech w projekcie typu brownfield: oszacowaliśmy, jak długo zajęłoby wdrożenie tej funkcji w projekcie typu greenfield bez niczego już zaimplementowanego. Następnie pomnożymy to oszacowanie przez 2, aby poradzić sobie z usuwaniem śmieci, które już istniały.

Współczynnik ten zależy od ilości sprzężenia i ogólnego rozmiaru kodu, ale jeśli wykonasz niektóre funkcje w ten sposób, możesz interpolować ten czynnik na podstawie rzeczywistych dowodów.

Myślę, że powinieneś usiąść z szefem, spojrzeć mu prosto w oczy i powiedzieć:

Słuchaj szefie! Właśnie refaktoryzujemy tutaj. Nie ma żadnej nowej funkcji do dostarczenia i klienci nie czekają na tę funkcjonalność; więc nie powinno być żadnych terminów. To zajmie tyle czasu, ile zajmie, musisz zdecydować, czy musimy to zrobić, czy nie.

Używaj stanowczej asertywnej gestykulacji, takiej jak wskazywanie i usiądź na krześle.

Alternatywnie możesz wymyślić kilka liczb, aby go uszczęśliwić. Ale spójrzmy prawdzie w oczy, dopóki nie znajdziesz się w połowie pracy, twoje szacunki będą dość niedokładne.