Hej. W mojej aktualnej pracy programiści na początku sprintu dostają zadania, które mają wyestymować. Zauważyłem, że moje estymacje i analizy często odbiegają od normy, dlatego chciałem się was zapytać, jak analizujecie nowe zadania, pod jakim kątem na nie patrzycie i jakie stawiacie ewentualne pytania dla kogoś kto to zadanie wystawił? Macie jakieś pewniejsze reguły odnośnie estymowania zadań? Wydaje mi się, że u mnie problem leży bardziej przy niepoprawnej analizie zadania i rozbicia go na mniejsze, a także mimo nagromadzenia paru pytań później okazuje się, że temat nie jest wyczerpany i tracę czas na dojście do rozwiązania samemu lub ostatecznie podpytania kogoś. Znalazłyby się może jakieś porady?
0
0
Przeczytaj: omg.org/mda/mda_files/032111230X.pdf
Masz 2 podstawowe opcję Zachowanie. Czyli: jak to się zmienia, dlaczego to się zmienia, pod jakim warunkiem to się zmienia, Jak często się zmienia i tp.
Czym to się staje: Np. Rezerwacja pokoju na jedną noc generuję propozycję oferty śniadania za pół ceny
0
Na pewno duże znaczenie ma doświadczenie zarówno zawodowe jak i w danym projekcie. Oprócz tego takie podstawowe punkty brane pod uwagę w estymacji które mi się teraz nasuwają to...
- Trudność zadania (np. nowe technologie, moduły których nie znamy)
- Czasochłonność (może być super proste ale wymaga zmian w milionie miejsc)
- Czynniki zewnętrzne (np. zewnętrzne serwisy z którymi zadanie ma coś wspólnego, mogą nie działać, albo mieć błędy)
- Ryzyko (czasem jedno zadanie jest bardzie corowe od drugiego, zmiana labela będzie zaraz widoczna, ale jakieś zmiany głęboko w kodzie mogą napsuć więcej, teoretycznie testy powinny to wykryć ale...)
Chętnie się dowiem co inni mają do powiedzenia.
3
Po pierwsze: NIe przejmuj się - estymaty nie muszą być dokładne i nie wszyscy muszą dawać takie same. Jakby były dokładne to by nie były szacunkami.
Im dłuższe zadanie i mniejszy czas poświęcony na szacowanie -> tym większa rozbieżność.
Jeśli ktoś od Ciebie wymaga dokładnych szacowań - to wymagaj dokładnie opisanych zadań i dużo czasu na analizę najlepiej tyle ile trwa zadanie :-) Zrobisz zadanie, a potem powiesz ile trwało i masz dokładnie zmierzone. Każde inne podejście oczywiście skutkuje jakimś błedęm.
Jeśli twoje zadania wymagają dopytywania ... to znaczy, że nie są gotowe do estymacji przez programistę -> norma.
Pocieszę Cie, że jeśli chodzi estymowanie to nawet jak będziesz grupą doświadczonych architektów to zdażą Ci się niezłe wtopy. Moje ulubione to kiedyś zadanie wycenione na ZERO. Miało być tak trywalne, że nie warto było wpisywać czasu (mniej niż 5 minut). Udało nam się (zespołowi programistów) to zadanie wyrzucić do zrobienia dla tegoż zespołu architektów. Skoro ZERO to im też wiele zajac nie mogło - 3 miesiące i było gotowe...
0
Nie przejmuj sie tym czy estymaty odbiegają od propozycji innych tylko tym czy się sprawdzają. Jak się nie sprawdzają możesz obserwować czy masz tendencję do niedoszacowywania czy przeszacowywania. W jakich sytuacjach? Generalnie dawanie dobrych estymat przychodzi z doświadczeniem. Bez doświadczenia nic dziwnego że robisz błędy. Poza tym jeśli wystawiasz estymatę dla kogoś innego to mussz wiedzieć jak ta osoba pracuje, bo kazdy ma swoje tempo.
Co do rozbijania zadań na mniejsze to to jest inny błąd. Zadania do wykonania powinny być atomowe. Na tym polega agile.
0
Dzięki za odpowiedzi. Z tego co wyestymuje rozliczam sie potem, czyli opierdzielac sie za bardzo nie mozna. Oczywiscie moge przekroczyc czas ktory wyestymowalem, tylko to nie powinno zdarzac sie zbyt czesto (zapiski w umowach). Wiec jednym z problemow jest analiza zadania. O ile poczatek zadania przewaznie rozplanowany mam dobrze, to potem wszystko sie miesza i czesto jest tak ze oddajac zadanie do technicznego review jestem uradowany ze wreszcie sie go pozbylem. Do tego dochodza nieprzewidziane problemy i niegdys czeste zmiany decyzji przez architektow. Tak czy owak czesto moje szacowania sa zbyt male i przekraczam czas. Spotykam takie problemy, jak na przyklad wiem ze taka i taka metoda istnieje i mam jej gdzies uzyc, ale w polowie zadania okazuje sie, ze mam ja poszerzyc o jeden dodatkowy argument (nie bylo nic o tym w opisie zadania). Niby rzeczy nieprzewidywalne (a moze jednak?) a bardzo wplywajace na moj czas spedzony na zadaniach.
2
Jeśli wychodzą rzeczy, których nie było w opisie zadania (dodatkowy argument), a ty jesteś z tego rozliczany... to ktoś Cie oszukuje. Po prostu to zadanie nie było gotowe do szacowania. Następnym razem jak coś takiego wyjdzie - pokaż, że nie było i żądaj zmiany czasu, nowego zadania.
Głupia i prosta reguła do szacowania to: pomnóż ile Ci się wydaje ...przez 3.
Ma to nawet sens, bo:
- robisz zadanie mniej więcej w czasie X, (to taki czas o jakim początkujacy programista myśli, że mu zajmie, bo myśli tylko o kodzie),
- musisz poświęcić trochę czasu na testowaie, jako profesjonallista robisz testy automatyczne, czy inną weryfikację +100%,
- kodu nie zostawiasz brzydkiego, więc robisz na koniec refaktoring, przerabiasz aż jest ładny i czytelny + 100%
Czyli 3*X i profit :-)
Teraz, nawet jak nie trafisz to najwyżej nie starczy Ci na jakość - smutne, ale ból mniejszy.
Przy okazji - wiem, że to nie proste. Wielokrotnie musiałem przekonywać różnych i całkiem doświadczonych i dobrych programistów, żeby dawali słuszny bufor na refkatoring, ta nauka trwała czasem miesiące....
0
Możesz zadanie rozbić na mniejsze taski i oszacować ile Ci zajmie ich zrobienie. Miej tylko proszę na uwadze, że oszacowanie obarczone jest błędem bo to jest tylko szacowanie. Aby określić ściśle ile zajmie Ci zrobienie zadania musiałbyś po prostu je zrobić:) Po pewnym czasie zgromadzisz doświadczenie, które pozwoli Ci na łatwą i dokładniejszą estymacje wykonania pracy. Weź pod uwagę, że jest coś takiego zwanego "zawsze k...a coś" czyli coś co wyskoczy w trakcie pracy, a co wpływa na przedłużenie jej wykonania. Warto brać margines na takie nieprzewidziane rzeczy i ogólnie zakładać, że wykonanie pracy zajmie Ci więcej niż początkowo zakładałeś (bufor, o którym napisał kolega w poście powyżej). Zawsze też można powiedzieć, że estymacja była źle wykonana. Za to nikt głowy nie urywa, ale warto wykorzystać to w przyszłości, aby szacunki były zbliżone do realnych.
0
W moim zespole staramy się estymować na podstawie podobieństwa /złożoności do zadań, które już wykonaliśmy. Wymaga to oczywiście czasu na zbudowanie bazy ale wraz z jego upływem nasze estymaty są bardziej trafne.
Na początku planowania, przechodzimy po story, sprawdzamy ile szacowaliśmy, a ile wyszło rzeczywiście i logujemy to sobie. W ten sposób budujemy bazę różnych zadań i przypadków. Podczas estymowania nowych story staramy się odpowiedzieć czy dane story "wydaje" się bardziej/mniej złożone od jakiegoś zalogowanego. Jakoś to działa.
Przy podzielonych zdaniach gramy też w scrumpokera - najczęściej drugie rozdanie (po wysłuchaniu skrajnych opinii) jest ostatnim.
Nikt nikogo nie ściga za błędy w szacowaniu - to jest tylko szacowanie, z góry obarczone błędem.
Poza tym nie wiem jak u innych ale u mnie jak to w scrumie zwykle bywa odpowiada cały zespół, a nie pojedyncza osoba. Nie ma czegoś takiego, że ja kiepsko wyszacowałem ponieważ na tą estymate zgodził się cały zespół to zespół jest za to odpowiedzialny. To, że ja jestem odpowiedzialny w zespole za jakieś story nie zwalnia reszty zespołu z interesowania się tym story.