[PaaD]

Co myślicie o takim podejściu? ( ͡° ͜ʖ ͡°)
#scrum #programista15k #programowanie #java

[elf_pszeniczny]

@PaaD: musi być estymata bo się potem nie da zrobić wykresów na sprint review a szef działu patrzy

[S.....i]

@PaaD: kwestia tego jak jest wyceniany projekt, zazwyczaj zbiera sie wymagania od klienta i wycenia w MD estymujac per feature, klient kupuje godziny a skoro nie estymujemy to jak wycenic i spiac projekt? a sama estymacja czasowa (nie zlozonosciowa) jest faktycznie nie efektywna, task wyceniony na 2 dni, ktos robi w pare H i pyk csik :)

[PaaD]

@Szubrawski: No właśnie wydaje mi się, że na jakimś etapie i tak ktoś musi coś wycenić, bo rynek tego nie łyknie na ładne oczy - nawet jeśli będzie to wewnętrzny produkt. Może po prostu tylko nie zawracają tym głowy programistom.

A z drugiej strony, może to dość szczególny przypadek, bo jeśli goście pracują ze sobą od 10 lat to nawet bez używania liczb będą przez skórę czuć kiedy powiedzieć "Andrzej

[RapIArbuzy]

@PaaD: To nie jest szczególny przypadek, jeden z teamów w mojej firmie pracuje tak od dosyć dawna, a mój team to zaadoptował niedawno. Naszego product ownera nie interesują wykresiki, velocity, tylko progres na demo, a następnie są wyciągane priorytety w postaci user story na kolejne dwa tygodnie. A jak ktoś spyta o wyceny czasowe, to mamy podany mniej więcej przewidywany czas na epick, który często zajmuje z kilka miesięcy, nawet

[mpower]

@PaaD: od roku pracuję bez estymacji per task ale z estymacjami per projekt. Sytuacja podobna jak u kolegi wyżej - manager chce żeby robota była zrobiona np. w miesiąc i pyta nas tylko czy to realne. Od nas, jako programistów, zależy czy i jak się wyrobimy w terminie. W porównaniu do normalnych sprintów mi się pracuje w tym modelu dużo dużo lepiej i zwinniej.

[file_get_contents]

@RapIArbuzy: Jak duża jest rotacja w tym zespole, który pracuje w ten sposób? Jak duża jest rozbieżność poziomu umiejętności wewnątrz tego zespołu? Pytam z ciekawości, bo ja tak pracowałem i wszystko było dobrze, póki team był zgrany, gdy pojawiła się rotacja - 2 członków zespołu zmieniło pracę i przyszło 2 nowych, wszystko się #!$%@?ło. To tylko moja praktyka, więc nie podważam idei, ktorą uważam za słuszną, tylko zmienne środowiskowe.

[b.....r]

@file_get_contents: u mnie w zespole w ciągu półtorej roku pracy w Sprintach z 5 developerów aż 3 zmieniło pracę, manager i scrum master Ci sami.

Czasem sie zastanawiam ze firmom się kalkuluje wymienić developera aniżeli zwalniać tempo prac

[RapIArbuzy]

@file_get_contents: Kazdy u nas w zespole to senior, to znaczy z minimum 8 lat doświadczenia. Rotacja jest minimalna, a jezeli ktos nowy wchodzi do zespołu to mamy świadomość ze okres wdrożeniowy to kilka miesiecy, wiec dopiero po chwili nowy członkowie sa produktywni.

[janek_]

@PaaD: tu jest bardzo interesujący głos w temacie estymacji,

Why Programming Is Unreliable
#1 Not Repeatable
#2 Too Many Variables
#3