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
źródło
Odpowiedzi:
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.
źródło
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.
źródło
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.
źródło
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ą?
źródło
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.
źródło
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ą.
Ż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.
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.
źródło
Wygląda na to, że zadajesz dwa różne pytania:
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.
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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:
źródło