Za?to su procjene uvijek krive?

Prvo i osnovno: procjene ne mogu biti krive. U sr? rije?i "procjena" ugra?ena je nesigurnost i prema tome to?na procjena je ni?ta drugo do oksimoron.

No niste do?li ovdje to pro?itat, jel'da :)

Procjene su uvijek pogre?ne, odnosno stvarnost nikad ne odgovara procjeni zbog pa?teta na kruh efekta.

Da demonstriram.

Koliko vam treba da nama?ete pa?tetu na kri?ku kruha? - obi?nu pa?tetu, na obi?nu ?nitu, fetu kruha. Ovakvu:

20 sekundi, pola minute? Minuta?

Super. Koliko pak vam treba da nama?ete pa?tetu na kri?ku kruha ako po?nete ovog trena?

...

Jel odgovor i dalje kao i prije? :)

Ve?inu ljudi koje sam ovo pitanje pitao naravno ne daje isti odgovor. Ka?u da bi trebali do du?ana po pa?tetu, pa uzet kruh, pa oprat no?, odrezat kri?ku, eventualno i na?i otvara? za konzerve i tad pristupiti mazanju. Pa odgovor shodno svemu bude puno ve?i, od minute pa do 15.

Ista stvar se de?ava sa procjenjivanjem u razvoju softvera. Naj?e??e ne gledamo to?no u koje sve linije koda ?emo se zabit, koje nove klase kreirat, koje metode i model pro?irit i kako, da li je API to?no onakav kakvog ga trebamo, jel radi ispravno itd. Jer u momentu kad to napravimo svom silom ?emo po?eljeti implementirati tu funkcionalnost - a to naj?e??e nije moment kad nas za procjenu pitaju, ?to mi naravno znamo pa nam se mahom ni ne da ulaziti u zadnje detalje (sjesti za komp i zagledati se u k?d)

Ako ?ete kao naru?itelji svoje developere pitati za procjenu ne?ega (koliko god jasnog ili malog) u relativno daljnjoj budu?nosti (2-3 tjedana na vi?e) o?ekujte da ?ete dobiti pa?teta na kruh efekt. U velikoj ve?ini slu?ajeva barem.

Pitanje je glavno ?to napraviti s tim efektom?

Jednostavno. Nemojte pitati developere da procjenjuju ne?to ?to je daleko u budu?nosti. Nikad. Pitajte nas za procjenu ne?ega ?to ?emo raditi u nadolaze?im danima, odnosno sljede?i sprint (ako smo u Scrumu). Kako ?ete onda znati koliko je velik projekt? Jednostavno, suo?ite se s time da nema ?anse da znate. Stvorite zdrav odnos sa ?injenicom da je budu?nost nepredvidiva. S druge strane, budite opsjednuti sa mjerenjem koli?ine posla (zajedno sa efektom na korisnike koju inkrement ima, itd.) koju tim obavlja, u?inite sve kako biste to mjerenje olak?ali i kako bi barataju?i tim - empirijskim! - brojkama radili razne projekcije.

Jedino ste za njih sigurni da sadr?e odlazak do du?ana po novu konzervu.

要查看或添加评论,请登录

Darko ?poljari?的更多文章

  • A message to myself in 2019

    A message to myself in 2019

    Back in 2019, in my former company we were doing quarterly releases. For a period also bi-monthly.

    1 条评论
  • Scrum, "by the book"

    Scrum, "by the book"

    Many times I've seen teams struggle with Scrum. Many times I've seen "scrum, but" implementations.

  • Jack of all trades, master of none

    Jack of all trades, master of none

    ..

    1 条评论
  • Refactoring for business people

    Refactoring for business people

    Try calculating this without a calculator.: 1.

  • Business people and developers. The language.

    Business people and developers. The language.

    Recently I had a session with a couple of business people in my company and we had an interesting conversation. The…

  • O pregledu koda

    O pregledu koda

    Mislim na praksu code review - evo kako to sretno izgleda kad prevedete na hrvatski :) ?ujem dosta ekipe da pri?a kako…

  • O preuzimanju odgovornosti

    O preuzimanju odgovornosti

    Obuzelo me ju?er razmi?ljanje o odgovornosti, i preuzimanju odgovornosti na sebe. Kako je to .

    1 条评论
  • "Kako stojimo" - u waterfall projektima

    "Kako stojimo" - u waterfall projektima

    U zadnje vrijeme relativno ?esto me pitaju kako stojimo na projektu. Produkcija se bli?i, neki rokovi ve? pro?li i…

  • Software is a 100% thing.

    Software is a 100% thing.

    Disclaimer - this is a rant, and there's harsh language ahead. Let me ask you something.

  • Scrum is a challenge

    Scrum is a challenge

    I've been thinking about how many Scrum teams actually aren't Scrum teams, and why that is so. Stuff that usually…