Odmówienie podania wyceny/estymaty/story pointów

2

Mieliśmy planning w pracy podczas którego z grubsza umówiliśmy co trzeba zrobić w kolejnym Sprincie. Jak to zwykle bywa niektóre taski miały zwykły tytuł i np. 3 podpunkty. Przykład:

Stwórz nowy mikroserwis i zintegruj się z usługą zewnętrzną po SOAP i przemapuj takie pola i wyślij Event na message brokera.

Dla mnie takie taski są jak najbardziej wykonalne, jestem samodzielny, mówię biegle po angielsku, jak coś to z Product Ownerem nieraz gadam 1-1 w celu wyjaśnienia wymagań. Zazwyczaj wyceniałem te taski zbyt optymistycznie, przez co zazwyczaj siedziałem teraz na pracy zdalnej nadgodziny, ukryte, aby coś dowozić w czasie. Zauważyłem, że podczas tych wycen nie brałem pod uwagę, zbierania wymagań, nauki, poznania technologii, testów... po prostu zazwyczaj wyceniałem optymistycznie, ale potem okazywało się to dla mnie pułapką, bo dla managera jest to tak jakby "wstępny termin". No i przez te Story Pointy, Sprinty co dwa tygodnie nakładałem sam na siebie presję by coś dowozić średnio co dwa tygodnie. Od roku notorycznie przez to robiłem nadgodziny darmowe.

Dzisiaj podczas Daily zbuntowałem się i powiedziałem, że nie będę wyceniał taska ani tworzył sobie sam "deadline"u. Cała scena na Daily zamarzła, manager zaczął coś mówić że jesteśmy zespołem Scrum i że musimy dzielić codziennie statusy i wyceniać taski. Potem ja coś odparłem, że mimo to mogę wziąć taska, przypisać na siebie, robić swoim tempem i kiedy skończę to skończę, a jak coś to będę uderzać do programistów, czy do kogoś bezpośrednio. Odpowiedziałem tak dwa razy jak zdarta taśma.

Potem jeszcze zacząłem temat bo się wkurzyłem, dlaczego tylko my we czwórkę z programistów w tym bierzemy udział, a oni nie? Powiedziałem mu wtedy, że codziennie tylko my we czwórkę dzielimy się statusami, a analityk, ani on, ani sm się z nami nie dzielą. Tutaj już nie wiedział co odpowiedzieć. Ogólnie to chciałem się zwierzyć, nie wiem jak to będzie w projekcie, czy mnie zwolnią czy nie, ale przynajmniej chciałem opowiedzieć jak dzisiaj miałem na Daily.

16

Jest tu kilka problemow, tylko że nie samej konieczności wyceniania. Problemy:

  1. założenie, że jeśli coś estymujesz to musisz to dowieźć
  2. nadgodziny, o które nikt nie prosił
  3. za niskie wyceny

Zamiast iść na wojnę z wycenami możesz tak samo jak większość z nas mieć wywalone w wyceny, estymować pesymistycznie, a nawet jeśli będziemy zbyt dużymi optymistami w tym pesymizmie to po prostu kończyć rzeczy w kolejnym sprincie.

Scrum jest narzędziem do tego, żeby developerzy się nie przemęczali, a jednak przez jakiś syndrom Sztokholmski ludzie biorą więcej niż są w stanie dostarczyć. Sam sobie zgotowales ten los.

3

Podszedles do tego troche nieprofesjonalnie, ale gdyby mieli Cie za to zwolnic to znaczy, ze i tak lepiej nie pracowac w takiej firmie.

Rob wieksze estymaty. Wszystko zalezy od tego jak wyglada wasza praca zespolowa. Jezeli jest to temat, ktory czujesz ze jestes w stanie zrobic, ale wiesz ze pare rzeczy musisz doczytac, przyswoic itd. to jasno to zakomunikuj. Jestes doroslym czlowiekiem, zgaduje ze nie stazysta ktory nie ma pojecia co sie robi i na samym pull requescie moze sie zaciac na 3 dni.

Inna sprawa jest taka, ze jezeli ktos nie wie po co robi te wszystkie estymaty, a jedynym argumentem jest manager zaczął coś mówić że jesteśmy zespołem Scrum i że musimy dzielić codziennie statusy i wyceniać taski. to znaczy, ze pracujesz w jakims pato scrumie przypominajacym kult, a nie narzedzie ktore ma pomagac.

2

Ogarniasz jak wykorzystywane sa story points? Co robicie z nimi na retrospekcji?

4

Jak czegoś nie potrafisz wyestymować z jakimś seksownym sensownym marginesem błędu to znaczy, że zadanie jest za duże i należy je podzielić. Ja bym zaczął od rozpoznania API klienta, potem przygotowanie implementacji (na podstawie poprzedniego rozpoznania) itd itp. Moim zdaniem postąpiłeś bardzo nieprofesjonalnie. Trochę ja dziecko w przedszkolu co tupie nóżką, że nie pójdzie spać.
Takie rzeczy rozwiązuje się przed dyskusje i negocjacje a nie wciskanie kolanem swojego widzimisię, bo to nie doprowadzi do niczego.

Co do brania udziału w stundapach to im mniej ludzi tym lepiej. Poza tym spotkania te nie służą tylko do monitorowania postępu prac, ale też przedyskutowania na forum całego zespołu ewentualnych problemów. Chodź moim zdaniem SM powinien być, aby ewentualne obsuwy raportować do PO i dopilnować porządku na spotkaniu.

0

Prosta metoda to swoje wyceny mnóż x2 albo x3 tak aż zaczniesz się mieścić z zadaniami. Po jakimś czasie będziesz wiedział, że z twoim optymizmem wycenę musisz dać x2.5 i będzie do zrobienia w normalnym czasie

Oczywiście mnożnik do indywidualnego ustalenia zależnie jak bardzo się mijasz wycenami

5

Stwórz nowy mikroserwis i zintegruj się z usługą zewnętrzną po SOAP i przemapuj takie pola i wyślij Event na message brokera.

To jest epopeja a nie task (czytaj jest o wiele wiele wiele za duży). To trzeba podzielić, inaczej jak to wyestymujesz.

Krótki poradnik jak radzić sobie z fanatykami religijnymi (Scrum):

  1. Zadania powinny być małe
  2. Estymujesz w złożoności a nie w czasie, więc o żadnym deadline'nie nie ma mowy (storypoint != dupogodzina).
  3. Velocity liczone na podstawie storypointów mówi ile średnio zespół jest w stanie dowieść
  4. Na tematy nowe i niezbadane robi się spike'i - czyli zadania badawcze, ograniczone w czasie np. 1 - 2 dni

Zadanie musi być dobrze opisane, w szczególności musi mieć Definition of done, jak bez tego ty możesz to w ogóle estymować?

Powodzenia, nie wiem czy Ci się to uda przepchać - widać że firma używa Scruma jako bicza. Nie bierz darmowych nadgodzin, nie psuj branży.

9

Czasami nie wierzę, jak w czasach wszechobecnego Scrumu można robić darmowe nadgodziny, a nie oficjalnie się obijać i zgarniać za to pochwały (podejrzewasz, że task zajmie 2 dni? Wyceń na 4 dni, zrób w 3 dni - masz 1 dzień wolny + pochwałę).

4

Znów: wiem że plucie na scruma zawsze jest w cenie ale tutaj problem jest zupełnie inny:

  1. Story pointy TO NIE JEST WYCENA CZASOWA! To jest wycena "względnego wysiłku" i po sprincie powinniście podliczyć ile "story pointów udało się zrobić" i na tej podstawie okreslić "velocity" zespołu. Jeśli wyceniliście w sprincie zadania na 20 story pointów, ale dowieźliście tylko 15, to znaczy ze wasze velocity to 15 i na następny sprint po wycenach bierzecie sobie tasków na 15 story pointów. Jeśli wyceniacie taski w "dniach" to nic z tego nie będzie.
  2. Czy ktoś stoi nad robą z batem? xD Nie zdążyłeś zrobić taska to nie zdążyłeś i tyle. Widocznie przeestymowaliście i trzeba będzie to omówić na retro i tyle. Nie robisz zadnych nadgodzin, jak się nie udało to się nie udało. Task nie zając, nie ucieknie. Wrócisz do niego jutro i tyle.
  3. W ogóle nie wycenia się tasków które nie są dobrze zdefiniowane z jasnymi wytycznymi i kryteriami akceptacyjnymi. Jeśli masz task co do którego trzeba będzie latać i z Product Ownerem nieraz gadam 1-1 w celu wyjaśnienia wymagań to w ogóle nie ma mowy o wycenianiu go, bo niby na jakiej podstawie?
3

Ja jestem zwolennikiem pełnej transparentności i mówię wprost, że owszem to zadanie było na 2 SP, ale założyliśmy, że w module B metoda xyz() zwraca UUID a okazało się, że jednak nie i implementacja po nowemu zajmie około 5-8SP, wtedy już sobie product owner decyduje czy idziemy dalej w las czy może są inne priorytety. Tak samo jak ktoś był pewien, że ogarnie jenkinsa, a jednak nie dostał uprawnień, to sorry, nie jego wina. Potem jest pole do dyskusji na retro czy pod większe zadania robić POC albo spike, albo niech ktoś z przełożonych ogarnia lepiej dostępy, bo tracimy czas.

0

Kult zapierdalania i kłócenia się wśród Polaków wiecznie żywy. Nie chce mi się powtarzać kolejny raz tego samego, ale kilka uwag ode mnie.

  1. W estymacji nie chodzi o to, żeby zgadnąć ile zajmie dana historyjka tylko chodzi o to, żeby estymata była większa niż to ile faktycznie zajmuje historyjka. Wtedy łatwiej managerowi oszacować ile zajmie cały projekt.
  2. Jeżeli widzę, że programista zawsze zaniża estymaty to przy którymś razie w formie żartu mu mówię "widzę, że mamy ochotnika do tej historyjki" i robię mu ostre review i pilnuję czy wszystko dopiął, po takiej sesji zaczyna rozumieć, że szacowanie projektu to nie jest konkurs mierzenia kutasa.
  3. Nie pytaj analityków dlaczego nie dzielą się statusami (bo samo to pytanie z siebie jest już pójściem na konfrontację). Zamiast tego zapytaj się ich po prostu jaki jest ich status.
7

Pomijając już fakt, że to nie jest task tylko kilka historyjek, to rodzą się np. takie pytania:

  1. czemu estymowanie było na daily?
  2. co na callu w sprawie estymowania robił manager?
  3. skoro jedna osoba estymuje taski, to co robią pozostałe?
4
Manualek napisał(a):

Zazwyczaj wyceniałem te taski zbyt optymistycznie, przez co zazwyczaj siedziałem teraz na pracy zdalnej nadgodziny, ukryte, aby coś dowozić w czasie.

To ma sens, jeśli masz płacone za efekt jak na freelance. Wyestymujesz zbyt optymistycznie - robisz po nocach, żeby zdążyć. Coś jest łatwiejsze, niż się wydawało - to zrobisz coś szybciej i będziesz miał więcej czasu wolnego.

Ale jeśli rozliczasz się za spędzony czas w pracy, jak to zwykle bywa na etacie, to nie ma żadnej potrzeby, żeby coś takiego odwalać. Płacą ci za to, że jesteś dostępny w określonych godzinach i coś tam robisz, a nie za to, że zrobisz konkretną funkcjonalność. Pomyśl o odwrotnej sytuacji - co jeśli byś coś zrobił zbyt szybko? To, co estymowałeś na 5 dni, zrobiłeś w 1 dzień? Czy firma pozwoli ci się obijać w pozostałe 4 dni? Wątpię (no chyba, że mają chaos organizacyjny albo jeśli będziesz dobrze markował pracę i się nie skapną. Opieprzanie się tak, żeby nikt nie zauważył, to też sztuka).

8

Ja bym chciał zwrócić uwage w sumie na to ze tylko inzynierowie musza sie 'tlumaczyc' na daily. Powiedzmy ze w 'daily' uczestniczy SM i Manager.
Skoro wszyscy jestesmy teamem i wszyscy pracujemy nad produktem itp itd. To zadaje sobie pytanie ? "Czemu SM lub Manager nie dzieli się swoim statusem i tym co robil wczoraj i co bedzie robil dzisiaj i jaki sa blokery itp itd ?"

Tak wiem ze SM lub manager niby odpowiada za powodzenie calego "przedsiewziecia" no ale jak sie nad tym zastanowic to ja tez chce wiedziec co on robi ? i jakie to przynosi efekty dla mnie i mojego zespolu ? No bo skoro wszyscy "jestesmy zespolem" to czemu sa rowni i rowniejsi.

Czemu manager czy SM zadaje pytanie i to jest naturalna postawa a jak inzynier zadaje pytania to jest "zdziwienie" ktore nastepnie przeradza sie w ty "nie rozumiesz Scruma" ...
Chodzi mi o to ze ta relacja jest 'jednostronna' i prace inzynierow sie wycenia i oczekuje sie estymat a prace SM/Manager nie jest estymowana i jego praca i odpowiedzialnosc sie po prostu "rozmywa" - a te typowe managerskie/sm-owe "pomagam zespolowi" to odbieram tak jakbym ja na daily mowil "pisze oprogramowanie i co mi zrobisz szmato ?!" :P

4

No bo scrum to narzędzie pozwalające managementowi na łatwą mikrokontrolę pracowników, poprzez właśnie daily, spowiadanie się ile czego się zrobiło i czemu tak długo itd. Wszystko pod płaszczykiem dobrych praktyk i mitów o autonomicznych zespołach, które same sobie wymyślają co mają robić i same sobą rządzą (a jak jest to każdy kto pracuje w branży, ten wie). Ale jak zauważyłeś, szefostwo już się spowiadać nie musi i oni nie są rozliczani. Programiści ich nienawidzą - managerowie odkryli jeden prosty trik ;)

0

Jak nie masz dobrze zdefiniowanego zadania to odmowa wyceny, albo zaporowa wycena moim zdaniem jedynym słusznym podejściem.

PO spowiada się wyżej i dlatego mu zależy by być poinformowanym jak projekt idzie i jakie szacunki są na najbliższą przyszłość.
Najmniej lubię Scrum Masterów nie czuję potrzeby takiej roli, w najlepszym wypadku pomoże ustawić kilka spotkań i Jirę w najgorszym są poganiaczami zespołu z różnymi głupimi gadkami motywacyjnymi...

1

@DolBo:

Czemu manager czy SM zadaje pytanie i to jest naturalna postawa a jak inzynier zadaje pytania to jest "zdziwienie" ktore nastepnie przeradza sie w ty "nie rozumiesz Scruma" ...

od kiedy ktokolwiek zadaje pytania na daily?

To zadaje sobie pytanie ? "Czemu SM lub Manager nie dzieli się swoim statusem i tym co robil wczoraj i co bedzie robil dzisiaj i jaki sa blokery itp itd ?"

u mnie zawsze wszyscy obecni na scrumie dzielili się tym co robili/będą

1
DolBo napisał(a):

Ja bym chciał zwrócić uwage w sumie na to ze tylko inzynierowie musza sie 'tlumaczyc' na daily. Powiedzmy ze w 'daily' uczestniczy SM i Manager.
Skoro wszyscy jestesmy teamem i wszyscy pracujemy nad produktem itp itd. To zadaje sobie pytanie ? "Czemu SM lub Manager nie dzieli się swoim statusem i tym co robil wczoraj i co bedzie robil dzisiaj i jaki sa blokery itp itd ?"

Tak wiem ze SM lub manager niby odpowiada za powodzenie calego "przedsiewziecia" no ale jak sie nad tym zastanowic to ja tez chce wiedziec co on robi ? i jakie to przynosi efekty dla mnie i mojego zespolu ? No bo skoro wszyscy "jestesmy zespolem" to czemu sa rowni i rowniejsi.

Czemu manager czy SM zadaje pytanie i to jest naturalna postawa a jak inzynier zadaje pytania to jest "zdziwienie" ktore nastepnie przeradza sie w ty "nie rozumiesz Scruma" ...
Chodzi mi o to ze ta relacja jest 'jednostronna' i prace inzynierow sie wycenia i oczekuje sie estymat a prace SM/Manager nie jest estymowana i jego praca i odpowiedzialnosc sie po prostu "rozmywa" - a te typowe managerskie/sm-owe "pomagam zespolowi" to odbieram tak jakbym ja na daily mowil "pisze oprogramowanie i co mi zrobisz szmato ?!" :P

No to są raczej pytania do Ciebie, a na końcu powinieneś sobie też zadać pytanie, czemu pracujesz w gównianej firmie, w której managerowie wywyższają się ponad zespół i nawet nie dzielą się statusem?

jackson-mike napisał(a):

No bo scrum to narzędzie pozwalające managementowi na łatwą mikrokontrolę pracowników, poprzez właśnie daily, spowiadanie się ile czego się zrobiło i czemu tak długo itd. Wszystko pod płaszczykiem dobrych praktyk i mitów o autonomicznych zespołach, które same sobie wymyślają co mają robić i same sobą rządzą (a jak jest to każdy kto pracuje w branży, ten wie). Ale jak zauważyłeś, szefostwo już się spowiadać nie musi i oni nie są rozliczani. Programiści ich nienawidzą - managerowie odkryli jeden prosty trik ;)

Hmm, ale kto w sumie twierdził, że programiści sami sobie mają wymyślać pracę?

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

Ja bym chciał zwrócić uwage w sumie na to ze tylko inzynierowie musza sie 'tlumaczyc' na daily. Powiedzmy ze w 'daily' uczestniczy SM i Manager.
Skoro wszyscy jestesmy teamem i wszyscy pracujemy nad produktem itp itd. To zadaje sobie pytanie ? "Czemu SM lub Manager nie dzieli się swoim statusem i tym co robil wczoraj i co bedzie robil dzisiaj i jaki sa blokery itp itd ?"

Tak wiem ze SM lub manager niby odpowiada za powodzenie calego "przedsiewziecia" no ale jak sie nad tym zastanowic to ja tez chce wiedziec co on robi ? i jakie to przynosi efekty dla mnie i mojego zespolu ? No bo skoro wszyscy "jestesmy zespolem" to czemu sa rowni i rowniejsi.

Czemu manager czy SM zadaje pytanie i to jest naturalna postawa a jak inzynier zadaje pytania to jest "zdziwienie" ktore nastepnie przeradza sie w ty "nie rozumiesz Scruma" ...
Chodzi mi o to ze ta relacja jest 'jednostronna' i prace inzynierow sie wycenia i oczekuje sie estymat a prace SM/Manager nie jest estymowana i jego praca i odpowiedzialnosc sie po prostu "rozmywa" - a te typowe managerskie/sm-owe "pomagam zespolowi" to odbieram tak jakbym ja na daily mowil "pisze oprogramowanie i co mi zrobisz szmato ?!" :P

No to są raczej pytania do Ciebie, a na końcu powinieneś sobie też zadać pytanie, czemu pracujesz w gównianej firmie, w której managerowie wywyższają się ponad zespół i nawet nie dzielą się statusem?

To prawda powinienem reagować i zadawać konkretne pytania o efekty pracy/status etc. Sam swoim działaniem tj. jego brakiem dałem się sprowadzić do takiego poziomu.
A co do "gównianej firmy" - podjąłem już odpowiednie kroki - jestem na wypowiedzeniu ;)

1a2b3c4d5e napisał(a):

@DolBo:

Czemu manager czy SM zadaje pytanie i to jest naturalna postawa a jak inzynier zadaje pytania to jest "zdziwienie" ktore nastepnie przeradza sie w ty "nie rozumiesz Scruma" ...

od kiedy ktokolwiek zadaje pytania na daily?

Poza odklepaniem 'co robilem/co robie/blockery' zdarzaja sie jakies kilku minutowe ustalenia/pytania o rozne tematy ktore trzeba poruszyc.

0

Na daily wyceniacie taska?

no more estimates

1

Ostatnio z klientem klienta rozmawiam - po ustaleniu dokładnych wymagań - chcą wycenę.
Idę do dev teamu i Ci mi mówią 8 story pointsów - ja na to i co mam z tym zrobić? Chce w ilości dni. Jak pójdę do klienta i powiem, potrzebuję budżetu na 8 story pointsów to oni mają mieć budżet na 1, 5 czy 10k euro developmentu?

Klient klienta, który zamawia usługę płaci za mandaye i potrzebuje zaalakować budżet na ich pracę - niestety trzeba wycenę podać w dniach.

Zgadzam się, że z opisami co tutaj są - to do estymat "eksperckich" to to jest spotkanie na 20-30 min max, 2-3 ekspertów, którzy rzucają sobie złożonością po 1-2 minutach przeczytania taska, ale raczej na zasadzie dni, tygodnie, miesiące.

Nie wiem jak można mówić o "wycenie" - bez dokumentu analizy i projektu realizacji, przecież trzeba poświęcić 1-3+ dni na zaprojektowanie, doczytanie, przeczytanie kodu, to jest taki prework, bez którego nikt nie wie ile jest do zrobienia. Już nie mówiąc o WorkBreakdown. Choćby to zadanie od OP'a - no trzeba przeczytać dokumentację tego zewnętrznego serwisu.

Nie rozumiem czemu byście dzielili tego taska na kilka historyjek:

  • stworzenie mikroserwisu - to odpalenie skryptu inicjalizującego projekt serwisu - 15 min?
  • integracja z zewnętrznym serwisem + przemapowanie danych + wrzucenie do brokera - no to jest właściwe mięcho, które sugeruje, że integrujemy jakiś 1 endpoint API - ja tutaj najwyjżej bym podzielił, gdyby dało się na więcej niż 1 jednostkę wdrożeniową to podzielić, aby dało się albo zrównoleglić pracę, lub to wdrażać automatem małymi kawałkami
4
MuadibAtrides napisał(a):

Ostatnio z klientem klienta rozmawiam - po ustaleniu dokładnych wymagań - chcą wycenę.
Idę do dev teamu i Ci mi mówią 8 story pointsów - ja na to i co mam z tym zrobić? Chce w ilości dni. Jak pójdę do klienta i powiem, potrzebuję budżetu na 8 story pointsów to oni mają mieć budżet na 1,
5 czy 10k euro developmentu?

Klient klienta, który zamawia usługę płaci za mandaye i potrzebuje zaalakować budżet na ich pracę - niestety trzeba wycenę podać w dniach.

Bo SCRUM nie jest do wszystkiego. Ale tak naprawdę po pojemności sprint jego długości itp można wyliczyć ile kosztuje jeden story point.

Nie wiem jak można mówić o "wycenie" - bez dokumentu analizy i projektu realizacji, przecież trzeba poświęcić 1-3+ dni na zaprojektowanie, doczytanie, przeczytanie kodu, to jest taki prework, bez którego nikt nie wie ile jest do zrobienia. Już nie mówiąc o WorkBreakdown. Choćby to zadanie od OP'a - no trzeba przeczytać dokumentację tego zewnętrznego serwisu.

Tu podzieliłeś zadanie na mniejsze

Nie rozumiem czemu byście dzielili tego taska na kilka historyjek:

  • stworzenie mikroserwisu - to odpalenie skryptu inicjalizującego projekt serwisu - 15 min?
  • integracja z zewnętrznym serwisem + przemapowanie danych + wrzucenie do brokera - no to jest właściwe mięcho, które sugeruje, że integrujemy jakiś 1 endpoint API - ja tutaj najwyjżej bym podzielił, gdyby dało się na więcej niż 1 jednostkę wdrożeniową to podzielić, aby dało się albo zrównoleglić pracę, lub to wdrażać automatem małymi kawałkami

A tu twirdzisz że jest to zbędne.

10

@MuadibAtrides:

Idę do dev teamu i Ci mi mówią 8 story pointsów - ja na to i co mam z tym zrobić? Chce w ilości dni. Jak pójdę do klienta i powiem, potrzebuję budżetu na 8 story pointsów to oni mają mieć budżet na 1, 5 czy 10k euro developmentu?

No nie wiem, może masz wykonać swoją pracę o_O? Skoro jesteś jakimś SMem to powinieneś prowadzić ewidencje velocity zespołu, czyli informacje o tym ile story pointów udawało się dowozić w ostatnich sprintach i na tej podstawie może mniej więcej wymierzyć ile sprintów potrzeba na te 8 story pointów.
Albo powinieneś mieć na tyle doświadczenia i na tyle znajomość swojego zespołu że wiesz mniej więcej ile to zajmie.
Zawsze śmieszą mnie wszelkiej maści wielcy "managerowie" którzy robią wielce zdziwioną minę jak się okazuje, że oni też muszą wykonać jakąś pracę a nie tylko rozkazywać i oczekiwać że ktoś zrobi za nich xD

stworzenie mikroserwisu - to odpalenie skryptu inicjalizującego projekt serwisu - 15 min?

xD Szkoda to nawet komentować.

integracja z zewnętrznym serwisem + przemapowanie danych + wrzucenie do brokera - no to jest właściwe mięcho, które sugeruje, że integrujemy jakiś 1 endpoint API - ja tutaj najwyjżej bym podzielił, gdyby dało się na więcej niż 1 jednostkę wdrożeniową to podzielić, aby dało się albo zrównoleglić pracę, lub to wdrażać automatem małymi kawałkami

Czy ty w ogóle wiesz o czym mówisz? A jak ten zewętrzny serwis w ogóle nie ma żadnego API? Albo jak można sie z nim komunikowac tylko CORBą albo gołymi socketami? :D Może się okazać ze trzeba to będzie podzielić a 100 historyjek i będzie klepania na pół roku, a może się okazać że zewnętrzny serwis ma już programowego klienta pod nasz język i zepniemy to 1 dzień z buta.

1
jackson-mike napisał(a):

Jak proszą mnie o wycenę story pointów, to zawsze odmawiam, powołując się na klauzulę sumienia.

W niemieckim zespole tak robiłem przez rok, potem niestety musiałem opóścić ten projekt :(
Teraz mówię 3. 3 jest prawie zawsze dobrą odpowiedzią w obecnym projekcie :P
No, ale to projekt produktowy, a nie dla klienta na zamówienie więc nie trzeba uzasadniać każdej godziny :D

3
MuadibAtrides napisał(a):

Ostatnio z klientem klienta rozmawiam - po ustaleniu dokładnych wymagań - chcą wycenę.
Idę do dev teamu i Ci mi mówią 8 story pointsów - ja na to i co mam z tym zrobić? Chce w ilości dni. Jak pójdę do klienta i powiem, potrzebuję budżetu na 8 story pointsów to oni mają mieć budżet na 1, 5 czy 10k euro developmentu?

To chyba matematyka do ogarnięcia w szablonie excelowym?

TS = Rozmiar Zespołu (ilość ziomków)
DSP = Ilość SP, który zespół dostarcza w sprincie
SD = długość sprintu (dni)

DSP / SD - tyle SP dostarcza na dzień

8* SD / DSP - tyle dni zespół będzie dostarczał te 8 story pointów (flashback z fizyki: czas = droga / prędkość )

8* TS * SD / DSP - tyle mandaysów ?

1

@yarel: te wzory są szczególnie dobre do fabryki cegieł.

1

@Manualek:

  1. Ty jako developer masz co najwyżej komunikować, jaka jest złożoność zadania i dbać o to by zadanie były dobrze przedyskutowane i przemyślane.
  2. Złożoność podawajcie w jednostce oderwanej od czasu np. T-shirt size: S, M, L, XL (do rozbicia), żeby żadnemu słabemu managerowi nie przyszło do głowy tego tłumaczyć na czas.
  3. Najważniejszym pytaniem w Agile / Scrum jest to, czy budujemy odpowiednią rzecz, jaką klient i rynek potrzebuje. I czy potrafimy szybko zmienić kierunek.
  4. Pytanie, jak szybko i na kiedy, zostaw managerom, powinni oni wiedzieć, jak zespół dostarcza i szacować jak długo zajmie dowiezienie czegoś.
  5. Nie pracuj po godzinach, rób zadania porządnie, codziennie komunikuj kolegom, jak Ci idzie, szczególnie podkreślając przeszkody.

Twoje zachowanie nie było dobre. Za dużo energii i nerwów przeznaczyłeś na nieistotny z punktu widzenia developmentu szczegół. Powinieneś próbować, łagodnie skierować projekt na lepsze tory, proponując powyższe usprawnienia.

1

@Shalom:

Story pointy TO NIE JEST WYCENA CZASOWA! To jest wycena "względnego wysiłku" i po sprincie powinniście podliczyć ile "story pointów udało się zrobić" i na tej podstawie okreslić "velocity" zespołu. Jeśli wyceniliście w sprincie zadania na 20 story pointów, ale dowieźliście tylko 15, to znaczy ze wasze velocity to 15 i na następny sprint po wycenach bierzecie sobie tasków na 15 story pointów. Jeśli wyceniacie taski w "dniach" to nic z tego nie będzie.

chyba w jednym jedynym projekcie SP traktowano jak powinny być traktowane - wszędzie indziej 1 SP to był równoważnik wyceny czasowej (najczęściej 1SP to 1MD) - OK tak być nie powinno, ale kop się z ludźmi z 2,3 lokalizacji, z zastaną "kulturą" itd :) - jak się wchodzi między wrony trzeba krakać jak i one

Czy ktoś stoi nad robą z batem? xD Nie zdążyłeś zrobić taska to nie zdążyłeś i tyle. Widocznie przeestymowaliście i trzeba będzie to omówić na retro i tyle. Nie robisz zadnych nadgodzin, jak się nie udało to się nie udało. Task nie zając, nie ucieknie. Wrócisz do niego jutro i tyle.

tu znowu teoria jedno, praktyka drugie - programista jest zawsze winny :) - co z tego, że łatwo zmienić pracę itd, jak i tak zjeba będzie, nerwów trochę się straci itd
Była okazja posłuchać paru wyjaśnień BA, PM czy jak ich tam zwą czemu nie dowiezione - a bo oni......
Marketing coś sprzeda - dev o tym nie wie nawet - ale i tak to wina zespołu dev, że nie dowiózł
i to jeszcze pół biedy
Najgorsza rzecz to kozioł ofiarny - dwa razy takie coś widziałem, bo to on.......

nie wnikam w umiejętności techniczne itp itd - chodzi o fakt, w sytuacjach podbramkowych, to narracja była taka, że wszystko było dogadane, przygotowane tylko te one, programisty zawiodły

tu potwierdzają się stare prawdy - jak się ma miękkie serce to trzeba mieć twardą dupę, pokażesz raz - będzie wymagane już cały czas, kierownik to nie kolega, wśród serdecznych przyjaciół psy zająca zjadły
ale to już zupełnie inna para kaloszy - asertywność, odporność na manipulacje itd

W ogóle nie wycenia się tasków które nie są dobrze zdefiniowane z jasnymi wytycznymi i kryteriami akceptacyjnymi. Jeśli masz task co do którego trzeba będzie latać i z Product Ownerem nieraz gadam 1-1 w celu wyjaśnienia wymagań to w ogóle nie ma mowy o wycenianiu go, bo niby na jakiej podstawie?

W swoim życiu zawodowym spotkałem jednego, słownie jednego TL, który miał takie podejście, reszta - na zasadzie, dla świętego spokoju coś tam się powie i będzie
nie mówię że to jest podejście dobre
uważam, ze ono jest trudne do zrealizowania - bo taki typowy dev to człowiek z komputerem chowany, nie rozumie ludzkiej mowy, tych gierek, manipulacji, taki jest odbiór, że jak ktoś miły to go lubi szczerze, a nie że chce czegoś od niego, chce mieć święty spokój i w imię tego spokoju na różne rzeczy się godzi.

Najgorsze jest to, jak nie ma zrozumienia wśród kolegów
otóż w jednym z projektów w sytuacji estymacji - mówię nie, moja estymacja i tak była by g**no warta teraz, bo świeżak ze mnie, jak mnie koledzy po fachu zaczęli do pionu stawiać, że tak nie można, że to nieprofesjonalne itp itd - i Herkules dupa kiedy ludzi kupa, co było robić, wyciągało się te karty i tyle

2
MuadibAtrides napisał(a):

Nie rozumiem czemu byście dzielili tego taska na kilka historyjek:

Bo w końcu pracujemy w scrumie, więc chcemy dowozić jak najszybciej, śledzić postęp na bieżąco, a inni członkowie zespołu muszą widzieć te postępy.
Bez Scruma można nie dzielić, zamknąć się w piwnicy na tydzień i oddać skończone rozwiązanie. Ja bym nawet tak wolał. Tylko jak płacą mi za X, to robię X, a nie udaję.

  • stworzenie mikroserwisu - to odpalenie skryptu inicjalizującego projekt serwisu - 15 min?

I rozumiem, że po tych 15 minutach https://api.firma.com/probe zwraca healthy?

nie100sowny napisał(a):
  1. Złożoność podawajcie w jednostce oderwanej od czasu np. T-shirt size: S, M, L, XL (do rozbicia), żeby żadnemu słabemu managerowi nie przyszło do głowy tego tłumaczyć na czas.

Zamiast S, M, L i XL można też użyć 1, 2, 3 i 5 SP. Łatwiej potem liczyć średnią, bo z zestawu rzymskich cyfr + S nie bardzo.

A literki nie przeszkodzą słabemu managerowi w wysnuciu głupich wniosków.

zimna pitulka napisał(a):

tu znowu teoria jedno, praktyka drugie - programista jest zawsze winny :) - co z tego, że łatwo zmienić pracę itd, jak i tak zjeba będzie, nerwów trochę się straci itd

Sugeruję nie zatrudniać się u januszy, to nie będzie klęczenia w kącie na grochu.

4

stworzenie mikroserwisu - to odpalenie skryptu inicjalizującego projekt serwisu - 15 min?

Ha ha hahaha chłe chłe chłe hihi hi hi hi LOLs

Wygenerowanie szablonu może i tak, jak skrypt jest dobry to stworzy też repozytorium i ogarnie Dashboardy, Jenkinsa i JIRĘ. No ale teoria jedno a praktyka drugie.

Kilka rzeczy których skrypt nie ogarnie:

  1. Ile tego cpu/ram/podów/VMek/itp, jakie są przewidywane koszta itp. - rzecz dzieje się w pracy, a frashback'i jak z urzędu skarbowego
  2. Ustalenie z jakimi innymi serwisami nasz będzie się komunikował i "porobienie dziur" w firewallu, błogosławieństwo od security
  3. Dotarcie z kodem na produkcje tak żeby "przetrzeć szlak" (czasami mimo generatora serwisu wychodzą kwiatki)
  4. Sprawdzenie czy wygenerowany przez skrypt dashboard się odpala i prawidłowo raportuje, czy logi się agregują z odpowiednimi tagami
  5. Sprawdzenie czy w PagerDuty alerty się prawidłowo routują do "ownerów" serwisu
  6. Skrypt generujący może nie być na czasie, więc aktualizacja wszystkich zależności
  7. Modyfikacja README tak żeby opisywał stan faktyczny, dodanie CODEOWNERS

Punkt 1 trzeba często robić co najmniej kilka dni przed dodaniem serwisu, jak to ma być coś ciężkiego to nawet z 2 tyg. wcześniej. Reszta to co najmniej dzień jak nie wyjdzie nic nieprzewidzianego, a uwierz mi wychodzi i to bardzo często.

Jak robisz coś z publicznym api a nie internal to jeszcze jest bujaka z api gateway, dokumentacją api, przepychaniem wersji 1.0 przez api reviewers.

Dlatego generalnie preferuje startupy, wkładasz skrypt w Pythongu na Lambdę i masz wszystko w D...

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