On Monday, August 19, 2013 8:17:58 AM UTC+2, Paweł Kierski wrote:
> > Więc czasem tylko utrzymujemy i wtedy tak naprawdę nie ma co obgadywać,
> > kończymy szybko. Ale jak przychodzą nowe rzeczy, wówczas nierzadko nie
> > wystarcza czasu, nawet jak rozciągniemy spotkanie na maksa i się streszczamy.
> > Zresztą planowanie jest w wielu przypadkach bez sensu, ponieważ bez
> > jakiegoś rozpoznania tematu przez programistów estymaty są z kosmosu.
>
> Czyli klasyka - brakuje wizji na poziomie trochę wyższym.

Błędna diagnoza. Oczekiwanie na decyzje klientów. Wyobraź sobie, że
liczą każdą złotówkę. :)

> Skoro są sprinty, w których "tylko utrzymujemy", to wypada się
> zastanowić, czy na pewno potrzeba w ogóle pracy nad tym projektem.

Akurat to nasz główny produkt, który jest na produkcji od kilku lat.
Nie można go olać, to nie opensource. :)

> Na estymaty z kosmosu znam dwie główne metody - uczyć się estymować oraz
> robić proof of concept. Niektórzy twierdzą, że to nie ortodoksyjne, ale
> w skrajnych przypadkach, gdy temat jest kompletnie nieznany robimy
> sprint wcześniej badanie tematu. Siada jedna osoba i dwa, góra trzy dni
> szuka rozwiązań, próbuje projektować, pisać jakieś mockupy, czy co tam
> jeszcze potrzebne do odpowiedzi na pytanie "ile to będzie kosztowało?".
> Rezultatem takiego zadania jest odpowiedź, np. "już nie między 5 a 40,
> ale między 20 a 40".

Były takie pomysły, ale zostały - mówiąc efemistycznie - chłodno przyjęte. :)

w.