Komentáře k článku

Agilní vývoj: Scrum

Po minulém úvodu, kde jsme si představili agilní metodiky a techniky obecněji, nastal čas podívat se na pravděpodobně nejznámější metodiku agilního programování, která nese název Scrum. Kdo je Scrum Master? Kdo jsou kuřata a kdo prasata? A proč? Vše se dozvíte v dnešním pokračování.

Zpět na článek

15 komentářů k článku Agilní vývoj: Scrum:

  1. dc

    fajn

    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.

  2. xx

    Odhad času pro složitější problémy

    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?

    1. Jiří Knesl

      Re: Odhad času pro složitější problémy

      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.

        1. Martin Malý

          Re: Odhad času pro složitější problémy

          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ář.

  3. fredy

    pekne

    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.

    1. Jiří Knesl

      Re: pekne

      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.

      1. fredy

        Re: pekne

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

  4. metak

    User Stories

    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 ?

    1. Jiří Knesl

      Re: 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í).

  5. pho

    Rozbijeni user stories na tasky

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

    1. pht

      Re: Rozbijeni user stories na tasky

      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.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3138