Story pointy - bezsens i robienie przedszkola

Śmieszy mnie gdy się zwraca uwagę, czy ktoś tu w ogóle czytał np Scrum Guide czy coś o Agile, a odpowiedź na to brzmi:

No ładnie w książce przeczytałeś. Nijak się to ma do rzeczywistości i tego w jaki sposób SP są używane.

Klasyczny Agile. W teorii inny w praktyce inny. Jak religia.

(biorę to jako reprezentację sceptyka tutaj)

To ładnie, że pracujecie w branży a nie macie jakiegokolwiek pojęcia, ani chociaż ciekawości przeczytać dokument na podstawie którego organizuje się prace w 99% firm z branży. Nie wiecie nic o tym jak powinniście pracować w modelu waszych organizacji i to z dumą, zapałem i fochem na całe te scrumy punkty agile i wymyślanie.

To ja się już nie dziwie, że są problemy

Jak dla mnie mają sens taki że przy taskach estymowanych na godziny można się czepiać że coś zajęło za dużo godzin, albo jeszcze gorzej - trzeba wypełniać timesheet i liczba godzin tasków ma się zgadzać w każdym miesiącu więc są w cholerę bardziej stresujące niż story pointy gdzie dwa podobne taski mogą mieć po 3 punkty i jeden zajmie 2 dni, drugi 4 i jest ok co jest bardziej ludzkim podejściem bo praktycznie nigdy nie da się z góry wyestymować taska co do godziny.

Poza tym dochodzi ludzka psychologia - zgodnie z zasadą Parkinsona - "jeżeli pracownik ma określony czas na wykonanie danego zadania, zadanie to zostanie wykonane w możliwie najpóźniejszym terminie" więc task wyceniony na 8 dni zajmie prawie na pewno 8 dni, a task wyceniony na 8 SP może zająć dużo mniej i ktoś będzie się jeszcze chwalił że "jebnął taska na 8 SP w 2 dni". Taki trochę element gamifikacji. Dlatego też w programach lojalnościowych zbieramy punkciki a nie grosiki mimo że zazwyczaj 1P=1gr to zarobienie 10 punktów brzmi mniej śmiesznie niż 10 groszy.

Czegoś tu nie rozumiem — nie macie wyliczanego velocity w pracy? Nie macie człowieka, któremu zależy, żeby to velocity było możliwie stałe pomiędzy sprintami?

Bo jeśli macie, to macie też estymację godzinową — każdy, nawet najgorszy programista umie podzielić te „bezjednostkowe” SP przez jednostkowe velocity, żeby wyznaczyć to, za to tak naprawdę będą go rozliczać, tj. za zrobienie odpowiedniej ilości pracy w danej jednostce czasu. Ilości pracy liczonej, być może, jako liczba storypointów na sprint, a nie bezpośrednio jako liczba zrealizowanych estymacjogodzin na godzinę… ale to jest przecież kwestia jednego dzielenia, żeby przetworzyć jedno na drugie. Jako, że sprinty trwają przecież tyle samo każdy, to storypointy to, po prostu, jednostka czasu. Tylko dziwna i niewygodna.

A jeśli nie macie… to po co tracić czas na szacowanie czegokolwiek? Można wpisać wszędzie 3, można wpisać wszędzie randint(1, 8). Bo… czemu nie?
W praktyce nie, bo velocity będzie szaleć i szefostwo będzie wkurzone, ale jak komuś nie liczą tego velocity i/lub nie pilnują jego przestrzegania… to w czym problem?

Dlaczego programista zapytał budowlańca, ile zajmie remont?

Bo chciałby zobaczyć, czy można oszacować czas, który zajmie mu unikanie estymacji zadań w pracy

Riddle napisał(a):

Estymacja tasków w jednostce czasu (godziny, dni, tygodnie) nie ma sensu i mija się z celem. Cały sens story pointów jest taki że to jest bezjednostkowa wartość. Mają służyć do tego żeby porównać skomplikowanie dwóch feature'ów (np 3 vs. 5) bez podania absolutnego czasu, obietnic, terminów czy deadline'ów, bo to w ogóle nie jest po to. Story pointy nie są po to żeby na ich podstawie szacować czas wykonania, i każdy kto prosi/wymaga jakiś czasowych estymacji stosuje faux-agile.

Tyle tylko, że i tak na koniec, w świecie rzeczywistym, liczy się czas wykonania. Co prawda w Scrumie (było nie było najpopularniejszej implementacji) doszło do redefinicji jednostek, tzn. zamiast wyceniać zadania w dniach, masz:

• SP jako jednostkę „skomplikowania” zadania - czyli inaczej pracochłonności
• sprint jako jednostkę czasu, łatwo przeliczalną na dni
• i to magiczne velocity, czyli SP/sprint

Czyli kiedyś po prostu sumowałeś godziny, a dzisiaj dzielisz liczbę SP przez velocity i zaokrąglasz do najbliższego okresu sprintowego. Takie podejście jest niesamowicie wadliwe (tzn. nie stoi w sprzeczności z samym Agile'em, po prostu nie działa), ale właśnie tak wygląda przeliczanie SP na czas.

Przy czym od estymacji czasowe nigdy nie uciekniesz, bo koniec końców nikogo nie obchodzi jak skomplikowane są zadania, tylko ile będzie to kosztowało i na kiedy.

wartek01 napisał(a):

Riddle napisał(a):

Estymacja tasków w jednostce czasu (godziny, dni, tygodnie) nie ma sensu i mija się z celem. Cały sens story pointów jest taki że to jest bezjednostkowa wartość. Mają służyć do tego żeby porównać skomplikowanie dwóch feature'ów (np 3 vs. 5) bez podania absolutnego czasu, obietnic, terminów czy deadline'ów, bo to w ogóle nie jest po to. Story pointy nie są po to żeby na ich podstawie szacować czas wykonania, i każdy kto prosi/wymaga jakiś czasowych estymacji stosuje faux-agile.

Tyle tylko, że i tak na koniec, w świecie rzeczywistym, liczy się czas wykonania. Co prawda w Scrumie (było nie było najpopularniejszej implementacji) doszło do redefinicji jednostek, tzn. zamiast wyceniać zadania w dniach, masz:

• SP jako jednostkę „skomplikowania” zadania - czyli inaczej pracochłonności
• sprint jako jednostkę czasu, łatwo przeliczalną na dni
• i to magiczne velocity, czyli SP/sprint

Czyli kiedyś po prostu sumowałeś godziny, a dzisiaj dzielisz liczbę SP przez velocity i zaokrąglasz do najbliższego okresu sprintowego. Takie podejście jest niesamowicie wadliwe (tzn. nie stoi w sprzeczności z samym Agile'em, po prostu nie działa), ale właśnie tak wygląda przeliczanie SP na czas.

Przy czym od estymacji czasowe nigdy nie uciekniesz, bo koniec końców nikogo nie obchodzi jak skomplikowane są zadania, tylko ile będzie to kosztowało i na kiedy.

W tej dyskusji pomijamy szerszy horyzont czasu. Co mam na myśli?

1. W krótszym horyzoncie chcemy wiedzieć ile zajmie wykonanie X (tak jak piszesz @wartek01 )
2. W dłuższym chcemy wiedzieć czy wykonanie X zajmuje więcej czy mniej czasu niż np. 6 miesięcy temu (to na co @Althorion wskazuje)

Althorion napisał(a):

Czegoś tu nie rozumiem — nie macie wyliczanego velocity w pracy? Nie macie człowieka, któremu zależy, żeby to velocity było możliwie stałe pomiędzy sprintami?

Bo jeśli macie, to macie też estymację godzinową — każdy, nawet najgorszy programista umie podzielić te „bezjednostkowe” SP przez jednostkowe velocity, żeby wyznaczyć to, za to tak naprawdę będą go rozliczać, tj. za zrobienie odpowiedniej ilości pracy w danej jednostce czasu. Ilości pracy liczonej, być może, jako liczba storypointów na sprint, a nie bezpośrednio jako liczba zrealizowanych estymacjogodzin na godzinę… ale to jest przecież kwestia jednego dzielenia, żeby przetworzyć jedno na drugie. Jako, że sprinty trwają przecież tyle samo każdy, to storypointy to, po prostu, jednostka czasu. Tylko dziwna i niewygodna.

Zasadnicze pytanie - po co?

Tak serio - jaki jest sens estymować czasowo zadanie? Weźmy konkretne powody na tapet. Opieranie się na estymatach czasowych to taki stary model produkcji trochę.

Moja teza brzmi: nic dobrego Ci nie dadzą estymaty czasowe - nie potrzeba ich, a mogą zaszkodzić. Możemy o tym porozmawiać

A jeśli nie macie… to po co tracić czas na szacowanie czegokolwiek? Można wpisać wszędzie 3, można wpisać wszędzie randint(1, 8). Bo… czemu nie?
W praktyce nie, bo velocity będzie szaleć i szefostwo będzie wkurzone, ale jak komuś nie liczą tego velocity i/lub nie pilnują jego przestrzegania… to w czym problem?

Szefostwo będzie złe, to prawda - chyba że szefostwo też jest Agile, i rozumie że lepiej dowozić rzeczy iteratywnie zamiast estymować.

Ilekroć pojawia się temat story pointów i estymowania emocje sięgają zenitu jak na koncercie Martyniuka w Ciechocinku...

Na pytanie "kiedy zostanie dostarczony system", agile nie daje odpowiedzi innej niż "jak zrobimy, to będzie". Jest to oczywista wada tego podejścia w porównaniu do waterfall. A raczej byłaby, gdyby waterfall nie kłamał. W przypadku software development w tej chwili nie ma sposobu na uzyskanie dokładnych odpowiedzi na pytania:

• Kiedy to będzie?
• Ile to będzie kosztować?
• Czy uda się to zrobić?

Przykład - chcemy zrobić porównywarkę ubezpieczeń, coś jak Rankomat, jesteśmy wstępnie dogadani z 10 różnymi ubezpieczalniami, więc do napisania jest:

• frontend
• API gateway
• backend
• 10 różnych integracji
  Zespół liczy 5 osób, biznes pyta ile to zajmie - ktoś jest chętny, żeby na podstawie tych danych dać wiążącą odpowiedź?

W przypadku waterfall, zostałby zrobiony WBS, zadania podzielone jak komuś tam się w głowie ułożyło, poukładane w szereg zależnych od siebie makro zadań i wyssane z palca, przepraszam z doświadczenia szacunki.
Podejście zwinne proponuje inne rozwiązanie - zidentyfikujmy absolutne MVP, czyli zakres, który pozwoli z jednej strony mieć działającą podstawową funkcjonalność, z drugiej da okazję na zmierzenie się z największymi obawami i ryzykiem., czyli definiujemy najprostszy możliwe rozwiązanie, które pozwoli użytkownikowi wprowadzić zapytanie i uzyskać chociaż jedną ofertę dla jednego typu produktu ubezpieczeniowego. Niech będzie NNW (nie robiłem za dużo w ubezpieczeniach, to wydaje mi się najprostsze).
Odpalamy projekcik na powiedzmy miesiąc i robimy.
Możliwe rezultaty, to:

• udało się zrobić
• nie udało się zrobić
  Pokazujemy biznesowi z komentarzem "5 ludzi, w miesiąc zrobiło to co widzisz, zapłacisz za więcej, czy kończymy?".Jak jest za mało, to zwijamy projekt, jak klient jest zadowolony, to ponawiamy iterację.

Dlaczego nie ma tutaj story pointów? Bo są na tym poziomie absolutnie niepotrzebne. W story pointach wycenia się drobnoziarniste historyjki typu "dodaj do formularza dodatkowe pole", może "przygotuj formularz z 10 polami". Podzielenie całego projektu na takie historyjki to kilka tygodni, przygotowanie designu UI, całej, szczegółowej dokumentacji, przejrzenia wszystkich API, które mają zostać zintegrowane itd. Czyli realnie, będzie kosztować więcej niż przygotowanie MVP, zespół po miesiącu dyskusji czym jest SP, dlaczego trzeba oszacować jakieś zadanie, chociaż nie ma do tego żadnych danych, ani nawet zakresu będzie potrzebować kolejnego miesiąca na zaleczenie traumy, a uzyskane szacunki nie będą miały żadnego oparcia w danych, bo nie napisano nawet linijki kodu.

Możliwym rozszerzeniem metody agile są szacunki "koszulkowe", dalej na wysokim poziomie, czyli przed przystąpieniem do tego MVP dzielimy zakres na średno-duże fragmenty, np. "integracja z towarzystwem A", "implementacja API gateway dla UI", "przygotowanie kolejek dla zapytań". Ponieważ nie mamy pojęcia ile będzie trwało każde z takich zadań, nie szacujemy w czasie/pieniądzach, tylko używamy relatywnej skali jak rozmiary koszulek, kolory smoków z hirołsów, Takie jednostki nie tylko nie przekładają się w momencie szacowania na czas, ale również nie znamy ich wzajemnych relacji (nie wiemy, czy XL'ka to 5, czy 50 S'ek). Jeżeli będziemy mierzyć pracę poświęconą na wykonanie tych kawałków, to dość szybko zaczną nam się wyłaniać wartości w roboczogodzinach, relacje pomiędzy koszulkami itd. Po miesiącu pracy zespołu będziemy w stanie stworzyć pięknego excela dla biznesu z wykresem pokazującym, na podstawie niepełnych, ale jednak danych jaki jest przewidywany czas/koszt ukończenia całego projektu. W kolejnych iteracjach dane stają się szersze, a backlog krótszy, co przekłada się na większą wiarygodność i mniejszą niepewność.

Dopiero te duże bloki "koszulkowe" trafiają na refinement, gdzie zespół dzieli je na historyjki, które mogą zostać wycenione w SP. Jeżeli zostaną porządnie podzielone, to ich koszt będzie bardzo zbliżony do siebie, a wielkość na poziomie atomu (niegdyś uważanego za niepodzielny). Pisałem już wcześniej, że SP nie mają sensu, ale przyznam się, że w swoich zespołach je stosuję Powody, to:

• Wiem, że zespół, który jest w stanie oszacować jakieś zadanie przeczytał je i wie o co w nich chodzi.
• Mamy okazję pomyśleć, czy jakieś zadanie nie jest za duże i czy nie powinno zostać podzielone na kawałki.
• Widać niepewność. W przypadku integracji z zewnętrznym API, do którego jeszcze nie ma dokumentacji dostanę odpowiedź "wygląda na pierdołę, ale równie dobrze możemy się z tym bujać rok".
• Można mierzyć velocity.

Velocity ma znaczenie nie ze względu na jakiekolwiek szacunki, natomiast daje sygnał o kondycji zespołu i kulturze pracy. Jeżeli zmienność jest wysoka, to znaczy, że coś jest nie tak ze sposobem pracy jaki stosujemy. Dodatkowy plus, to można przewidzieć następne kilka tygodni i pilnować zdefiniowania historyjek na najbliższy czas.

Dodam jedynie, że praktyki typu:

• Rozliczanie zespołu z liczby wytworzonych w sprincie SP.
• Ocenianie poszczególnych członków zespołu z wytworzonych SP.
• Programy naprawcze, bo miało być 50SP, a jest 48SP.
• Burze z powodu tego, że ktoś miał zamknąć zadanie w piątek, a zamknął w poniedziałek i to już był kolejny sprint.
  Uważam za kompletną patologię i proszenie się o kłopoty, a w rezultacie sprawienie, że ludzie albo odejdą, albo się dostosują i metryki się zgadzają, a projekt leży na ziemi.

Riddle napisał(a):

Zasadnicze pytanie - po co?
Tak serio - jaki jest sens estymować czasowo zadanie? Weźmy konkretne powody na tapet. Opieranie się na estymatach czasowych to taki stary model produkcji trochę.

Bo w biznesie wszystko się liczy wg czasu — wg czasu rozlicza się pracowników (płacąc im pensję co miesiąc, a nie co xyz zaimplementowanych feature’ów), wg czasu się planuje projekty (kiedy zabrać się za następny? Jak długo zapewniać wsparcie?), wg czasu planuje się zatrudnianie/zwalnianie pracowników, wg czasu tworzy się wyceny, wg czasu przygotowuje raporty finansowe…

Jeśli zespół nie jest w stanie odpowiedzieć, czy daną usługę będzie realizował rok, dwa, czy półtora, to nie sposób tego przetłumaczyć na potrzebne zasoby. Nie wiadomo, ile to będzie kosztować, nie wiadomo, jak i czy zatrudniać kogoś dodatkowego, nie wiadomo, czy i kiedy zacząć się rozglądać za kolejnym kontraktem, nie wiadomo nic.

I nawet, jak nasze szefostwo jest bardzo agile, i woli „dowozić iteratywnie”, to reszta świata nie jest. Jak ktoś kupuje customowy sklep internetowy, to musi wiedzieć, kiedy będzie działał, bo od tego zależy, od kiedy będzie potrzebował ludzi do obsługi, towar na magazynach, całą resztę zaplecza. Jak ktoś rozpisuje kontrakt na oprogramowanie, to musi wiedzieć, kiedy je dostanie, bo od tego zależy, od kiedy musi mieć serwerownię, administratorów, resztę zaplecza. Jak robimy coś in-house, to też szefostwo musi wiedzieć, kiedy będzie, bo od tego zależy, kiedy rozpocząć działania marketingowe i jakie, żeby nie wypalić przedwcześnie ani nie zrobić nic za późno.

No i nawet, jak żadna z tych rzeczy nie zachodzi, to wciąż pozostaje ta kwestia, że ludziom się regularnie płaci pensje, czy można na ich oprogramowaniu zarabiać, czy jeszcze nie. Więc chce się wiedzieć, czy będzie się to jeszcze robić krótko, czy długo. Nikt nie jest na tyle cierpliwy i wyrozumiały, żeby mu było wszystko jedno, czy projekt przejdzie do następnej fazy za miesiąc, czy za pięć lat…

Moja teza brzmi: nic dobrego Ci nie dadzą estymaty czasowe - nie potrzeba ich, a mogą zaszkodzić. Możemy o tym porozmawiać

Moja jest taka — estymaty czasowe to jedyne estymaty, które są komukolwiek z zewnątrz potrzebne do czegokolwiek. Jak je będą mieli, to mogą sobie wyliczyć i zaplanować całą resztę; jak ich nie mają, to nie mogą wyliczyć i zaplanować nic. Jeśli więc oprogramowania się nie robi dla samych siebie, takiej trochę „sztuki dla sztuki” — a prawie nigdy, poza open source, tak nie jest — to bez wyliczania, budżetowania, i planowania następnych faz nic się nie osiągnie.

A nawet jeśli, to przecież SP to są estymaty czasowe. Tak jak pisałem wyżej — jest velocity, gdzie nas pilnują, żeby było możliwie niezmienne, i długość sprintu, która jest niezmienna, więc z tego wychodzi, przez proste dzielenie, ile wypada czasu na każdy SP. A jak nas nie pilnują, żeby velocity było niezmienne, to możemy sobie zaoszczędzić czasu i wysiłku, wpisując SP dowolnie, bo czemu nie? Estymacja czasowa całkowicie od tego wybuchnie… ale skoro się upieramy, że to nie problem, to co jest problemem?

Althorion napisał(a):

Bo w biznesie wszystko się liczy wg czasu — wg czasu rozlicza się pracowników (płacąc im pensję co miesiąc, a nie co xyz zaimplementowanych feature’ów), wg czasu się planuje projekty (kiedy zabrać się za następny? Jak długo zapewniać wsparcie?), wg czasu planuje się zatrudnianie/zwalnianie pracowników, wg czasu tworzy się wyceny, wg czasu przygotowuje raporty finansowe…

Agile sugeruje, że biznes powinien określić cel, regularnie sprawdzać postępy rzeczywistego projektu, po każdej iteracji produkt powinien być lepszy. Wiem, że to nie jest wygodna informacja, ale prawdziwa. Nawet szacując kopanie rowu melioracyjnego, może się okazać, że po drodze przetniemy jakiś nieudokumentowany kabel, albo natkniemy się na niewypał.

Jeśli zespół nie jest w stanie odpowiedzieć, czy daną usługę będzie realizował rok, dwa, czy półtora, to nie sposób tego przetłumaczyć na potrzebne zasoby. Nie wiadomo, ile to będzie kosztować, nie wiadomo, jak i czy zatrudniać kogoś dodatkowego, nie wiadomo, czy i kiedy zacząć się rozglądać za kolejnym kontraktem, nie wiadomo nic.

Zespół nie jest w stanie odpowiedzieć na to pytanie. SP w scrum istnieją w perslektywie 2-3 sprintów, bo w takiej perspektywie robi się refinementy. Softwarehouse'y muszą dawać takie wyceny i w rezultacie schodzą z ceną tak nisko, aż przy którymś projekcie przegną.

Moja jest taka — estymaty czasowe to jedyne estymaty, które są komukolwiek z zewnątrz potrzebne do czegokolwiek. Jak je będą mieli, to mogą sobie wyliczyć i zaplanować całą resztę; jak ich nie mają, to nie mogą wyliczyć i zaplanować nic. Jeśli więc oprogramowania się nie robi dla samych siebie, takiej trochę „sztuki dla sztuki” — a prawie nigdy, poza open source, tak nie jest — to bez wyliczania, budżetowania, i planowania następnych faz nic się nie osiągnie.

Ponieważ estymaty to tylko estymaty tak je należy traktować, planując odpowiednie bufory czasowe/funkcjonalne/budżetowe. Jeżeli założysz, że w projekcie za bańkę i za rok powstanie dokładnie wyspecyfikowana funkcjonalność, to na 100% się pomylisz. Musisz mieć możliwość przesunięcia terminu | redukcji zakresu | dołożenia kolejnych ludzi. Oczywiście możesz i powinieneś wykonać szacunki, ale jednocześnie masz obowiązek założyć, że będą znaczne odstępstwa od tego planu.
Apple - nie podają terminów i zakresu do momentu aż jest zrobione.
CDPR podał kiedy będzie CP2077 i był. Efekt komentował szeroko cały świat, a akcje spadły o 60% Błędy wynikające z ogłoszonych na podstawie szacunków terminów i zakresu naprawiano przez 2 lata. Gdyby ograniczyli zakres / przesunęli premierę, to kosztowałoby ich to więcej, ale zarobiliby również więcej.

A nawet jeśli, to przecież SP to są estymaty czasowe. Tak jak pisałem wyżej — jest velocity, gdzie nas pilnują, żeby było możliwie niezmienne, i długość sprintu, która jest niezmienna, więc z tego wychodzi, przez proste dzielenie, ile wypada czasu na każdy SP. A jak nas nie pilnują, żeby velocity było niezmienne, to możemy sobie zaoszczędzić czasu i wysiłku, wpisując SP dowolnie, bo czemu nie? Estymacja czasowa całkowicie od tego wybuchnie… ale skoro się upieramy, że to nie problem, to co jest problemem?

SP nie jest szacunkiem czasu. SP rodzi się na początku iteracji i w tym momencie nie wiadomo jaką wartość przyjmie na jej koniec. Przeliczenia na czas dokonujesz po fakcie, a nie przed. Możesz zrobić sobie projekcję na już zdefiniowane i wycenione zadania, ale nadal:

• nie masz pewności, że efektywność zespołu się nie zmieni
• robisz to w krótkiej perspektywie czasowej, która nikomu nie jest do niczego potrzebna

piotrpo napisał(a):

Agile sugeruje, że biznes powinien określić cel, regularnie sprawdzać postępy rzeczywistego projektu, po każdej iteracji produkt powinien być lepszy. Wiem, że to nie jest wygodna informacja, ale prawdziwa. Nawet szacując kopanie rowu melioracyjnego, może się okazać, że po drodze przetniemy jakiś nieudokumentowany kabel, albo natkniemy się na niewypał.

OK, tylko… nie wiem, jak się to ma do tematu. Biznes powinien określić cel, powinien regularnie sprawdzać postępy, produkt powinien się ulepszać. Ale biznes wciąż potrzebuje wiedzieć, czy może sklep internetowy wystawić światu za miesiąc, dwa, czy za rok; potrzebuje wiedzieć, czy automatyczne wózki widłowe będą dostępne za rok, dwa, czy pięć; potrzebuje wiedzieć, czy reklamować nową wersję oprogramowania już teraz, czy z tym poczekać. Czas jest tutaj wszystkim. Praktycznie nikt nie ma na niego kompletnie wyłożone, i jak odpowiedź będzie „jak zrobimy; może będzie za tydzień, a może za dziesięć lat”, to sobie pójdzie gdzie indziej.

I podobnie z samymi programistami — jak podpisujesz umowę, to chcesz wiedzieć, że będziesz mieć pensję płaconą co miesiąc, a nie co 40 koszulek; że będziesz miał 28 dni urlopu, a nie 15 kwiatuszków; i że rozpoczniesz ją pierwszego marca, a nie za 200 storypointów. I chociażby to, samo z siebie, powoduje, że estymacja czasowa po prostu być musi.

Zespół nie jest w stanie odpowiedzieć na to pytanie. SP w scrum istnieją w perslektywie 2-3 sprintów, bo w takiej perspektywie robi się refinementy. Softwarehouse'y muszą dawać takie wyceny i w rezultacie schodzą z ceną tak nisko, aż przy którymś projekcie przegną.

Zespół musi być w stanie odpowiedzieć na to pytanie. „No może zrobimy, chyba że nie zrobimy, a nawet jak już, to nie wiemy na kiedy” to po prostu nie jest dopuszczalna odpowiedź. Podobnie jak nie jest nią „no może dostaniecie pensję, chyba że nie dostaniecie, a nawet jak tak, to nie wiemy kiedy”. Oczywiście, błędy i pomyłki się zdarzają, zdarzają się niedoszacowania, przeszacowania, nieprzewidywalne problemy; ale jakieś oszacowania być muszą, bo wg tego się planuje.

Moja jest taka — estymaty czasowe to jedyne estymaty, które są komukolwiek z zewnątrz potrzebne do czegokolwiek. Jak je będą mieli, to mogą sobie wyliczyć i zaplanować całą resztę; jak ich nie mają, to nie mogą wyliczyć i zaplanować nic. Jeśli więc oprogramowania się nie robi dla samych siebie, takiej trochę „sztuki dla sztuki” — a prawie nigdy, poza open source, tak nie jest — to bez wyliczania, budżetowania, i planowania następnych faz nic się nie osiągnie.

Ponieważ estymaty to tylko estymaty tak je należy traktować, planując odpowiednie bufory czasowe/funkcjonalne/budżetowe. Jeżeli założysz, że w projekcie za bańkę i za rok powstanie dokładnie wyspecyfikowana funkcjonalność, to na 100% się pomylisz. Musisz mieć możliwość przesunięcia terminu | redukcji zakresu | dołożenia kolejnych ludzi. Oczywiście możesz i powinieneś wykonać szacunki, ale jednocześnie masz obowiązek założyć, że będą znaczne odstępstwa od tego planu.

A jak nie założę nic, to też się pomylę. Przy czym jak podam datę „za rok” i wyjdzie „za półtora roku”, to się pomylę o 50%; a jak nie powiem nic, i wyjdzie „za półtora roku”, to pomyłka jest nieskończona.

SP nie jest szacunkiem czasu. SP rodzi się na początku iteracji i w tym momencie nie wiadomo jaką wartość przyjmie na jej koniec. Przeliczenia na czas dokonujesz po fakcie, a nie przed. Możesz zrobić sobie projekcję na już zdefiniowane i wycenione zadania, ale nadal:

• nie masz pewności, że efektywność zespołu się nie zmieni
• robisz to w krótkiej perspektywie czasowej, która nikomu nie jest do niczego potrzebna

SP jest szacunkiem czasu, bo istnieje velocity i zespoły są rozliczane z tego, żeby było ono stałe. A skoro velocity to miara zrealizowanych SP w sprincie i jest stałe, zaś sprint jest stałej długości, to z konieczności SP jest miarą czasu.
Przeliczenia na czas dokonuje się przed zakończeniem projektu, bo po zakończeniu projektu to już nikogo nie obchodzi — łatwiej sobie odjąć datę rozpoczęcia od daty zakończenia. A przed faktem trzeba wiedzieć, ile będzie to kosztować (więc i ile roboczogodzin na to pójdzie), na kiedy dograć inne elementy, i mieć jakiekolwiek pojęcie, na czym się stoi.

Pewności, oczywiście, nie ma — w końcu to estymata. Ale daje to jakieś pojęcie, o czym mówimy. Umożliwia planowanie.

tl;dr;

• Jeśli nie jest agile (pracujesz tak jak biznes chce, z planowaniem) - to absolutnie story pointy nie mają żadnego sensu.
• Jeśli jesteś Agile - to story pointy, brak szacowania, brak planowania, ma sens.

Odpowiedź:

@Althorion Bardzo się cieszę że odpisałeś w taki racjonalny, spokojny sposób. Już odpowiadam.

Althorion napisał(a):

Riddle napisał(a):

Zasadnicze pytanie - po co?
Tak serio - jaki jest sens estymować czasowo zadanie? Weźmy konkretne powody na tapet. Opieranie się na estymatach czasowych to taki stary model produkcji trochę.

Bo w biznesie wszystko się liczy wg czasu — wg czasu rozlicza się pracowników (płacąc im pensję co miesiąc, a nie co xyz zaimplementowanych feature’ów), wg czasu się planuje projekty (kiedy zabrać się za następny? Jak długo zapewniać wsparcie?), wg czasu planuje się zatrudnianie/zwalnianie pracowników, wg czasu tworzy się wyceny, wg czasu przygotowuje raporty finansowe…

Bo w biznesie _wszystko_ się liczy wg czasu to jest jedno z (moim zdaniem) błędnych założeń, i należy się go wyzbyć, jak chce się być agile.

No okej, czyli to co opisałeś to taki "standardowy" sposób biznesowy na wytwarzanie oprogramowania, i rozumiem go. Ma swoje zalety, tylko jest jeden problem z nim. On zakłada że da się coś wyestymować - że programista/programiści popatrzą na task/zadanie, i będą potrafili powiedzieć ile zajmie dowiezienie go - i niestety często nie potrafią :/ "Estimate" to jest po prostu mądre słowo na "zgadywanie". Statystyki z wielu projektów pokazują że estimate'y dot. oprogramowania mylą o 4x w jedną lub drugą stronę (czyli estimate na 28 dni, może zając 7, lub 112 dni, statystycznie). Moim zdaniem sporym problemem jest to że "ludzie u góry" domagają się pewności, od ludzi którzy nie mogą jej dać - manager nade mną "ile zajmie to zadanie, dokładnie?" - "nie wiem" - "to wyestymuj" (czyli zgadnij). Programiści wtedy wpadają w taką pułapkę, i zgadują ile może coś zająć, i taki manager potem snuje plany na podstawie danych które mogą się okazać (i często się okazują) nie prawdziwe. Ile razy programisci się spóźniali i mówili "aa, bo się okazało że to jest bardziej skomplikowane". To jest właśnie to - to nie jest przez niewiedzę, tylko przez to że nikt nie jest dobry w zgadnięcie ile coś zajmie. Trzeba po prostu spróbować zacząć coś zrobić, i minimalizować konsekwencje - małe iteracje.

Można powiedzieć że Agile to jest sposób na minimalizowanie konsekwencji wynikających z działania kiedy nie mamy pewności (czyli małe iteracje, feedback od klienta.

Jak idziesz do dentysty albo do taksówki i pytasz "ile czasu zajmie to kanałowe" albo "ile czasu do centrum", to oni Ci odpowiedzą, nie dlatego że estymują, tylko dlatego że robili to samo już setki razy, i pamiętają ile to zajęło. Z wytwarzaniem oprogramowania jest inaczej - zawsze robimy coś nowego, więc nie wiemy ile to zajmie.

To teraz odpowiem na wszystkie rzeczy po kolei:

Althorion napisał(a):

Jeśli zespół nie jest w stanie odpowiedzieć, czy daną usługę będzie realizował rok, dwa, czy półtora, to nie sposób tego przetłumaczyć na potrzebne zasoby. Nie wiadomo, ile to będzie kosztować, nie wiadomo, jak i czy zatrudniać kogoś dodatkowego, nie wiadomo, czy i kiedy zacząć się rozglądać za kolejnym kontraktem, nie wiadomo nic.

I nawet, jak nasze szefostwo jest bardzo agile, i woli „dowozić iteratywnie”, to reszta świata nie jest. Jak ktoś kupuje customowy sklep internetowy, to musi wiedzieć, kiedy będzie działał, bo od tego zależy, od kiedy będzie potrzebował ludzi do obsługi, towar na magazynach, całą resztę zaplecza. Jak ktoś rozpisuje kontrakt na oprogramowanie, to musi wiedzieć, kiedy je dostanie, bo od tego zależy, od kiedy musi mieć serwerownię, administratorów, resztę zaplecza. Jak robimy coś in-house, to też szefostwo musi wiedzieć, kiedy będzie, bo od tego zależy, kiedy rozpocząć działania marketingowe i jakie, żeby nie wypalić przedwcześnie ani nie zrobić nic za późno.

No i nawet, jak żadna z tych rzeczy nie zachodzi, to wciąż pozostaje ta kwestia, że ludziom się regularnie płaci pensje, czy można na ich oprogramowaniu zarabiać, czy jeszcze nie. Więc chce się wiedzieć, czy będzie się to jeszcze robić krótko, czy długo. Nikt nie jest na tyle cierpliwy i wyrozumiały, żeby mu było wszystko jedno, czy projekt przejdzie do następnej fazy za miesiąc, czy za pięć lat…

Bo zadałem pytanie "po co komu estymaty", i pozwolę sobie podsumować w punktach Twoją odpowiedź:

• "według czasu rozlicza się pracowników"
• "według czasu planuje się projekty"
• "według czasu planuje się zatrudnianie i zwalnianie pracowników"
• "według czasu tworzy się wyceny"
• "według czasu przygotowuje się raporty finansowe"
• "przetłumaczenie projektu na potrzebne zasoby"
• "oszacowanie kosztu"
• "czy zatrudnić kogoś nowego"
• "czy złapać nowy kontrakt"
• "informacja dla klienta kiedy coś będzie gotowe"
• "kiedy rozpocząć działania marketingowe"
• "wiedza dla managementu ile trzeba będzie płacić pracownikom za ich pracę, przed wydaniem softu".
• "cierpliwośc czy projekt będzie za miesiąc czy za pięć lat".

Rozumiem wszystkie te argumenty - są bardzo sensowne, i moim zdaniem, do żadnej z tych rzeczy nie potrzebujesz estymate'ów czasowych (bo moja teza brzmi że "estimate" == "zgadywanie"). Postaram się odpowiedzieć na nie wszystkie.

• "według czasu rozlicza się pracowników"

  • W Agile projektach po prostu ludziom się płaci na etacie, 8h dziennie, przez 21 dni w miesiącu. Nie widzę powodu czemu estymowanie zadań miałoby w tym pomóc.
  • Jeśli ktoś jest kontraktorem, to płaci mu się za przepracowany czas. Co jeśli ktoś ma mały budżet? Patrz punkt niżej.

• "według czasu planuje się projekty"

  • Odpowiedź Agile na "planowanie projektu" jest bardzo prosta. Agile mówi: nie ma potrzeby planować projektu. To jak to wygląda: bierzesz osobę lub zespół, dajesz im projekt, i oni robią najmniejszą, najprostszą możliwą rzecz jaką mogą zrobić i wdrożyć na środowisko testowe lub od razu na produkcję, robią coś co można przygotować w dzień lub kilka dni. Pierwsza wersja można powiedzieć że jest "zdegenerowana", sam basic feature, bez architektury, bez bibliotek, bez frameworków, basic hello world, który robi tylko i wyłącznie jedną, najprostszą, najgłupszą rzecz którą klient chce. Zaczynają od najważniejszej rzeczy. Czyli to wygląda tak, że jak duża firma X chce zbudować powiedzmy kopię Netflixa, na którym ma się dać oglądać filmy, to zespuł buduje głupią stronę na której jest tylko lista filmów, i jeszcze nie da się nic oglądać, i wrzuca na środowisko (testowe, staging, uat albo prod, zależy jak klient chce). Klient potem patrzy na tą apkę, i daje feedback. Owszem - strona nie działa, nie da się oglądać filmów, ale to nic. Klient patrzy, i daje feedback, programiści go zbierają. Nikt nie zakłada że oprogramowanie jest gotowe i nikt nie zakłada że wiedzą co robią, klient też tego nie wie. Jest to dosyć nieprzyjemne, ale w Agile wszyscy biorący udział w projekcie muszą mieć mindset "nie wiem co robię, to jest początek projektu, nikt nie wiem jak on będzie wyglądał, spróbujmy małą rzecz, zobaczmy co z niej wyjdzie, jak się nie uda, to stracimy mały - minimalizujmy konsekwencję niewiedzy". Programiści zbierają feedback od klienta, i spędzają kolejny dzień, dwa, trzy na nowej wersji, i tym razem np dodają drugi najważniejszy feature (skąd wiedzą który jest najważniejszy, klient im powiedział w feedbacku), to możę być lajkowanie filmów, to może być logowanie, to może być faktyczne oglądanie filmów, etc.) Poświęcają max jeden,dwa, trzy dni na dostarczenie tego, i znowu pokazują klientowi. Produkt oczywiście nadal nie jest gotowy, ale klient otwiera stronę, i patrzy czego mu tam brakuje. W dowolnym momencie klient możę powiedzieć "porzucamy projekt", w dowolnym momencie klient może powiedzieć "potrzebujemy jeszcze zmian", i w dowolnym momencie klient może powiedzieć "nie potrzebujemy więcej zmian, jest dobrze tak jak jest". Nie ma powodu żeby znać "przyszłość" i estymować (pod tym względem). Jeśli klient zlecił oglądanie filmów, to programiści starają się to dostarczyć w te 1-3 dni, jeśli im się nie udaje, to muszą zrobić coś co trochę przypomina oglądanie filmów, np pokazanie miniaturku. To nie jest to co klient chciał, ale nie mogą z tym nic zrobić - nie wyrobią się tak w 3 dni. Więc pokazują klientowi wersje z miniaturkami bez filmów, i mówią "tyle zrobiliśmy". Klient mówi "ale miały być filmy", programiści mówią: "musieliśmy dodać wgrywanie obrazków, nie udało nam się tego tak zrobić", daliśmy Ci miniaturki. Klient mówi; "muszą być filmy", programiści zaczynają pracę, i tym razem powiedzmy udaje im się zahardkodzić film tak że można oglądać tylko jeden, przychodzą do klienta i pokazują mu. Klient jest zadowolony. I tak dalej. Zbierają feedback od klienta, klient mówi: "dobra, to teraz zróbcie żeby dało się lajkować film", i programiści zaczynają pracę nad lajkami, i wracają znowu za 1-2 dni. Powiedzmy że da się lajkować, ale nie mieli czasu zrobić "odlajkowywania" (nie napisali ifów i testów pod odlajkowanie). Klient mówi że to spoko, bo i tak nie chce odlajkowania. Klient daje kolejny feedback, i programiści go robią - powtórz.

• "według czasu tworzy się wyceny"

  • @Althorion Tutaj chodzi o wycenę pensji dla programistów, czy chodzi o to za ile sprzedać gotowy soft?

• "według czasu przygotowuje się raporty finansowe"

  • @Althorion Tego też nie do końca rozumiem, mógłbyś lepiej wyjaśnić w jaki sposób estimate'y poszczególnych zadań mają być potrzebne do takiego raportu?

• "przetłumaczenie projektu na potrzebne zasoby"

  • To samo co z programistami - nie potrzebujesz tłumaczyć czasu na potrzebne zasoby, bo w każdym jednym momencie widzisz aktualny progress, więc można na to reagować na bieżąco. To właśnie znaczy agile w słowie agile. Agile znaczy "zwinny", dosłownie - czyli nie planujesz, tylko reagujesz.

• "oszacowanie kosztu"

  • W Agile nie ma potrzeby szacować kosztów, bo w dowolnym momencie można powiedzieć "stop, nie pracujemy więcej". Zaczynamy projekt od jednej iteracji, jeden/dwa/trzy dni, więc w najgorszym wypadku stracisz kasę na kilka dni. Jak chcesz rozwijać produkt dalej, to zapłać za jedną iteracje, i dostaniesz nową wersję, która jest trochę bliżej tego co chcesz. Zaczynamy od najważniejszych rzeczy, więc jak już się zrobi najważniejszą rzecz, to klient widzi że ona już jest zrobiona - mamy działający software, więc nie ma już niepewności z tym związanej.

• "czy zatrudnić kogoś nowego"

  • To jest decyzja managementu, i nie wymagają do tego estimate'ów od programistów. Projekt się zaczyna, programisci robią kilka iteracji, oddają nową wersję po 1/2/3 dniach, i management sam widzi jakie zmiany udało się wdrożyć przez te trzy dni. Może podjąć decyzję, czy chce dopłacić więcej do projektu czy mniej. Sam zatrudniałem programistów do takich zespołów, i nie musiałem znać "estimate'ów czasowych" takich zadań.

• "informacja dla klienta kiedy coś będzie gotowe"

  • Klient nie potrzebuje wiedzieć kiedy coś będzie gotowe, bo po pierwsze: cały czas widzi aktualną wersję, która wychodzi codziennie, albo co kilka dni (w najgorszym wypadku co tydzień albo dwa). Każdego nowego dnia wchodzi na stronę, i bardzo szybko widzi zmiany.
    • Co jak klient się domaga terminów? Należy mu odpowiedzieć: "nie wiemy kiedy to będzie gotowe, ale damy Ci najważniejszy feature za kilka dni i możesz sam ocenić".

• "kiedy rozpocząć działania marketingowe"

  • To klient musi sam zdecydować, na podstawie tego co widzi w gotowym produkcie. Estimate'y (czyli zgadywania) programistów mu nie pomogą w tym, klient sam widzi jak szybko soft się rozwija. Jeśli jakiś konkretny feature jest potrzebny pod działania marketingowe, to klient może dać feedback programistom: "chce rozpocząć działania marketingowe i po to potrzebuję feature X, zróbcie go", i programiści zaczynają go robić, i dadzą jakąś początkową wersję za 1/2/3 dni, klient zobaczy i zdecyduje sam czy to jest good-enough na rozpoczęcie działań marketingowych czy nie. Jeśli okaże się że klapa, to w najgorszym case'ie straci te kilka dni na przygotowanie tego.

• "wiedza dla managementu ile trzeba będzie płacić pracownikom za ich pracę, przed wydaniem softu".

  • Management nie potrzebuje takiej wiedzy, bo w każdym momencie może przestać wytwarzać taki soft, i management cały czas widzi aktualny progres. I ponownie - estimate programistów niewiele tutaj pomoże. Management widzi że kasa na 1/2/3 dni pracy programistów daje im określony return (czyli np wydają 1000zł dziennie, i za to 1000zł mają jedną nową wersję), mogą zdecydować sami czy chcą nadal inwestować w projekt czy nie. Feedback loop jest mały. Nie potrzebują widzieć "w przyszłośc".

• "cierpliwośc czy projekt będzie za miesiąc czy za pięć lat".

  • Tego w sumie argumentu nie rozumiem.

• "czy złapać nowy kontrakt"

  • @Althorion to rozumiem że chodzi o kontrakt z programistami? Czy o kontrakt z zewnętrzną firmą?

• "według czasu planuje się zatrudnianie i zwalnianie pracowników"

  • Nigdy nie słyszałem żeby ktoś planował zwalnianie pracowników. Natomiast jeśli ktoś planuje zatrudnienie nowych praconików, to szczerze mówiąc nie wiem jak "estimate" poszczególnych zadań miałoby w tym pomóc. Mógłbyś dopowiedzieć?

Większość moich odpowiedzi brzmi "nie potrzebujesz planować", bo widzę że niektóre argumenty są trochę circular, tzn. "ja potrzebuje coś zaplanować, bo ktoś inny musi coś zaplanować". To ja tylko odpowiadam: jak robisz Agile, to nie musisz planować.

Wymaga to zmiany mindset'u, owszem. Nie jest to też proste. Ale jak zaczniesz myśleć w taki sposób, to to nawet ma sens.

I na dodatek, powiem tak - to wszystko co napisałem wyżej, to nie jest tak, że taki sposób działania jest jakoś "lepszy". Tylko chodzi o to że "estimate'y" to jest zgadywanie, jest niedokładne, ludzie podczas estymowania się mylą. Tak na logikę - skąd programista miałby wiedzieć ile zajmie wykonanie jakiegoś zadania, jak nie wie co klient do końca chce - klient też nie do konca wiec co chce (klient Ci tylko powie czy mu się podoba co jest teraz czy nie).

Gdyby ludzie byli dobrzy w estymowaniu - czyli można zerknąć na projekt, i dokłądnie powiedzieć "to zadanie zajmie 15 godzin", to spoko - to cały Agile jest nie potrzebny. Ale nie jesteśmy. Biznesy się oszukują że można "oszacować" zadania, bo fantazja że możemy mieć pewnośc w tym temacie jest bardzo kusząca, ale rzeczywistośc niestety mówi że większość estimate'ów w programowaniu jest nietrafiona. Więc nierozsądne jest opierać coś na nietrafionych danych (estimate'ach). Coś zawsze wychodzi nowego, nikt nie przewiduje przyszłości.

Althorion napisał(a):

Moja teza brzmi: nic dobrego Ci nie dadzą estymaty czasowe - nie potrzeba ich, a mogą zaszkodzić. Możemy o tym porozmawiać

Moja jest taka — estymaty czasowe to jedyne estymaty, które są komukolwiek z zewnątrz potrzebne do czegokolwiek. Jak je będą mieli, to mogą sobie wyliczyć i zaplanować całą resztę; jak ich nie mają, to nie mogą wyliczyć i zaplanować nic. Jeśli więc oprogramowania się nie robi dla samych siebie, takiej trochę „sztuki dla sztuki” — a prawie nigdy, poza open source, tak nie jest — to bez wyliczania, budżetowania, i planowania następnych faz nic się nie osiągnie.

Tylko że te estymaty nie są dokładne i wiarygodne, to są tylko zgadywania. Więc jeśli biznes planuje coś na niedokładnych danych, to wyjdzie mu niedokładny plan, i to jest słabe.

Althorion napisał(a):

A nawet jeśli, to przecież SP to są estymaty czasowe. Tak jak pisałem wyżej — jest velocity, gdzie nas pilnują, żeby było możliwie niezmienne, i długość sprintu, która jest niezmienna, więc z tego wychodzi, przez proste dzielenie, ile wypada czasu na każdy SP. A jak nas nie pilnują, żeby velocity było niezmienne, to możemy sobie zaoszczędzić czasu i wysiłku, wpisując SP dowolnie, bo czemu nie? Estymacja czasowa całkowicie od tego wybuchnie… ale skoro się upieramy, że to nie problem, to co jest problemem?

To co piszesz, nie wiem dokładnie co to jest za model pracy, ale na pewno nie Agile. Już powiem czemu.

Przy czym od razu mówię - nie próbuję podważać tego co mówisz. Ja tylko mówię że ten "system" (ze story pointami, sprintami), cała ta zabawa tylko wtedy ma sens kiedy jesteśmy Agile - i trochę to opisałem wyżej. Natomiast jeśli ktoś nie jest agile (nie robi tego co tutaj opisałem wyżej), to wiadomo że żadne SP, żadne sprinty, żadne nic nie ma sensu - i jeśli ktoś nie jest agile, to się zgadzam - SP nie mają sensu. Story pointy mają sens tylko w otoczeniu zespołu i managementu który jest agile - bez niego, nie mają żadnego (i można estymować w godzinach/dniach).

Althorion napisał(a):

Tak jak pisałem wyżej — jest velocity, gdzie nas pilnują, żeby było możliwie niezmienne, i długość sprintu, która jest niezmienna, więc z tego wychodzi, przez proste dzielenie, ile wypada czasu na każdy SP.

Noo, tak i nie. To nie jest tak że w agile trzeba "pilnować velocity". W agile, sprinty są po to żeby próbować zmierzyć velocity (ale zmierzyć, a nie wymusić albo pilnować). Po co zmierzyć - właściwie tylko po jedną rzecz (w Agile) - i tą jedną rzeczą jest priorytetyzowanie następnych zadań, po nic innego.

Przy czym ja nie mówię jak Ty albo ktoś inny ma pracować - ja tutaj w tym poście opisuję tylko sposób w jaki ktoś może być Agile, i w jaki sposób SP oraz sprinty mogą w tym pomóc. Jeśli ktoś nie jest agile (bo np robi faux-agile), to to co tutaj piszę, dla niego jest całkowicie nieadekwatne.

Oprócz estymacji do tego dochodzą inne czynniki - np. to że często programiści jak sobie zaplanują np sprint na dwa tygodnie - to zrobią ich wizję tego co klient chce, a nie na prawdę co klient chce. Może się okazać że poświęcą cały sprint, na coś co jest zupełnie nie trafione. To jest bardzo ryzykowna zagrywka. Po co czekaż z feedbackiem od klienta 2 tygodnie, skoro można mu pokazać 1/14tą, i spytać "w dobrą strone to idzie czy w złą?", i wtedy klient Ci powie. Jeśli zrobisz tą 1/14tą, i okaże się że to nie jest do końca co klient chce, to stracisz jeden dzień a nie dwa tygodnie.

Althorion napisał(a):

OK, tylko… nie wiem, jak się to ma do tematu. Biznes powinien określić cel, powinien regularnie sprawdzać postępy, produkt powinien się ulepszać. Ale biznes wciąż potrzebuje wiedzieć, czy może sklep internetowy wystawić światu za miesiąc, dwa, czy za rok; potrzebuje wiedzieć, czy automatyczne wózki widłowe będą dostępne za rok, dwa, czy pięć; potrzebuje wiedzieć, czy reklamować nową wersję oprogramowania już teraz, czy z tym poczekać. Czas jest tutaj wszystkim. Praktycznie nikt nie ma na niego kompletnie wyłożone, i jak odpowiedź będzie „jak zrobimy; może będzie za tydzień, a może za dziesięć lat”, to sobie pójdzie gdzie indziej.

Biznes może sobie oszacować na podstawie swoich doświadczeń, skonsultować się z zespołem, ale bez sensu jest pytać "czy zrobicie ten projekt w rok". To tak jak pytać Goździkowej, czy będzie używać więcej, czy mniej prądu za 5 lat, bo nie wiemy, czy budować elektrownię. Nie ten poziom po prostu.

Zespół musi być w stanie odpowiedzieć na to pytanie. „No może zrobimy, chyba że nie zrobimy, a nawet jak już, to nie wiemy na kiedy” to po prostu nie jest dopuszczalna odpowiedź. Podobnie jak nie jest nią „no może dostaniecie pensję, chyba że nie dostaniecie, a nawet jak tak, to nie wiemy kiedy”. Oczywiście, błędy i pomyłki się zdarzają, zdarzają się niedoszacowania, przeszacowania, nieprzewidywalne problemy; ale jakieś oszacowania być muszą, bo wg tego się planuje.

Zespół wg. scrum'a musi być w stanie oszacować zadania na następne 2 tygodnie (dać im SP), zaplanować te 2 tygodnie i starać się ten plan wykonać. W jaki sposób przełożysz to na odpowiedź kiedy zostaną zakończone prace nad projektem systemu bankowego?
Weź też pod uwagę, że tych szacunków i planów biznes potrzebuje często zanim ten zespół/zespoły zostaną utworzone. Kogo ma wtedy pytać? Chyba, że mówimy o naprawdę prostych rzeczach typu prosta strona www z jakąś promocją, banalna aplikacja mobilna itp.

A jak nie założę nic, to też się pomylę. Przy czym jak podam datę „za rok” i wyjdzie „za półtora roku”, to się pomylę o 50%; a jak nie powiem nic, i wyjdzie „za półtora roku”, to pomyłka jest nieskończona.

Nie jest nieskończona. Równie dobrze, możesz powiedzieć, że trafiona w punkt bo, "było jak się zrobiło". Twoim zdaniem kłamstwo jest lepszą odpowiedzią, niż brak odpowiedzi. Biznes musi sobie zdawać sprawę z niepewności. W części projektów, które robiłem, niejasne było nie tylko kiedy będzie, ale nawet czy się uda. Dlatego zamiast zapinać się na konkretne terminy, budżety, rezultaty lepiej jest zaryzykować i monitorować na bieżąco, czy są szanse na sukces.

SP jest szacunkiem czasu, bo istnieje velocity i zespoły są rozliczane z tego, żeby było ono stałe. A skoro velocity to miara zrealizowanych SP w sprincie i jest stałe, zaś sprint jest stałej długości, to z konieczności SP jest miarą czasu.
Przeliczenia na czas dokonuje się przed zakończeniem projektu, bo po zakończeniu projektu to już nikogo nie obchodzi — łatwiej sobie odjąć datę rozpoczęcia od daty zakończenia. A przed faktem trzeba wiedzieć, ile będzie to kosztować (więc i ile roboczogodzin na to pójdzie), na kiedy dograć inne elementy, i mieć jakiekolwiek pojęcie, na czym się stoi.

Pewności, oczywiście, nie ma — w końcu to estymata. Ale daje to jakieś pojęcie, o czym mówimy. Umożliwia planowanie.

Scrum zobowiązuje zespół do planowania i szacowania zadań na następne 2 tygodnie. Wytłumacz proszę, jak te szacunki, niech będzie, że "czasowe" przekładają się na szacowanie kosztu i terminu ukończenia projektu? Bo po tym sprincie będziesz wiedział, że zaplanowano 20SP, wykonano 20SP i postęp projektu wynosi 20SP/nie wiadomo ile SP. Co więcej, gdyby tego nie szacować, to otrzymałbyś dokładnie taką samą informację, bo ostatecznie wiadomo co zostało zrobione, jak już zostanie zrobione.

I dla wyjaśnienia, bo chyba o 2 różnych rzeczach rozmawiamy.
Ja nie neguję, że biznes potrzebuje prognozy na kiedy i za ile będzie. Ja neguję sens stosowania SP jako narzędzie służące osiągnięciu tego celu. Przykład podejścia agile, które na to pozwala opisałem wyżej.
Oczywiście są te mityczne ogłoszone premiery, albo mniej mityczne terminy zmiany prawa i trzeba się wyrobić, bo będzie bolało. Tylko rzeczywistość jest taka, że projekt definiowany przez zakres, koszt, czas nie jest z gumy. Jak biznes wie, że za pół roku trzeba mieć jakieś zmiany w systemie, bo wchodzi nowy system podatkowy, to pracujemy nad tymi zmianami i monitorujemy jak te prace przyśpieszyć (np. dorzucając kasy na nowych ludzi) a nie łazimy po firmie pytając ile czasu zajmie zaimplementowanie zmian w przepisach określanych przez Polski Ład, które jeszcze nie zostały uchwalone. Jeżeli coś jest pilne, to najszybszą metodą na osiągnięcie celu jest to zaimplementować.
Jeżeli widzisz inną możliwość, to chętnie się z nią zapoznam, bo na razie kręcisz się jedynie wokół "SP jest jednostką czasu".

@Riddle
Zgadzam się, że estymacje czasowe są w dużej mierze oparte na przewidywaniach i są trudne do osiągnięcia z dużą precyzją. Dlatego też, w podejściu Agile, zamiast estymacji czasowej, stosuje się story pointy jako jednostkę abstrakcyjną, co pozwala na porównywanie trudności zadań bez konieczności przypisywania im konkretnego czasu. Jak bez tego chciałbyś wskazywać kolejność zadań do zrobienia?

Scrum jest jak komunizm - Idea słuszna, natomiast jego realne działania destrukcyjne.

Ok, jest scrum guide i cała reszta złotych zasad. Finalnie i tak każda firma implementuje to po swojemu, stąd scrum scrumowi nie równy. Można się kłócić o SP, estymacje i inne cudactwa, ale to nie i tak nie ma większego znaczenia. Przyjdziesz do projektu gdzie PO/SM, czy inny wariat ma swoją wizję scruma i SP będzie dla Ciebie estymatem czasowym :D

ledi12 napisał(a):

Scrum jest jak komunizm - Idea słuszna, natomiast jego realne działania destrukcyjne.

Ok, jest scrum guide i cała reszta złotych zasad. Finalnie i tak każda firma implementuje to po swojemu, stąd scrum scrumowi nie równy. Można się kłócić o SP, estymacje i inne cudactwa, ale to nie i tak nie ma większego znaczenia. Przyjdziesz do projektu gdzie PO/SM, czy inny wariat ma swoją wizję scruma i SP będzie dla Ciebie estymatem czasowym :D

IMO Scrum jest useless, i można go olać.

@anonimowy: Kolejność zadań to akurat dość prosta rzecz. Na początek jak najszybciej masz zrobić MVP, czyli coś co chociaż trochę widać. W następnej kolejności bierzesz się za realizację tego co musi być zrobione i ma określony termin, lub jest obarczone największą niepewnością.
Przykład:
Kino robi system do rezerwacji, obsługi biletów:

• stawiasz serwer, tworzysz frontpage
• wyświetlasz seanse i liczbę wolnych miejsc
• wprowadzasz możliwość rezerwacji przypadkowego miejsca
• integrujesz płatności <--- można zacząć biznes
• robisz widok z układem kina
• pozwalasz rezerwować konkretne miejsca
• dorabiasz opcję rezerwacji i płatności za miejsce parkingowe
• dorabiasz opcję zakupu popcorny, żeby czekał na ciebie w kinie
• dorabiasz system podpowiadania seansów emailem na podstawie tego co już widziałeś
• wprowadzasz system rabatowy
• ....

@piotrpo no i na jakiej podstawie ustalisz, że "dorabiasz system podpowiadania seansów emailem na podstawie tego co już widziałeś" jest ważniejszy niż "wprowadzasz system rabatowy"? Na podstawie widzimisię autora projektu. Ale on może by zmienił zdanie jak powiedziałbyś mu, że system rabatowy jest mega prosty do zrobienia (1 SP) a system podpowiadania (8 SP).

@anonimowy: Odpowiem tutaj na komentarz
Jeżeli coś jest trudne, ale nie przynosi małą korzyść, oznacza, że najprawdopodobniej nie jest potrzebne. W każdym razie mówiąc o agile, gdzie klient na bieżąco współdecyduje o dalszej ścieżce projektu, nie wyobrażam sobie sytuacji, w której słyszę, że coś jest małowartościowe, drogie ale konieczne. Jeżeli faktycznie jest konieczne, to jest też ważne. Jeżeli jest konieczne i trudne, to powinno mieć bardzo wysoki priorytet, bo "trudne" oznacza, że nie wiem, czy uda się taką funkcjonalność zrealizować i jeżeli projekt ma się wysypać, to im szybciej, tym lepiej.
Systematyzując to co próbuję napisać:

• Projekt zawsze ma swoją core funkcjonalność, bez której nie ma sensu i ta funkcjonalność powinna mieć najwyższy priorytet. W przykładzie wyżej, to pierwsze kilka punktów, do momentu "tu rusza biznes", czyli momentu, w którym można sprzedawać bilety, a do tego jest przeznaczony system. Mogą to też być funkcje, które mają być wyróżnikiem tego produktu. Po co wydawać parę baniek na sklep internetowy, który nie będzie w niczym lepszy od jakiegoś gotowca?
• Jeżeli w podstawowej funkcjonalności projektu są duże niewiadome, to należy się z nimi zmierzyć tak szybko jak to możliwe, w celu ograniczenia ew. strat.
• Funkcje poboczne (np. to domawianie popcornu) zostawia się na koniec i szereguje względem wartości dodanej/pracochłonności.

@Riddle

"Estimate" to jest po prostu mądre słowo na "zgadywanie".

Estimate to nie żadne zgadywanie (zgadywać można wzrost/spadek danego dnia na giełdzie), a oszacowanie (na podstawie analiz i doświadczenia).

Statystyki z wielu projektów pokazują że estimate'y dot. oprogramowania mylą o 4x w jedną lub drugą stronę (czyli estimate na 28 dni, może zając 7, lub 112 dni, statystycznie).

To że programiści mylą się 4x, bo szacują zadania na godzinę, a realizują je 4h oraz szacują na 8, a realizują w 2 wcale nie oznacza że będą z 10 dni robić 40.
Trzeba byłoby wziąć te dane które były użyte do tworzenia tej statystyki i z nich to wyciągnąć.

Jak idziesz do dentysty albo do taksówki i pytasz "ile czasu zajmie to kanałowe" albo "ile czasu do centrum", to oni Ci odpowiedzą, nie dlatego że estymują, tylko dlatego że robili to samo już setki razy, i pamiętają ile to zajęło. Z wytwarzaniem oprogramowania jest inaczej - zawsze robimy coś nowego, więc nie wiemy ile to zajmie.

To że każdy dzień programisty wygląda inaczej wcale nie oznacza że taski nie są takimi, które są w dużej mierze podobne do historycznych.

Jeżeli programujesz 5 lat w danej technologii, frameworkach, domenie biznesowej oraz codebasach, to chyba w większości przypadków powinieneś być w stanie dość dobrze estymować, prawda?
Generalnie im więcej expa, to te estymaty powinny być coraz lepsze.

albo "ile czasu do centrum", to oni Ci odpowiedzą, nie dlatego że estymują, tylko dlatego że robili to samo już setki razy, i pamiętają ile to zajęło.

Oni również estymują, bo nie wiedzą jakie są warunki i uczestnicy na całej trasie.

Gdyby byli pewni, to nie byłoby opóźnień w transporcie publicznym itd.

@piotrpo

CDPR podał kiedy będzie CP2077 i był. Efekt komentował szeroko cały świat, a akcje spadły o 60% Błędy wynikające z ogłoszonych na podstawie szacunków terminów i zakresu naprawiano przez 2 lata. Gdyby ograniczyli zakres / przesunęli premierę, to kosztowałoby ich to więcej, ale zarobiliby również więcej.

Data release CP2077: 10 grudnia 2020

Czyli kiedy? Pierwszy rok COVIDA, siedzenia w domu, WFH, itd. - peak gamingu
A do tego okres świąteczny

Myślisz że nie mogli przełożyć? imo mogli, ale uznali że jest to zbyt dobry okres aby tego nie zrobić.

to kosztowałoby ich to więcej, ale zarobiliby również więcej.

Odważnie, ale skąd taka pewność?

Aby tak było musiałoby być więcej konsolowców niż PC gamerów którzy mają mało czasu na gry, którym akurat okres COVIDowy dał okazje do grania.

Konsolowców według losowych stronek jest ok 250 milionów, a PC gamerów 1.85 miliarda

Więc nie wiem czy tak łatwo to ocenić.

A zresztą, a co z produktami gdzie jest duża rywalizacja i time to market się liczy? np. ChatGPT vs Googlowy Bard, czy inne AIowe rzeczy ostatnio?

Albo produkty typu GPU?

@WeiXiao: TTM liczy się wszędzie. Jak już ogłosisz po raz chyba 3 "teraz, to już będzie", to wycofanie się z takiej obietnicy "a nie, jednak za 2 lata" jest dość bolesne dla marki, akcjonariuszy. W tym przypadku, moim zdaniem ewidentnie kogoś poniosło, ale to tylko moje zdanie.
W każdym razie gra była ewidentnie zabugowana, zarówno od strony technicznej, jak i od strony gameplay, ekonomii gry. Na pocieszenie, dodatek jest już znacznie lepszy moim zdaniem.

@Riddle

Zasadnicze pytanie - po co?
Tak serio - jaki jest sens estymować czasowo zadanie? Weźmy konkretne powody na tapet. Opieranie się na estymatach czasowych to taki stary model produkcji trochę.

Szacowanie jest częścią czegoś większego - oceny ryzyka oraz strategii i występuje nie tylko w biznesie, a właściwie wszędzie.

• Aby udobruchać marudzącą żonkę postanawiasz podpytać robotników kończących twój dom jak szacują kiedy uda im się skończyć, bo chcesz obiecać żonie że święta spędzicie w nowym domu.
• Starasz się o awans i masz świadomość jak pozytywnie postrzegane jest dowożenie na czas, więc interesujesz się estymatami aby wiedzieć czy potrzebujesz dołożyć ludzi do projektu czy też nie
• Jesteś firmą która planuje wydać bardzo ważny produkt i inwestorzy zaczynają pytać "kiedy?", więc znów potrzebujesz roadmapy, estymat, buforu itd. Jeżeli się nie wywiążesz to stracisz wiarygodność u ludzi którzy mają kasę i chcieliby cię finansować, a tego nie chcesz.

Każdy (ja, ty, firmy, rządy itd) komuś coś obiecuje i stawia na to swoją wiarygodność, reputacje czy coś tam i czasem nawet więcej, więc każdy z nas jest zainteresowany oceną ryzyka tych obietnic.

piotrpo napisał(a):

@anonimowy: Odpowiem tutaj na komentarz
Jeżeli coś jest trudne, ale nie przynosi małą korzyść, oznacza, że najprawdopodobniej nie jest potrzebne. W każdym razie mówiąc o agile, gdzie klient na bieżąco współdecyduje o dalszej ścieżce projektu, nie wyobrażam sobie sytuacji, w której słyszę, że coś jest małowartościowe, drogie ale konieczne. Jeżeli faktycznie jest konieczne, to jest też ważne. Jeżeli jest konieczne i trudne, to powinno mieć bardzo wysoki priorytet, bo "trudne" oznacza, że nie wiem, czy uda się taką funkcjonalność zrealizować i jeżeli projekt ma się wysypać, to im szybciej, tym lepiej.
Systematyzując to co próbuję napisać:

• Projekt zawsze ma swoją core funkcjonalność, bez której nie ma sensu i ta funkcjonalność powinna mieć najwyższy priorytet. W przykładzie wyżej, to pierwsze kilka punktów, do momentu "tu rusza biznes", czyli momentu, w którym można sprzedawać bilety, a do tego jest przeznaczony system. Mogą to też być funkcje, które mają być wyróżnikiem tego produktu. Po co wydawać parę baniek na sklep internetowy, który nie będzie w niczym lepszy od jakiegoś gotowca?
• Jeżeli w podstawowej funkcjonalności projektu są duże niewiadome, to należy się z nimi zmierzyć tak szybko jak to możliwe, w celu ograniczenia ew. strat.
• Funkcje poboczne (np. to domawianie popcornu) zostawia się na koniec i szereguje względem wartości dodanej/pracochłonności.

Problem jest taki, że biznesy mają ograniczony budżet i muszą mądrze nim zarządzać. Nadal podtrzymuję, że lepiej zrobić "low-haning fruit" jeśli to możliwe. W Twoim podejściu nie można ich zrobić bo nie ma wiedzy o nich

Althorion napisał(a):

Czegoś tu nie rozumiem — nie macie wyliczanego velocity w pracy? Nie macie człowieka, któremu zależy, żeby to velocity było możliwie stałe pomiędzy sprintami?

Czemu komukolwiek miałoby zależeć, żeby było stałe?

Bo jeśli macie, to macie też estymację godzinową — każdy, nawet najgorszy programista umie podzielić te „bezjednostkowe” SP przez jednostkowe velocity, żeby wyznaczyć to, za to tak naprawdę będą go rozliczać, tj. za zrobienie odpowiedniej ilości pracy w danej jednostce czasu.

Skąd pomysł, że kogoś będą za coś rozliczać?

A jeśli nie macie… to po co tracić czas na szacowanie czegokolwiek?

A kiedy przestałeś tracić czas na bicie żony? :-P

Nawet jeśli uznajesz, że wynik szacowania jest bez sensu, to sam proces szacowania może mieć sens - bo ludzie mają szansę zrozumieć zawczasu o co chodzi w zadaniu, i jak podejść do jego realizacji.

piotrpo napisał(a):

Dlaczego nie ma tutaj story pointów? Bo są na tym poziomie absolutnie niepotrzebne. W story pointach wycenia się drobnoziarniste historyjki typu "dodaj do formularza dodatkowe pole", może "przygotuj formularz z 10 polami". Podzielenie całego projektu na takie historyjki to kilka tygodni, przygotowanie designu UI, całej, szczegółowej dokumentacji, przejrzenia wszystkich API, które mają zostać zintegrowane itd. Czyli realnie, będzie kosztować więcej niż przygotowanie MVP, zespół po miesiącu dyskusji czym jest SP, dlaczego trzeba oszacować jakieś zadanie, chociaż nie ma do tego żadnych danych, ani nawet zakresu będzie potrzebować kolejnego miesiąca na zaleczenie traumy, a uzyskane szacunki nie będą miały żadnego oparcia w danych, bo nie napisano nawet linijki kodu.

Jeśli robimy MVP, to nie ma sensu planować całego projektu, wystarczy zaplanować MVP.

ledi12 napisał(a):

Przyjdziesz do projektu gdzie PO/SM, czy inny wariat ma swoją wizję scruma i SP będzie dla Ciebie estymatem czasowym :D

No dokładnie. I jak będzie miał wizję, w której dwa dni w sprincie są zmarnowane na spotkania, a daily trwa 1 godzinę codziennie, to taki projekt opuszczę. A jak będzie znośnie, to i scrum nie będzie przeszkadzał.

somekind napisał(a):

Czemu komukolwiek miałoby zależeć, żeby było stałe?

To była połowa zaproponowanej alternatywy. Drugą było, że skoro nie ma potrzeby, żeby velocity było stałe, to nie musimy tracić czasu na estymację. Wszędzie wpiszmy to samo, albo w ogóle zróbmy losowo z góry na dół. Jaka oszczędność czasu!

Co prawda wtedy estymacje czasowe diabli wezmą, ale ponoć to nie jest cel. Velocity też będzie szaleć, ale to też miał nie być cel. No to wszystko super, oszczędność bez żadnych problemów!

Skąd pomysł, że kogoś będą za coś rozliczać?

Z tego, że mnie rozliczają w pracy. Nie mogę sobie robić jednego taska do końca roku — bo bym zaniżał velocity. A jakbym mógł mieć takie velocity, jakie mi się podoba, to mógłbym nie robić z goła nic.

A kiedy przestałeś tracić czas na bicie żony? :-P

Co, gdzie, jak?

Nawet jeśli uznajesz, że wynik szacowania jest bez sensu, to sam proces szacowania może mieć sens - bo ludzie mają szansę zrozumieć zawczasu o co chodzi w zadaniu, i jak podejść do jego realizacji.

A po co mają to zrozumieć zawczasu? Co mi to da, że będę rozumiał pół roku, rok, dwa wcześniej? Dlaczego, nawet jakby to miała być jakaś wartość, to miałoby być skodyfikowane przez narzucanie jakiejś obiektywnej wartości na to, i kłócenie się o to, jakie te wartości być powinny?

somekind napisał(a):

Jeśli robimy MVP, to nie ma sensu planować całego projektu, wystarczy zaplanować MVP.

Jeżeli masz gruboziarniście zdefiniowany projekt (bo niektóre faktycznie nie są zdefiniowane "do końca"), to można zrobić zgrubną koszulkową estymację całości i po zrobieniu MVP mieć jakąś tam możliwość odpowiedzenia "mamy 2-7% projektu zrobione". Czyli planujesz resztę projektu, ale na wysokim poziomie.

Althorion napisał(a):

Z tego, że mnie rozliczają w pracy. Nie mogę sobie robić jednego taska do końca roku — bo bym zaniżał velocity. A jakbym mógł mieć takie velocity, jakie mi się podoba, to mógłbym nie robić z goła nic.

Dobra, ale po co kogokolwiek rozliczać? Oczywiście możesz mieć kulturę pracy, która na tym się opiera i regularnie ktoś wyciąga twoje osobiste velocity i mówi, że na tle zespołu, twój SP wypadł 10% drożej niż średnia, tylko po co?
Jeżeli masz zespół, który jest agile, to założenie jest takie, że pracujesz z ludźmi, którzy wiedzą co robią, chcą to robić, dają z siebie tyle ile w danym momencie mogą. W tym zespole, po miesiącu pracy, każdy doskonale wie kto dowozi, kto nie dowozi i jak zaczniesz w pracy przeszkadzać, to zwrócą ci uwagę od razu. Jak to olejesz, to po kolejnych 2 miesiącach sami poproszą managera o zmianę. Ostatnio, w ten sposób poleciał SM , bo zamiast reagować na prośby "weź zrób coś pożytecznego i ogarnij tego excela, którego wymagają" zajmował się dobieraniem kolorków do karteczek na retro.

A po co mają to zrozumieć zawczasu? Co mi to da, że będę rozumiał pół roku, rok, dwa wcześniej? Dlaczego, nawet jakby to miała być jakaś wartość, to miałoby być skodyfikowane przez narzucanie jakiejś obiektywnej wartości na to, i kłócenie się o to, jakie te wartości być powinny?

Nie ma sensu robić tego rok do przodu. Walić szacowanie, to tylko nadanie numerka, ale rozpisanie jakiegoś ficzera na historyjki, tak, żeby to miało sens, jest dużym wysiłkiem całego zespołu. W agile zakładasz, że wymagania do tego ficzera się zmienią, albo ficzer zniknie, więc poświęcanie mu uwagi jest stratą czasu.

Zdaję sobie sprawę, że pewnie 90% korporacyjnego agile, to taki waterfall, tylko w Jira i ze story pointami. Problem w tym, że jeżeli zaczynasz rozliczać zespół/ludzi z robienia storypointów, to ten zespół ci dostarczy story pointy, ale nie dostarczy ci produktu. Najpierw zadania zaczną być wyceniane z nadmiarem, jak zaczniesz mieć z tym problem, to zaczną być rozdrabniane na bardzo drobne historyjki, jak znajdziesz na to sposób, to ludzie zaczną się między sobą kłócić o zadania bardziej opłacalne niż inne. Połowa energii, która powinna zostać przeznaczona na produkt, pójdzie w lokalne wojenki, w efekcie dostaniesz stałe, wysokie velocity i nawet odpowiedź "kiedy będzie" aż do ostatniego momentu, kiedy się okaże, że jednak nie ma. Oczywiście zakładając, że zespół ci nie ucieknie w lepsze miejsce.

Czytam z zapartym tchem ten wątek, bo nie dalej jak w piątek (dwa dni temu) rozmawiałem z człowiekiem z biznesu, który nic nie rozumie z tych story pointów. Jest właścicielem firmy budowlanej (sporej), potrafi wydać pieniądze na IT/systemy, tyle że mówi że wyceniają mu w tych story pointach, później mówią, że story point kosztuje XXX USD. Tylko, że ma problem z tym, że coś zrobili, myślał, że dostał wycenę za zrobienie całego procesu, a otrzymał jakiś półfunkcjonalny kawałek softu i informację, że dokończenie tego wszystkiego to kolejnych ileś story points i kolejna kasa.

I ja wiem, że zaraz się dowiem, że chv**wo dostawca robi itd. Ale ten człowiek ma prosty temat - chce wiedzieć, że dostanie obsługę pełnego procesu + informację ile to kosztuje i na kiedy.

Jak czytam o tych story pointsach w dyskusji, to jawią się one jako piąty wymiar, a że żyjemy w trzech + czas, to jest to trudne do przełknięcia przez zewnętrznego odbiorcę.

Dla mnie "ruch no estimates" to jest jakieś podejście zdejmujące odpowiedzialność z osoby, która ma robić robotę. Rozumiem, że jest to wygodne, powoduje niższy stres, ale podejście, że na pytanie kiedy będzie za każdym razem odpowiadamy - "będzie kiedy będzie" jest dla mnie nieprzekonujące i na maksa trudne w komunikacji ze światem zewnętrznym (poza zespołem developerskim).

Dajmy na to, ten właściciel zapytany przez inwestora na kiedy będzie wyremontowany ten budynek jakby odpowiedział tak jak mu developerzy odpowiadają, to go wyjebią z tej budowy od jutra, albo lepiej - wjadą kary umowne i realizacja zastępcza na koszt developerów.

Sami, jeśli dajmy na to budowalibyście dom, to z pewnością nie chcielibyście usłyszeć:

• no wylanie fundamentów zajęło nam 38 story points - robimy dalej czy kończymy?
• na kiedy zrobisz mi pan stan surowy zamknięty? może przed zimą, a może po zimie
• powiedzcie np. w banku przy kredycie, że nie wiadomo kiedy będzie przekazanie, czy oddanie kolejnego etapu
• i pewnie można wymyślać dłużej

Story Pointsy to mam wrażenie coś, co sprawia, że znowu "trudno dogadać się z programistami", a po drugie jest narzędziem komunikacji dosyć hermetycznym, elementem żargonu, ergo nie jest wg. mnie DOBRYM narzędziem komunikacji ze światem poza zespołem developerskim (wewnętrznie jeśli wszyscy rozumieją jak działa i PO CO ono jest to cytując wieszcza "jak się kochają to *uj z nimi").

Story Pointy to taki odpowiednik klas, funkcji, zmiennych, interfejsów i innych rzeczy mówienie o których jednak pokazuje laikom że programiści mają jakąś wiedzę. SM i inne takie też chcą poudawać że ich stanowisko wymaga czegoś więcej niż bycia kolesiem zarządu, wiec wymyślili własny hermetyczny język i ściemniają że stoi za nim jakaś nauka

brzezmac napisał(a):

Jest właścicielem firmy budowlanej (sporej), potrafi wydać pieniądze na IT/systemy, tyle że mówi że wyceniają mu w tych story pointach, później mówią, że story point kosztuje XXX USD.

Słucham?!

brzezmac napisał(a):

Tylko, że ma problem z tym, że coś zrobili, myślał, że dostał wycenę za zrobienie całego procesu, a otrzymał jakiś półfunkcjonalny kawałek softu i informację, że dokończenie tego wszystkiego to kolejnych ileś story points i kolejna kasa.

I ja wiem, że zaraz się dowiem, że chv**wo dostawca robi itd. Ale ten człowiek ma prosty temat - chce wiedzieć, że dostanie obsługę pełnego procesu + informację ile to kosztuje i na kiedy.

Jak czytam o tych story pointsach w dyskusji, to jawią się one jako piąty wymiar, a że żyjemy w trzech + czas, to jest to trudne do przełknięcia przez zewnętrznego odbiorcę.

Dla mnie "ruch no estimates" to jest jakieś podejście zdejmujące odpowiedzialność z osoby, która ma robić robotę. Rozumiem, że jest to wygodne, powoduje niższy stres, ale podejście, że na pytanie kiedy będzie za każdym razem odpowiadamy - "będzie kiedy będzie" jest dla mnie nieprzekonujące i na maksa trudne w komunikacji ze światem zewnętrznym (poza zespołem developerskim).

Dajmy na to, ten właściciel zapytany przez inwestora na kiedy będzie wyremontowany ten budynek jakby odpowiedział tak jak mu developerzy odpowiadają, to go wyjebią z tej budowy od jutra, albo lepiej - wjadą kary umowne i realizacja zastępcza na koszt developerów.

Sami, jeśli dajmy na to budowalibyście dom, to z pewnością nie chcielibyście usłyszeć:

• no wylanie fundamentów zajęło nam 38 story points - robimy dalej czy kończymy?
• na kiedy zrobisz mi pan stan surowy zamknięty? może przed zimą, a może po zimie
• powiedzcie np. w banku przy kredycie, że nie wiadomo kiedy będzie przekazanie, czy oddanie kolejnego etapu
• i pewnie można wymyślać dłużej

Story Pointsy to mam wrażenie coś, co sprawia, że znowu "trudno dogadać się z programistami", a po drugie jest narzędziem komunikacji dosyć hermetycznym, elementem żargonu, ergo nie jest wg. mnie DOBRYM narzędziem komunikacji ze światem poza zespołem developerskim (wewnętrznie jeśli wszyscy rozumieją jak działa i PO CO ono jest to cytując wieszcza "jak się kochają to *uj z nimi").

Bardzo rozsądne argumenty, dobrze wiedzieć że @brzezmac trzymasz poziom rozmowy.

Jest kilka problemów, z tym co opisałeś.

• Ale ten człowiek ma prosty temat - chce wiedzieć, że dostanie obsługę pełnego procesu + informację ile to kosztuje i na kiedy. :
  Tylko tutaj są dwa problemy:

  • Po pierwsze, "obsługa pełnego procesu" to za pewne nie jest dobrze zdefiniowany termin, zleceniodawca za pewne wie mniej więcej jak ten proces mógłby wyglądać, ale to programiści mają zaprojektować system który to umożliwi, i to po pierwsze nie jest zadanie trywialne
  • A po drugie nikt przed końcem tego projektu nie wie jak finalny produkt będzie wyglądał. Nawet klient tego nie wie.

• Dla mnie "ruch no estimates" to jest jakieś podejście zdejmujące odpowiedzialność z osoby, która ma robić robotę. - faktycznie, może to sprawiać takie wrażenie, bo faktycznie Agile ma taką konsekwencję że zdejmuje odpowiedzialność z programistów, ale to nie jest cel.

brzezmac napisał(a):

Dajmy na to, ten właściciel zapytany przez inwestora na kiedy będzie wyremontowany ten budynek jakby odpowiedział tak jak mu developerzy odpowiadają, to go wyjebią z tej budowy od jutra, albo lepiej - wjadą kary umowne i realizacja zastępcza na koszt developerów.

Sami, jeśli dajmy na to budowalibyście dom, to z pewnością nie chcielibyście usłyszeć:

• no wylanie fundamentów zajęło nam 38 story points - robimy dalej czy kończymy?
• na kiedy zrobisz mi pan stan surowy zamknięty? może przed zimą, a może po zimie
• powiedzcie np. w banku przy kredycie, że nie wiadomo kiedy będzie przekazanie, czy oddanie kolejnego etapu
• i pewnie można wymyślać dłużej

Tylko że budowanie domu to nie jest dobra analogia do programowania. Jak chcesz zbudować 2x większy dom to trzeba to budować 2x dłużej i wydać 2x więcej materiałów. Jak chcesz dać software 2x większej ilości ludzi... to nie trzeba nic robić, wystarczy skopiować. Czas na stworzenie produkt w programowaniu to nie jest "czas potrzebny na napisanie linii kodu", ten czas bierze się z tego że trzeba wymyślić jak on ma działać, przetestować to i zaprojektować.

Druga rozbieżność to to, że taki budowlaniec budował pewnie podobne domy w przeszłości, więc wie ile poszczególne elementy mogą zacząć. Programiści którzy piszą oprogramowanie dla niego, za pewne pierwszy raz piszą taką aplikację. Z tego powodu szacunek czasu na budowie jest poparty wieloletnim doświadczeniem i jest trafny. Szacunek czasu w wytwarzaniu oprogramowania bardzo często jest nietrafny - z tego powodu że praktycznie zawsze jak tworzymy nowy soft to robimy coś nowego.

I to nie chodzi o to żeby "zdjąć odpowiedzialność z pracowników", że "programiści powinni lepiej estymować", etc. - to się nie bierze ze złej woli. Po prostu nie ma dobrego sposobu żeby przewidzieć ile czasu zajmie wytworzenie takiego oprogramowania. No po prostu nie ma i tyle, nikt nie jest w stanie tego robić dobrze (z jakimkolwiek poziomem wiarygodności).

Joanna Chmielewska, Autobiografia
" Proszę państwa, muszą państwo wiedzieć, że architekci na ogół są uważani za wariatów. I słusznie. Sposób myślenia architekta przypomina sposób myślenia wariata. Normalny człowiek myśli zazwyczaj o jednej, dwóch, najwyżej trzech rzeczach równocześnie. Architekt z konieczności musi myśleć o trzydziestu…
I wymienił nam te trzydzieści rzeczy. Pamiętam początek.
Rzut budynku, elewacja, przekrój, funkcjonalność, teren, nośność gruntu, rodzaj konstrukcji, instalacje, normatywy, strony świata, rodzaj i koszty materiałów…"
taaaaa budowa domu jest powtarzalna