Názory k článku
Agilní vývoj: Scrum

Fandím, tleskám, tisknu!

Vybrony clanok, len priznam sa nic zasa take objavne mi nedal. Je to pre mna akurat taky trochu iny pohlad a inak pomenovane tie iste veci. Osobne si myslim ze kazdy vyvojar a sw project manager, mozno aj nevedomky, k niecomu podobnemu v praxi dospel a dopracoval sa (mozno mierne ine ale podobny princip). Je fajn ze je to spisane a ze zacinajuci team sa moze z toho poucit (aj ked asi kazdy si peklo terminov a odovzdavania musi prejist sam a popalit sa :-)) ale v konecnom dosledku to je stale len teoria.

Osobne ja som narazal vzdy na dva problemy a myslim ze tie budu v kazdom systeme a koli nim aj ma velka vecsina projektov problem s casom.Ten prvy, ktory tu bol aj popisany ale tazko sa v praxi dosahuje je zakazanie zmien zadania po starte vyvoja. A druhy moznost povedzme tych 6 hodin v kuse pracovat a sustredit sa bez vyrusovania a vytrhavania od prace.

Asi bude tazke zmenit zauzivany postoj ze sw je predsa „soft“ tak sa moze menit hoci kedy aj pocas vyvoja a v hocijakom rozsahu s predstavou ze to nejak zasadne neovplivni cas vyvoja.

V článku říkáte, že je třeba odhadnout čas. Nicméně, co když je součástí aplikace i nějaký složitější problém, se kterým jsme se setkali poprvé a řešení bude třeba vymyslet (nevíme, jak dlouho to bude trvat), jak v takovém případě odhadnout čas.

Například děláme aplikaci pro přípravu rozvrhů do školy. Zadá se, jaké předměty je třeba rozvrhnout, jaké třídy jsou k dispozici + další omezení jako, kdo kdy z učitelů má čas a aplikace vygeneruje rozvrh. Navrhnout uživatelské rozhraní je docela snadné, jádrem programu je ovšem plánovací algoritmus a nikdo neví, jak dlouho bude trvat ho naprogramovat, aby dával slušné výsledky.

Co v podobných případech napsat jako odhad času?

K problému s odhadováním

1) odhadování se často řeší pomocí tzv. „planning pokeru“. Jednotliví členové týmu odhadují náročnost kroků nutných k implementaci. Pokud se někdo příliš odchýlí, zjištuje se, proč to odhadl tolik odlišně.

2) ve Scrumu dostáváte z backlogu úkoly, které často trvají třeba 4 hodiny, 6 hodin, málokdy přes 12 hodin. Pokud nejste schopni rozepsat implementaci takového algoritmu na úkoly po (dejme tomu) 6 hodinách, nemáte dostatečnou analýzu a nemůžete správně odhadnout čas.

3) Příprava rozvrhů skutečně není jednoduchý algoritmus. Může se tedy i stát, že čas přesáhne víc než 1 iteraci. Přes tuto iteraci byste časový odhad stejně neprovedli.

4) První 2 iterace je běžné, že se časové odhady úplně ustřelí, než se zjistí skutečná velocity týmu, pak už je odhadování přesnější.

V případě vaší firmy bych zvolil zkrácené iterace (třeba 1–2 týdny) a pokusil bych se sepsat product backlog po malých krocích (kratších než 1 člověkoden). Rychle zjistíte velocity, naučíte se odhadovat krátké kroky a předběžný časový odhad.

Problémem je ale dotlačit zákazníka (je-li to pro 1 zákazníka na míru), aby byl ochoten odhadovat, fakturovat a pracovat v krátkých iteracích.

Díky za odpověď a těším se na další díl seriálu.

planning poker

Příště prosím uveďte takto stručnou odpověď alespoň nějakým úvodem – např. že „k odhadu času lze použít nástroj Planning Poker“. Takto to vypadá jako spamový komentář.

dobry clanocek, dik.
Existuju nejaka metodika, ked pracujem na projekte sam?
Tiez by som v tom chcel mat poriadok a prehlad, takisto chcem pracovat co najefektivnejsie, nerobit nic zbytocne, dodat produkt vcas apod.

Já sám na svou organizaci používám Getting Things Done a několik agilních technik. Hodně inspirace jsem nasbíral v Getting Real (o kterém vyjde něco příští týden).

Vyzkoušejte, třeba to bude fungovat i u Vás. Každý člověk má ale jiné potřeby.

Dakujem, GTD sa snazim s vacsim ci mensim uspechom pouzivat :-)
Tesim sa na ten Getting Real, snad ma to posunie zase o krok dalej…

A systemove ukoly, ktore se netykaji uzivatelskych funkcii ako napriklad tvorba databazy,tvorba Data Access vrstvy a rozne architektonicke ukony sa ties radia medzi user stories ?

Je to individuální. Obecně by vám to asi nikdo nezakázal, v praxi se toto asi nestane. Už proto, že samotný DAL nezvyšuje business-hodnotu.

Respektive určí se user-stories a kroky, které jsou nutné k jejich implementaci. Tedy např.vytváření DAL musí být nutné pro nějaký user-story (a to bude téměř stoprocentně). Takže se vytváření DAL dostane do project backlogu jako jedna z podmínek implementace jiných vlastností.

Změny v architektuře se vejdou do fáze refaktoring a jako takové by se měly provádět na konci každé iterace (pokud je stará arch.nevyhovující).

Jakym zpusobem a v jake fazi se rozbijeji user stories na jednotlive tasky a kdo hodnoti jejich narocnost?

Pokud chapu dobre tak chcete delit story na tasky (nebo pod-story). Da se to delat pred zacatkem iterace, nebo i v prubehu, dulezite je obeznameni zadavatele (zakaznik, nebo nekdo v jeho roli). S tim, ze obvykle pod-story/task sam o sobe neprinasi prodatelnou hodnotu, a mel byste byt schopen nejakou jejich mnozinu mit hotovou do konce iterace.

Narocnost stanovuje vzdy implementator (tedy vyvojar). Muze se klidne stat, ze soucet odhadu novych ukolu nesedi s puvodnim. Byl to jen odhad a ten se prave upresnil.