Wpis z mikrobloga

@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 :)
@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 to
@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 jeżeli
via Wykop Mobilny (Android)
  • 1
@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.
@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.
@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.
@PaaD: tu jest bardzo interesujący głos w temacie estymacji,

Why Programming Is Unreliable
#1 Not Repeatable
#2 Too Many Variables
#3 Surface Understanding
#4 Unique Integration
#5 Low Diagnostic Output
#6 Knowledge Work Mismatch
#7 Undervalued Teamwork
Reduce Impact of Bad Estimates
#1 Reduce Estimated Work
#2 Keep Estimates With Estimators
#3 Estimate In Components
#4 Choose Familiar Technologies
#5 Find Native Integrations
#6 Stop Using Estimates
janek_ - @PaaD: tu jest bardzo interesujący głos w temacie estymacji, 

Why Program...