Czy SP są obowiązkowe dla zespołów w banku?
Mnie się wydaje, iż nie powinny być.
Mój tok myślenia:
· SP jest bardzo ogólną metodą, która bazuje na podobieństwie zadań
· jeżeli zadań nie da się kategoryzować, to SP nie mają zastosowania
· SP są wrażliwe na zmiany składu zespołu, wrzutki, zmiany technologii
· SP są silnie zależne od konkretnych ludzi
· Czyli SP dobrze działają tam, gdzie kilka wiesz i gdy rzeczy cię zaskakują
Jeżeli produkt jest już w miarę dojrzały i ma określoną architekturę to można bazować na bardziej specjalizowanych metodach, które są dokładniejsze i niezależne od konkretnych ludzi:
· PERT – gdy dokładnie znasz bebechy algorytmu – można szacować ze z góry założoną dokładnością
· Manday – przy powtarzalnych zadaniach i podobnych do siebie
· NoEstimation – przy dobrze zgranym zespole i stablilnym produkcie, gdy skupiamy się na optymalizowaniu flow, gdyż zadania mają najczęściej ten sam rozmiar
· Event Modelling – gdy stosujesz architekturę CQRS i Event Sourcing – autor tej metody Adam Dimitriuk uzyskuje powtarzalną trafność na poziomie 5%
Krzystof Kicior na 4Dev Dobra metoda, ale mało sexy
Witkor Żołnowski na LI spoko, ale potrzebujemy trust index for the Software Houses bsed on client experiences and results;
fixed price to metoda na ograniczenia ryzyka, jesli dostarczyny innej np SHTI, to będzie OK
Wobraźmy sobie odwrotną sytuację SH podpisuje weksekl do wysokości 1mln euro, zapadalny jeżeli nie osiągnie celu klienta albo nie rozwiąże problemu idziesz w to?
