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?”
źródło
Odpowiedzi:
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:
Twoja ocena to wtedy (a + b + 2c) / 4
Edytować:
Moje założenia, kiedy odpowiedziałem na to:
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:
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.
źródło
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:
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.
źródło
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.
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.
źródło
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 :
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.
źródło
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:
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 .
źródło
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.
źródło
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.
źródło
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.
źródło
Myślę, że powinieneś usiąść z szefem, spojrzeć mu prosto w oczy i powiedzieć:
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.
źródło