Szacowanie kosztów czasu w bazie kodu starszego typu

86

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?”

JuniorDev
źródło
37
Dokonuj szacunków z szerokimi marginesami, a nie z pojedynczymi wartościami; np. 5 do 15 dni
Richard Tingle
32
@JuniorDev: dlaczego uważasz, że jest „nie do przyjęcia dla nietechnicznego lidera zespołu”? Może nie polubić twojej odpowiedzi, ale jeśli nie możesz podać lepszej oceny, często mówi się wprost, zamiast próbować zadowolić go teraz zbyt niską oceną i powiedzieć mu po 5 dniach, przepraszamy, tylko zakończyliśmy zadanie do 30%.
Doc Brown
13
„Wydaje się, że rozsądne wydaje się, aby naprawdę zagłębić się w kod, zanotować każdą gałąź i wezwania do innych funkcji, a następnie oszacować koszt czasu. Ale naprawdę jest niewielka różnica między dokumentowaniem starego kodu a faktycznym zapisywaniem nowej wersji”. - hahahahahahahahahahahahahahahahahahahaha heh. heh Może się tak wydawać, ale kiedy wyczyścisz trochę starszego kodu, okazuje się, że dziwactwa zajmują się problemami, o których nigdy nie słyszałeś w przypadkach, których nigdy nie rozważałeś. Lub załataj błędy w innych miejscach. Lub są błędem, ale błędy, na których polegają inne części kodu.
Jak
27
Powiem ci o małej tajemnicy: jeśli twój menedżer prosi młodszego programistę o dokonanie oceny technicznej, to jedna z dwóch rzeczy jest prawdą: wie, że nie wiesz, jak dokonać prawdziwej oceny i robi to okazja do nauczania lub jest niedoświadczonym menedżerem i myśli, że młodszy twórca może to zrobić. Nigdy nie widziałem młodszego programisty, który mógłby to zrobić, w tym (zwłaszcza?) Siebie, gdy byłem młodszym programistą.
corsiKa
27
Jak wszyscy wiemy, od 6 do 8 tygodni .
Matthieu M.

Odpowiedzi:

111

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.

Mcottle
źródło
31
„Są głupcami - ale spotkałem takich.” W rzeczy samej.
Kramii
17
Chcę to zagłosować, ale nie mogę przekroczyć jednego punktu szacunkowego.
RubberDuck,
6
Dobrze. +1 za ostatni punktor.
RubberDuck,
5
+1, szacunek nie jest dokładnym czasem, więc nie może być pojedynczą liczbą. Warto również dodać, że jest to szacunek , a nie zobowiązanie, więc menedżer nie powinien oczekiwać, że na pewno się skończysz. Inżynier oprogramowania jest odpowiedzialny za wyjaśnienie kierownikowi tej różnicy.
Kat
10
@mcottle FYI to nie jest szacunek Monte Carlo. Po prostu obliczyłeś oczekiwaną wartość (która byłaby skuteczna tylko w około 50% przypadków) rozkładu PERT. Monte Carlo odnosi się do procesu, w którym wartości statystyczne są uzyskiwane zasadniczo poprzez brutalną siłę z generatorem liczb losowych.
David Meister
30

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.

amelvin
źródło
Działa to najlepiej w przypadku projektów na większą skalę (ponad miesiąc). W przypadku mniejszych projektów może to zadziałać dopiero po kilku podobnych projektach.
Emile Bergeron
1
@RobP. dziwactwo w zwinnym postępie w punktach fabularnych: 13, 20, 40, 100 - chociaż większość ludzi nie zadaje sobie trudu, aby ustawić więcej niż 20 punktów, ponieważ do tego czasu naprawdę trzeba to rozbić
HorusKol
1
Nie zgadzam się, że punkty historii + ceremonie = zwinne.
webdevduck
1
@webdevduck „nie zgadzam się zgodzić”?
krillgar
1
@krillgar D'oh! Nie zgadzać się!
webdevduck
14

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.

Gumowa kaczuszka
źródło
1
+1 za „włóż go do uprzęży testowej”. Podczas refaktoryzacji starego kodu podejście polegające na pierwszym przetestowaniu (w celu zweryfikowania krytycznych składników starego kodu działa dokładnie tak, jak myślisz , zanim zrobisz cokolwiek), jest bezkonkurencyjne. Ta odpowiedź przekonała mnie również do zakupu książki „Szacowanie oprogramowania”, o której nigdy wcześniej nie słyszałem (moje oceny są słabe).
GlenPeterson
7

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.

Jeutnarg
źródło
+1 za ostatni akapit - szkoda, że ​​nie
zawarłem
3

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”.

Cort Ammon
źródło
2

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.

JeffO
źródło
Mimo że do zrozumienia starego kodu konieczne jest głębokie zrozumienie, istnieje ogromna różnica między dokumentowaniem starego kodu a uzyskiwaniem nowego kodu do tego stopnia, że ​​nie zawiera on błędów.
Thorbjørn Ravn Andersen
1

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.

Loren Pechtel
źródło
-1

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.

peruka
źródło
-3

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.

Ewan
źródło
3
-1 za zalecenie potencjalnie samobójczego zawodu. Ponadto OP twierdzi, że ocenia pracę nad funkcjami, a nie tylko refaktoryzuje istniejący kod.
RubberDuck,
samobójstwo zawodowe LUB skok do wielkiej gry
Ewan
Cóż, to słuszna uwaga @Ewan. Nie mogę powiedzieć, że nie zrobiłem w tej chwili kilku rzeczy, które wydawały się samobójstwem zawodowym.
RubberDuck,
Niektórych rzeczy nie da się oszacować. Komunikacja może być frustrująca. To powiedziawszy, głosowałem za odrzuceniem tego pytania, ponieważ brzmi to tak, jakbyś sugerował, że OP próbuje zastraszyć swojego szefa, aby uwierzył im. Wiem, że tak się dzieje, a może nawet jest to konieczne w odosobnionej rozpaczliwej sytuacji. Ale nie chcę pracować nigdzie, co jest normą. Mamy spory w pracy i denerwujemy się. Ale radzimy sobie z tym, próbując przekonać się nawzajem za pomocą danych, badań i historii. Firma ma większe szanse na sukces dzięki kulturze „wygrywa najlepszy pomysł” niż „wygrywa najbardziej zastraszająca osoba”.
GlenPeterson
1
to odpowiedź na policzek. ale mam na myśli to poważnie. dlaczego szef pyta o szacunki? czy pomagasz w oszacowaniu? to wszystko bardzo dobrze, ten „wujek bob” używa odpowiedzi w stylu sekwencji Fibonacciego. ale nie docierają do źródła problemu. szef obawia się, że refaktoryzacja to strata czasu i chce, aby wkrótce się skończył
Ewan