Story pointy - bezsens i robienie przedszkola

o takie rzeczy powinni pytać analitycy i architekci na początku, przed rozpoczęciem pracy, bo od tego zależy np. wybór bazy danych, Klient nie musi wiedzieć że powinien to powiedzieć, oni powinni wiedzieć że muszą zapytać. No ale jak decyzje podejmuje mityczny zepół, juniorów po bootkampie. Widziałam przy pracy ludzi którzy zbierali założenia z poważnej w miarę firmy, z SAS, i dopiero po pół roku zrozumiałam że mieli rację w pewnych przypadkach gdy upierali się że data zmiany zapisu rekordu w bazie musibyć im też przekazana

brzezmac napisał(a):

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.

Story pointy to miara, która obowiązuje wyłącznie wewnątrz zespołu. Jak ktoś rozmawia z klientem / biznesem nie-IT używając tej miary, to popełnia błąd.

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.

I taką informację powinien dostać od biznesu dostawcy, a nie od zespołu deweloperskiego. Jak widzisz budowę autostrady, to idziesz do operatora walca pytać "na kiedy będzie", czy raczej do zarządu firmy, która to robi? Operator walca ma jedynie odpowiedzieć zarządowi, że te 100m to do fajrantu wywalcuje na błysk, chyba, ze mu asfaltu nie dowiozą. Na pytanie o całość projektu odpowie "uuu kierowniku, to jeszcze zejdzie w p...du". To zarząd przed inwestorem odpowiada za to kiedy będzie i za ile, bo to zarząd podpisał umowę.

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).

Bo świat zewnętrzny albo jest agile i rozumie takie podejście, albo co częstsze nie jest i wtedy "biznes" ma to oszacować, ocenić ryzyko i dowalić taką marżę, żeby nie stracić.

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.

A ten właściciel, to lata z łopatą, czy jednak bierze na siebie ryzyko podpisania umowy z konkretną datą, za konkretną kasę?

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").

SP's nie są dobrym narzędziem do komunikacji z deweloperami. One kompletnie nie powinny być wykorzystywane w tym celu. Nikt nie powinien (by the book) kazać deweloperom używać SP. To zespół (czyli te kilka osób przy klawiaturach) może sobie w ten sposób ułatwiać pracę.

No i analogia z budownictwem jest mocno naciągana. Budując dom dokładnie wiesz co masz zbudować, bo powstał za grubą kasę projekt specyfikujący jak ten dom ma wyglądać, gdzie są przyłącza, jakich materiałów, w którym miejscu użyć, masz specyfikację tych materiałów i wiesz, że beton w fundamentach musi poleżeć w spokoju przez 2 tygodnie zanim pójdziesz dalej, Na podstawie tego projektu, możesz zbudować terminarz prac, upewnić się, że masz kim te prace wykonać i masz prawie całkowitą pewność, że ten projekt nie zostanie zmieniony. Jeżeli będzia jakaś potrzeba zmiany, to będzie ona dotyczyła innych kafelków w łazience, a nie tego, że com trzeba obrócić o 90 stopni.

Miang napisał(a):

o takie rzeczy powinni pytać analitycy i architekci na początku, przed rozpoczęciem pracy, bo od tego zależy np. wybór bazy danych, Klient nie musi wiedzieć że powinien to powiedzieć, oni powinni wiedzieć że muszą zapytać.

Po pierwsze - na pewno nie powinni wybierać bazy danych na początku projektu. Początek projektu to jest czas kiedy wiesz najmniej, więc to nie jest mądre żeby na początku podjąć tak istotną decyzję.

Po drugie - Klient nie musi wiedzieć że powinien to powiedzieć klient też nie wie czego chce, klienci są bardzo słabi w precyzowaniu tego co chcą. Jedyne co klient może zrobić, to zobaczyć wersję aplikacji i powiedzieć czy mu się podoba czy nie.

Po trzecie - oni powinni wiedzieć że muszą zapytać. taki proces wytwarzania oprogramowania po prostu jest droższy i dużo wolniejszy.

Riddle napisał(a):

Miang napisał(a):

o takie rzeczy powinni pytać analitycy i architekci na początku, przed rozpoczęciem pracy, bo od tego zależy np. wybór bazy danych, Klient nie musi wiedzieć że powinien to powiedzieć, oni powinni wiedzieć że muszą zapytać.

no ale dlaczego to na mongo tak wolno działa ;)

@Riddle nie kupuję argumentu, że budowanie domu to za każdym razem to samo, a budowanie softu to za każdym razem co innego. To nie jest tak, że na jednym projekcie budujesz drugiego netflixa, na drugim obsługę pasu bagażowego, na trzecim system workflow w telco, a na czwartym oprogramowanie wahadłowca. Większość z nas robi te apki biznesowe, która mają sekwencje formularzy, jakieś integracje (których koncepcyjnie jest skończona ilość), bazę danych. Jeśli wszystko za każdym razem jest inne, to jaka jest korzyść z frameworków, które w sposób dosyć "zopiniowany" (dogmatyczny?? - szukam odpowiednika "opinionated") dają zestaw domyślnych rozwiązań, które mają przyspieszyć dostarczanie systemów?

Odnośnie tez tego co w ramach projektu należy budować (wymagania), to bujamy się już trochę z tym zagadnieniem i jest to osobne wątek (inżynieria wymagań), który jest jakoś rozpracowany. Na poziomie procesu jest już parę koncepcji jak podchodzić do kolejnych projektów tworzenia oprogramowania. Nie rozumiem więc, dlaczego całe agile'owe środowisko stara się to wszystko wyrzucić do śmieci i budować narrację, jakby każdy kolejny projekt to było odkrycie na miarę stworzenia internetu.

Z mojego doświadczenia najlepiej sprawdzało się - setup projektu zgodnie z metodyką sztywniejszą (waterfall, v-model, pmp), który pozwala też biznesowi się zastanowić co chce zrobić i dać też jakieś ramy, w których się poruszamy. Sama realizacja to już jak najbardziej agileowo, bo dynamika na projekcie jest taka, że jeden zespół już by chciał integrację robić, a drugi jeszcze jej nie dostarczył, albo implementujemy obsługę generowania PDFów, ale słabo z zakresem pól do szablonu, itd. .... A na tym etapie, to już z grubsza wiemy w czym się musimy zmieścić (budżet).

brzezmac napisał(a):

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

Hm, ale co człowiek od biznesu, a niedajbosz właściciel firmy, robi w piwnicy z ludźmi rozmawiającymi storypointami?

Te dwa światy się przecież nie powinny spotykać.

A na serio to jakie systemy firma budowlana chce mieć takie customowe że aż zleca pisanie softu od zera. Nie ma czegoś gotowego?

@piotrpo "masz prawie całkowitą pewność" - taką samą jak w projekcie developerskim. I w jednym i w drugim pojawiają się zmiany, którymi trzeba zarządzać. I w jednym i w drugim pojawiają się wyzwania (jak się wkopałeś w ziemię i coś jest nie tak jak planowałeś, to musisz przeplanować cały proces), czasami sypie się łańcuch dostaw (w budowlance materiały, w software inny zespół, od którego zależysz nie dowiózł), etc.
W podejściu, które opisujesz odpowiada tylko "biznes", "zarząd", etc. - a ci co fizycznie robotę robią to nie odpowiadają za nic?

I taką informację powinien dostać od biznesu dostawcy, a nie od zespołu deweloperskiego.

Tutaj ewidentnie developerzy są biznesem. Ale to jest kwestia umiejętności komunikacji, a nie biznesu, czy niebiznesu.

brzezmac napisał(a):

@Riddle nie kupuję argumentu, że budowanie domu to za każdym razem to samo, a budowanie softu to za każdym razem co innego. To nie jest tak, że na jednym projekcie budujesz drugiego netflixa, na drugim obsługę pasu bagażowego, na trzecim system workflow w telco, a na czwartym oprogramowanie wahadłowca. Większość z nas robi te apki biznesowe, która mają sekwencje formularzy, jakieś integracje (których koncepcyjnie jest skończona ilość), bazę danych. Jeśli wszystko za każdym razem jest inne, to jaka jest korzyść z frameworków, które w sposób dosyć "zopiniowany" (dogmatyczny?? - szukam odpowiednika "opinionated") dają zestaw domyślnych rozwiązań, które mają przyspieszyć dostarczanie systemów?

Odnośnie tez tego co w ramach projektu należy budować (wymagania), to bujamy się już trochę z tym zagadnieniem i jest to osobne wątek (inżynieria wymagań), który jest jakoś rozpracowany. Na poziomie procesu jest już parę koncepcji jak podchodzić do kolejnych projektów tworzenia oprogramowania. Nie rozumiem więc, dlaczego całe agile'owe środowisko stara się to wszystko wyrzucić do śmieci i budować narrację, jakby każdy kolejny projekt to było odkrycie na miarę stworzenia internetu.

Z mojego doświadczenia najlepiej sprawdzało się - setup projektu zgodnie z metodyką sztywniejszą (waterfall, v-model, pmp), który pozwala też biznesowi się zastanowić co chce zrobić i dać też jakieś ramy, w których się poruszamy. Sama realizacja to już jak najbardziej agileowo, bo dynamika na projekcie jest taka, że jeden zespół już by chciał integrację robić, a drugi jeszcze jej nie dostarczył, albo implementujemy obsługę generowania PDFów, ale słabo z zakresem pól do szablonu, itd. .... A na tym etapie, to już z grubsza wiemy w czym się musimy zmieścić (budżet).

Okej, może się za bardzo pospieszyłem z tym "budowanie domu to jest zawsze to samo".

Ale jest prawdą, że stawianie kolejnych domów wymaga większej produkcji (chcesz postawić 2x więcej domów == 2x więcej pracy). W programowaniu tego nie ma. Raz wytworzone oprogramowanie można kopiować do woli. Z tego powodu w budownictwie domów siłą rzeczy jest powtarzalność, której w programowaniu nie ma.

Powiedziałbym, że budowlaniec z 20 letnim doświadczeniem, jest w stanie lepiej przewidzieć ile zajmie budowanie domu, niż programista z 20 letnim doświadczeniem przewidzi ile zajmie napisanie oprogramowania. I nie wynika to z niewiedzy, tylko z natury pracy jaką wykonują. Moim zdaniem zbudowanie domu posiada mniejszą ilość zmiennych czynników niż programowanie. Dlatego estymacja czasu oprogramowania jest bardzo niemiarodajna, i nie warto na niej polegać.

Dlatego uważam że budowanie domów nie jest dobrą analogią do wytwarzania oprogramowania. To co działa w budownictwie, nie koniecznie musi zadziałać w softwarze.

Jak zrobisz estimate w dniach, to nijak nie wepchną więcej do sprintu.

A tak ogólnie co jest złego w estymacji w koszulkach, potem w story pointach a potem definiowanie długości sprintu w dniach? To wszystko ma głęboki sens.

Wracając do estymatów czasowych to powiem tak. Jeśli w projekcie estymuje się w dniach / godzinach itp i estymacja nadal jest tylko estymacją a nie realnym terminem dowiezienia, to nadal jest to akceptowalne. Trochę to co mówi @Riddle - Albo 30h przeciągnie się na 50h albo skróci do 10h.

Dla developera nie robi to żadnej różnicy.

ledi12 napisał(a):

Wracając do estymatów czasowych to powiem tak. Jeśli w projekcie estymuje się w dniach / godzinach itp i estymacja nadal jest tylko estymacją a nie realnym terminem dowiezienia, to nadal jest to akceptowalne. Trochę to co mówi @Riddle - Albo 30h przeciągnie się na 50h albo skróci do 10h.

Dla developera nie robi to żadnej różnicy.

Myślę że trafiłeś w sedno. Czyli "estymacje to estymacje", ale biznesy traktują je jak obietnice. Wymagają pewności tam gdzie jej nie ma.

I tutaj wszystko tak na prawdę zależy od warstwy pośredniej pomiędzy developerami a biznesem, czyli TL, PM, PO itp. Jeśli odciąża zespół z takich konfrontacji i bierze na klatę rozmowy z biznesem i faktycznie pozwala na taką kolej rzeczy (normalną), że estymata to tylko estymata, to już połowa sukcesu. Z tego co zauważyłem, najczęściej takie coś można spotkać w firmach produktowych. Z doświadczenia wiem, że takie środowiska bardziej stawiają na jakość niż ilość i faktycznie estymata to tylko pewna orientacja i nikt nie traktuje tego jako termin dowozu. Ale wiadomo, firma firmie nie równa.

@Riddle

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ę.

Już kolejny raz piszę post że imo to są brednie.

Chyba że raz pracujesz w web devie, innym razem klepiesz kompilator, innym robisz patcha do linóxa, a jeszcze innym piszesz firmware do GPU.

Ale jeżeli nawalasz od 5 lat cały czas tą webówkę i miałeś ekspozycje na różne tech i architektury, no to chyba nie powinno być to cały czas czyms nowym, lol.

Zostaje jeszcze złożoność biznesowa/domenowa, i tutaj trzeba usiąść, włożyć dużo wysiłku w analizę i zrozumienie tego co chce klient.
Nie twierdzę że da się to idealnie wyestymować, ale sugerowanie że za każdym razem robi się coś innego, a więc nie idzie estymować to przesada.

Ale jest prawdą, że stawianie kolejnych domów wymaga większej produkcji (chcesz postawić 2x więcej domów == 2x więcej pracy). W programowaniu tego nie ma. Raz wytworzone oprogramowanie można kopiować do woli. Z tego powodu w budownictwie domów siłą rzeczy jest powtarzalność, której w programowaniu nie ma.

A 2x więcej featuresów? no bo przecież każdy dom jest inny (może mniej przy hurtowym budowaniu).

brzezmac napisał(a):

@piotrpo "masz prawie całkowitą pewność" - taką samą jak w projekcie developerskim.

O jakim projekcie mówimy, takim za 10l, 100k, bańkę, czy takim za 100 baniek? Jeżeli robiłeś 10 sklepów internetowych, przychodzi klient i chce 11, to dokładnie wiesz czego użyjesz, jak użyjesz, ile to będzie trwało, na jakiej infrastrukturze to postawisz i ile to będzie wymagało pracy. Jak przychodzi klient i chce czegoś poważniejszego, to musisz to zaprojektować, rozpisać funkcje, pomyśleć o środowiskach dev, test, prod, CI/CD, na jakich systemach to ma chodzić, jakie przeglądarki / urządzenia obsługiwać, jak sobie poradzić ze skalą projektu, ochroną danych, security, testami, monitoringiem, alarmingiem, wsparciem użytkownika, rodo, backupach, wymaganej dostępności. Później rozpisać to na zadania deweloperskie, tak, żeby dawało się je oszacować, czyli w przypadku jakiegokolwiek UI, potrzebujesz designów. Ktoś musi jeszcze ten projekt zweryfikować. Mogą pojawić się rzeczy o których nie masz pojęcia i trzeba to pojęcie zdobyć. Czasami wystarczy poczytać, czasami trzeba się upewnić jakimś PoC.
Wtedy możesz zaprosić zespoły dev. na dyskusję o estymatach.

Całość kosztuje w cholerę kasy i czasu i dopiero wtedy teoretycznie możesz iść do klienta z ofertą. Problem w tym, że on może mieć już całkiem sporą część systemu dostarczoną przez innego dostawcę, który oszacował zgrubnie wartość projektu, dorzucił 20% marży i zaczął robić, przy okazji zdobywając informację o tym, czego klient naprawdę potrzebuje.

Tutaj ewidentnie developerzy są biznesem. Ale to jest kwestia umiejętności komunikacji, a nie biznesu, czy niebiznesu.

To popełniają błąd komunikując się z klientem za pomocą mistycznych SP, których klient nie rozumie, bo nawet programiści tego nie rozumieją.

Althorion napisał(a):

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!

Ale oszczędność czasu na czym? Zadania są różnej wielkości i trudności, kogo w ten sposób się oszuka? Samych siebie?

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.

Wydawało mi się, że dyskutujemy o estymowaniu zadań, nie o silent quittingu.

Co, gdzie, jak?

Zadałeś pytanie z tezą, więc ja też. Że to głupie, to nie moja wina. ;-]

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?

Ale skąd się nagle wzięła perspektywa lat?
Planuje się jeden, góra kilka sprintów naprzód, czyli 2-10 tygodni.

Po co rozumieć? No cóż, jest część ludzi, która nie chce rozumieć, co robi, zazwyczaj potem narzekają na forach, że mają w pracy jakieś głupie rozmowy o zdaniach, estymowanie i planowanie. Jest też część ludzi, która wie, co robi, a potem na forach nie narzeka.

piotrpo napisał(a):

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.

Chyba się nie zrozumieliśmy. Dla mnie MVP czegokolwiek to jest projekt, jak każdy inny. MVP ma jakiś cel i zakres, nie widzę powodu, dla którego nie można tego zaplanować, zaprojektować i wykonać w normalny sposób.

Już lepiej wyceniać w SP niż w Man Dayach, jak w pewnym smutnym korpo na S z siedziba w Katowicach, gdzie jak się pomyliłeś o dzień czy dwa to potem wielki płacz był na retro, a w dżirce bieda i rozpacz, bo tylko team lider chodził na wszelkie spotkania dotyczące ficzerow i pustka w tickecie, a na groomingu "no siema elo muszę lecieć na inne spotkanie", a po groomingu to też się nie pytaj co ma być zrobione bo nie mam czasu

Dla mnie SP są całkiem spoko z punktu widzenia developera. Zespół składa się z osób o różnej wydajności, więc wyceny w czasie są trochę bez sensu. SP mają ten plus, że w zazwyczaj w 2 tygodniowym sprincie zespół dowozi podobną ilość SP i łatwo dzięki temu określić capacity a przy wycenianiu też można sobie pozwolić na pewne uogólnienie bo finalnie się to w miarę uśredni. Jak w zespole jest zawodnik, który notoryczne zaniża wyceny to to też się z czasem uśredni bo po prostu zespół będzie dowoził mniej SP.

Problem zaczyna się, gdy klient chce wyceny rozbite na poszczególne taski i PM zaczyna przeliczać SP na czas.

Ogólnie metodologie Agile zostały stworzone raczej z myślą o pracy dla klienta wewnętrznego, gdzie rozwija się produkt. W software housach wszyscy wszystkim patrzą na ręce i ważniejsze od jakości staje się czas bo czas to pieniądz.

Moim zdaniem żadna metodologia wycen nie jest zła ani dobra, bo każda ma swoje wady i zalety - grunt aby z klientem grać do jednej bramki i dobrze sobie wytłumaczyć zasady, a to nie jest proste.

Chyba z 10 lat pracowałem w różnych projektach gdzie były story pointy.
Nie kojarzę jednej sytuacji żeby to było coś innego niż bezsensowna strata czasu.

W dużych projektach biznes planuje ficzery na kwartały i to co zespół pieprzy o planie na następny tydzień lub dwa nie ma żadnego znaczenia.
Jak trzeba coś zaplanować większego to bierze ludzi, którzy mają pojęcie (zazwyczaj max 2 w zespole) i pyta co się da zrobić za miesiąc, a co za pół roku.

W małych projektach wystarcza, że PO ustala priorytety i jest pod ręką. Jak ficzer okazuje się problematyczny (wydawało się proste, ale to bagno) to po prostu podejmuje decyzję w minutę czy brnąć czy robić coś innego. Żadne planowanie sprintów nie jest do niczego potrzebne.

I pomimo Story pointów, SCRUMów, policji agilowej itp. tak to się właśnie (przeważnie) rozsądnie odbywało. Byłem w projekcie gdzie pół dnia układało się sprint, który zwykle już po dwóch dniach był nieaktualny :-) A projekt i tak był całkiem spoko - PO był kompetentny, szybko ustalał priorytety, po prostu dużo się działo i dużo było niewiadomych (jebane mikroserwisy plus działająca produkcja).

Często ktoś pisze, że to planowanie i szacunki i tak zajmują mało czasu - np. paręnaście minut. Nadal to czas stracony. Poza tym zajmuje to może kilkanaście minut w tygodniu, ale poczucie zażenowania wysysa mi energię na pół dnia.

Tak mi się skojarzyło dlaczego zespoły robią wyceny w SP:

Mąż zauważył, że żona obcina kiełbasę z obu stron przed smażeniem.
- Czemu tak robisz? - pyta.
- Nie wiem, moja mama tak robiła.
Dzwonią do teściowej.
- Obcinałam, bo twoja babcia tak robiła.
W słuchawce słychać głos babci:
- Jeszcze nie kupiliście se, k..rwa, większej patelni?`

Kto jest u Was głównym konsumentem informacji o ilości SP ?

onomatopej napisał(a):

Już lepiej wyceniać w SP niż w Man Dayach, jak w pewnym smutnym korpo na S z siedziba w Katowicach, gdzie jak się pomyliłeś o dzień czy dwa to potem wielki płacz był na retro, a w dżirce bieda i rozpacz, bo tylko team lider chodził na wszelkie spotkania dotyczące ficzerow i pustka w tickecie, a na groomingu "no siema elo muszę lecieć na inne spotkanie", a po groomingu to też się nie pytaj co ma być zrobione bo nie mam czasu

Szacowanie pracochłonności w czasie jest jeszcze większym bezsensem niż te SP. Szacuje zespół, za zadanie zawsze wykonuje konkretny człowiek, więc:

• szacujemy ile komuś powinno zająć zrobienie czegoś
• nie wiemy ile HR'y zaplanują tzw. "szkoleń", a Scrum Commando retro-planning-refinement-**uje-muje-dzikie-węże
• Czy to powinno już uwzględniać czas na 1 i 2'kę

Na koniec tak jak już napisałeś, robota trwała 2 dni dłużej i tracimy dzień, bo trzeba zrobić root cause analysis dlaczego ktoś się spóżnił o 10% z zadaniem i jakie akcje powinniśmy wdrożyć, żeby uniknąć tego w przyszłości. W ramach tych akcji przyjdzie jakiś Uberscrumfuhrer i zacznie robić serię pogadanek o tym jak ważne jest estymowanie, bo gdybyśmy mieli zaplanowaną kampanię marketingową (ch... że nie mamy i nie będziemy mieć), to przecież biznes musi wiedzieć, bo byłby pieniądze wydane i może zmarnowane nawet.

W pewnym czasie firma próbowała wdrożyć XP (Extreme Programming), co ostatecznie nie wyszło, ale fajną rzeczą tam było estymowanie. Nie mieliśmy typowych SP, ale proste estymaty:

• 0 -> coś trywialnego, np zmiana configu
• 1 -> coś prostego, każdy w zespole już robił coś podobnego
• 2 -> coś bardziej skomplikowanego lub nowego, mogą być niewiadome, ale ogólnie wiadomo co zrobić
• 3 -> coś skomplikowanego, dużego, całkiem nowego, dużo niewiadomych, do rozbicia na mniejsze tickety lub najpierw do inwestygacji

Potem firma przeszła na typowego scruma i się zaczęły typowe SP. Jak dla mnie powyższe estymaty były najlepsze, bo każdy wiedział, o co chodzi i nie było debaty, czy coś powinno mieć X czy Y SP.

W globalnym korpo w którym spędziłem jakiś rok prowadzono eksperymenty w obszarze delivery. W projekcie do którego trafiłem było sporo rzeczy tworzonych od podstaw. Białe kołnierzyki doszły do wniosku, że do nowych ficzerów najlepszy będzie pair programming. Efektywność pracy w parach dało się utrzymać może przez tydzień czy dwa, a może w niektórych przypadkach trzy. Potem zaczęły się typowe sytuacje jak w każdym projekcie.

Co do planowania. Kto ma wiedzieć ten wie, że procesy pgoodowe da się przewidzieć dla danego obszaru z pewnym prawdopodobieństwem na dwa czy trzy dni do przodu. Potem złożoność tak rośnie, że możemy mówić o bardzo ogólnych przypuszczeniach. Dowolny projekt z zakresu software jest równie złożonym tematem, a my wciąż chcemy zaklinać rzeczywistość.

jarekr000000 napisał(a):

Często ktoś pisze, że to planowanie i szacunki i tak zajmują mało czasu - np. paręnaście minut. Nadal to czas stracony. Poza tym zajmuje to może kilkanaście minut w tygodniu, ale poczucie zażenowania wysysa mi energię na pół dnia.

To chyba wtedy rzucają wyceny bez sprawdzenia co to za task i co trzeba zrobić. U mnie wycena taska zajmuje od 2 minut do nawet 20-30 przy złożonych rzeczach. Ale pamiętajmy, to nie był prawdziwy agile, kolejnym razem się uda xD

SP to jest jednostka trudności zadania (takie jest oficjalne tłumaczenie) więc polecam zrobić sobie takie ćwiczenie: wy-estymować zadanie na 3sp a potem robić je dwa tygodnie bo przecież trudność jest na 3 tylko zajmuje tyle czasu. Zanotujcie sobie co powiedzą wasi koledzy i SM i PM/PO na taki stan rzeczy . Myślę że w dużej części poproszą was o reestymację taska na więcej SP a w dosłownie każdym przypadku będą pytać czemu to tyle zajmuje. Tyle jest z teorii, ale możemy sobie wmawiać że to nie był prawdziwy agile.

Tu jeszcze chciałbym poruszyć temat tego że 2 w projektach w których byłem mnóstwo czasu zostało przepalone na to żeby zespoły zdefiniowały kto jest ich klientem bo jak się okazuje jest to trudne. Finalnie wyszło na to że kasę na dniówki kilkudziesięciu osób zostały wydane, klient ustalony a potem wróciliśmy do tego samego backlogu który ustala jednak nie klient tylko góra xD

1000 razy powtórzone kłamstwo staję się prawdą a na 1000 wprowadzonych scrumów tylko jeden z nich obniża koszty.

pair programming to dobra technika do rozwiązywania bugów (debugowania) czy dzielenia się wiedzą ale pod następującym warunkiem:

• Osoba która chce się parować robi to dobrowolnie, oraz osoba proszona o sparowanie robi to dobrowolnie.
• Osoba prosząca może wybrać z kim się sparuje.
• Szanujemy wzajemnie swój czas, a sama praktyka jest ograniczona czasowo (dla mnie do max 2h na dzień).

Natomiast wszelkie wymuszanie tego typu pracy traktuje jako poważną ingerencje w prywatność oraz samodzielność pracownika.

Na koniec wy wszyscy apologeci technik XP pomyślcie sobie że jest upalny sierpniowy poniedziałek a wy musicie siedzieć sparowani z tym tłuściochem który przyjechał rano na rowerze lecz nie wziął prysznica, a na dodatek z japy jedzie mu czosnkiem...

0xmarcin napisał(a):

pair programming to dobra technika do rozwiązywania bugów (debugowania) czy dzielenia się wiedzą ale pod następującym warunkiem:

• Osoba która chce się parować robi to dobrowolnie, oraz osoba proszona o sparowanie robi to dobrowolnie.
• Osoba prosząca może wybrać z kim się sparuje.
• Szanujemy wzajemnie swój czas, a sama praktyka jest ograniczona czasowo (dla mnie do max 2h na dzień).

Zgadzam się, aczkolwiek nie tylko. Do standardowego developmentu też jest bardzo dobre.

0xmarcin napisał(a):

Natomiast wszelkie wymuszanie tego typu pracy traktuje jako poważną ingerencje w prywatność oraz samodzielność pracownika.

Takie opinie słyszę tylko od ludzi którzy nigdy nie stosowali PP. Jak ktoś tak popracuje przez kilka tygodni, to zaczyna to preferować (w większości).

0xmarcin napisał(a):

Na koniec wy wszyscy apologeci technik XP pomyślcie sobie że jest upalny sierpniowy poniedziałek a wy musicie siedzieć sparowani z tym tłuściochem który przyjechał rano na rowerze lecz nie wziął prysznica, a na dodatek z japy jedzie mu czosnkiem...

I rozwiązaniem na to jest odsunięcie się od niego? Czy może lepszym rozwiązaniem byłoby poprosić go o prysznic w pracy. Poza tym, nie musisz parować z kimś z kim nie chcesz - bylebyś parował z kimkolwiek.

Riddle napisał(a):

Poza tym, nie musisz parować z kimś z kim nie chcesz - bylebyś parował z kimkolwiek.

Czyli wychodzi że jednak muszę.

bagietMajster napisał(a):

Riddle napisał(a):

Poza tym, nie musisz parować z kimś z kim nie chcesz - bylebyś parował z kimkolwiek.

Czyli wychodzi że jednak muszę.

No nie musisz, kazać nikt Ci nie będzie.

Ale są twarde statystyki które pokazują że zespoły które regularnie dzień w dzień stosują Pair Programming dostarczają więcej feature'ów i mniej bugów, rzędu kilkudziesieciu procent.

Consequently, there was no evidence of an "assembly bonus effect," where the performance of a collaborating pair exceeds the performance of its best member working alone. While this finding may appear counterintuitive due to the general perception of two heads being better than one, it is consistent with the findings in small group research

https://www.jstor.org/stable/20650280

0xmarcin napisał(a):

Consequently, there was no evidence of an "assembly bonus effect," where the performance of a collaborating pair exceeds the performance of its best member working alone. While this finding may appear counterintuitive due to the general perception of two heads being better than one, it is consistent with the findings in small group research

https://www.jstor.org/stable/20650280

No wiadomo że dwie osoby nie napiszą szybciej tego co jedna osoba, powiedzmy w ramach jednego zadania - ale nie po to stosuje się Pair Programming.

Owszem - para piszę jeden dany feature trochę wolniej niż jedna osoba, i to jest prawda. Czyli dwie osoby osobno napiszą po jednym tasku szybciej, niż dwie osoby w parze napiszą te same dwa taski razem. Także Twój cytat jest prawdziwy. I gdyby firmy wynajmowały nas na ten jeden task to miałbyś 100% rację.

Tak jednak nie jest - jak pracujemy w firmie, to robimy task, za taskiem. Często dostarczamy ich kilkaset. I teraz problem jest taki, że taski dostarczone przez jedną osobę są dużo niższej jakościi, mają niższe pokrycie testami, są gorzej zaprojektowane, i często mają więcej bugów. Przez co task dowieziony przez taką jedną osobę jest mniej warty, bo i tak ktoś potem będzie musiał to poprawić - np. buga, albo zapłacić dużo dłuższy debugging żeby się przeżreć przez ten kod.

Także owszem - stosując PP robimy każdy task trochę wolniej, tak. Ale za to mamy dużo lepszy software, który w niedalekiej przyszłości okaże się dużo łatwiejszy, prostszy, tańszy i szybszy do zmian. Przez co np. zespół który stosuje PP przez pierwszych kilka tasków będzie wolniejszy, ale nie zostanie zatrzymany przez mess który osoby pracujące samemu zrobią. Np za miesiąć lub dwa wyjdzie bug, którego naprawienie zajmie 2 tygodnie, ale w zespole stosującym PP czegoś takiego nie będzie (a przynajmniej szansa na to jest bardzo mała).