Blog naukowy z Gliwic. Zdobądź wiedzę z języków obcych, nauki pływania...

Mityczny osobomiesiąc

Więcej przedsięwzięć programistycznych zakończyło się niepowodzeniem z powodu braku czasu kalendarzowego niż ze wszystkich innych powodów razem wziętych. Dobre gotowanie wymaga czasu: niektórych zadań nie da się przyspieszyć bez zepsucia wyniku.

Wszyscy programiści są optymistami: „Wszystko pójdzie jak z płatka”. Programiści budują z czystej materii myślowej: zakładają więc, że przy implementacji będzie niewiele kłopotów. Ponieważ nasze koncepcje mają niedociągnięcia, pojawiają się błędy.

W naszych metodach szacowania czasu mylimy nakłady z postępem prac. Przyjęcie osobomiesiąca jako jednostki miary wielkości zadania to niebezpieczna i zwodnicza praktyka. Bierze się z założenia, że ludzie i miesiące to wielkości zamienne. Podział zadania między wielu ludzi wymaga dodatkowych nakładów pracy na czynności komunikacyjne – szkolenie i wzajemne komunikowanie się.

Według stosowanej przeze mnie praktycznej zasady 1/3 czasu poświęca się na projektowanie, 1/6 na kodowanie, 1/4 na testowanie elementów składowych i 1/4 na końcowe testowanie systemu.

W naszej dyscyplinie brakuje danych do procedury szacowania czasu. Ponieważ nie jesteśmy pewni naszych szacunków, często brakuje nam odwagi, żeby ich z uporem bronić wobec zarzutów kierownictwa i klientów.

Prawo Brooksa: Przydzielenie dodatkowych osób do opóźnionych już prac nad projektem oprogramowania jeszcze wykonanie tych prac odwleka. Przydzielenie dodatkowych osób do prac nad projektem oprogramowania powoduje zwiększenie potrzebnych nakładów pracy, a to z trzech powodów: zmienia się organizacja zespołu i powstaje zakłócenie w realizacji zadania wywołane nowym podziałem pracy: zachodzi konieczność szkolenia nowych ludzi: zwiększa się liczba czynności komunikacyjnych.

Podobne Artykuły

Zostaw odpowiedź

Twoj adres e-mail nie bedzie opublikowany.