Estymacja zadan, czyli malowanie trawy na zielono.

0

Mam refleksje odnośnie estymacji.

Bywa ona przez wiele zależności nieprecyzyjna, a przez to zwodnicza.
Podczas ostatnich dni dowiezienia wartości robi się zazwyczaj trytytkowanie, gdzie okłamujemy sami siebie, ze poprawi się później.
Podczas trytytkowania jakość naszej pracy spada i pojawia się flustracja.
Oraz rzecz najważniejsza - dostarczenie dobrej wartości biznesowej jest lepsze niż dowiezienie ledwo działającej usługi o niskiej jakości technicznej.

Jak wy dealujecie z estymacja? Bo jedyne co to mając dobre DoD trzeba czasowo rozciągnąć dość mocno taska, przez co biznes zawsze jest smutniejszy, obarczając was winą..

8

Jest nieprezycyjna bo siłą rzeczy nie może być precyzyjna. Zresztą samo słowo szacowanie to mówi. Może jak masz dodanie walidacji na jeden input w formatce to wiesz ile Ci to może zająć, ale jak masz coś bardziej skomplikowanego to ciężko precyzyjnie określić. I z jednej strony albo ocenisz nierealistycznie że szybciej coś zrobisz i wtedy biznes się wkurza że nie dowozisz, albo szacujesz że coś zajmie dłużej i wtedy biznes się wkurza czemu taski szacujesz na tak długo.
TL;DR - biznes się zawsze przyczepi :D
Ale jeśli widzicie że zawsze idzie dłużej niż planujecie to warto następnym razem oszacować zadania na więcej ;)

To jeszcze to skomentuje żartem:

  • Czemu wy, programiści, nigdy nie możecie dokładnie ocenić czasu niezbędnego do realizacji projektu?!
  • Szefie, to bardzo proste. Wyjaśnię na przykładzie. Szef lubi w wolnym czasie dłubać przy samochodach, tak?
  • Dawaj ten przykład.
  • Musi szef rozładować samochód. Ile to szefowi zajmie?
  • Do godziny.
  • To jest Kamaz.
  • Niech będą cztery godziny.
  • Załadowany piaskiem.
  • No to z osiem.
  • Szef nie ma żadnych narzędzi, tylko ręce i nogi.
  • Doba, dwie..
  • Na dworze jest minus czterdzieści.
  • No to ze trzy.
  • A Kamaz jest pod wodą i przerębel zamarzł.
6

Stara zasada estymacji:

  • zbieramy zespół
  • wybieramy najbardziej pesymistyczną estymację
  • mnożymy *2
  • dodajemy 2 miesiące

i już!!!

2

u mnie zdołaliśmy wyeliminować ten problem w jakichś 95% - po pierwsze jeśli na wstępie stwierdzamy, że coś zajmie więcej niż 5 dupodni to nie estymujemy tylko wrzucane jest do worka na później. Tak samo jeśli ewidentnie task aż się prosi, żeby go podzielić na mniejsze, np. zmiany w formatce osobno, logika osobno, api osobno, BD osobno. Teraz wracając do tasków, które na starcie dostały > 5DD - ktoś z zespołu, który ma największą wiedzę o danym kawałku dostaje zadanie rozbicia taska na mniejsze i dopiero takie estymujemy. Sprawdza się to dość dobrze i o ile nie trafimy na jakąś nieoczekiwaną przeszkodę (którą zazwyczaj jest "a bo tu panowie jednak miało być inaczej") to od dłuższego czasu nie mamy obsuw czasowych. Jesteśmy też w tej komfortowej sytuacji, że jeśli po wyestymowaniu coś się w sprincie nie mieści to jest po prostu przesuwane a nie wciskane kolanem.

2

Podstawą dobre estymacji jest odpowiednie rozbicie zadań, w przeciwnym wypadku to jest po prostu zgadywanie. Zadania powyżej 8 godzin (moim daniem 4 h to maks ile powinno być) powinny być rozbite na mniejsze i dopiero wtedy estymowane.

Bo jedyne co to mając dobre DoD trzeba czasowo rozciągnąć dość mocno taska, przez co biznes zawsze jest smutniejszy, obarczając was winą..

Ale jaką winą was obarczają? Jedna strona zaleca druga realizuje. Wina jest wasza jak coś wyestymujecie zupełnie bez sensu - na zasadzie "to bedzie ze 20 dni".

0

@UglyMan: a co jeśli nie da się zadania rozbić?

0
ProgScibi napisał(a):

@UglyMan: a co jeśli nie da się zadania rozbić?

Ale że jak się nie da rozbić? Jak ktoś nie potrafi rozbić zadania to znaczy, że dostatecznie nie przeanalizował tematu.
Problemem są zadania z utrzymania, bo takie to nie wiadomo ile zajmą. Ale tego raczej nikt nie estymuje.

0

@UglyMan: serio? Nigdy nie miałeś niczego co sensownie nie da się podzielić tak aby jedna część miała mniej niż 8 godzin? Bo jakoś mi ciężko uwierzyć że każde zadanie da się rozbić na te poniżej 8h. O 4h nawet nie mówię

0

@ProgScibi: Możesz dać takiego przykład takiego zadania?

2

Podstawą dobrego oszacowania czasu realizacji systemu / aplikacji jest dobry projekt przeanalizowany i zatwierdzony przez zamawiającego.
Jeśli projekt jest jedynie zbiorem myśli i luźnych pomysłów to i czas realizacji zadania jest tak samo luźny.
Dobry analityk, najlepiej z doświadczeniem w programowaniu, wie ile czasu trwa robienie pewnych elementarnych klocków, z których zbudowana jest całość zadania i na tej podstawie może dość precyzyjnie oszacować ilość roboczogodzin potrzebnych na zrealizowanie całości. Następie tę liczbę dzieli na ludzi, ustawia w kalendarzu, dodaje margines czasowy na wypadek: urlopów, chorób, drobnych wpadek i poprawek niezbędnych na etapie wdrożenia... W przypadku większych zadań mamy odpowiednie narzędzia ułatwiające wskazanie ścieżki krytycznej, pomagające układać harmonogramy, dobierać zasoby itp...

Ważne jest aby osoba zajmująca się szacowaniem czasu realizacji zadań, zwyczajnie była w temacie dobrze zorientowana. Musi wiedzieć jakie funkcje już w systemie są co jest łatwe a co trudne do dorobienia. Jak ktoś ogólnie mało wie to także jego estymacje będą mało precyzyjne.

Dobre oszacowanie czasu realizacji projektu daje gwarancję dostarczenia w spokoju dobrej jakości produktu... Chyba, że zespół jest ogólnie do d... ale na to to już nie ma rady.

3
katakrowa napisał(a):

Podstawą dobrego oszacowania czasu realizacji systemu / aplikacji jest dobry projekt przeanalizowany i zatwierdzony przez zamawiającego.

Chodzenie po wodzie jest tak samo proste, jak pisanie aplikacji zgodnie ze specyfikacją - pod warunkiem, że jedno i drugie jest zamrożone.

Jeśli projekt jest jedynie zbiorem myśli i luźnych pomysłów to i czas realizacji zadania jest tak samo luźny.
Dobry analityk, najlepiej z doświadczeniem w programowaniu, wie ile czasu trwa robienie pewnych elementarnych klocków, z których zbudowana jest całość zadania i na tej podstawie może dość precyzyjnie oszacować ilość roboczogodzin potrzebnych na zrealizowanie całości. Następie tę liczbę dzieli na ludzi, ustawia w kalendarzu, dodaje margines czasowy na wypadek: urlopów, chorób, drobnych wpadek i poprawek niezbędnych na etapie wdrożenia... W przypadku większych zadań mamy odpowiednie narzędzia ułatwiające wskazanie ścieżki krytycznej, pomagające układać harmonogramy, dobierać zasoby itp...

Ważne jest aby osoba zajmująca się szacowaniem czasu realizacji zadań, zwyczajnie była w temacie dobrze zorientowana. Musi wiedzieć jakie funkcje już w systemie są co jest łatwe a co trudne do dorobienia. Jak ktoś ogólnie mało wie mało to także jego estymacje będą mało precyzyjne.

Dobre oszacowanie czasu realizacji projektu daje gwarancję dostarczenia w spokoju dobrej jakości produktu... Chyba, że zespół jest ogólnie do d... ale na to to już nie ma rady.

Ale to wysiada przy projektach robionych zwinnie.

2

Ja podzielę się swoimi refleksjami:

  • czasem ludzie nie widzą różnicy między nakładem prac, a czasem realizacji (np. realna praca to 8h, ale rozciągnięta na 3 tygodnie realizacji; "effort" vs "duration")
  • niechętnie estymują, bo nie wiedzą, jak będzie to wykorzystywane ("wyestujmuję i będę musiał zrobić w takim czasie, k**a, lepiej dam mnożnik x10"), czy nie wiedzą jak się do tego metodycznie zabrać ("nie wiem, nie potrafię") i stąd opór wewnętrzny "po co? i tak nie będzie dokładnie"
  • ilość "nieznanego" jest tak przytłaczająca, że nie są w stanie wyartykułować zależności
  • duże rzeczy ciężko estymować ("Kobylion mandaysów?!"), więc trzeba dzielić na mniejsze ("Możesz ten kobylion rozbić na mniejsze części?")
  • estymaty mają sens przy ustalonych założeniach (najczęściej okazuje się, że założenia są odmienne od rzeczywistości) i trzeba przyjęte założenia jasno komunikować - dla swojego (i innych) dobra
  • estymaty pozawalają na starcie ubić głupie przedsięwzięcia (np. koszt zbyt duży wobec spodziewanego przychodu -> nie ma sensu realizować projektu)
  • samo ćwiczenia pozwala zarysować zakres prac (zgrubny, ale lepszy taki niż "nieokreślony") i bardzo wysokopoziomową architekturę logiczną -> uszczegóławiać w kolejnych iteracjach estymacji -> dobre narzędzie do wstępnego definiowania zakresu
2

@ProgScibi: Możesz dać takiego przykład takiego zadania?

@UglyMan: Jak pokryjesz karę za ujawnanie tajemnic to OK :P
A tak na poważnie np. kolega miał jeden task gdzie oprócz samej implementacji pewnego mechanizmu zapewniającego przejście spójne z podejścia A do B (i zachowac sensowność danych w bazie) trzeba było jeszcze zmierzyć jak taką spora migrację przeprowadzić, próbować na różne sposoby, kombinować np. z wielowątkowością. Innym przykładem może być np. aktualizacja zależności, często to może długo potrwać a jest to operacja atomowa (bo jak nie zrobisz pełnego update to aplikacja nie będzie działać). Nie oceniam czy takich zadań jest dużo, wiem że występują. No chyba że klepie się same formatki w React i PHP to może tak nie jest.

1

@ProgScibi: To, że coś nie dało się wykonać w ciągu 8 h nie znaczy, że nie mona tego robić na mniejsze zadania dla samej estymacji. Czyli jak masz taka migracje to i tak to robisz na pobieranie danych, wrzucanie, testy itp. Nie można zjeść słonia w całości, po kawałku już jak najbardziej. Dzięki takiemu rozbiciu zyskujesz ten lepszy obraz tego, co trzeba zrobić.

2

Tyle że są to czasem bardziej skomplikowane zadania i nie wiesz ile Ci zajmie. Nie wiesz ile razy będziesz musiał przerabiać cały proces, bo jednak tak jest nie efektywnie i trzeba zrobić inaczej. A nawet jeśli by się dało, to nie zawsze jest sens. Ale nikt Ci nie zabrania wiary w to że każde zadanie da się rozbic na <8h podzadania.

2
ProgScibi napisał(a):

Tyle że są to czasem bardziej skomplikowane zadania i nie wiesz ile Ci zajmie. Nie wiesz ile razy będziesz musiał przerabiać cały proces, bo jednak tak jest nie efektywnie i trzeba zrobić inaczej. A nawet jeśli by się dało, to nie zawsze jest sens. Ale nikt Ci nie zabrania wiary w to że każde zadanie da się rozbic na <8h podzadania.

Dlatego to się nazywa estymata a nie wycena. A przed takimi zadaniami robi się zadanie na kilka godzin na analizę i potem już wiesz co mniej więcej trzeba zrobić.

3
UglyMan napisał(a):

Dlatego to się nazywa estymata a nie wycena. A przed takimi zadaniami robi się zadanie na kilka godzin na analizę i potem już wiesz co mniej więcej trzeba zrobić.

A czasami analiza zajmuje 2 dni, a to już więcej niż 8h. :P

Ja np. jutro będę robił to samo, co robiłem dzisiaj - testował nowo zaimplementowany flow i naprawiał ad-hoc wszystkie błędy. To też jest niepodzielne zadanie.
Wiele razy już zadania zajmowały mi 2-3 dni. Nie wszystko jest podzielne, a dzielenie na siłę, na zasadzie jedno zadanie - jedna klasa, testy jednostkowe oddzielnie, i manualne oddzielnie to patologia.
No, tylko u nas się nie estymuje zadań lecz całe user story. I nie w godzinach.

2

U nas szacowanie wygląda inaczej niż w scrumie z obrazków. Przez kilka próbowaliśmy typowo scrumowego szacowania pojedynczych zadań w izolacji, wraz z uzasadnianiem czemu ktoś dał dużo mniejsze lub dużo większe oszacowanie niż inni. Było sporo niepotrzebnych dyskusji, krzywych wykresów, brandzlowania się liczbami, etc Teraz mamy inaczej:

  • planning co prawda jest dalej co tydzień, ale
  • nie mamy szacowania pojedynczych zadań
  • zamiast tego lider przydziela zadania ludziom i pyta czy się wyrobią ze swoimi zadaniami w tydzień, albo czy może im trochę czasu zostanie
  • jeśli ktoś twierdzi, że jest spora szansa, że się wyrobi ze swoimi zadaniami w mniej niż tydzień roboczy, to dokłada mu się kolejne zadanie
  • często ludzie się nie wyrabiają ze swoimi zadaniami i wtedy przenosi się je na następny tydzień (czyli następny sprint)
  • na planowaniu często jest biznes i na bieżąco pytami się ich jaki priorytet przydzielić zadaniom, a może niektóre zadania straciły priorytet i można je wrzucić do tzw. backlogu (dziwne amerykańskie określenie na kosz na śmieci)

Dzielenie zadania na mniejsze robi się z różnych powodów:

  • powodem może być brak zaufania ze strony biznesu czy architektów z wieży. Jeśli zespół jest nowy albo jeszcze nie udowodnił swoich zdolności rozwoju złożonych projektów, to biznes chciałby się tego dowiadywać raczej szybko. Siedzenie w jednym zadaniu dwa miesiące, przy braku zaufania/ reputacji/ etc, raczej zwiększy napięcia. Jeżeli natomiast zespół udowodnił swoje umiejętności, dowozi rzeczy w rozsądnych ramach czasowych, system od dłuższego działa względnie stabilnie i wydajnie, to biznes nie ma parcia na drobnostkową kontrolę i nieustanne przyglądanie się postępom prac.
  • powodem może sytuacja, w której kilkoro ludzi robi zmiany w tych samych miejscach i to powoduje konflikty na poziomie kodu źródłowego. Jeżeli wszyscy będą robić te zmiany długo to będzie dużo pracy z np. rebase'owaniem, usuwaniem konfliktów, synchronizacją zmian, etc Dzieląc zadania na mniejsze można np. szybko kończyć zmiany we wspólnych kawałkach kodu, a potem na spokojnie poświęcić więcej czasu na dłubanie w kodzie, w którym na razie inni nie grzebią.
1
somekind napisał(a):
UglyMan napisał(a):

Dlatego to się nazywa estymata a nie wycena. A przed takimi zadaniami robi się zadanie na kilka godzin na analizę i potem już wiesz co mniej więcej trzeba zrobić.

A czasami analiza zajmuje 2 dni, a to już więcej niż 8h. :P

Ja np. jutro będę robił to samo, co robiłem dzisiaj - testował nowo zaimplementowany flow i naprawiał ad-hoc wszystkie błędy. To też jest niepodzielne zadanie.
Wiele razy już zadania zajmowały mi 2-3 dni. Nie wszystko jest podzielne, a dzielenie na siłę, na zasadzie jedno zadanie - jedna klasa, testy jednostkowe oddzielnie, i manualne oddzielnie to patologia.
No, tylko u nas się nie estymuje zadań lecz całe user story. I nie w godzinach.

Super, że tak możesz - ale jak robisz dla klienta zewnętrznego to nie można sobie na coś takiego pozwolić, bo każda obsuwa może przechylić projekt w stronę tych nierentownych, co dla małej firmy może oznaczać koniec działalności.

7

@UglyMan: Miałem do napisania troszkę kodu, który miał coś pobierać z pewnego API. Zadanie nieskomplikowane, troszkę przetwarzania danych. Przed rozpoczęciem zadania nawet miałem dokumentację do API. Bułka z masłem - moja wycena 2 dni.
1 dzień - napisanie kodu i testów
2 dzień - ew. poprawki po code-review, deploy na staging i sprawdzenie czy na stagingu wszystko działa jak powinno.

Co się okazało?

  1. SOAP to jednak idzie jak krew w piach
  2. dokumentacja nie do tej wersji API, które nam udostępniono
  3. nowy pdf z dokumentacją okazuje się być niekompletny, bo od czasu napisania dokumentacji zmieniło się sporo
  4. dostawca API niektóre endpointy ograniczył firewallem i trzeba było się dopraszać o dopisanie do whitelisty
  5. na 10 requestow do API, średnio 3 miały timeout. Okazało się, że dostawca API miał jakieś problemy z infrastrukturą
  6. W jednym przypadku (odpowiednie parametry przekazywane do endpointa) rzucały całym javowym stacktrace'm (zgłoszone do klienta, nie wiem nawet co było popsute, ale naprawili na następny dzień)
  7. W tym samym przypadku co wyżej - okazało się, że zamiast pięknej 200, dostawaliśmy 400 i informację, że "Maybe some parameter is missing" (no piękne API ;P )
  8. Wszystko parametry ustawione - nawet miałem rozmowy we Frankfurcie na żywo z ich uber-mensch-sturm-develöperem i co? "No powinno działać - Ich glaube alle ist gut".

Jak skończyła się historia zadania na max 2 dni?

Okazało się, że istnieje jeden wymagany, nigdzie nie udokumentowany parametr, który nic nie robi, ale jest wymagany - ww. developer nawet sam powiedział, że on nie wie po co jest ten parametr, bo nigdzie go nie używają, ale dostał takie polecenie, zrobił i zapomniał gdziekolwiek to zapisać (oprócz kodu w aplikacji przy której pracował).

Ile dni realnie zajęło wszystko - około 20, akurat miałem co robić w międzyczasie, więc samego męczenia się z tym przestarzałym tworem wyszło mi 6~8 man days.

0
axelbest napisał(a):

@UglyMan: Miałem do napisania troszkę kodu, który miał coś pobierać z pewnego API. Zadanie nieskomplikowane, troszkę przetwarzania danych. Przed rozpoczęciem zadania nawet miałem dokumentację do API. Bułka z masłem - moja wycena 2 dni.

1 dzień - napisanie kodu i testów
2 dzień - ew. poprawki po code-review, deploy na staging i sprawdzenie czy na stagingu wszystko działa jak powinno.

Co się okazało?

  1. SOAP to jednak idzie jak krew w piach
  2. dokumentacja nie do tej wersji API, które nam udostępniono
  3. nowy pdf z dokumentacją okazuje się być niekompletny, bo od czasu napisania dokumentacji zmieniło się sporo
  4. dostawca API niektóre endpointy ograniczył firewallem i trzeba było się dopraszać o dopisanie do whitelisty
  5. na 10 requestow do API, średnio 3 miały timeout. Okazało się, że dostawca API miał jakieś problemy z infrastrukturą
  6. W jednym przypadku (odpowiednie parametry przekazywane do endpointa) rzucały całym javowym stacktrace'm (zgłoszone do klienta, nie wiem nawet co było popsute, ale naprawili na następny dzień)
  7. W tym samym przypadku co wyżej - okazało się, że zamiast pięknej 200, dostawaliśmy 400 i informację, że "Maybe some parameter is missing" (no piękne API ;P )
  8. Wszystko parametry ustawione - nawet miałem rozmowy we Frankfurcie na żywo z ich uber-mensch-sturm-develöperem i co? "No powinno działać - Ich glaube alle ist gut".

Jak skończyła się historia zadania na max 2 dni?

Okazało się, że istnieje jeden wymagany, nigdzie nie udokumentowany parametr, który nic nie robi, ale jest wymagany - ww. developer nawet sam powiedział, że on nie wie po co jest ten parametr, bo nigdzie go nie używają, ale dostał takie polecenie, zrobił i zapomniał gdziekolwiek to zapisać (oprócz kodu w aplikacji przy której pracował).

Ile dni realnie zajęło wszystko - około 20, akurat miałem co robić w międzyczasie, więc samego męczenia się z tym przestarzałym tworem wyszło mi 6~8 man days.

Jak byś wcześniej wziął zadanie na 4h na zrobienie POC i testów API to pewnie by to wyszło wcześniej i byś zaplanował to lepiej. Założyłeś, że cos niezależne od ciebie działa itp itd.

3

@UglyMan: przeniose sie tutaj:
Po 4h może i bym się dowiedział, że dokumentacja jest zła. Ale i tak do tej pory musiałbym przygotować dane które tam wysyłałem, więc już czas leci. Zakomunikowałbym po 4h, że dokumentacja jest zła i bym czekał do następnego dnia by dostać nową, która także była nikompletna. Problemów z infrastrukturą przy większym obciążeniu nie przewidziałbym.

Zatem chcesz mi powiedzieć, że Ty estymujesz najgorsze warianty, napisanie testów POC i masz max 4~8h... no spoko. W moim świecie jest to nierealne.

Tak czy siak - estymacje bywają zmylnicze i nie zawsze wszystko da się przewidzieć. Jest to tylko jakiś wyznacznik, któremu nie można ufać. Czym więcej czasu na analizę i poc, tym większy koszt. A jak koszt jest duży to i biznes jest w stanie dojść do etapu, w którym stwierdzi, że to jednak zbyt dużo będzie kosztować. Tak czy siak pieniądz przepalony.

0
axelbest napisał(a):

@UglyMan: przeniose sie tutaj:

Po 4h może i bym się dowiedział, że dokumentacja jest zła. Ale i tak do tej pory musiałbym przygotować dane które tam wysyłałem, więc już czas leci. Zakomunikowałbym po 4h, że dokumentacja jest zła i bym czekał do następnego dnia by dostać nową, która także była nikompletna. Problemów z infrastrukturą przy większym obciążeniu nie przewidziałbym.

Zatem chcesz mi powiedzieć, że Ty estymujesz najgorsze warianty, napisanie testów POC i masz max 4~8h... no spoko. W moim świecie jest to nierealne.

W projektach których nie znam staram się je rozbijać do małych zadań, a potem je wyceniać. Robie POCe jak nie jestem pewien, że wiem jak coś zrobić, dopiero wyceniam.

Czym więcej czasu na analizę i poc, tym większy koszt.

To nie jest prawda.

0
UglyMan napisał(a):

Super, że tak możesz - ale jak robisz dla klienta zewnętrznego to nie można sobie na coś takiego pozwolić, bo każda obsuwa może przechylić projekt w stronę tych nierentownych, co dla małej firmy może oznaczać koniec działalności.

Ale jaka obsuwa? Pisałem o podzielności zadań, nie o obsuwach.

0
DKN napisał(a):

Bywa ona przez wiele zależności nieprecyzyjna, a przez to zwodnicza.

Istotą szacowania jest jego niedokładność. Ważne, żeby wszyscy zainteresowani wiedzieli, że dane są wyssane z palca.

Podczas ostatnich dni dowiezienia wartości robi się zazwyczaj trytytkowanie, gdzie okłamujemy sami siebie, ze poprawi się później.

To dopychanie kolanem, kombinowanie jak przepchnąć dalej, czyli kopanie samego siebie w gluteus maximus - nie rozumiem. Alternatywnie, ktoś was skrzyczy (i to delikatnie, bo jak przesadzi to się przeniesiecie do konkurencji).

Oraz rzecz najważniejsza - dostarczenie dobrej wartości biznesowej jest lepsze niż dowiezienie ledwo działającej usługi o niskiej jakości technicznej.

Z punktu widzenia biznesu albo działa, albo nie działa. Dlatego trzeba pilnować swojego DoD.

Jak wy dealujecie z estymacja? Bo jedyne co to mając dobre DoD trzeba czasowo rozciągnąć dość mocno taska, przez co biznes zawsze jest smutniejszy, obarczając was winą..

Zależy od projektu. Na początek prosty przypadek - klient zewnętrzny, kontrakt podpisany, data oddania ustalona, kasa też. To po co tu cokolwiek estymować? Szkoda czasu na takie bzdury. Ktoś stwierdził, że bańka starczy na ten projekt i jedziemy.

Projekt "zwinny", nie ma sensu szacować całości, bo się jeszcze 500 razy zmieni zanim będzie koniec. Można jedynie szacować bieżącą pracę (kilka tygodni do przodu). Sens tego jest taki, że widać na ile zespół ogarnia projekt. Im trafniejsze szacunki, tym lepiej podzielone zadania, sensowniej opisane wymagania. Te 20% błędu będzie nawet w idealnym układzie, bo albo ktoś się szybciej upora z zadaniem, albo przeziębi i weźmie 3 dni wolnego. Co ważne - nie warto poświęcać dużo czasu na szacowanie. Błąd i tak będzie duży, więc jakieś zadania rozpoznawcze tak, ale takie nakierowane na rozpoznanie bojem problemu a nie określenie czy coś powinno zająć dzień, czy 2 tygodnie. W skrócie, tak jak poprzednio - nie ma sensu szacować. Te dane są zbyt niedokładne.

Jak biznes chce sobie wyciągać wnioski, to patrzy na dane historyczne (dane, a nie wróżby), ile zadań zostało zrobione w czasie X, liczy prędkość, przykłada do tego co zostało w backlogu do zrobienia i ma wszystko czego potrzeba.

0
somekind napisał(a):
UglyMan napisał(a):

Super, że tak możesz - ale jak robisz dla klienta zewnętrznego to nie można sobie na coś takiego pozwolić, bo każda obsuwa może przechylić projekt w stronę tych nierentownych, co dla małej firmy może oznaczać koniec działalności.

Ale jaka obsuwa? Pisałem o podzielności zadań, nie o obsuwach.

Jaki masz DOD w tym zadaniu? Skonsumowanie 3 dni na testy i poprawki?

1
UglyMan napisał(a):

Jaki masz DOD w tym zadaniu? Skonsumowanie 3 dni na testy i poprawki?

Nie mam DOD w zadaniu, mam AC w historyjce. W ogóle koncepcja DOD na poszczególne zadania to jakaś aberracja.

1 użytkowników online, w tym zalogowanych: 0, gości: 1