W sumie poruszałem już ten temat we wpisie Agile vs Waterfall – jak przekonać zarząd i klienta, ale ponieważ znowu odbyła się ciekawa dyskusja na ten temat, to chciałbym jeszcze raz do tego wrócić może na bardziej konkretnym poziomie. Bo czasami zbyt wysoki poziom abstrakcji powoduje trudności w zrozumieniu tematu.

Początkiem dyskusji była opinia, że mimo wszystko czasami lepiej jest przygotować projekt z góry, opisać architekturę, wymogi itp. Takie podejście powinno pomóc uniknąć pułapek, które mogą pojawić się w trakcie tworzenia systemu, zaprojektować architekturę, przewidzieć technologię …

Czytaj dalej →

Chciałbym podsumować trochę wiedzę zdobytą w trakcie rozmów z trenerami Scrum na temat szacowania. Dyskusja z zespołami dostarczyły następnych ciekawych przemyśleń. A generalnie wiąże się to również z powszechnymi próbami przeliczania story pointów na dni robocze i odwrotnie. Wiadomo, że nie powinno się tak robić ale uzasadnienie i zrozumienie dlaczego jest trudniejsze.

Z punktu widzenia logiki jak i statystyki jest to jak najbardziej uzasadnione. Jeśli przeliczmy story pointy na dni to tak naprawdę przestajemy już estymować tylko dokonujemy wyceny czasochłonności. A estymaty służą do czegoś innego – ocenienia jak dużo pracy trzeba wykonać w konkretnym user story. Przecież warunki będą się zmieniać, istnieją urlopy, zwolnienia, może się zmieniać skład zespołu i tak można by wymieniać.

Czytaj dalej →