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