Czy programista powinien zaakceptować oszacowanie obciążenia wykonane przez makro Excela?

12

W nowym projekcie przyjaciel musiał napisać testy, w których czas wymagany do ich napisania został obliczony przez makro Excel napisane przez jego menedżera, który nie jest programistą.

Czy w takich okolicznościach deweloper powinien przyjąć odpowiedzialność za napisanie i uruchomienie testów w obliczonym czasie? Czy wyniki tych testów są wiarygodne?

Aby uzyskać informacje, mój przyjaciel odmówił ponoszenia odpowiedzialności za szacunki, których nie dokonał, poprosił o sukces w pracy nad innym projektem, a został zastąpiony przez niedoświadczonego pozaszkolnego tak-faceta.

project-management productivity testing

— Nelstaar
źródło

7

Co to znaczy „zaakceptować” „oszacowanie”? Jeśli oszacujesz, że zrobienie czegoś zajmie mi 30 dni, co się stanie, jeśli „zaakceptuję”? Co mnie obchodzi, ile czasu zajmie mi zrobienie czegoś? Można oszacować, zrobię to w minutę dla wszystkich obchodzi mnie, ty będzie źle, nie ja.

— David Schwartz

2

@David Akceptacja szacunków ogólnie odnosi się do przeglądu szacunków i zapewnienia konsensusu. Na przykład, jeśli używane jest narzędzie do oceny parametrycznej, inżynierowie projektu sprawdzają te dane w celu zapewnienia spójności, być może stosując drugą metodologię, taką jak Wideband Delphi.

— Thomas Owens

12

Brzmi jak coś, co powinno zostać wysłane do Scotta Adamsa po kreskówkę Dilberta.

— MetalMikester

1

Tak długo, jak istnieje recenzja. W tym konkretnym przykładzie nie było żadnego.

— Nelstaar

5

Pamiętaj: szacunek, zobowiązanie, cel i plan osiągnięcia celu to cztery różne rzeczy. Upewnij się, że wszyscy mają jasność co do tych rzeczy i która z tych czterech rzeczy jest wynikiem programu Excel.

— nlawalker

14

To zależy od tego, jak rozsądnie wyglądają dla programisty i na jakich danych / logice są oparte. ( mogą być oparte na danych statystycznych gromadzonych przez kilka lat o tym, ile czasu wymagało - sam programista i / lub inni - aby rozwiązać podobne zadania w przeszłości ... lub mogą być całkowicie oparte na zadaniach jego menedżera - poprawne lub niepoprawne - założenia).

Idealnie byłoby, gdyby przedyskutował ze swoim przełożonym, że nie można racjonalnie oczekiwać, że podejmie się i podejmie odpowiedzialność za zadanie oszacowane przez kogoś innego.

Zwykła odmowa przyjęcia szacunków może rzeczywiście skutkować jego szybkim zastąpieniem, dlatego lepiej jest zastosować łagodniejsze podejście i unikać bezpośredniej konfrontacji, jeśli to możliwe.

— Péter Török
źródło

7

Przypuszczalnie makro działa na danych wejściowych, nie jest to tylko generator liczb losowych? Aby odpowiedzieć na twoje pytanie, musimy wiedzieć, jakie są dane wejściowe i co robi makro. Bez tego żadna odpowiedź nie ma większego znaczenia.

Czy twoje pytanie naprawdę dotyczy akceptacji szacunków sporządzonych przez kierownika, który nie ma odpowiedniego doświadczenia? W takim przypadku odpowiedź brzmi „nie”, ty (lub twój przyjaciel) powinieneś sporządzić własne oszacowania i przesłać je kierownikowi. Jeśli 2 cyfry nie pasują do siebie, muszą współpracować, aby znaleźć najlepszy sposób - może zgodzić się na napisanie mniejszej liczby testów lub może zająć więcej czasu.

Bezpośrednia odmowa nie pomoże nikomu, a praca w czasie, którego nie można spotkać, nie jest też zabawą, rozwiązaniem jest przyjęcie profesjonalnego podejścia i osiągnięcie kompromisu, który pozwala na kontynuowanie pracy.

— Steve
źródło

Testy są podzielone na pod-części (prawie atomowe) i jeden otrzymuje małą ocenę.

— Nelstaar

Myślę, że przy użyciu tej metody końcowy tester nie widzi / nie testuje dużego obrazu.

— Nelstaar

1

„Przypuszczalnie makro działa na pewnym rodzaju danych wejściowych, nie jest to tylko generator liczb losowych”. Równie dobrze może być losowy, ponieważ nie ma sposobu na przechwycenie KAŻDEJ zmiennej, która uczyniłaby taki algorytm dokładnym.

— wałek klonowy

1

@maple_shaft: Dlatego nazywają to oszacowaniem - nie jest (lub nie powinno) być dokładne. Niezależnie od tego, czy oszacujesz za pomocą niektórych obliczeń w programie Excel, czy ołówkiem i papierem, nie ma to znaczenia. Używanie Excela do oszacowań ma o wiele większy sens niż niektóre inne „techniki”, które widziałem w użyciu ...

— Treb

Szacunki @Treb powinny być tak dokładne, jak pozwalają na to dostarczone dane i aktualny status projektu, biorąc pod uwagę Stożek Niepewności.

— Thomas Owens

5

Zdecydowanie NIE.

Mały program, nawet duży, skomplikowany program, nie jest w stanie oszacować, jak długo zajmie każde zadanie programistyczne. Zobacz Matematyczne ograniczenia szacowania oprogramowania z powodów, dla których. Dostępny jest także dłuższy, recenzowany artykuł, Large Limits to Software Estimation .

Chciałbym również ponownie rozważyć moją opinię menedżera: dlaczego on lub ona uważa, że makro arkusza kalkulacyjnego nie było próbowane w przeszłości, biorąc pod uwagę, że wszystko inne próbowano oszacować czas trwania zadania programowego w przeszłości.

— Bruce Ediger
źródło

1

Nie przeczytałem tych artykułów w całości (jeszcze), ale metody parametryczne były szeroko stosowane do szacowania projektów oprogramowania w granicach 15% przez ponad 20 lat, przy założeniu, że dane wejściowe są prawidłowe. Ponadto metody współpracy, takie jak Wideband Delphi, mogą (i były stosowane) w celu potwierdzenia dokładności modeli parametrycznych. Zobacz Software Engineering Economics (Boehm) w celu omówienia metod parametrycznych i zastosowania Wideband Delphi w projektach oprogramowania (zarówno z modelami paremetrycznymi, jak i bez nich).

— Thomas Owens

Zgadzam się z Thomasem. Chociaż nie można dokładnie przewidzieć każdego zadania dla całego projektu, w trakcie projektu i przy użyciu danych historycznych dla konkretnej organizacji można dostać się do gry w piłkę. Niektóre zadania potrwają dłużej, a niektóre krócej, ale ostatecznie się uśredniają. Zwłaszcza jeśli projekt jest podobny do projektu już wykonanego przez organizację. Biorąc to pod uwagę, szacunki nie mogą uwzględniać naprawdę złych nieoczekiwanych rzeczy, takich jak sprzęt / oprogramowanie nie działa zgodnie z reklamą, nowe technologie są znacznie trudniejsze niż się spodziewano, niedobory programistów, słabe przywództwo i zarządzanie.

— Dunk

1

Ludzie musicie przeczytać i zrozumieć artykuł. Proste makro arkusza kalkulacyjnego nie ma szansy na prawidłowe oszacowanie. Oprogramowanie to matematyka, a systemy matematyczne czasami podlegają niewielkiemu problemowi zwanemu niekompletnością. Gwarantuję ci, że dany menedżer oszukuje siebie i że wyniki makra nie korelują z rzeczywistością.

— Bruce Ediger,

1

@Bruce: Z powodzeniem wykorzystałem formuły (w tym arkusze kalkulacyjne Excel) do oszacowania projektu, z całą pewnością mogę twierdzić, że ani Thomas, ani kierownik, ani ja sami siebie nie oszukujemy. Jak już powiedziałem, każde indywidualne zadanie będzie się różnić, ale w trakcie realizacji projektu mają tendencję do wyrównywania się. Przekonałem się, że stosowanie formuły (opracowywanej i modyfikowanej w czasie) było znacznie bardziej dokładne niż szacunki poszczególnych programistów. Ogólnie programiści są nadmiernie optymistyczni lub nadmiernie pesymistyczni. Oczywiście formuły działają tylko wtedy, gdy podane są rozsądne dane, umiejętności z pewnością są czynnikiem.

— Dunk

Czytałem te papiery zeszłej nocy. Są przeciwni ponad 40 lat dowodów w zarządzaniu projektami i ponad 30 lat dowodów w zarządzaniu projektami oprogramowania. Zobacz iiasa.ac.at/Admin/PUB/Documents/RM-75-071.pdf i sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

— Thomas Owens

4

Ugh!

To gigantyczny „zapach pracy”. To niesamowite mikrozarządzanie.

Jeśli nie mogą ufać swoim pracownikom, jeśli chodzi o oszacowanie, z czym jeszcze ci nie ufają?

— ozz
źródło

1

99% programistów nie może nawet przedstawić złych szacunków opartych na czymkolwiek obiektywnym, nie mówiąc już o dokładnych szacunkach. Nic więc nie wskazuje na „zapach pracy”, ponieważ ktoś inny wymyślił szacunek. Zwłaszcza jeśli wykorzystali rzeczywiste dane do uzasadnienia swoich liczb. Jeśli ludzie ponoszą odpowiedzialność za wykonanie każdego oszacowania, to jest to problem z zapachem pracy. Jeśli jednak narzędzie znacznie nie doceniło wszystkich zadań, wszyscy programiści nie mieliby szacunków. OTOH, jeśli wszyscy inni wydają się spełniać wszystkie szacunki, a inny programista nigdy tego nie robi, to jest to problem z zapachem programisty.

— Dunk

@Dunk - mój punkt widzenia, mikro zarządzanie do tego stopnia w tworzeniu oprogramowania to „zapach pracy” i nie chciałbym tam pracować.

— ozz

1

to, co nazywacie mikrozarządzaniem, jest jedynym sposobem prowadzenia działalności w wielu branżach. Jeśli nie jesteś w stanie opracować rozsądnych kosztów i zaplanować szacunków dla dużych projektów, Twoja firma będzie miała bardzo trudne zlecenia na znalezienie pracy. W przeciwieństwie do ideału zwinnego, klienci w wielu branżach nie będą zobowiązani do zawierania dziesiątek milionów kontraktów dolarowych, jeśli nie będą wiedzieli, co ostatecznie otrzymają. Nie byliby zadowoleni z pomysłu, że ich pieniądze zniknęły, mają działający produkt, ale robi to tylko 50% tego, czego potrzebują lub chcą.

— Dunk

@dunk - Jeśli jesteś zadowolony z tego, że kierownictwo przygotowuje dla ciebie prognozy, śmiało. Wolę, aby zespół programistów opracowywał szacunki. Absurdalne szacunki kierownictwa (wraz ze stale zmieniającymi się wymaganiami, całą inną dyskusją) są przyczyną tego, że wiele projektów oprogramowania nie zapewnia terminowości i zaplanowanego budżetu. Wolę ufać ludziom, którzy wykonują pracę.

— ozz

Nie chodzi o to, czy kierownictwo dokonuje oszacowań, ani o ludzi wykonujących pracę, którzy opracowują oszacowania. Jest to kwestia wyciągnięcia szacunków z tyłka lub próby oparcia szacunków na niektórych obiektywnych danych. Z mojego doświadczenia wynika, że porównując szacunki kierownictwa z szacunkami deweloperów, okazało się, że szacunki kierownictwa zwykle powodują wydłużenie czasu realizacji. Deweloperzy wydają się być optymistami .....

— Dunk

3

Absolutnie nie.

Obiecuję, że menedżer nie ma złudzeń, że jego makro Excel może dokładnie przewidzieć oszacowania. Nie twierdzę nawet, co powinno być dobrze znanym faktem, że w grę wchodzi zbyt wiele zmiennych, aby dokładnie przewidzieć coś takiego w algorytmie. Jeśli wynalazłby taki algorytm, powinien go opatentować i, moim zdaniem, zarobić miliony.

To, co się naprawdę dzieje, polega na tym, że menedżer używa tego domniemanego makra Excela jako cienko zawoalowanego przebrania, aby ukryć fakt, że wymusza nierealistyczne oczekiwania i nadmierną presję na swoich programistów.

Wie, że jest to BS i nie obchodzi go to, jest to wymówka, aby przepełniać zasoby i starać się robić rzeczy szybciej, czyniąc wszystkich jego „bezwartościowych” programistów wiecznie „LATE”.

Ten menedżer brzmi jak wyrywkowy palant.

— wałek klonowy
źródło

1

Ech, tylko dlatego, że menedżer generuje prognozy dla programistów, nie oznacza, że są one niedokładne i naprawdę nie możemy wyciągnąć takiego wniosku bez dodatkowych informacji. Jeśli menedżer jest kompetentny, powinien rozpoznać realistyczne kontra nierealistycznie dość łatwo odpowiednio dostosować rzeczy.

— rjzii

1

@Rob, Zapomniałeś kluczowego punktu, który przedstawił PO, że są trzymani tych szacunków (zakładanych ściśle, ponieważ poprzedni programista w zespole wspomniał, że „nie chciał się trzymać szacunków” i został ponownie przydzielony). Nie ma nic złego w modelach estymacji, ale powinny one stanowić szorstkie wytyczne i nie powinny „trzymać deweloperów”, co niestety widziałem, jak zarząd robi wiele osobom.

— wałek klonowy

2

Problem polegał na tym, że te szacunki zostały bezpośrednio przeniesione na fakturę klienta. Dlaczego niektórzy menedżerowie nazywają to szacunkami?

— Nelstaar

@maple_shaft - Nie wiedząc, jakie są szacunki, trudno powiedzieć, czy były one nierozsądne, a zatem sprzeciwy wobec ich posiadania były ważne. Gdyby były to uczciwe szacunki (tj. „Osiem godzin na napisanie Hello World”), nie byłoby problemu z trzymaniem ich poza filozofią.

— rjzii

3

W nowym projekcie przyjaciel musiał napisać testy, w których czas wymagany do ich napisania został obliczony przez makro Excel napisane przez jego menedżera, który nie jest programistą.

Istnieją parametryczne modele szacowania do szacowania czasu realizacji projektów, w tym projektów oprogramowania. Zazwyczaj szacunek dotyczy kodu produkcyjnego, ale nie rozumiem, dlaczego nie można go ekstrapolować, aby oszacować, ile czasu zajmie napisanie kodu testowego. Te szacunki są jednak tak dobre, jak dane, które są do nich wprowadzane.

Zakładając, że zastosowana metoda jest prawidłowym modelem szacunkowym, a dane są dokładne i prawidłowe, nie ma powodu, dla którego dobre oszacowanie nie może pochodzić z makra Excel napisanego przez menedżera niebędącego programistą.

Czy w takich okolicznościach deweloper powinien przyjąć odpowiedzialność za napisanie i uruchomienie testów w obliczonym czasie?

Żadne oszacowanie nie powinno być nigdy ślepo akceptowane, w żadnych okolicznościach. Żadne oszacowanie nigdy nie jest idealne, niezależnie od tego, w jaki sposób jest generowane. Inżynier musi przejrzeć wszelkie oszacowania, zidentyfikować potencjalne problemy, ocenić ich wpływ oraz przedyskutować i doprecyzować oszacowanie w razie potrzeby.

Czy wyniki tych testów są wiarygodne?

Testy są tak dobre, jak wysiłek włożony w ich zaprojektowanie i wdrożenie. Jeśli tester przeprowadzi testy niskiej jakości, wady przejdą przez testy i przejdą do późniejszej fazy projektu. Jest oczywiste, że presja harmonogramu doprowadzi do testów niskiej jakości, więc jeśli czas nie jest wystarczający do zaprojektowania odpowiednich przypadków testowych, a następnie ich wdrożenia, testy nie byłyby tak przydatne.

— Thomas Owens
źródło

3

Wygląda na to, że zadajesz dwa różne pytania:

Czy wyniki tych testów są wiarygodne?

Excel to narzędzie, jak każde inne, z którym współpracujemy, a to, w czym zostały zapisane obliczenia, nie powinno tak naprawdę mieć wpływu na wyniki samego algorytmu. Fakt, że oszacowanie pochodzi z makra Excela, nie ma znaczenia dla tego, czy wyniki obliczeń (tj. Ważność oszacowania) są prawidłowe. Jeśli masz złe założenia w modelu bazowym, nie ma znaczenia, czego użyjesz do obliczenia, ponieważ podstawowe założenia są niepoprawne.

Czy w takich okolicznościach deweloper powinien przyjąć odpowiedzialność za napisanie i uruchomienie testów w obliczonym czasie?

Jeśli wymóg, aby deweloper wykonał pracę we wskazanym czasie, jest w ich kontakcie, nie ma wiele do zrobienia, aby się z nim kłócić, o ile szacunki są uzasadnione. Co prowadzi do następnego punktu: jeśli obliczenia dają rozsądny czas i są podobne do szacunków, które dałby sobie deweloper, nie ma powodu, by nie sprzeciwiać się podanym terminom. W rzeczywistości może to działać na korzyść programistów, ponieważ mogą oni mieć wpływ na założenia przyjęte w module, w przeciwieństwie do sytuacji, gdy otrzymają arbitralną oś czasu.

Jeśli ramy czasowe wydają się niewykonalne ze względu na wymaganą ilość pracy, to oczywiście powinni podnieść tę obawę i spróbować współpracować z menedżerem, aby uzyskać bardziej realistyczne ramy czasowe, ale jeśli harmonogram jest wykonalny, będą mieli trudności z wyrażeniem sprzeciwu wobec nich.

Jeśli chodzi o zarządzanie projektami i szacowanie terminów, tak, można to zrobić, ale w dużym stopniu zależy to od charakteru wykonywanej pracy. Prawdopodobnie zobaczysz dokładniejsze szacunki dotyczące czasu potrzebnego na napisanie kodu testu jednostkowego (zakładając, że programista rozumie platformę i napisał je wcześniej), niż będziesz pisać nowy kod w przypadkach użycia kodu testowego dla.

— rjzii
źródło

Zgadzam się, że tej metody można / można używać, dopóki istnieje dialog między podmiotami projektu.

— Nelstaar

1

@Nelstaar - Prawie wszystko, co kiedykolwiek czytałem na temat zarządzania projektami i szacowania, wymaga prowadzenia dialogu i dostosowywania rzeczy w miarę upływu czasu. Zwykle najbardziej wiarygodne szacunki wiążą się z prawdopodobieństwem związanym z prawdopodobieństwem trafienia we wskazany cel (tj. 90% szansy na zajęcie 8 godzin).

— rjzii

2

Nie chcę lekceważyć testów pisania, ale prawdopodobnie w projekcie było już napisanych przez kilku programistów. Jeśli szacunki opierają się na tych danych, mogą być one bardziej dokładne niż zakładał twój przyjaciel. Ponieważ twój przyjaciel opuścił projekt, nie próbował tworzyć przeciwnych prognoz ani sprawdzać, czy można je zrealizować zgodnie z przewidywaniami, nigdy się nie dowiemy.

Jedyne, co musiał zrobić, to ukończyć jeden lub dwa testy, aby zobaczyć, jak dokładna jest szacunek, i powrócić do kierownika z uzasadnionym argumentem. Mogą istnieć inni członkowie zespołu, którzy mogliby przekazać informacje zwrotne na temat wiarygodności szacunków lub konsekwencji zaległości. Czasami jeden menedżer musi dać „coś” swojemu szefowi, aby wszyscy byli zadowoleni. Deweloperzy postrzegają to jako fałszywe poczucie bezpieczeństwa. Być może jeśli programiści mieli tendencję do przedstawiania szacunków i wykazywania gotowości do wykonania zadań, kierownictwo może zyskać większe zaufanie.

Zgaduję, że gdyby był w stanie ukończyć testy w krótszym czasie, nie powiedziałby nic na ten temat. Z drugiej strony usprawiedliwianie się praktyką, w którą nie wierzy, może wskazywać na wysoki poziom uczciwości.

— JeffO
źródło

+1 za udzielenie informacji zwrotnej podczas pracy nad zadaniami w odniesieniu do szacunków.

— rjzii,

1

Prosta i krótka odpowiedź:

Nie obchodzi cię, skąd pochodzi ta ocena.

To, co naprawdę cię obchodzi, to samo oszacowanie. Zgadzam się z nim lub nie zgadza i wyjaśnić, dlaczego i ile ty by oszacować. To jest najważniejsze.

— Clement Herreman
źródło

1

Powinieneś dbać o to, skąd pochodzi szacunek. Model parametryczny z prawidłowymi i uzasadnionymi danymi wejściowymi, generator liczb losowych, student informatyki pierwszego roku, inżynier oprogramowania z 5-letnim doświadczeniem z mniej niż 6 miesiącami w dziedzinie oraz inżynier oprogramowania, kierownik projektu z 25-letnim doświadczeniem w domenie mają różną zdolność do skutecznego oszacowania. To także wraca do komentarza, który wypowiedziałem na temat poprzedniej odpowiedzi na temat etycznej / zawodowej odpowiedzialności inżyniera oprogramowania za odpowiednie reprezentowanie, obronę i kwestionowanie szacunków.

— Thomas Owens

Dokładnie: najważniejsze jest omówienie oszacowania. Z przyjemnością zgodziłbym się na użycie makr Excela, jeśli dokonywane przez niego szacunki były częstsze niż 25-letnie doświadczenie inżyniera. Ważne jest oszacowanie i wyjaśnienie, które do niego prowadzi (obciążenie, dostępne zasoby, trudność), a nie przez kogo lub co zostało ogłoszone.

— Clement Herreman,

Zgadzasz się ze mną, mówiąc, że twoja odpowiedź jest zła? Biorąc pod uwagę te same dane wejściowe (takie jak obciążenie pracą, zasoby, trudność itp.), Kto jest tak samo ważny jak co i dlaczego. Wszystko sprowadza się do czynnika zaufania. Ufam COCOMO (stworzonemu i utrzymywanemu przez niektóre wiodące umysły w zakresie szacowania kosztów oprogramowania) bardziej niż makru Excela (stworzonemu przez kogoś z ograniczonym doświadczeniem i wiedzą w zakresie szacowania kosztów, a tym bardziej domeny aplikacji). Chodzi o ogólny obraz, aby ustalić, jak wiarygodne jest to oszacowanie.

— Thomas Owens

Nie nie, chyba nie jestem wystarczająco jasny. To naprawdę nie jest ważne, kto dokonał oszacowania. Ważna jest dokładność oszacowania. Ilekroć otrzymuję oszacowanie, porównuję je z tym, co oszacowałem, a następnie omawiam je z moim kierownikiem projektu, jeśli się zgadzam, czy nie. Jeśli ich argument jest wystarczająco dobry, to zgadzam się z nimi i akceptuję oszacowanie. Widzieć? Nigdy nie rozmawiałem ani nie myślałem o tym, kto oszacował.

— Clement Herreman,

Jak określić dokładność, jeśli nie wiesz, kto oszacował i jakich metod zastosował? Mógłbym przekazać te same dane dwóm osobom - jedna jest studentem pierwszego roku inżynierii oprogramowania, który bierze obecnie swój pierwszy kurs informatyki, a druga jest starszym inżynierem oprogramowania z 15-letnim doświadczeniem i 5 w tej dziedzinie. Oba używają tych samych metod szacowania (nie zapominaj - często dane wejściowe są również szacunkami). Student może powiedzieć, że zajmie to 6 miesięcy z 95% pewnością. Starszy inżynier może powiedzieć, że zajmie to 15 miesięcy z 80% pewnością. Bardziej ufałbym starszemu inżynierowi.

— Thomas Owens

1

Teoretycznie deweloper nigdy nie powinien akceptować oszacowania dokonanego przez jakąkolwiek inną osobę, bez względu na to, jak do tego doszło. Jednym z powodów jest to, że podanie dłuższej prognozy, niż kierownikowi wygodnie, natychmiast ujawnia potencjalny problem z harmonogramem lub może nieporozumienie co do zakresu pracy, którą należy wykonać.

Ludzie na ogół uważają, że oszacowanie czasu programowania jest nawet trudniejsze niż samo programowanie, więc jeśli twój menedżer może napisać makro Excela, może rozwiązać ten problem, prawdopodobnie może zbudować makro do napisania kodu (mało prawdopodobne).

Teraz, w praktyce , jeśli rozumiesz pracę, a szacunki wyglądają na rozsądne, sensowne jest po prostu wyrażenie troski o metodologię, ale tymczasowo zgadzasz się, czy możesz je spełnić. Później, jeśli praca zajmuje Ci więcej czasu niż szacunki, powinieneś zwrócić na to uwagę menedżerów w jak najwcześniejszym momencie. Przygotuj się do przedyskutowania dokładnych przyczyn w oparciu o Twoje rzeczywiste doświadczenia związane z wdrażaniem. Mam nadzieję, że w tym momencie Twój menedżer nie będzie nierozsądny i nadal będzie nalegał, abyś pracował nad mechanicznie generowanymi szacunkami.

— PeterAllenWebb
źródło

-1

Jedną z najnowszych metodologii tworzenia oprogramowania jest zwinny , a jedną ze znanych platform zwinnych jest scrum . Ale w tej metodologii programiści (zespół scrum) są odpowiedzialni za obliczenie czasu potrzebnego na wykonanie zadania lub wdrożenie historii użytkownika.

Zdecydowanie mówię NIE . Bo:

Menedżer niebędący programistą nie może oszacować wymaganego czasu na wykonanie zadania
Oszacowanie wymaganego czasu na wykonanie jakiejkolwiek pracy wymaga ludzkiej inteligencji, której Excel nie ma
Akceptując takie praktyki robocze, menedżer stopniowo przyzwyczaja się do zastępowania programistów w szacowaniu czasu. Może to doprowadzić do katastrofy. Rozważ ten scenariusz, w którym kierownik mówi:

Chcę rozpocząć nowy projekt sprzedaży rowerów online i wiem, że jego realizacja zajmuje 3 tygodnie.

— Saeed Neamati
źródło

5

OP nie wspomina o zespole swojego przyjaciela, stosując zwinne metody. Nie sądzę, aby zwinne reguły miały jakiekolwiek znaczenie dla zespołów używających innych metod (lub żadnej metody). Rozsądek powinien jednak :-) Ponadto oczywiste jest, że to Excel nie decydował o szacunkach, wykonał tylko pewne obliczenia na podstawie niektórych (nieznanych nam) założeń i danych (z których każde może być poprawne lub niepoprawne) . Jeśli wprowadzę prognozy dla danego zadania przez każdego z członków naszego zespołu, a następnie skonfiguruję program Excel do obliczenia ich średniej, czy program Excel dokonuje oszacowania?

— Péter Török

3

1 i 2 są rażąco fałszywe. Modele oceny parametrycznej są powszechnie akceptowane w zarządzaniu projektami oprogramowania i są stosowane od ponad 20 lat, a każdy ze szkoleniem w zakresie zarządzania projektami (inżynier oprogramowania lub nie) może zostać przeszkolony w zakresie korzystania z tych narzędzi, przy założeniu, że oni (lub najlepiej inżynierowie projektu) ) są w stanie dostarczyć dokładne oszacowania danych wejściowych.

— Thomas Owens

3

-1 - To nie odpowiada na pytanie, ma oczywiste błędy („... najnowsze metodologie tworzenia oprogramowania są zwinne”) i nie wydaje się dodawać nic istotnego. Nie jestem pewien, po co były głosy poparcia ani zaakceptowana odpowiedź.

— Morgan Herlocker

1

z pewnością nie wiemy z pytania, czy szacowanie parametryczne jest normą w tej firmie i / lub czy opiera się na dobrej historii ich działalności; jeżeli jest to przypadek, o ile nie chcę tego mówić, odmowa wykonania pracy zgodnie z przyjętymi przez organizację procedurami operacyjnymi (bez zachowania rozsądnej ścieżki przesłuchań) jest nieroztropna.

— StevenV

2

@Thomas Zgadzam się, po prostu uważam, że jest zbyt wiele rzeczy, których nie wiemy o sytuacji, aby kategorycznie odpowiedzieć Tak lub Nie. W każdym razie, całkowita odmowa bez dobrej dyskusji, aby upewnić się, że sytuacja i rozumowanie są zrozumiane, rzadko jest dobry ruch kariery.

— StevenV