Co może być dobrym działaniem budującym zespół w celu poprawy umiejętności szacowania? [Zamknięte]

9

Przygotowuję prezentację, aby przekazać ją niektórym z moich kolegów z zespołu (wszystkim programistom) i chciałbym zamieścić krótką aktywność budowania zespołu, która koncentruje się na poprawie umiejętności szacowania. Czy ktoś ma jakieś sugestie lub zna jakieś działania budujące zespół, których mógłbym użyć?

estimation team-building

— Obrabować
źródło

2

Poprawa oszacowania nie jest czymś, co można zrobić za pomocą krótkiej aktywności. Śledzenie twoich szacunków, faktycznych czasów i pewnego rodzaju pośmiertnego musi być długofalowym wysiłkiem, aby ustalić, dlaczego szacunkowy i rzeczywisty czas są różne. To także umiejętność, która rozwija się z czasem - poprawiasz się, oceniając błędy i ucząc się na ich podstawie poprzez analizę.

— Thomas Owens

Czy masz jakiś problem? Jak dokładne są twoje szacunki i czy powinieneś poświęcić czas na ich poprawienie?

— JeffO

@Thomas Owens, zdaję sobie sprawę, że nie można tego zrobić za pomocą krótkiej aktywności. Próbuję tylko zwiększyć świadomość znaczenia rozwijania dobrych umiejętności szacowania. Powinienem był uściślić swoje pytanie.

— Rob

2

@Jeff O, nie ma problemu - są to nowi pracownicy, niektórzy z mniejszym doświadczeniem, i chcę pomóc im w ogólnej ocenie.

— Rob

8

Sprawdź Planowanie oparte na dowodach oprogramowania Joela , jest to dość prosty sposób, aby ludzie mogli dowiedzieć się, jak dokładniej oszacować.

Najlepszym sposobem nauczenia się szacowania jest posiadanie dobrych wymagań, praktyki, praktyki i praktyki. Nauczenie ich takich rzeczy, jak planowanie oparte na dowodach, pomoże ćwiczyć bardziej efektywnie, ale nic nie zastąpi faktycznego ćwiczenia.

— Malfist
źródło

Kocham mnie trochę EBS (jestem zapalonym użytkownikiem FogBugz). Jednak nie myślałem o tym, żeby użyć go jako przykładu - dobra sugestia. Czerpię z tego inspirację.

— Rob

6

Przedstaw przykładowy problem z wykorzystaniem Minecraft.

Klient potrzebuje brązowej piramidy schodkowej o wymiarach 20 x 20 bloków. Piramida potrzebuje także fosy o szerokości co najmniej 10 bloków.

Daj im 3 minuty na szkicowanie prostej WBS i oszacowanie.

Za 2 minuty powiedz, że klient zmienił zdanie i potrzebuje teraz piramidy 30x30. Powiedz im, aby skorygowali swoje prognozy w pozostałej minucie.

Pod koniec czasu powiedz im, aby odłożyli ołówki, a teraz powiedz, że programiści zaczynają pracę nad projektem, ale klient jest zdezorientowany, ponieważ przez fosę nie przeszedł most.

Powiedz im, że budowa mostu zajmie X godzin, i poproś wszystkich, którzy nie docenili, by wstali.

To doprowadzi punkt do domu.

— wałek klonowy
źródło

2

Podoba mi się to, ale jeśli nie znasz Minecrafta, nie jestem pewien, w jaki sposób możesz opracować oszacowanie, które ma sens. Jak oceniłbyś czas potrzebny na zbudowanie brązowej piramidy schodkowej?

— Rob

1

@Thomas Owens, myślę, że celem maple_shaft jest przekonanie programistów o znaczeniu odkrywania tego rodzaju wymagań. Jako konsultant osobiście widziałem wiele przykładów absurdalnie oczywistych rzeczy, o które użytkownik powinien był poprosić, ale nie zrobił tego, ponieważ nie zdawał sobie sprawy, że tego właśnie potrzebuje. Ja i moi programiści jesteśmy konsultantami, aw naszej obecnej sytuacji nie mamy luksusu dobrych inżynierów wymagań, dlatego staram się pomóc im zmusić ich do zadawania tego typu pytań odkrywczych swoim klientom, aby poprawić ich szacunki .

— Rob

2

@ unforgiven3 Nie ma to jednak nic wspólnego z szacowaniem. Zadanie inżynierii wymagań może spoczywać na deweloperze, ale możesz opierać swoje szacunki tylko na znanych wymaganiach. Poprawa zdolności do analizowania, weryfikowania, sprawdzania poprawności i odkrywania wymagań jest nierozerwalnie związana z poprawą zdolności do szacowania, ile czasu zajmie wykonanie zadania. Wymagania się zmieniają, dlatego szacunki się zmieniają, ale niemożliwe jest oszacowanie tego, czego nie wiesz i nie powinieneś próbować.

— Thomas Owens

1

@Thomas Owens, zgadzam się, że niemożliwe jest oszacowanie tego, czego nie wiesz - co dokładnie o to mi chodzi - musisz odkryć wymagania dotyczące funkcji i zweryfikować założenia o niej jako warunek wstępny do stworzenia przyzwoitej oceny. Zgadzam się jednak, po pewnym przemyśleniu, że nie ma nic wspólnego z poprawą zdolności do oszacowania - być może skoncentrowanie działania na odkrywaniu wymagań byłoby bardziej przydatne natychmiast niż oszacowanie. Dobre punkty - na pewno każą mi myśleć, że być może skupiam się na złych umiejętnościach do poprawy.

— Rob

1

@ unforgiven3 Dobry inżynier powinien zawsze pracować nad ulepszeniem obu. Byłem na stanowisku, w którym nie powierzono mi inżynierii wymagań, ale otrzymałem specyfikację, w której widziałem problemy. Umiejętność ich dostrzegania i zadawania właściwych pytań jest niezbędna każdemu, kto tworzy oprogramowanie i należy nad tym popracować. Jednak, kiedy oceniam, zawsze opieram swoje oszacowania na specyfikacji, nawet jeśli pojawiają się pytania. Po prostu zostawiam większe okno błędu (daje 75% szans zamiast 85% lub daje nieco większe okno).

— Thomas Owens

1

Sugeruję generator / solver labiryntu dla następujących punktów:

To jest zabawne
Nie możesz pomyśleć o wszystkich przypadkach po raz pierwszy
Generowanie i rozwiązywanie problemów jest dość komplementarne
Obejmuje to od zaplecza z zapisywaniem danych do interfejsu z ładowaniem danych
Ludziom można przypisać wiele punktów: specyfikację pliku, wyświetlanie, generowanie, rozwiązywanie, optymalizację, testowanie itp.

— Whiskas
źródło

1

Możesz zagrać w „Ile czasu zajęłoby ci napisanie tego?” gra. Podobne do grupy osób przechwalających się tym, jak mogą jechać do Las Vegas za X godzin (gdzie liczba X zwykle maleje z każdym braggartem, dopóki ktoś nie twierdzi, że może to zrobić w ciągu niecałej godziny). Tak więc dla programistów: rzuć prosty cel i zobacz, co mówi każda osoba oraz czy grupa ma konsensus lub wyjątkowe opinie. Jak długo zajęłoby ci napisanie cześć światu? Co oznacza „pisać”, czy to też oznacza „uruchomić” i „przetestować”? Czy wymaga to najpierw środowiska symulacyjnego? Na jakiej platformie i który kompilator krzyżowy oraz czy narzędzia są już zainstalowane i gotowe? itd. itd. „Witaj świecie” może zająć 4 dni, aby „napisać” na wbudowanej platformie (zainstaluj narzędzia, przygotuj platformę,

Po tym, jak zespół skończy decydować o tym, jak długo może zająć cel, zmierz, ile on faktycznie zajmuje (być może nie dla sugerowanego celu, ale dla realnego podobnego celu) lub przywołaj poprzedni projekt z bardzo podobnym celem. Porównaj oszacowanie z faktycznym. Szaleńczo wyolbrzymiaj błąd między oszacowaniem a faktem i opublikuj wniosek dla wszystkich.

— Jonathan Cline IEEE
źródło