[lucidwires]

#heheszki #scrum #programowanie

[dzana]

@lucidwires: założenie jest takie, że nie jesteś w stanie przewidzieć ile potrwa jedno pojedyncze zadanie. I jedno zadanie wycenione na 8 może zająć 3 dni, a drugie wycenione na 8 może zająć 6 dni. Ale wyceniając jego trudność/złożoność w oparciu o doświadczenie z wcześniejszych sprintów wiesz, że mniej więcej ile jakich zadań zespół jest w stanie zrobić w przeciągu tych dwóch tygodni

[croppz]

czym się różni złożoność zadania od czasu na jego wykonanie?

@lucidwires: % sprintu jaki spędzisz grając w gierki nie wpływa na złożoność, ale na czas już tak. ( ͡° ͜ʖ ͡°)

[dzana]

@lucidwires: największym problemem jest biznes, który nie ogarnia że wyceny to tak naprawdę są właśnie dla nich, żeby mogli sobie zaplanować co i kiedy będzie zrobione. Zespół i tak mniej więcej będzie robił swoim tempem (zakładając brak nadgodzin i porządną jakość produktu) i nie ważne czy wyceni zadanie na 5 czy 8 ono i tak potrwa x czasu.
Ale dzięki wycenom wiemy, że dany feature ma x zadań z wyceną na

[lucidwires]

@dzana: to dalej nie rozumiem: skoro "jedno zadanie wycenione na 8 może zająć 3 dni, a drugie wycenione na 8 może zająć 6 dni" to jakim cudem mogę przewidzieć ile mniej więcej zadań zrobi zespół w ciągu określonego czasu?

[Drail]

@lucidwires: Ale chyba umiesz przewidzieć ile zajmie ci wystawienie danego endpointu a ile zajmie ci stworzenie algorytmu doboru przeciwnika w grze?

[jamajskikanion]

@beethoven: do tego takie pytanie jest istotne bo jeśli od 5 pracowników przychodzą informacje że ktoś się opieprza to zapytanie go dlaczego JEGO ZDANIEM nie wyszło ma sporo korzyści. Można wtedy skonfrontować to co on mówi z tym co mówią inni, rozwiązać kwasy w zespole albo wyeliminowac toxica z zespołu. Ciągła wymiana feedbacku to podstawa dobrego zarządzania, nikt nie czyta wam w myślach

[dzana]

@lucidwires: Znasz velocity zespołu i wiesz ile jakich zadań możesz na sprint wziąć. Jak w miarę dobrze wyceniacie zadania to ostatecznie nieważne czy dana 8 potrwa dłużej czy krócej. Dla Ciebie ważne jest że zespół może zrobić 3 takie ósemki w dwa tygodnie, wszystko się mniej więcej czasowo wyrówna. Im mniejsze zadania tym ławiej wycenić, tym mniejszy rozjazd, większa szansa że wszystko się ładnie zepnie. Np. u nas praktycznie nie bierzemy

[lucidwires]

@dzana: czyli te całe story pointy to tak naprawdę abstrakcyjna jednostka czasu, bo nie widzę różnicy między tym a wycenianiem po prostu w dniach - też można powiedzieć że można wziąć ileś 3-dniowych tasków bo się wyrówna

[edek_wladca_kredek]

@lucidwires: https://youtu.be/QVBlnCTu9Ms

[bydloszarewegierskie]

@lucidwires

to dalej nie rozumiem: skoro "jedno zadanie wycenione na 8 może zająć 3 dni, a drugie wycenione na 8 może zająć 6 dni" to jakim cudem mogę przewidzieć ile mniej więcej zadań zrobi zespół w ciągu określonego czasu?

A no takim że sprint ma stały czas i nie trackuje się ile zadania zajęły faktycznie. Natomiast złożoność to co innego, bo po paru sprintach wiesz ile w ciągu sprintu "złożoności" udało się

[mszto]

@dzana no tak a jeszcze dodać do tego dużą rotację w zespole i nagle pojawiające się tematy do zrobienia. To co mówisz to jest tylko i wyłącznie ile czasu to zajmie zrobienie tego a nie kiedy to zostanie zrobione. Czasem wycena jest w dużym, bardzo dużym przybliżeniu bo okazało się, że wymaganie było słabo opisane albo coś nie zostało dopowiedziane a trzeba wycenić.. Generalnie można sobie to w dupe wsadzić cały scrum

[H.....n]

@lucidwires: przecież dociekanie dlaczego nie wyszło i poprawianie tego w kolejnych sprintach to podstawa scruma i powód dla którego (jeśli pracuje się z dojrzałymi devami a nie #!$%@? klepaczami) to zajebiście działa

[uirapuru]

@lucidwires: nie scrum masterzy, tylko product ownerzy akurat

[Yahoo_]

@lucidwires: największy problem generalnie całego agile w korpo jest taki, że ludzie skupiają się ceremonii (wszystkie spotkania itd), a nie na samym manifeście, który jest mega zwięzły:

ludzie i interakcje ponad procesy i narzędzia

działające oprogramowanie ponad szczegółową dokumentację

współpracę z klientem ponad negocjacje umów

reagowanie na zmiany ponad realizację założonego planu

Szczególnie pierwszy punkt jest ruchany w dupala, większość korpo ma świra na punkcie procesów i narzędzi, miałem swego czasu

[mszto]

@Yahoo_ a weź, szkoda gadać. Byłem raz na sprint review jednego zespołu i przychodzi koleś i pokazuje jak to poprawili komunikaty dla użytkownika. Poprawki w stylu dodanie kropki.

[dzana]

czyli te całe story pointy to tak naprawdę abstrakcyjna jednostka czasu, bo nie widzę różnicy między tym a wycenianiem po prostu w dniach - też można powiedzieć że można wziąć ileś 3-dniowych tasków bo się wyrówna

@lucidwires: bez sensu wyceniać coś w jednostkach w których nie jesteś w stanie zrobić tego dokładnie. Bo jak zadanie zajmie między 3-6 dni, to na ile je wycenisz? na 3, na 6 czy na 4.5?

[d.....6]

@lucidwires: @NoMoreTearsJustSmile ale słaby mem, przecież na dolnym kadrze powinien być zadowolony brainet

[lucidwires]

@dzana: ja wyceniam w ten sposób że liczę ile by mi to zajęło optymistycznie (w tym przypadku 3 dni) i dorzucam jakiś procent, np. 50% czyli wychodzi 4.5

[Mr_Frodo]

@lucidwires: największy rak korpo teraz, scrum masterzy z miękkimi kompetencjami bez żadnej wiedzy xD