Traktowanie sprintów jako dwutygodniowych deadline'ów - jak uniknąć tych firm.

@Czitels:

Ale czemu Cię interesuje co ile zajmie? Jeżeli ktoś skończy dane zadanie to skończy i weźmie następne

Mnie nie koniecznie, ale biznes raczej tak.
Poza tym ludzie z natury to trochę lenie i jednak mam wrażenie, że część przynajmniej potrafi jednak oszukiwać. Ile tu na forum masz przykładów jak ktoś pisze że ogarnia 2 pełne etaty wpisując 8 godzin a pracując przez 6 dziennie.

@jarekr000000: myślę, że patrzysz trochę z perspektywy bardzo doświadczonego człowieka, który współpracuje z innymi doświadczonymi ludźmi. Niestety nie zawsze tak jest.

Warto dodać, że podczas tych sztywnych, regularnych, codziennych cermonii, dochodzi do gro absurdów :D Sztuczne dopytywanie skutkuję tym, że bardzo często zwyczajnie wymyśla się jakąś pierdołę, żeby tylko coś powiedzieć. Tak jak pisał @jarekr000000 - Niewidzialny bat do micromanagamentu.

@jarekr000000: I jeszcze zamiast 20 minut spotkanie jest ustawiane na 60, po 15 mogłoby się skończyć, ale zaczyna się wypełnianie czasu spotkania "ja mam jeszcze tylko jedno pytanie", bo również na wszelki wypadek, zaproszono na nie w cholerę osób, których na nim nie powinno być.

@ledi12: To jest kolejna patologia pato/korpo scruma. Zamiast powiedzieć "wczoraj zrobiłem X, możecie ruszać z Y", mówi się cokolwiek, byle nie wyszło, że się nic nie zrobiło.

To może spiszemy własnego 4PGuide'a ?
Bo dobrych pomysłów tutaj wpadło sporo, ale nikt tego nigdy nie wdroży.

U mnie ScrumKanban sprawdzał się najlepiej.
Masz priorytety, nie ma sztucznych "inkrementów", ale demo możesz zrobić praktycznie w każdym dowolnym momencie.
Masz retro, co jest źle w teamie.
Nie musisz robić sprint review, planningów, bo większość leci po kolei, a i tak masz estymaty

@Productionserver: Stworzyć Guida zacząć od płatnych certyfikatów i już programować nie musimy :D

jarekr000000 napisał(a):

No nie zgadzam się - story pointy, velocity i inne pierdoły to narzędzia manipulacji, które w oczach menadżerów mają skłonić ludzi do zapieprzu poprzez budowanie poczucia winy itp., ale tak, żeby nie było widać bata.

W scrumie szacujesz zadania i wybierasz je na sprint, a potem nie możesz zmieniać zakresu sprintu, co za tym idzie nie możesz dobrać następnych zadań. Jak skończysz swoją robotę w połowie sprintu, to potem tylko czekasz. A to jest dość oczywiste, że skończysz wcześniej, bo rozsądne i naturalne jest przeszacowywanie zadań, skoro każą je szacować. Do tego wszystkie zbędne spotkania sprawiają, że mniej się programuje, co dodatkowo zmniejsza wydajność pracy. (I zwiększa frustrację ludzi, którzy wolą programowanie od gadania.)
Jeśli jeszcze masz wprowadzone scrumowe zasady, typu limit dwóch zadań robionych jednocześnie na cały zespół np. pięcioosobowy, to oznacza, że 3 osoby albo edytują te same pliki - powodując zbędne konflikty i tracąc czas na ich rozwiązywanie, albo wręcz czeka się aż kolega napisze klasę, żebyś Ty mógł jej użyć.
To wszystko sprawia, że scrum to plaża. Frustrująca, ale nadal plaża (no w sumie pleonazm wyszedł, ale mniejsza z tym).
W każdym razie zero zapieprzu - z definicji i założeń.

Jeśli pracujesz w januszeksie, masz zapieprz, micromanagement i bezpłatne nadgodziny, to nie jest to wina scruma. Gdyby scruma nigdy nie wynaleziono, to praca w tym miejscu wyglądałaby tak samo.

jarekr000000 napisał(a):

2. No właśnie, to zwykle ważne czy coś będzie za rok dwa czy za tydzień. Natomiast przeważnie(!!!) zupełnie nieważne czy będzie za 3 dni czy za 5. Zawsze jak szacujesz to zadaj sobie pytanie co by się stało, gdyby zadanie trwało 3 razy dłużej i przeważnie odpowiedź jest - nic. Bo dość często zadania trwają 3 razy dłużej niż szacowano i jakoś świat się nie wali.

No nic się nie dzieje, poza tym, że wiemy na przyszłość, że tego typu zadania są trudniejsze niż nam się może wydawać. To chyba przydatna wiedza.

Oczywiście klient raz na jakiś czas chciałby dodać jakiś większy ficzer i zastanawia się czy warto i czy np. zdążymy na końcową wyprzedaż letnią czy inny termin - tu znowu IMO nie ma sensu szacowanie przez zespół - to jest duża grupa tasków, kilka doświadczonych osób musi to rozpisać na pomniejsze punkty i wyszacować zgrubnie.

No u mnie to "raz na jakiś czas" jest praktycznie ciągle - bo biznes żyje, wchodzi na nowe rynki, wprowadza nowe usługi, a i okoliczności prawne się zmieniają. Może są jakieś stabilne biznesy, w których soft raz napisany działa wiecznie, ale ja jeszcze takiego nie widziałem. Skoro ciągle jest coś do roboty, to biznes ciągle chce wiedzieć, kiedy to coś ma szanse być gotowe. Pewnie to potrzebne do jakiegoś budżetowania, zatrudniania ludzi, informowania inwestorów, i planowania dalszych etapów pracy.

Efektem tego, że "kilku doświadczonych rozpisało" jest jeden z chyba częstszych powodów narzekań na tym forum: lead oszacował mi taska na dzień, a ja robię go dwa tygodnie, lead ma pretensje, że za wolno pracuję, a co za tym idzie frustracja, zapieprz i bezpłatne nadgodziny (mimo braku scruma).

Wrzucanie tego na kark zespołu, gdzie większość i tak ma w dupie to co się wyświetla na ekranie jest bezsensowną stratą czasu.

W przypadku nieprofesjonalnych ludzi, to nie tylko estymacje nie mają sensu, ale w ogóle praca z nimi.

a szacowanie służy w zasadzie w 100% do sprawdzania czy wszyscy programiści mniej więcej podobnie rozumieją co jest do zrobienia.

Tak, właśnie o to w tym chodzi.

somekind napisał(a):

Wrzucanie tego na kark zespołu, gdzie większość i tak ma w dupie to co się wyświetla na ekranie jest bezsensowną stratą czasu.

W przypadku nieprofesjonalnych ludzi, to nie tylko estymacje nie mają sensu, ale w ogóle praca z nimi.

Tacy właśnie są programiści. Możesz sobie ich nazywać nieprofesjonalnymi, ale robią robotę. Mi się z takimi dobrze pracuje - może dlatego, że sam jestem w pełni nieprofesjonalny.
W dupie mam logikę biznesową:-) A jak ktoś mi przynosi excela z setką tasków i prosi o estymację na jakimś 5 godzinnym spotkaniu (ewidentnie dla profesjonalistów) - to też mam to w dupie.
Kłopot polega na tym, że tam gdzie szacowanie ma sens - bo np. musimy odpowiedzieć klientowi na pytanie ile będzie kosztowało zrobienie jakiegoś grubszego modułu to kończy się takim excelem. I albo dostajesz czas (ileś dni) żeby zrozumieć, wstępnie zaprojektować, i móc to jakoś tam oszacować, albo robimy cyrk, gdzie zespół szacuje ficzery, o których nie ma pojęcia, bo zwykle nikt nie daje całemu zespołowi tygodnia czasu na to, żeby ogarniać co tam klient chce w jakimś speku (zresztą uważam, że to byłoby mało ekonomiczne)

@somekind: obrońcą scruma.... piekło zgasło, raj płonie, Jakrkacz idzie w pokutnej paradzie róności...

jarekr000000 napisał(a):

Tacy właśnie są programiści. Możesz sobie ich nazywać nieprofesjonalnymi, ale robią robotę. Mi się z takimi dobrze pracuje - może dlatego, że sam jestem w pełni nieprofesjonalny.
W dupie mam logikę biznesową:-) A jak ktoś mi przynosi excela z setką tasków i prosi o estymację na jakimś 5 godzinnym spotkaniu (ewidentnie dla profesjonalistów) - to też mam to w dupie.
Kłopot polega na tym, że tam gdzie szacowanie ma sens - bo np. musimy odpowiedzieć klientowi na pytanie ile będzie kosztowało zrobienie jakiegoś grubszego modułu to kończy się takim excelem. I albo dostajesz czas (ileś dni) żeby zrozumieć, wstępnie zaprojektować, i móc to jakoś tam oszacować, albo robimy cyrk, gdzie zespół szacuje ficzery, o których nie ma pojęcia, bo zwykle nikt nie daje całemu zespołowi tygodnia czasu na to, żeby ogarniać co tam klient chce w jakimś speku (zresztą uważam, że to byłoby mało ekonomiczne)

Jeżeli mamy odpowiedzieć na pytanie "kiedy to wielkie coś będzie?", to story pointy nam w niczym nie pomogą. Story pointy istnieją w krótkim okresie, dla konkretnego zespołu, konkretnego rodzaju wykonywanych tasków, aktualnego poziomu ludzi w zespole, morale itd. Te czynniki są zmienne i task który dzisiaj zostanie oczacowany na 5sp, za 2 miesiące może być szacowany na 1sp, albo 21sp. Więc się nie da. To co u mnie się sprawdza to:

• Ktoś (PO, architekt) siada i robi waterfallowe WBS.
• Te same ktosie ustalają które zadania są najważniejsze, które mniej ważne, porządkowany jest backlog.
• Sam, albo wspólnie z zespołem wrzucam zgrubne szacunki. Jednostka miary to rozmiary koszulek (XXS - XXL). Proponowałem kolory smoków z hirołsów, ale to było ponad wytrzymałość biznesu i bardziej profesjonalnie nastawionych członków zespołu.
• Parę pierwszych zadań jest analizowanych i opisywanej do postaci pozwalającej na implementację.
• Robimy sobie backlog refinement, dostaję zjebki od zespołu, że to co mi się wydawało rozpisane, kompletnie nie ma sensu, jest nie jasne. Dopisujemy szczegóły, rozbijamy na historyjki, zespół daje swoje storypointowe szacunki dla historyjek, pojawia się przeliczenie pomiędzy t-shirt size a SP
• Idę do biznesu, przelczam swoje szacunkowe t-shit size na sp i mówię, że według moich szacunków, zrobimy to na za 14 miesięcy.
• Zaczynamy robić, z każdą zrobioną historyjką pojawia się trochę więcej danych, które sprawiają, że moje koszulki stają się coraz bardziej konkretne. Na bieżąco pokazujemy jaki jest aktualny przewidywany termin dostarczenia.
• Robota idzie dalej, kolejne ficzery są analizowane w szczegółach, rozpisywane na historyjki, szacowane, przewidywana data końca aktualizowana.
• Z każdym tygodniem coraz więcej behemota jest za nami, a coraz mniej przed nami, data końca staje się coraz bardziej przewidywalna.

Zalety takiego podejścia to:

• Nie poświęcamy za dużo czasu na szacunki, o których z góry wiadomo, że są Scientific Wild Ass Guess
• Nie wkurzam zespołu pytaniem ile im zajmie jakaś robota, której w całości nie rozumieją
• Zamiast poświęcać miesiąc na próby lepszego szacowania, zabieramy się za robotę i mamy zarówno jakiś kawałek pracy za sobą, jak i dużo lepsze szacunki dla całości
• Jak ktoś wyskakuje z tekstem, że "miało być na kiedyś tam, a teraz wychodzi, że będzie później", to mogę odpowiedzieć "Ups, sorki, pomyliłem się, moja wina. Ludzie robią najlepiej jak potrafią, ale ja niedoszacowałem jakiegoś zadania", albo "wrzuciliście nam z boku dodatkowe zadania, to się przesunęło".

Nie wiem, czy to jest rozwiązanie dla każdego zespołu, projektu itd. U mnie, jakoś tam się sprawdza.

somekind napisał(a):

W scrumie szacujesz zadania i wybierasz je na sprint, a potem nie możesz zmieniać zakresu sprintu, co za tym idzie nie możesz dobrać następnych zadań. Jak skończysz swoją robotę w połowie sprintu, to potem tylko czekasz.

Po przeczytaniu tego aż mnie zatkało. Ja się nie dziwię, że Scrum ma opinię metodyki nieefektywnej jeśli ludzie serio wierzą w takie rzeczy

Ja tylko powiem, że warto pokonać managerów ich własną bronią.
U nas 3 story pointy zostały ustalone jako około 1 dzień roboty.

"Ale szefie, to nie jest jednostka czasu".
"No ale jakoś musimy to ustalić"
"ok"

Zawyż estymaty, nabij 15 SP do środy, commituj taktycznie żeby wypełniło się do piątku do 16, wal konia w godzinach pracy.

W moim obecnym projekcie nasz scrum disaster zabronił nam estymować zadania przewidziane w sprincie na więcej niż osiem stroypointów bo "źle to wygląda w cyferkach". Wszycy więc estymujemy do 5 storypointów, a jak zadanie przeciąga się to podbijamy do 8 i więcej.

W moim poprzednim projekcie w Motoroli w KRK jak przeciągałeś zadanie powyżej 2 tygodni to lądowałeś na cenzurowanym, a jak podobny motyw był w kwartale kilka razy to requestowali o nowego kontraktora no bo ten jest "kiepski".

Sam byłem świadkiem jak podmieniano kontraktorów w jednej z firm gdzie kiedyś pracowałem aniżeli np. skupić się na "podciągnięciu" go czy dano mu czasu. Niestety często jako kontraktor musisz być jak komandos i niejednokrotnie wymagania się takie że masz wiedzieć i robić wszystko "na już". Przynajmniej ja tak zaobserwowałem.

Mógłbyś rozwinąć co to znaczyć "lądować na cenzurowanym"?

może spróbujcie nie być klepaczami do wynajęcia i poszukajcie firmy produktowej - to wiele upraszcza

jarekr000000 napisał(a):

Tacy właśnie są programiści. Możesz sobie ich nazywać nieprofesjonalnymi, ale robią robotę.

Jaką niby robotę robią? Te bugi, które trzeba potem naprawiać tygodniami? To chyba krecia robota jest.
Nie wiedząc co się robi ani po co, to dobrze można zrobić chyba tylko przypadkiem. Dla mnie to mało profesjonalne podejście. I chyba nie tylko dla mnie, bo jak widzę po narzekaniach tutaj na forum, to ludzie raczej chcieliby nie mieć bugów, za to jasno sprecyzowane wymagania co do zadań, a więc nie mają ich w dupie.

piotrpo napisał(a):

@somekind: obrońcą scruma.... piekło zgasło, raj płonie, Jakrkacz idzie w pokutnej paradzie róności...

xD
Nigdzie nie bronię scruma, po prostu stawiam mu o 180 stopni odmienne zarzuty niż padają tutaj. Scrum spowalnia, a nie przyspiesza.

Robienie bezpłatnych nadgodzin to efekt bycia nieasertywną ciapą, a nie tej czy innej metodyki.

abrakadaber napisał(a):

może spróbujcie nie być klepaczami do wynajęcia i poszukajcie firmy produktowej - to wiele upraszcza

Ale wtedy nie będzie na co narzekać. A tu przecież trzeba narzekać - jest źle, bo musi być źle, tak było za dziadów i ojców, więc nam też musi być źle.
A jak jakiś somekind pisze, że można mieć z pracy frajdę, że można nie mieć bugów, że można wiedzieć, co się robi, że można mieć zaplanowaną pracę - i na ogół ten plan wykonywać, to przecież nie ma racji - bo my wiemy lepiej, jak u kogo jest w robocie. ;)

Some, ale to Ty rozpowszechniasz, że zasady obowiązujące u Ciebie w robocie (na przykład to, że bugi da się zawsze mniej więcej estymować) przekładają się na cały świat, a nie w drugą stronę. Chyba ani jedna osoba tu nie stwierdziła, że nie ma takich poszczególnych przypadków, że da się to robić. Zanim włączysz reakcję obronną to weź po prostu jeszcze raz przeczytaj co inni piszą i co sam napisałeś, bo mi się wydaje, że tutaj w większości kwestii spornych pojawił się problem z wzajemnym zrozumieniem, a nie w różnicach w poglądach :P

somekind napisał(a):

jarekr000000 napisał(a):

Tacy właśnie są programiści. Możesz sobie ich nazywać nieprofesjonalnymi, ale robią robotę.

Jaką niby robotę robią? Te bugi, które trzeba potem naprawiać tygodniami? To chyba krecia robota jest.
Nie wiedząc co się robi ani po co, to dobrze można zrobić chyba tylko przypadkiem. Dla mnie to mało profesjonalne podejście. I chyba nie tylko dla mnie, bo jak widzę po narzekaniach tutaj na forum, to ludzie raczej chcieliby nie mieć bugów, za to jasno sprecyzowane wymagania co do zadań, a więc nie mają ich w dupie.

Nie wiem skąd ty takie wnioski wyciągasz..] wchodzisz już w erystykę - czyżby jakaś reakcja obronna?
Po pierwsze to oczywiście ludzie niektórzy może i nie chcieli by mieć bugów, ale że akurat dane było mi przećwiczyć to wiem, że zarządzenia w sprawie zakazu bugów nie działają.
A krecia robota to jest nie naprawianie bugów.
Jasno sprecyzowane wymagania co do zadań też by może chcieli mieć - natomiast praktyka jest taka, że robi się zadania bez jasno sprecyzowanych wymagań - bo część pracy programisty to te wymagania odnaleźć i spisać (resztę świetnie robi chatgpt).

Jakby osoby zgłaszające wymagania potrafiły je zdefiniować bardzo dokładnie to by klepacze byli zbędni, bo klepanie to właśnie doprecyzowanie wymagań do takiego poziomu, by głupi komputer je zrozumiał :P

@oliver_ zrób quite quitting i szukaj nowej roboty. Ten SM nie gra do Waszej bramki a liże dupe biznesowi. Toksyk, szkoda czasu.

@ToTomki: Na jakimś tam poziomie abstrakcji, to co nazywamy kodowaniem, to właśnie doprecyzowanie wymagań do poziomu rozumienia ich przez komputer.

@jarekr000000: Nie widziałem na własne oczy, ale słyszałem o "zakazie bugów", popartym zakazem zatrudniania testerów, bo jak programistom zakazano tworzenia błędów, to po co sprawdzać, czy faktycznie ich brakuje.

A nawiązując do reszty, tego co piszesz, to z mojego doświadczenia, każdy jeden projekt który upadł w mojej karierze, zrobił to z tego samego powodu: kłamstwa. Że coś zostało zrobione, a nie został.o TODO w kodzie, albo zamknięty task z towarzyszącym bugiem, żeby zdążyć z deadlinem. Albo że wiemy co ma zostać napisane, a nikt nie ma zielonego pojęcia. Ogólnie sytuacji, w której ktoś zamiast rozwiązać problem, zamiatał go pod dywan. Ekstremum, to system bankowy, który został z powodzeniem napisany, poczym wrócił od klienta po jednym dniu testów, bo działał tylko z jednym użytkownikiem na raz.

ToTomki napisał(a):

Some, ale to Ty rozpowszechniasz, że zasady obowiązujące u Ciebie w robocie (na przykład to, że bugi da się zawsze mniej więcej estymować) przekładają się na cały świat, a nie w drugą stronę. Chyba ani jedna osoba tu nie stwierdziła, że nie ma takich poszczególnych przypadków, że da się to robić. Zanim włączysz reakcję obronną to weź po prostu jeszcze raz przeczytaj co inni piszą i co sam napisałeś, bo mi się wydaje, że tutaj w większości kwestii spornych pojawił się problem z wzajemnym zrozumieniem, a nie w różnicach w poglądach :P

No niewątpliwie coś jest nie tak ze zrozumieniem tutaj. Bo ja np. nigdy nie twierdziłem, że bugi da się estymować. Kilka razy nawet temu zaprzeczyłem. A mimo to, znowu ktoś mi to imputuje. :)

jarekr000000 napisał(a):

Nie wiem skąd ty takie wnioski wyciągasz..] wchodzisz już w erystykę - czyżby jakaś reakcja obronna?

Z Twoich słów - raz piszesz o bugach, które potrafią wypełnić cały sprint, a innym razem o tym, że ludzie mają gdzieś to, co robią. Dla mnie to wygląda na dość prostą przyczynowość. Byłem tego świadkiem nie raz, jakoś nigdy ludzie, którzy mieli robotę gdzieś, nie tworzyli dobrego softu.

Po pierwsze to oczywiście ludzie niektórzy może i nie chcieli by mieć bugów, ale że akurat dane było mi przećwiczyć to wiem, że zarządzenia w sprawie zakazu bugów nie działają.

Ja nie sugerowałem nigdzie zakazywania bugów. Po prostu - jeśli rozumie się to, co się robi, to błędów jest mniej.

Jasno sprecyzowane wymagania co do zadań też by może chcieli mieć - natomiast praktyka jest taka, że robi się zadania bez jasno sprecyzowanych wymagań - bo część pracy programisty to te wymagania odnaleźć i spisać

No tak by zrobili profesjonaliści, ale po co drążyć wymagania, skoro macie je gdzieś? W moim odczuciu to, co piszesz na temat swoich doświadczeń z pracy jest jakieś takie niespójne.

Być może dzielenie się swoimi spostrzeżeniami to dla niektórych erystyka, nic na to nie poradzę. Nie wiem tylko przed czym miałbym się bronić - to nie ja mam problemy z jakością ani organizacją w robocie. :)

Jak czytam "To nie to jest prawdziwy scum!" przypomina mi się jak jeden z polityków mówi, że na Kubie czy Rosji to "To nie jest jest prawdziwy komunizm! Komunizm jest dobry, ale ten prawdziwy.".

Mierny zarządzający i mierni wykonawcy to zawsze źródło niekończących się problemów i konfliktów personalnych. Natomiast projekt i jego realizacja są na ostatnim planie.

Wydaje mi się, że to dyskretne podejście "scrum dobry|zły" jest bez sensu. Wszystko zależy od tego jak ten konkretny scrum wygląda i czy akurat w tym projekcie jest wartością dodaną, czy kulą u nogi.

• Jeżeli jakiś framework do zarządzania projektem jest wdrażany przez osoby, które nie rozumieją na czym polega projekt w IT - będzie źle
• Jeżeli ludziom, którzy sobie radzą z pracą narzuca się jak mają sobie z tą pracą radzić - będzie źle
• Jak ludzi, którzy sobie z pracą nie radzą nie uczy się jak sobie z tą pracą efektywnie radzić - też będzie źle.

Wracając do pytania @oliver_ jak wybadać firmę, czy nie stosuje takich metod, to prosto się nie da.
Nikt ci nie powie wprost, że jest do bani. Jak na rozmowie pojawia się SM i pyta, czy estymowaliście w SP to jest jakiś wskazówka, ale nie koniecznie jest to jeszcze powód do przekreślenia firmy. Jeżeli na pytanie o projekt zaczynają ci opowiadać o scrumach, hierarchiach, story pointach, zamiast po co to jest, dla kogo, jaką wartość niesie klientowi, jakich technologii używają - będzie źle.

Zamiast pytać "czy macie zrąbanego korpo-scruma wymuszanego przez scrum-mastera idiotę wpieprzającego się do każdej możliwej dyskusji i zamieniającego ją w g...." lepiej zapytać o to jak faktycznie pracują:

• Kto ustala wymagania biznesowe, w jaki sposób, jak upewniają się, że zespół je zrozumiał (jak nie wiedzą to źle, jak dzieje się to już w czasie pracy nad zadaniem też źle).
• Jak często robione są wydania (jak rzadko - źle).
• Czy zamknięcie zadania oznacza również dopisanie testów. (jak nie jest przetestowane, to jest duża szansa, że nie jest zrobione)
• Czy po pojawieniu się buga na produkcji (niezgodność z wymaganiami) jest on naprawiany w pierwszej kolejności. (jak z naprawą istotnego błędu trzeba czekać 2 tygodnie zanim się go zacznie robić...)
• Kto i kiedy przypisuje zadania do członków zespołu. (jak SM/PM/TL to uciekaj, jak dzieje się to na początku sprintu, to jeszcze gorzej)
• Czy jak ten bug wpada w środku sprintu, to jest rozwiązywany w pierwszej kolejności. Jeżeli tak, to co się dzieje z resztą zadań zaplanowanych na sprint. (Czy zespół jest dostatecznie elastyczny, żeby reagować na bieżąco na pojawiające się wymagania, czy najpierw pomaluje jakiś guzik na pomarańczowo, bo tak sobie zaplanował)
• Czy jeżeli uda się zamknąć wszystkie zadania ze sprintu przed jego końcem, to brane są zadania z następnego sprintu (byłem w projekcie gdzie op.... się w tym czasie, bo burndown chart by wyszedł brzydki...)
• Co jest dla nich 1 SP (jak przeliczają to na dzień pracy - uciekaj)
• Jak liczny jest zespół i ile tasków zamyka w sprincie (jak 1-2 na osobę, to źle, bo albo nie mają tego przyzwoicie rozpisanego, albo burdel w kodzie taki, że szybciej się nie da).

jak story point jest tracktowany jako dzien pracy to uciekaj :)

somekind napisał(a):

jarekr000000 napisał(a):

Nie wiem skąd ty takie wnioski wyciągasz..] wchodzisz już w erystykę - czyżby jakaś reakcja obronna?

Z Twoich słów - raz piszesz o bugach, które potrafią wypełnić cały sprint, a innym razem o tym, że ludzie mają gdzieś to, co robią. Dla mnie to wygląda na dość prostą przyczynowość. Byłem tego świadkiem nie raz, jakoś nigdy ludzie, którzy mieli robotę gdzieś, nie tworzyli dobrego softu.

Ewidentnie za dużo czatujesz z sam wiesz kim :-) Nigdzie nie napisałem, że mają w dupie to co robią, napisałem, że mają w dupie estymowanie tasków, między innymi dlatego, że ich nie robią. Jak masz zespół 8-mio osobowy to szansa, że trafisz na konkretne zadanie nie jest taka duża. A upierdliwość nudnego przeglądania dennych historyjek, dotyczących modułów których często nawet nie widziałeś na oczy, duża.

@jarekr000000: Chyba powtarzasz błąd scrum masterów. Tak jak oni, uważasz, że poznałeś zaj.....y sposób na robienie oprogramowania, który sprawdzi się zawsze, wszędzie, z każdym.
Ktoś kiedyś te historyjki musi przeczytać i zrozumieć. Chyba, że faktycznie są opisane tak, że bez najmniejszego problemu, każda potencjalna ofiara złapie, przeczyta i zaimplementuje.

piotrpo napisał(a):

@jarekr000000: Chyba powtarzasz błąd scrum masterów. Tak jak oni, uważasz, że poznałeś zaj.....y sposób na robienie oprogramowania, który sprawdzi się zawsze, wszędzie, z każdym.
Ktoś kiedyś te historyjki musi przeczytać i zrozumieć. Chyba, że faktycznie są opisane tak, że bez najmniejszego problemu, każda potencjalna ofiara złapie, przeczyta i zaimplementuje.

No ale chyba o tym pisałem, ktoś kiedyś musi (:-)), ale nie muszą wszyscy - nawet nie ma to sensu.
Uważam, że estymowanie kosztu przez zespół ma jakiś nawet sens czasem, ale przeważnie nie nadaje się do wyceny tam, gdzie ta wycena faktycznie jest potrzebna.
Estymowanie w sensie "are we on the same page" ma czasami jakiś sens - w niektórych projektach.

jarekr000000 napisał(a):

No ale chyba o tym pisałem, ktoś kiedyś musi (:-)), ale nie muszą wszyscy - nawet nie ma to sensu.
Uważam, że estymowanie kosztu przez zespół ma jakiś nawet sens czasem, ale przeważnie nie nadaje się do wyceny tam, gdzie ta wycena faktycznie jest potrzebna.
Estymowanie w sensie "are we on the same page" ma czasami jakiś sens - w niektórych projektach.

Dla mnie SP mają w tej chwili jeden sens - ludzie z jakimś tam PTSD wciąż mają odruch nie szacowania pracy, której nie rozumieją. Jak dostanę jakąś tam odpowiedź typu "3", to jestem troche spokojniejszy, że wiedzą co ma zostać zrobione.
Z ciekawości, jak nie wszyscy mają skumać historyjkę, to kto? Zadania są z automatu przypisane na konkretnego człowieka? Czy dopiero jak ktoś się złapie za robotę, to dopytuje o co chodzi w zadaniu?

somekind napisał(a):

No niewątpliwie coś jest nie tak ze zrozumieniem tutaj. Bo ja np. nigdy nie twierdziłem, że bugi da się estymować. Kilka razy nawet temu zaprzeczyłem. A mimo to, znowu ktoś mi to imputuje. :)

Bardzo możliwe. Przejrzałem teraz wiadomości na szybko i nie widzę takiej napisanej przez Ciebie. Być może pomyliłem osoby i uznałem Ciebie za autora nie Twoich słów. Jeśli tak to przepraszam.

Klucz w twoich obawach znalazłem tu

Chciałbym zmienić pracę ale boję się, że trafię znowu na to samo.

A może boisz się nie tylko tego?

1. Pracujesz w A
2. Nie podoba się to idziesz do B
3. Idź do punktu 1.