Váš názor na agilní vývoj - Scrum

[tomtim]

Zaujimal by ma vas nazor na tento druh vyvojoveho procesu. Pracovali ste s nim a boli ste spokojni? Nemate pocit, ze je tam vela veci zbytocnych, ktore otravuju vyvojarov? Ako dlhe sprinty su podla vas optimalne?
Ja som si presiel viacerymi firmami,  od vyvojoveho procesu "chaos" az po agilny vyvoj. Musim povedat, ze ten agilny vyvoj ma nieco do seba a vychadzal mi ako zatial najlepsi po tych ostatnych zazitkoch. Co ma na nom ale stve, je to mnozstvo mitingov. Clovek je zamysleny do prace a zrazu miting. X refinementov, rozne planningy, potom retrospektiva, kde sa pisu rozne happyend indexy (neviem si predstavit, ze niekedy vo veku 55 rokov budem pisat happyend indexy alebo robit ine aktivity, ktore si zmysli scrum master). Scrum board a premiestnovanie roznych buttonikov po tabuly. Dost takych zbytocnych veci mi pride na tom.

[Reklama]

[to_je_jedno]

Scrum je to nejlepsi co me kdy potkalo. Na zacatku me to prislo strasne neefektivni, ale postupne jsem mu prisel na chut. nevim co myslis tim porad meetingy. mame jednou denne standup. a jednou za dva tydny je den venovany tem ostatnim vecem. zadne happyend indexy nemame.

[Lambo]

Prosel jsem nekolika firmami. Spravne implementovat neni vubec jednoduche a predpoklada to disciplinu vsech zucastnenych a kvalitni zpracovani firemnich procesu, ktere musi byt striktne dodrzovany. Zazil jsem i to, ze se zavedl scrum, ale postupne se polevovalo a polevovalo, az se doslo zpet k vychozimu bodu. Takze duslednost a vymahat dodrzovani procesu.

Jinak idealni delka sprintu je podle mne jeden tyden. Zazil jsem i dva tydny, ale to bylo podle mne uz moc a bylo to celkove mene pruzne. Velkym prinosem jsou kazdy den standup meetings. Pomuze to pracovnikovi naladit mozek na praci a zorientovat se v tom, co resi kolegove. Pripadne lze na standupu zjistit, za jakym kolegou zajit pro pomoc. Standup by mel byt rano, kdyz jsou vsichni jiz v kancelari a jsou po prvnim kafi, takze jeste dostatecne cerstvi. Podle meho by na jednoho clena teamu mely pripadnout maximalne 2 minuty casu v ramci standupu. Chyba je, kdyz se ze standupu stane delsi porada. To pak ji pracovnici zacnou brat jako nudnou buzeraci, pri ktere musi stat. Proc by meli deset minut poslouchat podrobnosti o issue, ktere resi kolega? Staci jim par vet. Zbytek se musi resit na adhoc meetings.

Planning je v podstate zbytecny. Kvalitne zpracovane issue handling procesy ho mohou nahradit - jednoduchy uvod do issue na standupu od scrum mastera, zbytek pripadne na adhoc meetingu. Opet plati neobtezovat ostatni pracovniky. Maximalne vyuzivat issue tracking tools - jira je skvela.

Scrum a kanban boards se mi neosvedcilo. Moc barevnych papirku, na ktere kazdy kasle.

Happy end index? To neznam, ale mozna se jedno o nejaky teambuilding s happy endem...

Retrospektiva. Zde nemam jednoznacny nazor. Pokud je rozumna a kratka, muze to byt prinosne. Nekolika hodinova buzerace, ktera nic v podstate ani nemuze vyresit, je obtezujici a k nicemu.

[tomtim]

Scrum je to nejlepsi co me kdy potkalo. Na zacatku me to prislo strasne neefektivni, ale postupne jsem mu prisel na chut. nevim co myslis tim porad meetingy. mame jednou denne standup. a jednou za dva tydny je den venovany tem ostatnim vecem. zadne happyend indexy nemame.

Ano denne standupy su bezne. To je v pohode a to si myslim, ze je fajn.
Retrospektiva je o tom, kde sa zhodnoti sprint. A napr happyend index je index vyjadrujuci spokojnost. Nemusi sa to vyjadrovat len cislami.

[isimluk]

Se Scrumem je vzdycky kopa legrace. Zrovna vcera jsem na toto tema vytvoril demotivak: https://isimluk.fedorapeople.org/demot/agile.png

Nekdy se to ale prehani a zapomina se na 4 body agile manifesta. Tedy ze napriklad lide a vztahy jsou vic nez procesy. Nejcasteji se scrum stane procesem, ktery je vic nez lide a vztahy.

[Reklama]

[bumpy hater]

https://www.youtube.com/watch?v=FTM_-H1cPNE

[mon]

Zalezi:

• pre projekty mi lepsie fungoval openup
• pre produkty mi lepsie pasuje scrum
• na podporu kanban

V prvych dvoch mi najlepsie sadla iteracia/sprint 2 tyzdne, za 1 tyzden sa neda vela spravit a za viac je to malo agilne.

Rozumny framework ma feedback/retrospective na prisposobovanie procesu. Len sa na to ludia nesmu vysrat, lebo to dopadne ako pises ty (btw, o happyend indexe som nepocul).

V mojom sucastnom time, nikoho nebavi travit cas na meetingoch ale vsetci vedia ako nam pomahaju tak to drzime na minime. Zo 80h sprintu travime max 4h na meetingoch. Mame 5-15min standup. kazde dva tyzdne mame planing + retrospective spolu cca 30min a raz za tyzden estimation cca 30min. Ludia su zvyknuti sa pripravit dopredu tak tasky nevidime prvykrat na estimation, ani sa nebavime o zbytocnostiach na planingu. Obe sluzia len na detailnejsiu synchronizaciu v time.

Papierove veci som nikdy nepouzil, lebo jira a redmine (+plugin na board) to zvladaju z prehladom.

Hlavne netreba zabudat, ze proces ma pomahat a je pre ludi a nie naopak, aby sa robili veci len pre to, ze to proces vyzaduje.

[mikrom]

https://www.youtube.com/watch?v=2u0sNRO-QKQ

[Fuki]

Zaujimal by ma vas nazor na tento druh vyvojoveho procesu. Pracovali ste s nim a boli ste spokojni?

Nie je idealny ale je optimalny. U vacsich projektov a teamoch je to vyhodne. Pre one-two man show je lepsi kanban.

Nemate pocit, ze je tam vela veci zbytocnych, ktore otravuju vyvojarov?

Najhorsia vec co otravuje vyvojarov je zakaznik. U agile ti to nehrozi, si odtieneny PM, SM, PO od blbosti a tahanic so zakaznikom. Dostavas uz konkretne ulohy.

Ako dlhe sprinty su podla vas optimalne?

Zavisi od velkosti teamu, ale vacsinou sa pouzivaju 2 tyzdnove, teda 10 pracovnych dni. Z toho tak 1-2 sa zabiju meetingami, planovanim, vyhodnocovanim atd.

Co ma na nom ale stve, je to mnozstvo mitingov. Clovek je zamysleny do prace a zrazu miting. X refinementov, rozne planningy, potom retrospektiva

A to estie niektore teamy maju aj demo :-) Agile je o kvalite produktu. Cas (aj podla teba "zabity") je menej podstatna vec. A v spravnom agile nieco ako deadline neexistuje (co je velke plus). Proste nieco sa zle ohodnitilo ci naplanovalo tak sa nic nedeje, nehotova uloha ide do dalsieho sprintu. Ziadne sturmovacky a odovzdavanie nehotovych veci len aby bolo. Si uvedom ze agile v prvom rade CHRANI developera. Za to tych par mitingov stoji. Navyse je to o ludoch, nie je zadien problem sa z nejakeho mitingu ospravedlinit a venovat cas radej vyvoju ked citis, ze si uzitocnejsi tam.

Scrum board a premiestnovanie roznych buttonikov po tabuli

Opat zavisi od teamu a kvality scrum mastera, ci boardy su na nieco dobre alebo su len lebo "sa to patri". Vzdy a vsade zdoraznujte, ze agile je v prvom rade o kvalite produktu, nie o administrative okolo. S takymto postojom budu spokojni vsetci.

[Kit]

Scrum je fajn věc, pokud se provozuje správně. Bohužel to není samozřejmé. Jeho primárním cílem je šetřit časem stráveným na schůzích. Když vím, že stand-up je každý den v tolik hodin, tak tomu přizpůsobím denní režim a jsem rád, že se další schůze nebudou dělat ad-hoc.

Scrum samotný by měl zabrat zhruba 1-2 hodiny na jeden pracovní týden. Pokud někdo dělá delší, pouze plýtvá časem vývojářů.

[Kit]

V mojom sucastnom time, nikoho nebavi travit cas na meetingoch ale vsetci vedia ako nam pomahaju tak to drzime na minime. Zo 80h sprintu travime max 4h na meetingoch. Mame 5-15min standup. kazde dva tyzdne mame planing + retrospective spolu cca 30min a raz za tyzden estimation cca 30min. Ludia su zvyknuti sa pripravit dopredu tak tasky nevidime prvykrat na estimation, ani sa nebavime o zbytocnostiach na planingu. Obe sluzia len na detailnejsiu synchronizaciu v time.

Přesně takhle to má vypadat. Budiž to vzorem pro ostatní.

[Velky cykloturista]

Scrum samotný by měl zabrat zhruba 1-2 hodiny na jeden pracovní týden. Pokud někdo dělá delší, pouze plýtvá časem vývojářů.

To bych rekl, ze je docela dost. 10 min denne = 50 min. Nezapomen, ze se potkavaji lidi z ruznych oboru SWD/QA.

Jinak zaznelo tu slovo "spravne" nic takovyho neexistuje a kazdej tym si to svy spravne musi najit i.e. "scrum by books" je bull. Taky bylo zmineno, ze "vztahy v tymu ve scrumu znamenaji vic nez pomrdanej proces" (parafraze pro blbecky), to je treba mit na pameti.

[Mastr skram]

Pulka z vas nechape co vubec 'agilni' znamena. Jednak vas zmatly kecy konzultantu ktery to slovo znasilnili, jednak jste v cechach, kde se o vecech nedebatuje, jen se prebira, posloucha a drzi hubu a krok.

Jestli se hadate o micovinach typu jak dlouhy maji bejt sprinty ve scrumu a kdy delat standupy, tak pravdepodobne taky netusite o co go. Jestli vubec debatujes o tom jak pouzivat scrum, tak 'agilni' rovnou vzdej, protoze to nechapes.

Kanban a TPS taky velmi nepochopeno. Pokud nemate jasne definovany staze vyrobniho procesu, tak z toho tezko udelam kanban. Na cisty datlovani kodu to ani nejde pouzit. Musis se nejdric podivat na tok dat ve firme a ten mapovat kanbanem, ne nejaky pismenka co nejakej debzot macka do kompjutru a rika si programator. Kanban je pro ty co optimalizujou tok dat ve firme nebo organizaci, automatizace programivanim je jenom nastroj jak to optimalizovat. Kdezto kazdej mamlas v cechach to pouzije ve stylu 'pocet dodanych featur' 'pocet otestovanych featur'. Again, vzdejte to rovnou.

Fowler nekde tvrdil ze kdyz vymysleli jmeno pro manifesto, tak se to melo puvodne jmenovat 'komunikativni styl programovani'. Co jim prislo moc vagni tak tomu dali nazev agilni. Tim to spis jen imho zmrvili. Jakoze oproti vodopadu maji daleko rychlejsi agilnejsi zpetnou vazbu nebi tak nejak.

Mam po pivku, kdyby neco.

[Kolo]

Pulka z vas nechape co vubec 'agilni' znamena.

... snuska kydu...

Mam po pivku, kdyby neco.

A ty taky lopato.

[MarSik]

To bych rekl, ze je docela dost. 10 min denne = 50 min. Nezapomen, ze se potkavaji lidi z ruznych oboru SWD/QA.

Na druhou stranu je mnohem efektivnější se domluvit na plánu osobně, než si půl dne vyměňovat emaily. Ranní porady jsou celkem běžnou věcí ve spoustě profesí.

Za důležitější fakt považuju informaci, že Standup není status meeting. Je to totiž planning meeting. Není potřeba otravovat ostatní nudným vyprávěním o tom, co jsem dělal včera. Je potřeba zjistit co nám chybí a kdo potřebuje pomoct.