Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: tomtim 25. 11. 2018, 08:22:13
-
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.
-
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.
-
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.
-
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.
-
Se Scrumem je vzdycky kopa legrace. Zrovna vcera jsem na toto tema vytvoril demotivak: https://isimluk.fedorapeople.org/demot/agile.png (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.
-
https://www.youtube.com/watch?v=FTM_-H1cPNE
-
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.
-
https://www.youtube.com/watch?v=2u0sNRO-QKQ
-
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.
-
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ářů.
-
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í.
-
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.
-
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.
-
Pulka z vas nechape co vubec 'agilni' znamena.
... snuska kydu...
Mam po pivku, kdyby neco.
A ty taky lopato.
-
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.
-
Daily scrum (nebo standup) je fakt o tom co se dela, co se nemuze delat (blocked) a jestli neco nevisi a nema prirazenou osobu (treba code review hotoveho). Co jsem delal vcera do scrumu nepatri. Hlavni idea teto denni aktivity je aby zbytek teamu mel sajnu co delaji kolegove a jestli neobjevuji ameriku.
-
Styl odpovědi hrozný, ale máte v hodně věcech pravdu.
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.
Tohle je přesně to o čem mluví Bob Martin (další z autorů agile manifesto) ve své přednášce Future of programming. https://www.youtube.com/watch?v=ecIWPzGEbFc
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.
Ale jde. Například pro údržbu starého produktu, kde dominují bugy, je to mnohem vhodnější než Scrum. Kanban má přece jediné pravidlo, omezení na množství práce v rozdělaném stavu. A bugzilla/JIRA/redmine/... definuje i ty kroky procesu (třeba ve formě NEW - ACCEPTED - MODIFIED - VERIFIED - CLOSED).
Na vývoj na zelené louce zase Kanban tak moc vhodný není.
-
scrum je hodne vtipnej - a jeste vtipnejsi sou scrum masteri - to je vetsinou dobra bandicka naprostejch budizknicemu :) za ty roky co delam sw muzu rict ze nejvetsi zmr*i sou prave ty "role" nabaleny na sw vyvoj - jako scrum masteri, product manageri (owneri), testeri - proste banda hovad co neumi programovat ani premyslet ale cejti se jako vyvoleni v ramci vyvoje a ti jedini obvykle kteri nerozumi ani problemum ktere se maji resit ani tomu jak delat sw :)
scrum samotnej hodne pripomina demenci v pokrocilem stadiu - zvlast potom ty nalepovaci papirky nebo ruzne hry a pomucky - v cele se skrum masterem je to obcas hodne bizardni podivana na bandu a pokud by ten team daly za tluste sklo v bohnicich tak verim ze by nikdo nepoznal rozil ...
ale i mezi nima jsou svetle vyjimky - tyto vyjimky jsou ale samozrejme fungovat v jakemkoliv systemu zeno
-
Mě to trošku příjde jako s papírovou evidencí, vzniklo to jako podpora nějakého procesu. Pak se lidi zbláznili a začali papírovat každý nesmysl, bez vazby na realitu. Tlupa opic v akci :)
Každá pomůcka se má používat tak, aby byla efektivní a něco přinášela. Nikoliv aby "byla použita" a máme odškrtnuto.
Je mnoho situací, kdy se vyplatí papíry spálit, data vymazat a neřešit to. Stejně tak je mnoho úkolů, které si bez kvalitního předávání informací nelze představit.
Každý nástroj je taky vhodný na něco jiného a zabíjet hřebíky šroubovákem není dobrý nápad.
-
Taky jsme si dva roky zpátky na scrum a prvoplánový agilní vývoj hráli. Přišel s tím nový šéf a tlačil přesvědčení, že to je pro nás to správné.
Jenže on byl přijatý spíš kvůli zlepšení špatné finanční produktivity firmy - ziskovosti realizovaných projektů, a když se to po půlroce nelepšilo, tak byl zase odejit - a s ním odešel i scrum (myšleno standupy, retrospektivy... agilní vývoj úplně ne, různé jeho prvky používáme odjakživa).
Jeho volná náhrada sice programování nerozumí, ale rozumí vedení projektů a financím, dokáže si pohlídat smlovy, příjmy a náklady a firmě to celkově prospělo víc než scrum.
-
Mě to trošku příjde jako s papírovou evidencí, vzniklo to jako podpora nějakého procesu. Pak se lidi zbláznili a začali papírovat každý nesmysl, bez vazby na realitu. Tlupa opic v akci :)
+1
Když v minulé práci zavedli povinně stand upy, zjistili jsme, že jsou k ničemu a zrušili jsme je (úkoly byly v Jiře, nový věci stejně trvaly měsíc a nemělo smysl říkat, že "Jura dneska bude zase řešit co je v Jiře a Karel bude dneska dělat na implementaci protokolu XY jako celý předminulý a minulý týden". Manažeři se ale rozhodli, že to je povinný a nařídili nám je. Tak se ráno domlouvala naprosto konstruktivně hospoda, fotbal, řešily se ženský,... O projektu stejně ani slovo.
-
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.
Osobne ani omylom, to je akurát tak najrýchlejšia cesta na niečo zabudnúť. A maily tam tiež nepatria, tie sú leda tak na notifikácie, že mi bol napríklad pridelený ticket. Ani ma nehne urobiť nič, na čo nie je ticket. Kto zabudne požiadavku zadať, jeho chyba. Ak je zadaná a ja ten ticket ignorujem, moja chyba. Ale nikdy hádky typu "povedal som ti to, ale ty si na to zabudol" vs "nie, to ty si mi to zabudol povedať". NIKDY ŽIADNY PROCES NEZADÁVAŤ OSOBNE, NIKDY ZIADNY PROCES NETRACKOVAŤ MAILOM.
-
Me scrum postihl pred nekolika lety. Nejak jsem nepochopil, k cemu to je vlastne dobre. Byli jsme celkem sehrany tym, kazdy mel svou oblast, kde byl kovany s urcitymi prekryvy. A ted scrum do toho. Jak mam vedet, jak dlouho / jak je narocny ukol X? Pro me, co o tom vi kulovy, je mesic malo, kolega odbornik na danou vec to ma za 10 minut. Tak cemu scrumove hlasovani (mam na mysli takove ty karty s cisly obtiznosti co symbolem kafe)?
Scrum jsme meli 3 tydny. T.j. kazdy 3. tyden se jen schuzovalo, vetsinu ukolu jsme schuzovali 3x, na koncove schuzi, ze se nestihl, pak na uvodni, ze se zase bude delat a pak na planovaci, ze by se mel teda delat. Pak se to vetsinou za 3 tydny opakovalo, protoze prisel nejaky pru... a ten mel vyssi prioritu.
A "standup" - to je jak nastup na buzerplatz, ponekud nedustojne.
Prislo mi, ze scrum vede k odflakle praci, ted 5 minut usetrim a pak tim stravim hodinu kazdy dalsi scrum.
-
Neumeli jste to uchytit.
-
Neumeli jste to uchytit.
nemeli konzultanta ani certifikovanyho sc(r)um mastera
-
Dotaz:
Kdo měl v téhle souvislosti tu čest se [url =https://sochova.cz/]Zuzanou Šochovou[/url]?
Ještě teď na mě v práci na stole kouká z jedné z těch scrumových karet. ;D
-
Neumeli jste to uchytit.
Tak hlavní je, že tu kokotinu uměli vyhodit. :P
-
Dotaz:
Kdo měl v téhle souvislosti tu čest se [url =https://sochova.cz/]Zuzanou Šochovou[/url]?
Ještě teď na mě v práci na stole kouká z jedné z těch scrumových karet. ;D
na jeji webove strance:
'Je nositelkou mnoha dalších uznávaných certifikací jako'
mysli se tim, ze je nosi porad ssebou?
Jinak tech certifikatu ma mila pani vice jak rusky general vyznamenani. Je mi pres 60 a nikdy jsem neco takoveho nemusel delat, ale na druhou stranu nebyly ty banany a toaletni papir. Mladou generaci lituji, musi se s tim poprat, doufam ze nakonec zvitezi a mladi lide budou moct chodit normalne do prace jako my drive.
-
takovejch je cela armada ruzne rozstrkana po firmach :) je to peknej ulet - ma to za sebou i takovy ukrutny letadlo model
-
U nás vo firme su mixed teamy, kde sú ľudia roztrúsení po celom svete. Uriadiť to inak ako cez agile a scrumm si neviem predstaviť :)
-
U nás vo firme su mixed teamy, kde sú ľudia roztrúsení po celom svete. Uriadiť to inak ako cez agile a scrumm si neviem predstaviť :)
Mozes aspon naznacit aka je to firma? Alebo aspon mesto. Dik.
-
Prislo mi, ze scrum vede k odflakle praci, ted 5 minut usetrim a pak tim stravim hodinu kazdy dalsi scrum.
tohle je zajima myslenka. me to totiz z praxe vychazi naopak. ale mozna to jen ve firme delame blbe.
a jinak nez agile uz bych delat nesel.
-
SCRUM/Agile je dobrý pro tým lidí, kteří umí a chtějí. V týmu může být někdo, kdo neumí, a chce, pak se dokonce rychle dostane nahoru a ostatním to pomůže si utříbit, co má hodnotu a co ne, protože tenhle systém je tvrdě o hodnotách. Hodnoty si stanovuje tým na retrospektivách.
Nebude to fungovat pro skupinu - když vám nikdo nepomůže, nebo vy jemu, nemá smysl ztrácet čas na stand-up(u) ani retrospektivě, protože v tom případě se z nich staly jen různě často se opakující skupinové terapie.
-
tohle je zajima myslenka. me to totiz z praxe vychazi naopak. ale mozna to jen ve firme delame blbe.
a jinak nez agile uz bych delat nesel.
Scrum nepodporuje specializaci v ramci teamu, ale prave naopak. Kazdy dela vsechno, ukoly se prirazuji vyvojarum jak to vyjde. Takze vsichni vlastni vsechno, t.j. nikdo nevlastni nic. Zdrojak se stane vlivem castych a malych zmen od ruznych lidi prisernym bastlem. Nikdo tomu poradne nerozumi, jen se vi, ze ted to funguje a pridavam mensi zmenu. Kdyby dany kod delal zejmena 1 clovek, davno to prepise, zprehledni a vycisti. A pokud mu do toho hrabne nekdo jiny, vlastnik si to pri nejblizsi prilezitosti zreviduje a pripadne da kolegovi drzkovou :-)
-
SCRUM/Agile je dobrý pro tým lidí, kteří umí a chtějí. ...
My jsme tehdy byli zavedeny team, ktery umel a chtel. Scrum nam byl narizen, tak jsme jej delali, celkem jsme se i snazili najit to, co je v nem dobre, kdyz uz to stejne musime delat. Ale vlastni organizaci prace a technicke detaily jsme stejne resili bokem.
-
SCRUM/Agile je dobrý pro tým lidí, kteří umí a chtějí. ...
My jsme tehdy byli zavedeny team, ktery umel a chtel. Scrum nam byl narizen, tak jsme jej delali, celkem jsme se i snazili najit to, co je v nem dobre, kdyz uz to stejne musime delat. Ale vlastni organizaci prace a technicke detaily jsme stejne resili bokem.
- Neobhajuji, pouze říkám, co je nutná podmínka, aby to vůbec mohlo fungovat.
- Pokud fungujícímu týmu někdo vnutil metodiku, není divu, že to nemělo hodnotu.
-
Já nevím, mně to vždycky přišlo jako kargokult, který leda otravuje.
-
Zdrojak se stane vlivem castych a malych zmen od ruznych lidi prisernym bastlem. Nikdo tomu poradne nerozumi, jen se vi, ze ted to funguje a pridavam mensi zmenu. Kdyby dany kod delal zejmena 1 clovek, davno to prepise, zprehledni a vycisti. A pokud mu do toho hrabne nekdo jiny, vlastnik si to pri nejblizsi prilezitosti zreviduje a pripadne da kolegovi drzkovou :-)
Pokud máte tým a společný projekt, kde jste si nedohodli jednotná pravidla psaní kódu a každý si to mastí jak chce, tak to může skončit i takhle. Ale je to špatně už na začátku. Párové programování na vás! ;D
U nás je tedy trochu jiná situace (spousta menších projektů, ne jeden velký), ale pokud něco menšího upravuju v cizím kódu, snažím se ctít ten styl, který v kódu vidím - a přemýšlím při tom zda to má nějaké výhody abych to třeba převzal i do budoucna. Vlastní postupy v kódu, který jsem nezačínal, používám jen u větších bloků, kde za tu část přebírám plnou zodpovědnost.
-
My jsme tehdy byli zavedeny team, ktery umel a chtel. Scrum nam byl narizen, tak jsme jej delali...
Scrum nepodporuje specializaci v ramci teamu, ale prave naopak. Kazdy dela vsechno, ukoly se prirazuji vyvojarum jak to vyjde.
Toto je přesně ten problém, který tuším ve Vaší implementaci. Úkoly se totiž nepřiřazují lidem shora. Tým si sám rozhodne, kdo s kým a co bude ten den dělat. Jediné přiřazování úkolů celému týmu probíhá dohodou na planningu. A tam se "přesně" ví, kolik toho tým v daném složení zvládne. Ono ne všechno musí dělat ten jeden expert na danou oblast, nějaká zastupitelnost je potřeba i za cenu teoretického malého (a dočasného) zpomalení.
Tohle je totiž zásadní a úplně typický problém blbě použitého SCRUMu (nebo agile obecně). Nějaký šéf nařídí SCRUM, aby měl lepší kontrolu nad lidmi, místo toho aby ten tým použil vhodnou metodiku pro podporu své práce.
Takze vsichni vlastni vsechno, t.j. nikdo nevlastni nic. Zdrojak se stane vlivem castych a malych zmen od ruznych lidi prisernym bastlem.
Opět viz přednáška od Boba Martina, kterou jsem linkoval výše. Součástí Agile je i řemeslná kvalita zpracování. Takže to prasení nesmí projít přes code review (stejně jako absence testů).
Jeden z 12 základních principů Agile manifestu:
"Continuous attention to technical excellence and good design enhances agility."
Nebude to fungovat pro skupinu - když vám nikdo nepomůže, nebo vy jemu, nemá smysl ztrácet čas na stand-up(u) ani retrospektivě, protože v tom případě se z nich staly jen různě často se opakující skupinové terapie.
Amen. Ta skupina musí fungovat jako tým, kde silnější pomůžou slabším (a něco je tím naučí). Pak mají i daily standupy smysl (kolegové si navzájem řeknou, kde potřebují pomoct).
Osobne ani omylom, to je akurát tak najrýchlejšia cesta na niečo zabudnúť.
Na standupu se žádné úkoly nerozdělují. Slouží jen pro synchronizaci uvnitř týmu. Nadřízení tam můžou tak maximálně upozornit, že se v rámci běžícího sprintu změnila priorita (pokud to předtím zadali do Jiry, Trella, ...). Do ničeho jiného na standupu kecat NESMÍ (jinak už to není SCRUM).
Odpovídající princip z Agile manifestu: "Build projects around motivated individuals. Give them the environment and support they need, and TRUST them to get the job done."
Všechny úkoly jsou samozřejmě sledované a výstup z 5-10 minutové porady zvládnete do systému přepsat za minutu. Obzvlášť, když žádný není, protože na závažná rozhodnutí jste si udělali separátní poradu jen s relevantními lidmi a ty změny zapisujete průběžně.
-
Moje skusenosti v skratke...
Raz si niekto myslel ze to je len o tom mat kanban board.
Standupy, skvela vec ? Strasne ma to rusilo, ked som mal nieco rozpracovane ale vedel som ze v dany cas sa musim ist postavit niekde do kruhu a posuvat tasky na boarde. Casto sa tieto standupy prave zvrhnu na to, ze sa riesia problemy. Osobne v tom nevidim zmysel mat to kazdy den, max by som to obmedzil medzi ludi, ktory robia na rovnakej veci. 90% casu mi nedalo nic z toho ze som vedel ze kolega robi nieco a ze to bude robit este v ten den lebo to nieje hotove atd. Zalezi vsak od projektu a komplexity takze by som to nezahodil ale dal tomu viac volnosti. Na komunikaciu s remote ludmi to je fajn.
Skusenost z jednej korporacie, okolo standup time takmer hodinu nikto nepracoval.
Problemy okolo ludi by som nechal na zodpovedneho cloveka manazera a nezatazoval tim cely tim, veci ktore sa preberaju na retrospektive. Na druhej strane ako plus beriem ze viem viac informacii o projekte, co sa bude robit atd.
Pri planningu dlhsom ako 1,5h som vypinal mozog.
Rozlicne ponatie toho co je epic, stories a nasledne definovanie toho kto co bude robit, story pointy...
Neplanovane meetingy, opat len zabijak produktivity.
User stories bez definition alebo nekompletne, ale hlavne ze je product owner, scrum master a neviem kto este.
Moze to byt cool ale nie vzdy tade musi viest cesta. Osobne zmyslam skor "lean".
-
Pokud máte tým a společný projekt, kde jste si nedohodli jednotná pravidla psaní kódu a každý si to mastí jak chce, tak to může skončit i takhle. Ale je to špatně už na začátku. Párové programování na vás! ;D
U nás je tedy trochu jiná situace (spousta menších projektů, ne jeden velký), ale pokud něco menšího upravuju v cizím kódu, snažím se ctít ten styl, který v kódu vidím - a přemýšlím při tom zda to má nějaké výhody abych to třeba převzal i do budoucna. Vlastní postupy v kódu, který jsem nezačínal, používám jen u větších bloků, kde za tu část přebírám plnou zodpovědnost.
Jednotna pravidla psani kodu mozna definuje jak psat zavorky, jak odsazovat. Ale semanticke praseni takova pravidla nepokryvaji. Parove programovani - to se fakt nekde pouziva? Jakou to ma produktivitu prace? 25% ?
Nam se tehdy osvedcil model "kazdy zdrojak ma sveho majitele" a ostatni do toho zasahuji velmi opatrne a majitel to pak zreviduje.
-
Je to celý píčovina. Kdyby se takhle vyvíjely letadla, máme osmiplošníky s vrtulema na podvozku.
-
Je to celý píčovina. Kdyby se takhle vyvíjely letadla, máme osmiplošníky s vrtulema na podvozku.
+1
-
Je to celý píčovina. Kdyby se takhle vyvíjely letadla, máme osmiplošníky s vrtulema na podvozku.
Letadla asi ne, ale metodiky agilního vývoje SW berou přímou inspiraci mimo jiné z Lean Manufacturing uplatňovaném například v Toyotě. A nevšiml jsem si, že by její auta měly dveře na podvozku nebo tak něco :-D
-
Proč mi přijde, že tady diskutují převážně puberťáci z garážovek?
-
v dany cas sa musim ist postavit niekde do kruhu a posuvat tasky na boarde
a tohle se prave na standupu delat NEMA
-
Napriklad mi na standupe posuvame tasky, riesime, co sme robili a na com budeme robit v dany den a v com vidime problemy.
Co sa tyka rozdelenia uloh, vzdy si to delime v time. Takze stava sa, ze clovek robi aj v oblasti, ktoru nikdy nevidel. Taketo delenie sa mi nepaci, pretoze jeden cas robim na niecom a potom sa k tomu nedostanem napr dalsie 3-4 sprinty, cize sa nedokazem do toho az tak ponorit a ziskat vacsi prehlad o tom.
Takisto estimacia pomocou kariet mi pride trochu odveci. Pretoze kazdy vidi obtiaznost inak. Ten kto ovlada danu oblast da 3 a ten kto nie da 8. A co teraz? Da sa 3? Ako sa potom budu delit ulohy?
-
Pretoze kazdy vidi obtiaznost inak.
Jaky je v tomhle smeru rozdil mezi kartama a hodinama?
-
Vidim ze jste vetsina porad zmateny, tak vam to vysvetlim znova.
Vasi manazeri potrebujou vykazovat reporty svym nadrizenym. Ti zas reportujou tem svym nadrizenym a ultimatne CEO musi reportovat boardu a shareholderum a financnim analytikum. Dneska je v mode kvantitativni management. If you can't measure it you can't manage it. Takze odzhora mas tlak na to aby se vedelo kdy a jak co bude hotovo. Ty tam dole jses ta krysa v kanale na ktery cela tahle
firma a manazerska pyramida stoji. Bez tebe by firma nebezela a nebylo co reportovat (jen zlomek vyvojaru drzi ve sprave kriticky systemy, ostatni jsou propustitelny). No tim ze ses dole tak na tebe manazer tlaci abys mu reportoval kdy co bude aby moh on reportovat to samy. Manazer zjistil ze nemas rad mereni na man-daye nebo podobny meritka. Ale slysel ze prej mas rad 'agile'. Tak si o tom nastudoval vic nez ty, priohnul to k obrazu svemu a ukazal ti ze jiny (daleko uspesnejsi) tymy se meri skrz story pointy, gumovy medvidky a podobne. Ty, protoze jses nevzdelanej, mu na to skocis a dohromady tomu rikate s projektakem agilni vyvoj. Jses prece chytrejsi protoze umis kodovat, manazeresky kecy jsou pod tvoji uroven. Za chvili to cely slovo Agilni zacnes nesnaset.
Tru story bro. 70% z vas.
Hele projektaka muzes s timhle vsim poslat do pytle treba rovnou na definici projektu. Projekt ma totiz ohranicenej a jasne definovanej konec, coz je skoro 0% inhouse vyvoje. Nad touhle definici ho utluces jedna basen a muzes oddalovat tyhle sragoroviny do aleluja. Ale to by se chytrej programatorskej chlapec musel privzdelat co. Radsi budu nadavat ze agilni je hnus a litujte me.
Stejne vetsina programatoru by v tech firmach ani nemela bejt, takze tam sedite jen na teplym dobre placenym mistecku. Kdyby programator pracoval spravne, tak si odprogra uje svoji praci a uz ho neni treba. To ze tam sedi tolik koderu znamena, ze se nedokazali odprogramovat a tudiz delaji neco spatne.
Pís
-
Vidim ze jste vetsina porad zmateny, tak vam to vysvetlim znova.
...
Další žhavý kandidát na Cenu Brouka Pytlíka. Máš můj hlas.
-
Co sa tyka rozdelenia uloh, vzdy si to delime v time. Takze stava sa, ze clovek robi aj v oblasti, ktoru nikdy nevidel. Taketo delenie sa mi nepaci, pretoze jeden cas robim na niecom a potom sa k tomu nedostanem napr dalsie 3-4 sprinty, cize sa nedokazem do toho az tak ponorit a ziskat vacsi prehlad o tom.
Nakopej do rozkroku scrummastera. Jeho zodpovědnost je určit, kdo co bude dělat a zohlednit okolnosti. Pokud embeďák dělá databázi a expert na DB dělá GUI, je něco blbě a za tohle je zodpovědný právě SM. Co jinýho k tomu říct.
Takisto estimacia pomocou kariet mi pride trochu odveci. Pretoze kazdy vidi obtiaznost inak. Ten kto ovlada danu oblast da 3 a ten kto nie da 8. A co teraz? Da sa 3? Ako sa potom budu delit ulohy?
(best case + 4 * average + worst case) / 6, pokud zhruba znalosti odpovídají tasku a dostává to člověk ad hoc.
Pokud je tam několik specializací, dá se průměr * bulharská konstanta a přidělí se to tomu, kdo už s tím měl tu čest. Pokud ve finále bude rezerva, použije se na bugfix a dokumentaci.
Pokud jsou ve vedení blbci, násobí se odhad třema, pokud jsou blbci i markeťáci, násobí se pěti.
-
Hele projektaka muzes s timhle vsim poslat do pytle treba rovnou na definici projektu. Projekt ma totiz ohranicenej a jasne definovanej konec, coz je skoro 0% inhouse vyvoje. Nad touhle definici ho utluces jedna basen a muzes oddalovat tyhle sragoroviny do aleluja. Ale to by se chytrej programatorskej chlapec musel privzdelat co. Radsi budu nadavat ze agilni je hnus a litujte me.
Houby leda.
Odhad je problém proto, že lidi nechápou, co to slovo znamená. Klidně ti řeknu, kdy projekt bude, ale musíš říct, s jakou pravděpodobností to chceš. Dám ti jiný čísla, pokud chceš 90% šanci, že bude hotovo a jiný číslo, pokud chceš 99% jistotu, že nebudeš platit penále.
Další věc je to, že projekt se musí jinak účtovat zákazníkovi. Buďto je tam deadline s tím, že jsou pevně daný featury seřazený podle důležitosti a co se stihne, to se stihne, nebo je to placený paušálně, dokud to nebude a zákazník si může měnit zadání za běhu. A reportuje se, že "ve verzi x.y jsme za tolika tolik implementovali tohle a tohle s takovým a takovým přínosem pro zákazníka*" Pokud tohle management a marketing nechápe, je na čase změnit firmu
Další žhavý kandidát na Cenu Brouka Pytlíka. Máš můj hlas.
+1
--------------------
*) stará dobrá FMEA
-
(...) Takze odzhora mas tlak na to aby se vedelo kdy a jak co bude hotovo.
Cože právě, jak říká klasik, kardinální békovina. Agilní metody jsou vhodné pro situace, kdy nedokážeš přesně popsat, co chceš. A když nevíš co chceš, těžko můžeš chtít vědět, kdy a jak to bude hotovo.
Pokud víš co chceš, použiješ vodopád a pak víš, co kdy bude hotovo. Ale bez toho to nejde, to budou jen čísla vycucaná z prstu.
-
Hele projektaka muzes s timhle vsim poslat do pytle treba rovnou na definici projektu. Projekt ma totiz ohranicenej a jasne definovanej konec, coz je skoro 0% inhouse vyvoje. Nad touhle definici ho utluces jedna basen a muzes oddalovat tyhle sragoroviny do aleluja. Ale to by se chytrej programatorskej chlapec musel privzdelat co. Radsi budu nadavat ze agilni je hnus a litujte me.
Houby leda.
Odhad je problém proto, že lidi nechápou, co to slovo znamená. Klidně ti řeknu, kdy projekt bude, ale musíš říct, s jakou pravděpodobností to chceš. Dám ti jiný čísla, pokud chceš 90% šanci, že bude hotovo a jiný číslo, pokud chceš 99% jistotu, že nebudeš platit penále.
Další věc je to, že projekt se musí jinak účtovat zákazníkovi. Buďto je tam deadline s tím, že jsou pevně daný featury seřazený podle důležitosti a co se stihne, to se stihne, nebo je to placený paušálně, dokud to nebude a zákazník si může měnit zadání za běhu. A reportuje se, že "ve verzi x.y jsme za tolika tolik implementovali tohle a tohle s takovým a takovým přínosem pro zákazníka*" Pokud tohle management a marketing nechápe, je na čase změnit firmu
Další žhavý kandidát na Cenu Brouka Pytlíka. Máš můj hlas.
+1
--------------------
*) stará dobrá FMEA
Taky to nechapes Petre, ale rad vysvetlim. Odhad bys mi s temahle cislama dal kdyby vyskytujici se zadrhely dodrzovaly nejakou gaussovu krivku. Bohuzel to tak neni, maji spis exponencialni rozdeleni. Tj. Kdyz se neco zadrhne tak poradne. Snazis se pouzit odhady pro normalni rozdeleni tam kde to nejde. Taleb o tom psal hodne, vhodne precist.
Za druhy. Kdybys dokazal neco predikovat, tak to znamena ze mas ten proces podchycenej jako 'opakovatelnej'. Tj. s velkou pravdepodobnosti mas blby programatory v tymu, ktery to nedokazou rozpoznat a zautomatizovat. Veskerej zbytek procesu ve vy ohi sw, kterej neni opakovatelnej, se bude ridit exponencialnim rozdelenim, a tam si ty procenta muzes strcit do zadku, protoze s nima managementu akorat lzes. Nerikam ze nekdy v tomhle kontextu neni lez lepsi nez hola pravda, ale tady jsme na foru a rikame sinveci jak jsou.
-
Vidim ze jste vetsina porad zmateny, tak vam to vysvetlim znova.
...
Další žhavý kandidát na Cenu Brouka Pytlíka. Máš můj hlas.
Dik, ono bys to jinak nepochopil. Na brouky pytliky stejnym metrem.
-
Scrum? Takovy nesmysl jeste nezrusili?
Tady kazdy hlasi ze by za 200 nevstal z postele a najednou je tady plno cvicenych opic, ktere snad maji radi scrum, schuzovani a papirkovani.
-
Jedno mi uniká. Bavíte sa tu o agilnom vývoji, alebo o scrume? Lebo agilný vývoj sa nerovná scrum. Ale vy so to tu voľne zamieňate ako keby to bolo to isté.
-
Pokud máte tým a společný projekt, kde jste si nedohodli jednotná pravidla psaní kódu a každý si to mastí jak chce, tak to může skončit i takhle. Ale je to špatně už na začátku. Párové programování na vás! ;D
U nás je tedy trochu jiná situace (spousta menších projektů, ne jeden velký), ale pokud něco menšího upravuju v cizím kódu, snažím se ctít ten styl, který v kódu vidím - a přemýšlím při tom zda to má nějaké výhody abych to třeba převzal i do budoucna. Vlastní postupy v kódu, který jsem nezačínal, používám jen u větších bloků, kde za tu část přebírám plnou zodpovědnost.
Jednotna pravidla psani kodu mozna definuje jak psat zavorky, jak odsazovat. Ale semanticke praseni takova pravidla nepokryvaji. Parove programovani - to se fakt nekde pouziva? Jakou to ma produktivitu prace? 25% ?
Nam se tehdy osvedcil model "kazdy zdrojak ma sveho majitele" a ostatni do toho zasahuji velmi opatrne a majitel to pak zreviduje.
Přesně. Představa, že pravidla psaní kódu vyřeší např. organizaci kódu či jeho členění na podproblémy, je ZCELA NAIVNÍ! Zde má cítění každý jiné. Programování stále není mechanickou, přímočarou a jednocestnou činností. Jestliže jeden vývojář výrazně doplní nebo přepracuje cizí knihovnu, bude původní vývojář, až se k tomu vrátí, NASRANÝ a DEZORIENTOVANÝ. Takže osobně jsem též za řešení, že každá knihovna má mít svou zodpovědnou osobu, a cizí úpravy by měly být minimalizovány.
Od párového programování bych si sliboval především čistý, přehledný kód, méně chyb a výběr nejlepších nápadů. To jsou věci, které samy o sobě vedou k produktivitě.
-
Jedno mi uniká. Bavíte sa tu o agilnom vývoji, alebo o scrume? Lebo agilný vývoj sa nerovná scrum. Ale vy so to tu voľne zamieňate ako keby to bolo to isté.
Mno, autoři Scrumu (jak ho známe dnes) byli u tvorby Agile manifesta. Mechanizmy nejsou stejné s ostatními "agile" metodologiemi, ale je tam velký průnik v těch základních principech.
Jestliže jeden vývojář výrazně doplní nebo přepracuje cizí knihovnu, bude původní vývojář, až se k tomu vrátí, NASRANÝ a DEZORIENTOVANÝ. Takže osobně jsem též za řešení, že každá knihovna má mít svou zodpovědnou osobu, a cizí úpravy by měly být minimalizovány.
Kód má svého maintainera, který musí všechny úpravy schválit. Samo se to do repozitáře nedostane. A ten maintainer může souhlasit i s radikálním přepisem.
Od párového programování bych si sliboval především čistý, přehledný kód, méně chyb a výběr nejlepších nápadů. To jsou věci, které samy o sobě vedou k produktivitě.
Jistě, je to jiná forma code review. A ten agile princip ohledně řemesla a kvality už jsem zmiňoval výše..
-
Jedno mi uniká. Bavíte sa tu o agilnom vývoji, alebo o scrume? Lebo agilný vývoj sa nerovná scrum. Ale vy so to tu voľne zamieňate ako keby to bolo to isté.
Mno, autoři Scrumu (jak ho známe dnes) byli u tvorby Agile manifesta. Mechanizmy nejsou stejné s ostatními "agile" metodologiemi, ale je tam velký průnik v těch základních principech.
Jestliže jeden vývojář výrazně doplní nebo přepracuje cizí knihovnu, bude původní vývojář, až se k tomu vrátí, NASRANÝ a DEZORIENTOVANÝ. Takže osobně jsem též za řešení, že každá knihovna má mít svou zodpovědnou osobu, a cizí úpravy by měly být minimalizovány.
Kód má svého maintainera, který musí všechny úpravy schválit. Samo se to do repozitáře nedostane. A ten maintainer může souhlasit i s radikálním přepisem.
Od párového programování bych si sliboval především čistý, přehledný kód, méně chyb a výběr nejlepších nápadů. To jsou věci, které samy o sobě vedou k produktivitě.
Jistě, je to jiná forma code review. A ten agile princip ohledně řemesla a kvality už jsem zmiňoval výše..
Napriek tomu prieniku môže akýkoľvek tým vyvíjať agilne aj bez toho, aby vôbec počul slovo scrum. Akokoľvek je nepravdepodobné, že by sa s tým slovom nestretli, pokiaľ sa o agilnú metodiku zaujímajú. Pretože scrum je len konkrétna, špecifická implementácia agilnych princípov, nie tie princípy samé. A hlavný problém je všade ten istý. Čo z agilnych princípov použiť a čo nie, čo už by bolo kontraproduktívne nadužívanie. Napríklad keď niekto v mene ustráženia kvality nasadí pre trojčlenný tým tie isté pravidlá, čo pre 20 členný. Čo fungovať bude, ale produktivita pôjde dole. Ja nie som proti agilnému vývoju. Ktokoľvek si navrhne akékoľvek pravidlá vo vývoji a následne sa ich aj drží, nech už to nazve akokoľvek, v princípe vyvíja agilne. Ale Scrum mám, a nie len ja, ako tu vidím, spojený práve s jeho nevhodným nadužívaním, a existenciu osobitnej pozície Scrum master považujem akurát tak za známku neschopnosti zvyšku menežmentu. Pretože mnoho firiem robí Scrum čisto pre Scrum, miesto individuálne, v zmysle dosiahnutia čo najlepšieho pomeru kvality a produktivity.
-
Co sa tyka rozdelenia uloh, vzdy si to delime v time. Takze stava sa, ze clovek robi aj v oblasti, ktoru nikdy nevidel. Taketo delenie sa mi nepaci, pretoze jeden cas robim na niecom a potom sa k tomu nedostanem napr dalsie 3-4 sprinty, cize sa nedokazem do toho az tak ponorit a ziskat vacsi prehlad o tom.
Nakopej do rozkroku scrummastera. Jeho zodpovědnost je určit, kdo co bude dělat a zohlednit okolnosti. Pokud embeďák dělá databázi a expert na DB dělá GUI, je něco blbě a za tohle je zodpovědný právě SM. Co jinýho k tomu říct.
Takisto estimacia pomocou kariet mi pride trochu odveci. Pretoze kazdy vidi obtiaznost inak. Ten kto ovlada danu oblast da 3 a ten kto nie da 8. A co teraz? Da sa 3? Ako sa potom budu delit ulohy?
(best case + 4 * average + worst case) / 6, pokud zhruba znalosti odpovídají tasku a dostává to člověk ad hoc.
Pokud je tam několik specializací, dá se průměr * bulharská konstanta a přidělí se to tomu, kdo už s tím měl tu čest. Pokud ve finále bude rezerva, použije se na bugfix a dokumentaci.
Pokud jsou ve vedení blbci, násobí se odhad třema, pokud jsou blbci i markeťáci, násobí se pěti.
Neviem,ci je scrum master prave ten, kto by mal delit ulohy?
-
Pretože mnoho firiem robí Scrum čisto pre Scrum, miesto individuálne, v zmysle dosiahnutia čo najlepšieho pomeru kvality a produktivity.
Souhlasím. Tohle je rozšířený problém.
V té přednášce od "Uncle" Boba je to pěkně popsáno.. parafrázuji: "Vymysleli jsme agile pro překlenutí propasti mezi managementem a vývojáři, pak přišly různé certifikace a management si ty procesy 'ukradl' pro sebe. Takže efekt je přesně opačný než jsme chtěli, propast se ještě zvětšila."
-
(best case + 4 * average + worst case) / 6
Tohle jsem nepobral. Pokud je average průměr [ "average" = ("best case" + "worst case") / 2 ], tak ten výraz v citaci se rovná "average"
-
(best case + 4 * average + worst case) / 6
Tohle jsem nepobral. Pokud je average průměr [ "average" = ("best case" + "worst case") / 2 ], tak ten výraz v citaci se rovná "average"
Tomu sa nediv. Ten vzorec je ako zbytočný, tak vycucaný z prsta. Neexistuje skrz projekty spoločný best, ani worst case, takže už vôbec nie average. Čo projekt, to individuálny najlepší aj najhorší možný scenár. Navyše vyhodnotiť onen najlepší a najhorší možný scenár je možné až v momente úplného dokončenia projektu. Dovtedy je to len naprosto zbytočná, vymyslená hodnota a vzorec, aby príživníci typu Scrum master pôsobili fundovane a zmysluplne. Poslať tie opice naspäť na strom a firma v tom momente funguje efektívnejšie, bez vyhadzovania prostriedkov na to, čo má beztak za úlohu projekt menežér.
-
Pokud jsou ve vedení blbci, násobí se odhad třema, pokud jsou blbci i markeťáci, násobí se pěti.
Proc bys nasobil story points? Tyhle poucky, ktere rikas jsou asi validni pro MD estimates.
-
Scrum? Takovy nesmysl jeste nezrusili?
Tady kazdy hlasi ze by za 200 nevstal z postele a najednou je tady plno cvicenych opic, ktere snad maji radi scrum, schuzovani a papirkovani.
papirkujeme 1x 15 minut za sprint, tedy 2 tydny (retro). Je to moc ?
-
Scrum? Takovy nesmysl jeste nezrusili?
Tady kazdy hlasi ze by za 200 nevstal z postele a najednou je tady plno cvicenych opic, ktere snad maji radi scrum, schuzovani a papirkovani.
papirkujeme 1x 15 minut za sprint, tedy 2 tydny (retro). Je to moc ?
jo - na pravidelny bazi delate vubec neco - cela myslenka sprintu a neustale se opakujicich akci je UCHYLNA a uplne MIMO - takze ano - je to moc
-
Ktokoľvek si navrhne akékoľvek pravidlá vo vývoji a následne sa ich aj drží, nech už to nazve akokoľvek, v princípe vyvíja agilne.
To je trochu odvážné tvrzení. Od toho tu máme Agilní manifest, ten definuje, čeho bychom se měli držet.
-
Od toho tu máme Agilní manifest, ten definuje, čeho bychom se měli držet.
... a zpátky ni krok! (https://www.youtube.com/watch?v=tD2VXTfM9HY)
-
(best case + 4 * average + worst case) / 6
Tohle jsem nepobral. Pokud je average průměr [ "average" = ("best case" + "worst case") / 2 ], tak ten výraz v citaci se rovná "average"
Hmmm... Tenhle vzorec je opravdu vycucaný z prstu a používá se v Projektovém Managementu v případě, že opravdu, ale opravdu netušíte kolik bude úkol trvat. Pak se zeptáte několika lidí a dostanete min, avg, max a použijete vzorec. Dokonce se to nějak jmenuje a slouží jako zástěrka pro management, který nemá tušení co to znamená - a zní to učeně :-)
Ale opravdu potřebuješ 3 nezávislé hodnoty, jinak to nedává smysl...
-
Dokonce se to nějak jmenuje a slouží jako zástěrka pro management, který nemá tušení co to znamená - a zní to učeně :-)
Je to Simpsonova formule, takova primitivni forma integrovani. Proto se to v tomto kontextu pouziva pro vypocet stredni hodnoty (casu), coz je v podstate taky integral.
-
Od toho tu máme Agilní manifest, ten definuje, čeho bychom se měli držet.
... a zpátky ni krok! (https://www.youtube.com/watch?v=tD2VXTfM9HY)
A četl jsi ho vůbec? Agilní vývoj není vhodný na vše, ale pokud se podívám na manifest, tak tam těžko budu s něčím zásadně nesouhlasit. Jasně, pokud budu vyvíjet sw pro SpaceX nebo nemocniční rentgen, budou asi priority jiné.
-
Od toho tu máme Agilní manifest, ten definuje, čeho bychom se měli držet.
... a zpátky ni krok! (https://www.youtube.com/watch?v=tD2VXTfM9HY)
A četl jsi ho vůbec? Agilní vývoj není vhodný na vše, ale pokud se podívám na manifest, tak tam těžko budu s něčím zásadně nesouhlasit. Jasně, pokud budu vyvíjet sw pro SpaceX nebo nemocniční rentgen, budou asi priority jiné.
Omyl. Spacex pouzil prave agilni vyvoj narozdil od statnich rigoroznich vesmirnych agentur.
Posrali nekolik raket dokud to nezaclo fungovat. Namisto sezeni nekde v kobce po cela leta a 'releasnout' jednou za 10 let.
-
scrum je hodne vtipnej - a jeste vtipnejsi sou scrum masteri - to je vetsinou dobra bandicka naprostejch budizknicemu :) za ty roky co delam sw muzu rict ze nejvetsi zmr*i sou prave ty "role" nabaleny na sw vyvoj - jako scrum masteri, product manageri (owneri), testeri - proste banda hovad co neumi programovat ani premyslet ale cejti se jako vyvoleni v ramci vyvoje a ti jedini obvykle kteri nerozumi ani problemum ktere se maji resit ani tomu jak delat sw :)
scrum samotnej hodne pripomina demenci v pokrocilem stadiu - zvlast potom ty nalepovaci papirky nebo ruzne hry a pomucky - v cele se skrum masterem je to obcas hodne bizardni podivana na bandu a pokud by ten team daly za tluste sklo v bohnicich tak verim ze by nikdo nepoznal rozil ...
ale i mezi nima jsou svetle vyjimky - tyto vyjimky jsou ale samozrejme fungovat v jakemkoliv systemu zeno
Je to kacíř, upalte ho!
-
Omyl. Spacex pouzil prave agilni vyvoj narozdil od statnich rigoroznich vesmirnych agentur.
Posrali nekolik raket dokud to nezaclo fungovat. Namisto sezeni nekde v kobce po cela leta a 'releasnout' jednou za 10 let.
To sa mylis. Pri vyvoji v tomto obore a hlavne na zaciatku bez skusenosti musis robit releas casto aby si si veci overil v reale. Rozdiel medi statnymi vesmirnimi agenturami a SpaceX je ten, ze SpaceX je sukromna firma tak sa viacej zvidititelnovala aby si urobila PR a nalakala investorov. A pretoze Musk.
-
Dlouho jsem vahal jestli to napsat ale tak co ... napisu.
Neco jsem si o tom precetl, byl jsem na meetingu, mam byvaleho spoluzaka co to zavadi do praxe ve firmach. Z celeho jsem nabil dojmu ze tohle degraduje programatora na obycejnou lopatu. Jste jako zajic co bezi za zelym a kdyz tam je tak mu ho vemou a on bezhlave bezi dal. To bezhlave je tam dulezite. Ac se ten system snazi sebelip uzavira to programatora do klece jeho funkcii a sprintu a nevidi ten celek kolem. Proste sprintuje ale jaksi uz nevi proc. Jo pro penize ja vim.
Minule leto jsem byl na pivo se svagrem co dela managera velkymu projektu. Ma par tymu co tak nejak ridi. Jeden z tymu sel v tomhle. Rikal ze kvuli scrum a agile si udelal certifikat. Nastudoval knihu o 500 stranach v anglictine a nasledne absolvoval testy. Pak prisel, cele si to prehlednul, vyslysel jak to u nich funguje a cely ten tym zrusil. Okomentoval to slovy: "prišiel som tam a oni celý vysmiati, všetko im funguje všetko v zelených farbičkách. Ale to že im ten systém vobec nefunguje s našími ostatnými systémami ich vobec netrápilo". Tož tak.
-
zajic co bezi za zelym
https://youtu.be/E0gTf4eXa7Y?t=14
-
To bezhlave je tam dulezite. Ac se ten system snazi sebelip uzavira to programatora do klece jeho funkcii a sprintu a nevidi ten celek kolem. Proste sprintuje ale jaksi uz nevi proc. Jo pro penize ja vim.
Opět 100% chybná manažerská implementace (Tj. "SCRUM" na ovládání a měření mých oveček). Přece musí vědět proč, když si plánují úlohy na další Sprint. Součástí definice úlohy je přece i diskuze s "product ownerem" o přidané hodnotě. Každý sprint má podle teorie i definovaný cíl. To řízení tam musí pořád být, jen je zodpovědnost na úrovni týmu a ne jednotlivců.
Pokud se ta diskuse a hodnocení užitečnosti nedělá, tak je to jen manažerské zneužití sprintů na hodnocení lidí. Ještě hůře, pokud to hodnocení závisí i na splněných story points. Všichni školitelé a literatura před tím varují.. jenže manažerům v některých firmách se to tak líbí.
"prišiel som tam a oni celý vysmiati, všetko im funguje všetko v zelených farbičkách. Ale to že im ten systém vobec nefunguje s našími ostatnými systémami ich vobec netrápilo". Tož tak.
Měl vyhodit jejich manažera / product ownera. Pokud dokonale splnili zadání, tak to asi nebude úplně chyba těch vývojářů, ale spíš toho zadání (chybné nebo neúplné "acceptance criteria").
-
Dlouho jsem vahal jestli to napsat ale tak co ... napisu.
Neco jsem si o tom precetl, byl jsem na meetingu, mam byvaleho spoluzaka co to zavadi do praxe ve firmach. Z celeho jsem nabil dojmu ze tohle degraduje programatora na obycejnou lopatu. Jste jako zajic co bezi za zelym a kdyz tam je tak mu ho vemou a on bezhlave bezi dal. To bezhlave je tam dulezite. Ac se ten system snazi sebelip uzavira to programatora do klece jeho funkcii a sprintu a nevidi ten celek kolem. Proste sprintuje ale jaksi uz nevi proc. Jo pro penize ja vim.
Sorry, ale ono je to jinak. Určí se dílčí cíl a jde se za ním. "Tenhle sprint doděláme oko se setupem a demo implementace XY." Další sprint "pokračujeme v protokolu XY, zákazníkovi se nelíbilo menu v hlavním okně, Lojza to překope." Dělají se malý kroky, po nich je produkt nějak funkční a dá se ukázat zákazníkovi pokrok. Zákazník sám neví, co chce a ladí se to za běhu. Když to neví zákazník, jak to má vědět vývojář?
A pokud jde o ztrátu obzoru, systém má několik úrovní abstrakce. Opravdu musím řešit celek, když se vrtám v nějaké low level funkci? Vždycky se to navíc dělá metodou "rozděl a panuj"...
-
Má osobní zkušenost:
Pokud je Scrum aplikován správně, tak je velkým přínosem.
Zrada 1 (procesní): správná aplikace u řady projektů znamená, že se Scrum nepoužije. Posoudit, zda je pro daný produkt nebo projekt Scrum dobrá volba, je nedílnou součástí toho správně. Univerzální pravidlo není, takže jen subjektivní názor: na agilní věci to není dost agilní a na velké věci to není dost důsledné. Dá se to aplikovat stylem "rozděl a panuj" tak, že produkt řídíte klasickým iteračním modelem a do Scrumu cpete jen některé dílčí úkoly. Velké úkoly a změny je kolikrát snadnější prostě udělat, než se pokoušet je nějak rozsekat tak, aby na to hezky pasoval Scrum.
Zrada 2 (lidská): příliš často narazíte na lidi, kteří budou skálopevně přesvědčeni o tom, že "přesně podle instrukcí => správně". To pak máte Scrum tak krásný, že by vás hned mohli dávat do učebnic. Akorát tedy až na ten fakt, že to zrovna u vás vůbec nefunguje. Proto jsem tak strašně skeptický k "vystudovaným Scrum masterům". Oni nemají univerzální vzdělání typu "chirurg". Naopak, oni mají dost specifické vzdělání typu "operace zánětu slepého střeva". Dokud jsou si toho vědomi, tak je to v pohodě. Problém nastane když si to neuvědomují a aplikují ten postup i na operaci žlučníku nebo kýly, nedej bože kolene nebo vymknutého kotníku.
Zrada 3 (psychologická): řada lidí si myslí, že porušení Scrum pravidel je špatné. Což zrovna v případě Scrum metody, která se hlásí k agilnímu manifestu s jeho "Individuals and Interactions over processes and tools" působí na jednu stranu strašně legračně, ale na druhou stranu se vám z toho chce plakat. Hlavně nevynechat standup meeting, protože to by se tým zastavil a projekt zhroutil!
-
Já přidám ještě jednu zradu, která se netýká jen Scrumu, ale všech agilních metodik: Často si je management vyloží tak, že teď už se nemusí dělat analýza, prostě se programátorům dá vágní zadání a pak se doiteruje k tomu, co management/zákazník chce. Jenže to je samozřejmě fatálně špatně a následky jsou katastrofální. Přinejlepším se velmi draho a pomalu vyvine špatný produkt.
-
Má osobní zkušenost:
+1
Scrum je to nejlepší na údržbu projektu, ale někdy je prostě nevhodný. Zažil jsem situaci "děláme 100% waterfallem a nejsme flexibilní, za půl roku 100% scrum". Nefungovalo to.
Důvody:
1) Marketing - nějaký trouba jim nakecal, že se dá měnit zadání za běhu. Zajásali, u waterfallu tuhle možnost neměli. Takže člověk začal designovat kombajn a vyšel z toho čtyřtaktní benzínový toustovač.
2) Vedení - nějaký trouba nepochopil, že na začátku sprintu je odhad a že se neví, co bude za dva sprinty. Rozkreslili si projekty do M$Projektu (nejhorší nástroj na řízení vývoje SW) a strašně se divili, že se znovu překopávalo to, co před pěti sprintama, protože změněný zadání.
3) Vývoj - s*rem na papírování FMEA a rozvahy nejsou potřeba a budem jenom programovat. S*rem na architekturu a dokumentaci, za měsíc to bude všechno jinak... Potěmkin to jistí, dál se nedostaneme.
-
scrum a jeho protagonisti me strasne pripominaj jehovisty nebo podobnej alchymistickej kryptofasistickej bordel - ve spojeni s produktovym managementem a vyladenym Q.A. je z toho neco co presne ale naprosto PRESNE vystuhuje toto videjicko: https://www.youtube.com/watch?v=uX0XOcjVyz0
-
todle je jeste lepsi: https://www.youtube.com/watch?v=JC-VkFkKE8c
-
Má osobní zkušenost:
...
+1
Což zrovna v případě Scrum metody, která se hlásí k agilnímu manifestu s jeho "Individuals and Interactions over processes and tools
Nejsmutnejsi na tom je, ze spousta lidi (vcetne prispevatelu do teto diskuze) chape Scrum jako nejaky proces, ktery ma jasne dane pravidla, vlastnosti, atp. a da se to naucit z knih nebo skoleni. Nepremysli nad tim, ze je to jen framework, ktery jde uzpusobit konkretnimu projektu, lidem, a co hur, ze jej lze prubezne upravovat, aby vyhoval dane situaci.
Jednotlive casti Scrumu maji svou motivaci a mohou fungovat velice dobre, pokud je tato motivace pochopena. Problem je, kdyz se Scrumu chytnou lide, kteri nerozumi temto motivacim (nebo dokonce programovani). V takovem pripade se z toho stane bezduchy cargocult.
-
A co jsi myslite o estimaci v agilnim procesu? Estimaci myslim, poker cards (1,2,3,5,...). Me to pripada nekdy totalnej nesmysl, protoze nekdo muze pouzit pro estimaci 5 a nekdo 8 nebo 13. A co ted?
-
Estimation je podstatny proces scrumu kedy sa hodnoti casova narocnost nejakej ulohy. To ze niekomu sa zda ze to je uloha za 5 bodov a iny da 15, je v poriadku, ak priemer celeho timu bude dajme tomu 10 (cize odchylka od priemernej hodnoty nie je voci ostatnym clenom timu nijak zavratna). Ak ale vacsina ludi dava body okolo 5 a jeden clovek da 15, tak to vacsinou znamena ze nepochopil obsahu danej ulohy, (co moze byt aj opacny pripad, priemer 15, vs jeden clovek s 5timy bodmi).
Toto hodnotenie je navyse aj dobra spatna vazba pre buduce planovanie, kedy product owner vie dopredu zhruba odhadnut casovu narocnost riesenia urcitych uloh a tim padom teda vykonnost timu, na zaklade minulych hodnoteni rovnakych/podobnych uloh a da sa tak lepsie planovat praca v dlhodobejsom horizonte.
-
Dekuji za odpoved. A co rikate na vytvarani stories? Mel by se vyvojar podilet na vytvareni stories, nebo to je ukol PO a developeri by meli jenom ohodnotit popsanej ukol?
-
Moc mě baví lidi (a že jich tady takových v diskuzi je), kteří na každé "u nás SCRUM nefungoval" odpovídají "dělali jste to blbě". Kdyby se to přeložilo do lidštiny tak by mohlo zaznít něco jako "používali jsme na zatloukání hřebíků bagr a nefungovalo to dobře" -> "to je tím, že neumíte používat bagr". Prostě totální BS.
-
Dekuji za odpoved. A co rikate na vytvarani stories? Mel by se vyvojar podilet na vytvareni stories, nebo to je ukol PO a developeri by meli jenom ohodnotit popsanej ukol?
Mě to třeba nevadilo, ale znám vývojáře, kteří to striktně odmítají a chtějí mít zadaný konkrétní úkol.
-
Stories tvori pubertacky na instagramu.
Pokud programator ceka na konkretni ukol co mu PO nebo PM zada, tak at jde radsi k pasu do Hyunde. Role inzenyra v softwaru je pozorovat uzivatele v akci a vyextrahovat z toho 'vypozorovane pozadavky'. K tomu slouzi techniky treba iterativni vyvoj nebo pravidelne demo fungujiciho prototypu/produktu na konci iterace. To je cela podstata lean/agile vyvoje.
-
Stories tvori pubertacky na instagramu.
Pokud programator ceka na konkretni ukol co mu PO nebo PM zada, tak at jde radsi k pasu do Hyunde. Role inzenyra v softwaru je pozorovat uzivatele v akci a vyextrahovat z toho 'vypozorovane pozadavky'. K tomu slouzi techniky treba iterativni vyvoj nebo pravidelne demo fungujiciho prototypu/produktu na konci iterace. To je cela podstata lean/agile vyvoje.
To mozna funguje u appky pro decka, v komercnim svete to vypozorovani pozadavku je u vyvojare samozrejme nesmysl. On prumerny vyvojar zna treba procesy nakupu obchodniho retezce, nebo logiku v trideni prijezdu kamionu v logistickem centru? Obvykle vi o tom kulovy, od toho jsou tam ruzni analytici, konzultanti, architekti, kteri maji ve finale ukol tomu prostackovi programatorovi lopate dat jasne zadani jakou funkcionalitu ma vytvorit. U malych aplikaci muze fungovat vypozorovani nejake ocekavane funkcionality, ale i u sluzeb kde by to clovek necekal jsou pozadavky pro byznis faleko sirsi nez je prumerny programator lopata je schopen vypozorovat.
-
Hlavně neopomenout zdůraznit, jaký je vývojář prosťáček a lopata.
-
Je to jednoduche, takovy otravny Scrum co ty popisujes budes mit, kdyz vas tym bude mit nejakeho profesionalni Scrum mastera, co vlastne ani moc neumi vyvijet. Je to stejne s managerama a vubec s kazdym, kdo ma pracovat na procesu vyvoje SW, ale pritom je to blb a nebo tomu vubec nerozumi. Kazdy totiz bude delat, jak umi, a nikdo neprestane a nerekne "heledte ja to neumim a nejlepsi je, kdyz budu drzet hubu a nedelat radeji nic". No takze kdyz se sejde projektak co vi prd a v tymu Scrum master specialista, tak z toho mas takhle debilni Scrumy, ktere nejsou k nicemu.
My ted meli v tymu jen same vyvojare a projekteka co se snazi moc nevsirat, a mame normalni sebeorganizujici se tym, ktery ad hoc spolupracuje a doplnuje tasky do Jiry, a funguje to vyborne. Nemivame ani planningy a nejake retrospektivy, jen se obcas zogranizujeme k nejakemu knowledge transfer atp. Kdybychom tam ale meli Scrum mastera specialistu, nejakeho trotla co nedaval dev tak si nasel teple mistecko v tomhletom, tak hadej, co by se delo.
-
Stories tvori pubertacky na instagramu.
Pokud programator ceka na konkretni ukol co mu PO nebo PM zada, tak at jde radsi k pasu do Hyunde. Role inzenyra v softwaru je pozorovat uzivatele v akci a vyextrahovat z toho 'vypozorovane pozadavky'. K tomu slouzi techniky treba iterativni vyvoj nebo pravidelne demo fungujiciho prototypu/produktu na konci iterace. To je cela podstata lean/agile vyvoje.
V jaky delas firme, abych se ji obloukem vyhnul?
-
Moc mě baví lidi (a že jich tady takových v diskuzi je), kteří na každé "u nás SCRUM nefungoval" odpovídají "dělali jste to blbě". Kdyby se to přeložilo do lidštiny tak by mohlo zaznít něco jako "používali jsme na zatloukání hřebíků bagr a nefungovalo to dobře" -> "to je tím, že neumíte používat bagr". Prostě totální BS.
Jenomže to opravdu je často ten hlavní problém. Viděl jsem spoustu pokusů o agilní přístup, kde celé agile spočívalo v tom, že šéf nařídil nástroje, sprinty a odhady, ale tým neměl žádný vliv na plánování a přiřazené činnosti. Prostě to byl jen mikro-management lidí ze strany vedení. Použití agile nástrojů z toho ještě totiž nedělá agilní vývoj.
Stejně tak ten tým musí chtít tímto způsobem pracovat, pokud nechce, tak to zase fungovat nebude a postupně se to vrátí do původního stavu.
Ta paralela je totiž mnohem častěji spíše: Šéf nám na výkopy sice pořídil bagr, ale nepustil nás do kabiny. Ten bagr by mohl pomáhat, pokud ho tým chce použít, umí ho ovládat, šéf jim věří, nechá je ho použít a přestane jim říkat _jak_ mají pracovat (omezí se na _co_ mají dodat). A to je docela dost podmínek, které nejsou vždycky splněny.
-
Stories tvori pubertacky na instagramu.
Pokud programator ceka na konkretni ukol co mu PO nebo PM zada, tak at jde radsi k pasu do Hyunde. Role inzenyra v softwaru je pozorovat uzivatele v akci a vyextrahovat z toho 'vypozorovane pozadavky'. K tomu slouzi techniky treba iterativni vyvoj nebo pravidelne demo fungujiciho prototypu/produktu na konci iterace. To je cela podstata lean/agile vyvoje.
To mozna funguje u appky pro decka, v komercnim svete to vypozorovani pozadavku je u vyvojare samozrejme nesmysl. On prumerny vyvojar zna treba procesy nakupu obchodniho retezce, nebo logiku v trideni prijezdu kamionu v logistickem centru? Obvykle vi o tom kulovy, od toho jsou tam ruzni analytici, konzultanti, architekti, kteri maji ve finale ukol tomu prostackovi programatorovi lopate dat jasne zadani jakou funkcionalitu ma vytvorit. U malych aplikaci muze fungovat vypozorovani nejake ocekavane funkcionality, ale i u sluzeb kde by to clovek necekal jsou pozadavky pro byznis faleko sirsi nez je prumerny programator lopata je schopen vypozorovat.
Fungujes v bubline cesky malosti, kde ti nejakej manazer ze zapadu skrz firmu nebo vzdelavaci system nakukal tyhle pololzi, aby si z tebe udelal poskoka.
Tvuj model = business mapuje nejakej chytrej analytik, transformuje to na pozadavky a ty pak predava armade opic cvicenych skakat pres java obruby. Tvuj manazer se boji ze by se skutecnej programator naucil jeho business model a zalozil si efektivnejsi konkurenci. Proto najme opice u kterych ocekava fluktuaci tak jich radsi najme vic a naridi jim aby sdileli kod co nejvic.
Agilni pristup znamena ze najmu schopny programatory, ktery koukaji na problem celyho systemu, nejen nejakej jeden lokalni programek. V systemu fungujou masiny, kompjutry, lidi, nejen nejaky programky. Malej tym techle schopnych lidi zmapuje informacni tok ve firme a zacne ho mapovat na software. Takovejhle programator neni opice, ale skutecnej manazer. Jenom nemanazuje lidsky opice, ale maly trpajzliky co prenaseji bity a bajty v kompjutrech a tvori rozhrani pro lidsky uzivatele aby se mohli do celyho systemu taky zapojit.
-
Jenomže to opravdu je často ten hlavní problém. Viděl jsem spoustu pokusů o agilní přístup, kde celé agile spočívalo v tom, že šéf nařídil nástroje, sprinty a odhady, ale tým neměl žádný vliv na plánování a přiřazené činnosti. Prostě to byl jen mikro-management lidí ze strany vedení. Použití agile nástrojů z toho ještě totiž nedělá agilní vývoj.
Přesně tak, jenže ten šéf to často nemůže ani nějak změnit, musí se pohybovat v mantinelech, které mu určuje smlouva se zákazníkem. A zákazník se často nechce podílet a platit testování nějakých prototypů a taky nechce platit za nedodělanou funkcionalitu. Zákazník chce dostat a zaplatit za hotový produkt nebo funkcionalitu. Dodavatel se zase bojí, že bude muset dělat ve vlastní režii nějaké vícepráce, a tak chce do smlouvy dostat přesnou specifikaci....to vše jde proti agilnímu vývoji....Takže agilní vývoj jde použít pouze tam, kde je zákazníkem přímo dodavatel a kde nějaká smlouva hraje podružnou roli....
-
Agilni pristup znamena ze najmu schopny programatory, ktery koukaji na problem celyho systemu, nejen nejakej jeden lokalni programek. V systemu fungujou masiny, kompjutry, lidi, nejen nejaky programky. Malej tym techle schopnych lidi zmapuje informacni tok ve firme a zacne ho mapovat na software. Takovejhle programator neni opice, ale skutecnej manazer. Jenom nemanazuje lidsky opice, ale maly trpajzliky co prenaseji bity a bajty v kompjutrech a tvori rozhrani pro lidsky uzivatele aby se mohli do celyho systemu taky zapojit.
Spousta velkých i českých firem, pracuje na velkých systémech a má dobrý odpborníky, který nejsou opice. Možná jsi je ještě nepotkal, ale to ještě neznamená, že vyvíjí agilně...!!! Je dobré si o tom něco přečíst.
-
Agilni pristup znamena ze najmu schopny programatory, ktery koukaji na problem celyho systemu, nejen nejakej jeden lokalni programek. V systemu fungujou masiny, kompjutry, lidi, nejen nejaky programky. Malej tym techle schopnych lidi zmapuje informacni tok ve firme a zacne ho mapovat na software. Takovejhle programator neni opice, ale skutecnej manazer. Jenom nemanazuje lidsky opice, ale maly trpajzliky co prenaseji bity a bajty v kompjutrech a tvori rozhrani pro lidsky uzivatele aby se mohli do celyho systemu taky zapojit.
Spousta velkých i českých firem, pracuje na velkých systémech a má dobrý odpborníky, který nejsou opice. Možná jsi je ještě nepotkal, ale to ještě neznamená, že vyvíjí agilně...!!! Je dobré si o tom něco přečíst.
Ok, to je moje definice agilniho vyvoje. Podle agilniho manifestu si to muze kazdej nadefinovat podle sebe. Moje definice se ale silne shodujou s Martinem Fowlerem, kterej stal u zrodu celyho hnuti.
Agile in 2018: [https://youtu.be/G_y2pNj0zZg]
Abych dovysvetlil, opice neni clovek sam o sobe, ale role, do ktery je dosazen. Muzes mit frajera co pred spanim snupe davky z teorie cisel, ale pres den v praci pouze busi javu podle toho jak principal triska bicem.
A dalsi vec. Velkej system vetsinou znamena velkej binec. Klicem k automatizaci a tvorbe informacnich systemu je nutna podminka zjednodusovani procesu, redukce specialnich pripadu a komplexity obecne.
Doporucil bych odpornikum dricim na velkych projektech si precist o essential a accidental complexity. A uvedomit si, jak pravil Dijkstra. Pocet radku kodu neni asset, ale liabilita. Jinak receno vic radku neznamena vic dodany hodnoty, ale vic utracenyho rozpoctu. Chlubit se manazerovi ze delam na velkym projektu, je stejny jako chlubit se, ze utracim z rozpoctu hodne za firemni vecere.
-
Stories tvori pubertacky na instagramu.
Pokud programator ceka na konkretni ukol co mu PO nebo PM zada, tak at jde radsi k pasu do Hyunde. Role inzenyra v softwaru je pozorovat uzivatele v akci a vyextrahovat z toho 'vypozorovane pozadavky'. K tomu slouzi techniky treba iterativni vyvoj nebo pravidelne demo fungujiciho prototypu/produktu na konci iterace. To je cela podstata lean/agile vyvoje.
To mozna funguje u appky pro decka, v komercnim svete to vypozorovani pozadavku je u vyvojare samozrejme nesmysl. On prumerny vyvojar zna treba procesy nakupu obchodniho retezce, nebo logiku v trideni prijezdu kamionu v logistickem centru? Obvykle vi o tom kulovy, od toho jsou tam ruzni analytici, konzultanti, architekti, kteri maji ve finale ukol tomu prostackovi programatorovi lopate dat jasne zadani jakou funkcionalitu ma vytvorit. U malych aplikaci muze fungovat vypozorovani nejake ocekavane funkcionality, ale i u sluzeb kde by to clovek necekal jsou pozadavky pro byznis faleko sirsi nez je prumerny programator lopata je schopen vypozorovat.
Fungujes v bubline cesky malosti, kde ti nejakej manazer ze zapadu skrz firmu nebo vzdelavaci system nakukal tyhle pololzi, aby si z tebe udelal poskoka.
Tvuj model = business mapuje nejakej chytrej analytik, transformuje to na pozadavky a ty pak predava armade opic cvicenych skakat pres java obruby. Tvuj manazer se boji ze by se skutecnej programator naucil jeho business model a zalozil si efektivnejsi konkurenci. Proto najme opice u kterych ocekava fluktuaci tak jich radsi najme vic a naridi jim aby sdileli kod co nejvic.
Agilni pristup znamena ze najmu schopny programatory, ktery koukaji na problem celyho systemu, nejen nejakej jeden lokalni programek. V systemu fungujou masiny, kompjutry, lidi, nejen nejaky programky. Malej tym techle schopnych lidi zmapuje informacni tok ve firme a zacne ho mapovat na software. Takovejhle programator neni opice, ale skutecnej manazer. Jenom nemanazuje lidsky opice, ale maly trpajzliky co prenaseji bity a bajty v kompjutrech a tvori rozhrani pro lidsky uzivatele aby se mohli do celyho systemu taky zapojit.
Javamane, Javamane... takze jeden clovek ma byt programator, navrhar, dizajner, UXak, tester, softverovy architekt, team manazer, PO, PM, technical writer, sales, expert v problemovej domene zakaznikov (urcite je nevyhnutne aby programator bol zaroven lekar alebo fyzik alebo uctovnik atd.) a este co, aby nespadal do tvojej definicie opice? Prosim napis nam tu verejne, kde pracujes, myslim si, ze nie som jediny co by chcel takeho ubermenscha vidiet v akcii a nasledne sa takej firme vyhnut obrovskym oblukom.
-
Agilni pristup znamena ze najmu schopny programatory, ktery koukaji na problem celyho systemu, nejen nejakej jeden lokalni programek. V systemu fungujou masiny, kompjutry, lidi, nejen nejaky programky. Malej tym techle schopnych lidi zmapuje informacni tok ve firme a zacne ho mapovat na software. Takovejhle programator neni opice, ale skutecnej manazer. Jenom nemanazuje lidsky opice, ale maly trpajzliky co prenaseji bity a bajty v kompjutrech a tvori rozhrani pro lidsky uzivatele aby se mohli do celyho systemu taky zapojit.
Spousta velkých i českých firem, pracuje na velkých systémech a má dobrý odpborníky, který nejsou opice. Možná jsi je ještě nepotkal, ale to ještě neznamená, že vyvíjí agilně...!!! Je dobré si o tom něco přečíst.
Ok, to je moje definice agilniho vyvoje. Podle agilniho manifestu si to muze kazdej nadefinovat podle sebe. Moje definice se ale silne shodujou s Martinem Fowlerem, kterej stal u zrodu celyho hnuti.
Agile in 2018: [https://youtu.be/G_y2pNj0zZg]
Abych dovysvetlil, opice neni clovek sam o sobe, ale role, do ktery je dosazen. Muzes mit frajera co pred spanim snupe davky z teorie cisel, ale pres den v praci pouze busi javu podle toho jak principal triska bicem.
A dalsi vec. Velkej system vetsinou znamena velkej binec. Klicem k automatizaci a tvorbe informacnich systemu je nutna podminka zjednodusovani procesu, redukce specialnich pripadu a komplexity obecne.
Doporucil bych odpornikum dricim na velkych projektech si precist o essential a accidental complexity. A uvedomit si, jak pravil Dijkstra. Pocet radku kodu neni asset, ale liabilita. Jinak receno vic radku neznamena vic dodany hodnoty, ale vic utracenyho rozpoctu. Chlubit se manazerovi ze delam na velkym projektu, je stejny jako chlubit se, ze utracim z rozpoctu hodne za firemni vecere.
Agilní vývoj jakožto i agilní manifest vznikl jako reakce na vývoj vodopádem (do té doby používaný postup). Vodopád předpokládá, že se nejprve všechno do puntníku zanalyzuje a po té se to naprogramuje a otestuje. Jenže se ukázalo, že zákazník vlastně neví co chce a často na něco zapomene, a tyto dodatečné úpravy pak stojí mnoho peněz a často nejdou rozumně ani udělat.
Proto vznikl agilní vývoj, který je založen na tom, že požadovaná specifikace funkcionality ve smlouvě je jen RÁMCOVÁ a v průběhu vývoje se bude upřesňovat...a proto tu máme dnes scrum se svýma sprintama. Jenže aby agilní vývoj fungoval, tak na to musí v přistoupit nejdříve zákazník a pak i dodavatel. Zákazník musí být ochoten testovat i nehotovou funkcionalitu a platit za meziverze a naopak dodavateli musí být jasné, že je normální věci předělávat....A to ja kámen úrazu....jak smluvně takovou kooperaci ošetřit....smluvní vztahy prostě stále zamrzly před 20 lety a mají vodopádový charakter...proto se pouze tváříme, že agilně vyvíjeme, ale ve své podstaté je to pořád vodopád.
A vůbec zde nehraje roli jestli to vyvíjí opice, lopaty nebo odborníci...jde o princip.
-
"Pocet radku kodu neni asset, ale liabilita."
What? This není ani czech nor anglicky.
-
Přesně tak, jenže ten šéf to často nemůže ani nějak změnit, musí se pohybovat v mantinelech, které mu určuje smlouva se zákazníkem. ...Takže agilní vývoj jde použít pouze tam, kde je zákazníkem přímo dodavatel a kde nějaká smlouva hraje podružnou roli....
Ne nezbytně. Zákazník nemusí o interním vývojovém modelu vůbec vědět (je to lepší, ale ne nezbytné). Ten šéf totiž může reprezentovat zákazníkovy priority v komunikaci s vývojovým týmem a ty mezivýsledky můžou jít třeba jen k interním testerům, kteří ověří co funguje a co ne. A pořád to může být agilní pro ten vývojový tým. Zákazníka totiž zajímá funkcionalita a rozhraní, jenže interní architektura se také vyvíjí.
Ale jinak ano, je hodně případů, kdy tento přístup není vhodný. Ale pokud se mění požadavky ve smlouvě a zadání, tak je možné je přetlumočit vývojovému týmu agilním způsobem i v případě, že zákazník o tom nechce vědět. Jedna podstatná věc je ale nutná - důvěra manažerů ve schopnost týmu dodat co bylo domluveno pro danou iteraci.
-
Stories tvori pubertacky na instagramu.
Pokud programator ceka na konkretni ukol co mu PO nebo PM zada, tak at jde radsi k pasu do Hyunde. Role inzenyra v softwaru je pozorovat uzivatele v akci a vyextrahovat z toho 'vypozorovane pozadavky'. K tomu slouzi techniky treba iterativni vyvoj nebo pravidelne demo fungujiciho prototypu/produktu na konci iterace. To je cela podstata lean/agile vyvoje.
To mozna funguje u appky pro decka, v komercnim svete to vypozorovani pozadavku je u vyvojare samozrejme nesmysl. On prumerny vyvojar zna treba procesy nakupu obchodniho retezce, nebo logiku v trideni prijezdu kamionu v logistickem centru? Obvykle vi o tom kulovy, od toho jsou tam ruzni analytici, konzultanti, architekti, kteri maji ve finale ukol tomu prostackovi programatorovi lopate dat jasne zadani jakou funkcionalitu ma vytvorit. U malych aplikaci muze fungovat vypozorovani nejake ocekavane funkcionality, ale i u sluzeb kde by to clovek necekal jsou pozadavky pro byznis faleko sirsi nez je prumerny programator lopata je schopen vypozorovat.
Fungujes v bubline cesky malosti, kde ti nejakej manazer ze zapadu skrz firmu nebo vzdelavaci system nakukal tyhle pololzi, aby si z tebe udelal poskoka.
Tvuj model = business mapuje nejakej chytrej analytik, transformuje to na pozadavky a ty pak predava armade opic cvicenych skakat pres java obruby. Tvuj manazer se boji ze by se skutecnej programator naucil jeho business model a zalozil si efektivnejsi konkurenci. Proto najme opice u kterych ocekava fluktuaci tak jich radsi najme vic a naridi jim aby sdileli kod co nejvic.
Agilni pristup znamena ze najmu schopny programatory, ktery koukaji na problem celyho systemu, nejen nejakej jeden lokalni programek. V systemu fungujou masiny, kompjutry, lidi, nejen nejaky programky. Malej tym techle schopnych lidi zmapuje informacni tok ve firme a zacne ho mapovat na software. Takovejhle programator neni opice, ale skutecnej manazer. Jenom nemanazuje lidsky opice, ale maly trpajzliky co prenaseji bity a bajty v kompjutrech a tvori rozhrani pro lidsky uzivatele aby se mohli do celyho systemu taky zapojit.
Javamane, Javamane... takze jeden clovek ma byt programator, navrhar, dizajner, UXak, tester, softverovy architekt, team manazer, PO, PM, technical writer, sales, expert v problemovej domene zakaznikov (urcite je nevyhnutne aby programator bol zaroven lekar alebo fyzik alebo uctovnik atd.) a este co, aby nespadal do tvojej definicie opice? Prosim napis nam tu verejne, kde pracujes, myslim si, ze nie som jediny co by chcel takeho ubermenscha vidiet v akcii a nasledne sa takej firme vyhnut obrovskym oblukom.
Chtel bys mi snad na pohovoru rict, ze bys nic nedodal, dokud bys nemel vsechny tyhle role obsazeny? Vis, soucasti toho byt dospelej clovek je byt schopnej delat spoustu ruznych veci bez chozeni pro radu za tatinkem.
Az zacnes byt trochu zkusenejsi v businessu, zjistis, ze plno firem vznika tak, ze jeden nebo dva lidi delaji vsechny role a postupne delegujou opakujici se casti jinym lidem.
A ano, existujou tihle "ubermenschove". Napr. kazda matka je treba takovej univerzalni manazer na vsechno, kdyz vychovava dite. Jen pak doufa, ze dite vyroste a nebude mu muset predkousavat kazdy sousto.
-
Agilni pristup znamena ze najmu schopny programatory, ktery koukaji na problem celyho systemu, nejen nejakej jeden lokalni programek. V systemu fungujou masiny, kompjutry, lidi, nejen nejaky programky. Malej tym techle schopnych lidi zmapuje informacni tok ve firme a zacne ho mapovat na software. Takovejhle programator neni opice, ale skutecnej manazer. Jenom nemanazuje lidsky opice, ale maly trpajzliky co prenaseji bity a bajty v kompjutrech a tvori rozhrani pro lidsky uzivatele aby se mohli do celyho systemu taky zapojit.
Spousta velkých i českých firem, pracuje na velkých systémech a má dobrý odpborníky, který nejsou opice. Možná jsi je ještě nepotkal, ale to ještě neznamená, že vyvíjí agilně...!!! Je dobré si o tom něco přečíst.
Ok, to je moje definice agilniho vyvoje. Podle agilniho manifestu si to muze kazdej nadefinovat podle sebe. Moje definice se ale silne shodujou s Martinem Fowlerem, kterej stal u zrodu celyho hnuti.
Agile in 2018: [https://youtu.be/G_y2pNj0zZg]
Abych dovysvetlil, opice neni clovek sam o sobe, ale role, do ktery je dosazen. Muzes mit frajera co pred spanim snupe davky z teorie cisel, ale pres den v praci pouze busi javu podle toho jak principal triska bicem.
A dalsi vec. Velkej system vetsinou znamena velkej binec. Klicem k automatizaci a tvorbe informacnich systemu je nutna podminka zjednodusovani procesu, redukce specialnich pripadu a komplexity obecne.
Doporucil bych odpornikum dricim na velkych projektech si precist o essential a accidental complexity. A uvedomit si, jak pravil Dijkstra. Pocet radku kodu neni asset, ale liabilita. Jinak receno vic radku neznamena vic dodany hodnoty, ale vic utracenyho rozpoctu. Chlubit se manazerovi ze delam na velkym projektu, je stejny jako chlubit se, ze utracim z rozpoctu hodne za firemni vecere.
Agilní vývoj jakožto i agilní manifest vznikl jako reakce na vývoj vodopádem (do té doby používaný postup). Vodopád předpokládá, že se nejprve všechno do puntníku zanalyzuje a po té se to naprogramuje a otestuje. Jenže se ukázalo, že zákazník vlastně neví co chce a často na něco zapomene, a tyto dodatečné úpravy pak stojí mnoho peněz a často nejdou rozumně ani udělat.
Proto vznikl agilní vývoj, který je založen na tom, že požadovaná specifikace funkcionality ve smlouvě je jen RÁMCOVÁ a v průběhu vývoje se bude upřesňovat...a proto tu máme dnes scrum se svýma sprintama. Jenže aby agilní vývoj fungoval, tak na to musí v přistoupit nejdříve zákazník a pak i dodavatel. Zákazník musí být ochoten testovat i nehotovou funkcionalitu a platit za meziverze a naopak dodavateli musí být jasné, že je normální věci předělávat....A to ja kámen úrazu....jak smluvně takovou kooperaci ošetřit....smluvní vztahy prostě stále zamrzly před 20 lety a mají vodopádový charakter...proto se pouze tváříme, že agilně vyvíjeme, ale ve své podstaté je to pořád vodopád.
A vůbec zde nehraje roli jestli to vyvíjí opice, lopaty nebo odborníci...jde o princip.
Vodopad nebyl do te doby pouzivany pristup. Byl to jeden velkej omyl, kdyz v 1985 nekdo kdo designoval metody na vyvoj software v US Department of Defence (nejvetsi svetovy odberatel software) si precet jenom prvni pulku Roycovo clanku o Waterfallu a kodifikoval to do DOD-STD-2167 a tim razem se toho chytla ta vetsi cast prumyslu, ktera vic predstira, nez dodava. Nalepila se na to spousta sarlatanu, PMBOK manazeru, IBM, vsechno co uci na VSE v Praze a dalsich skolach, apod.
Agilisti prisli akorat s tim, ze oficialni mainstream metodiky na vyvoj software jsou totalne mimo a ze existujou i lidi, ktery dodavaji kvalitni software, rychle, v malych tymech a se spokojenym zakaznikem. Existovalo vic takovych lidi s ruznym stylem prace (Crystal clear od Cockburna, lidi od Scrumu, lidi od Extreme Programming, Fowler a dalsi). Snazili se najit, co jejich zpusoby spojuje, moc se jim to nepovedlo, tak z toho vzniklo takovy vagni 'Agile manifesto' s vagnim pojmenovanim, ktery si kazdej interpretuje po svym.
Problem lidi, co neznaji historii, je, ze zopakujou vsechny jeji chyby. Coz je videt na zmatenych lidech tady na foru a vsude ve firmach, ktery netusi, ze scrum, na kterej nadavaji, je ten sarlatanskej cargo cult, kterej se lehce prodava, protoze nikdo nezna tuhle historii.
"The "Waterfall" methodology was a historic accident and they knew it"
https://lobste.rs/s/8ce1ny/waterfall_methodology_was_historic
-
Prodavani scrum certifikatu uz nevydelava tolik co driv...
K nam nedavno dorazilo tohle https://en.wikipedia.org/wiki/Scaled_agile_framework (https://en.wikipedia.org/wiki/Scaled_agile_framework).
Nastesti se me to primo nedotyka.
-
Prodavani scrum certifikatu uz nevydelava tolik co driv...
K nam nedavno dorazilo tohle https://en.wikipedia.org/wiki/Scaled_agile_framework (https://en.wikipedia.org/wiki/Scaled_agile_framework).
Nastesti se me to primo nedotyka.
Dobre pro tebe.
https://martinfowler.com/bliki/CertificationCompetenceCorrelation.html
-
Hlavní problém tohohle je, že je to v podstatě náboženství, navíc s příživnickým businessem kolem sebe.
Mně osobně se po zavedení scrumu snížila produktivita možná i o 50 procent. Neskutečně přibylo mítinků a hlavně je přísně zakázáno udělat "něco navíc", na co není kartička. Spousta keců o tom, jak tým má být samoorganizující se, ale ve skutečnosti třeba standup slouží hlavně na to, aby byli všichni totálně pod kontrolou.
Znáte někdo nějakou metodu, jak přesvědčit vedení, že je to celé nesmysl?
-
U nás to vydrželo asi 3/4 roku, pak byl pro nespokojivé ekonomické výsledky šéf, který to protlačoval, odejit.
On agilní vývoj a scram sám o sobě není špatný, jen se nesmí považovat za náboženství, fixní dogma a zlaté tele - brát si z něj jen věci, co se hodí pro konkrétní prostředí a firmu a na zbytek kašlat.
Taky mě nadzvedávaly (bohužel doslova) takový kecy, že když je teď standup, ta u toho přece nemůžeme sedět... :D
-
Taky mě nadzvedávaly (bohužel doslova) takový kecy, že když je teď standup, ta u toho přece nemůžeme sedět... :D
To nejsou kecy, to je způsob jak lidi tlačit k tomu, aby se nevykecávali moc dlouho, neodbíhali na standupu k řešení problémů atp.
-
Nejkratší standupy byly, když tam dotyčný scrummaster vůbec nebyl, to jsme se nikdy přes 5 minut nedostali - takže nějaké vykecávání opravdu nehrozilo. ;D
-
A pokud tam byl, tak se prodlužovaly proč? Nutil vás, abyste detailně popisovali, co jste dělali? To je ovšem špatně.
-
U nás standupy nejvíc prodlužuje product owner. A to, že se stojí, nijak nepomáhá, spíš mi to přijde ponižující.
-
Product owner přece na standupu nemá vůbec co dělat. Ale to je klasika. Vždycky, když někdo nadává na agilní vývoj, tak se ukáže, že je to něčím, co s agilní metodikou vůbec nesouvisí, nebo co je dokonce přímo proti ní.
-
je to katastrofa. na stendape si denne vypocujem veci ktore ma na 95% nezaujimaju. jak idiot musim opakovat co som robil vcera a co budem robit dnes (co som robil vcera ma nezaujima a som rad ze to je hotove, co budem robit dnes sice mozem povedat ale aj tak dojde email ktory sa nedal naplanovat a ja zrazu robim nieco ine). no a sprinty nutia ludi robit na vela malych veciach aby to vyzeralo dobre. takze sa na projekte riesia len drobnosti ale vacsim dolezitim taskom sa vyhyba takze cely projekt ide do zadeke.
-
Product owner přece na standupu nemá vůbec co dělat. Ale to je klasika. Vždycky, když někdo nadává na agilní vývoj, tak se ukáže, že je to něčím, co s agilní metodikou vůbec nesouvisí, nebo co je dokonce přímo proti ní.
Nj, tak když je PO zároveň i něco jako scrum master... Jeho hlavní role se zdá být kontrolovat, jestli někdo náhodou nedělá něco jiného, než na co je ticket, případně jestli se dělá na ticketech, které jsou v backlogu nejvýš. U vás tohle nikdo nekontroluje?
-
Standup je o toho, aby každý krátce (!) řekl, na čem dělal včera, co bude dělat dneska a s čím má případně problém (na něčem se zasekl, na něco čeká, ...). A neříká pro pro sebe, ale pro ostatní, aby měli přehled.
Pokud zazní na standupu nějaký problém, neřeší se na něm, ale po něm, jen mezi lidmi, kterých se to týká. Jinak to dopadne tak, že Pepa s Frantou deset minut řeší nějaký problém a dalších pět lidí tam stojí jako tvrdý Y a nudí se, protože je to vůbec nezajímá. Což je samozřejmě špatně.
Ohledně ticketů, před sprintem se ohodnotí náročnost ticketů a podle toho se pak zařadí do sprintu tickety za odpovídající počet bodů. Lidi si berou tickety ze sprintu a na těch dělají. Tedy by rozhodně neměli dělat na něčem, co je v backlogu níže (= nedostalo se do sprintu), nebo na co ticket vůbec není. Pokud je potřeba to kontrolovat, nebo dokonce tou kontrolou trávit nějaké významnější procento času, je něco hodně špatně.
-
Standup je o toho, aby každý krátce (!) řekl, na čem dělal včera, co bude dělat dneska a s čím má případně problém (na něčem se zasekl, na něco čeká, ...). A neříká pro pro sebe, ale pro ostatní, aby měli přehled.
A to neexistuje jiný způsob, jak můžou ostatní zjistit, na čem dělá kolega, pokud jim po tom něco je - třeba tak, že se mrknou do trackeru nebo se ho, já nevím, zeptají? A scházet se takhle jeden každý den? To mi přijde jako skutečné psycho.
-
Ohledně ticketů, před sprintem se ohodnotí náročnost ticketů a podle toho se pak zařadí do sprintu tickety za odpovídající počet bodů. Lidi si berou tickety ze sprintu a na těch dělají. Tedy by rozhodně neměli dělat na něčem, co je v backlogu níže (= nedostalo se do sprintu), nebo na co ticket vůbec není.
A teď si představte, že se někdo tohle pokouší závést do týmu cca 10 vývojářů, kteří pracují na asi 6 menších projektech a k tomu drží dalších 5 placených servisních smluv na support nějakého SW vyvinutého dříve.
-
Náš tým právě taky nepracuje na jednom projektu/produktu, je tam víc menších věcí. Takže ten sprint nemá žádný jednotný cíl, neděláme žádný release jednou za 14 dní, je to jen kolekce ticketů na příštích 14 dní. Vůbec nechápu, jaký to pro tenhle případ dává smysl. Někdo byl na školení a vlezlo mu do hlavy, že se takhle dá řídit všechno. Ve skutečnosti je to jen nástroj na dohled a buzeraci.
-
Ano, nedává to smysl - protože to ve skutečnosti ani není scrum, jen se to snaží napodobit jeho vnější znaky.
I Wiki říká, že scrum je "metodika řízení vývoje produktu" - a kde chybí společný produkt, tam není důvod na denní společné schůzky.
U nás se to chvíli snažili zabalit do hesla že náš společný produkt je právě "Vývoj SW" na kterém si máme všichni společně pomáhat a když má někdo málo práce, operativně pomáhá v jiném projektu, takže by měl být pořád v obraze, co se tam děje. :D :D :D
-
Hlavní problém tohohle je, že je to v podstatě náboženství, navíc s příživnickým businessem kolem sebe.
Mně osobně se po zavedení scrumu snížila produktivita možná i o 50 procent. Neskutečně přibylo mítinků a hlavně je přísně zakázáno udělat "něco navíc", na co není kartička. Spousta keců o tom, jak tým má být samoorganizující se, ale ve skutečnosti třeba standup slouží hlavně na to, aby byli všichni totálně pod kontrolou.
Znáte někdo nějakou metodu, jak přesvědčit vedení, že je to celé nesmysl?
O takovýchto kravinách se s despektem vyjadřoval už Dijkstra (ano, ten Dijkstra) v 70. letech. Vše je o lidech, týmu lemplů nepomůže žádná metodologie a tým profíků ví sám nejlíp, jak si uspořádat práci. Čím méně do toho kecá nějaký nedovzdělaný manager, tím lépe.
-
Agile je skvely, kdyz se dobre uchopi, kdyz to lidi co to zavadi chapou a dokazou prenyst na "ty dole". Mam to stesti, ze v takovem tymu pro takoveho zakaznika funguju (jsme ve vice geografickych lokacich, domlouvame se anglicky).
Kdokoliv tady breci na dlouhy standup, moc meetingu apod tak to proste nekdo zpizdil kdyz ty procesy rozjizdel. Patrne jde o produkt nejakyho diplomu bez praktickych zkusenosti.
-
SCRUM vo mne zabil vsetok zaujem a radost z IT. Seriozne premyslam, ze zmenim obor a budem robit kludne aj za menej penazi, lebo neviem ako vam, mne SCRUM pride ako nieco co patri do ucebnic psychiatrie a psychopatologie nie do softverovej firmy.
EDIT:
co je na tom asi to najhorsie, ze je to doslova vsade. Neviem o jednej firme, kde by tato rakovina nebola v pokrocilom stadiu.
-
A to neexistuje jiný způsob, jak můžou ostatní zjistit, na čem dělá kolega, pokud jim po tom něco je - třeba tak, že se mrknou do trackeru nebo se ho, já nevím, zeptají? A scházet se takhle jeden každý den? To mi přijde jako skutečné psycho.
Mě tedy přijde spíš jako psycho když bych musel x-krát denně odpovídat různým lidem co dělám a zda/kdy to budu mít hotové, když bychom si to mohli jednou denně prostě říct všichni najednou :-) Ale proti gustu... Jinak, samozřejmě, jiné způsoby existují, ale taky mají své mouchy. Tickety často nejsou aktualizované, odpovídat neustále na dotazy otravné, lidé se často nezeptají, ale předpokládají. Standupy jsou prostě jen nástroj, ne nutně ve všech situacích nejlepší, ale podle mě pokud se používají správně, tak docela dobrý.
A teď si představte, že se někdo tohle pokouší závést do týmu cca 10 vývojářů, kteří pracují na asi 6 menších projektech a k tomu drží dalších 5 placených servisních smluv na support nějakého SW vyvinutého dříve.
Pokud to není tak, že všichni dělají (víceméně) všechno, tak to není scrumový standup, ať tomu říkají jak chtějí. To je prostě jen report manažerovi.
-
Ja mam so scrum-om pozitivnu skusenost. Cca tri roky v jednej vacsej spolocnosti. Skusim popisat, ako "sa to robilo u nas". V kazdom pripade, za tie tri roky tam bol citelny posun vo veciach a hladali sa optima...
Dvojtyzdenny sprint, standup primarne ako rekapitulacia a naznak co je v plane dnes. Ak niekto tri dni robil na tom istom, zvacsa sa ozval specialista na dany problem a len si kyvli, ze si daju parovu session/diskusiu a vyriesia to za polhodku. V kazdy tyzden bol jeden predplaning (kludne aj dvojhodinovy meeting s kartickami) a jeden planing. Zhruba rovnaka napln. Vpodstate bola snaha mat lepsie pripravene ulohy a lepsie definovane DefinitionOfDone, ci AcceptanceCriteria, ale tu sme sa kus motali. Samotny project owner nam do sprintu zvacsa nahodil tak 5 uloh a povedal ktore by mal rad spravene "navyse". Podla aktualneho technical dept-u sme si prihodili ako tim cca 5 az 15 uloh zvacsa technologickych, ci prevadzkovych (predsa sme DevOps a aj ked nik nevie s databazami, tak si ich budeme manazovat sami :). Samozrejma retrospektiva (snaha aby kazdy povedal aspon jednu pozitivnu a jednu negativnu vec). Zvacsa sme sa tu motali v podobnych veciach, ktore boli bud personalneho charakteru, alebo "bad luck" charakteru a nevedeli sme ich odstranit. Ziadne akcie, co scrummaster navrhol nezafungovali :/ Vnimali sme ale retrospektivu (cca 30 az 50 minutove boli) ako plus, kde sme si otvorene povedali, co sme (pripadne kto :) posrali tento sprint a pripadne ako to v buducnosti nespravit rovnako. Ulohy sme si vzdy vyberali sami a vzdy po jednej. Tiez zaradovane (tie technologicke) boli primarne podla timu. Ak sa nejaky clovek, co ma na starosti zalohovanie DB ohlasil, ze by potreboval daco prerobit, tak to nahodil do backlogu a nasledne na planingu sa to ohodnotilo a demokraticky dohodlo na zaradeni... Co sa tykastorypointov (karticiek), tak tam sa nerobil ziaden priemer. Kazdy ukazal a scrummaster bud povedal, ze vstupy 2, 3, 3, 5, 7 znamenaju, ze to dame za 5, alebo sa spytal dvojky a sedmicky, ze "preco". Tam sa niekedy zistilo, ze zadanie je nejednoznacne a upravilo sa znova sme tasili karticky. Vpodstate vzdy sme dospeli k spolocnemu cislu. Aj ked napriklad ulohu vsetci videli ako dvojku, ale ja ako patku, tak to niekedy skoncilo na tom, ze sa to da za tri (alebo 5) a spravim to so silnou ucastou kolegu, ktory by to mozno zvladol za jednotku... Co sa tyka dema, tak jednu dobu sme mali (fitnesse framework na testy a nasledne inhouse scalatest based framework s podobnym vlastnym vystupom) kvalitne demo, kde sme naozaj ukazovali nejake "end to end" testy (pre nas end bol backendovy rest call, alebo nejaky zaznam v databaze, ktoru sme monitorovali a ine legacy veci). Neskor sa dema zrusili a potom sa opat zaviedli, ale do podoby, kedy trvalo demo cca 5 minut a obsahovalo "Sprint sme nestihli, lebo choroba clenov timu a zaroven nam tim X nedodal nacas daco a este jeden bug, ktory trval dlhsie ako sme mali buffer...".
PS: Dakde som zachytil, ze storypointy vychadzaju z mody a lepsi pristup je, ze si na planingu ludia povedia pocitovo, ci tam tie tasky vojdu a daju ich tam tolko, aby to bolo OK. Teda idealne, ze sa dlzka sprintu nastavi na "zhruba 7 pracovnych dni", lebo "zhruba 4 pracovne dni" a nahadzu sa veci do sprintu a potom sa sprintuje.
-
EDIT:
co je na tom asi to najhorsie, ze je to doslova vsade. Neviem o jednej firme, kde by tato rakovina nebola v pokrocilom stadiu.
Ano, nějaké prvky z toho jsou skoro všude, ale dost se to liší v intenzitě. Někde je ze scrumu jen standup, jinde je to all inclusive i s demem pro uklízečky :)
-
A to neexistuje jiný způsob, jak můžou ostatní zjistit, na čem dělá kolega, pokud jim po tom něco je - třeba tak, že se mrknou do trackeru nebo se ho, já nevím, zeptají? A scházet se takhle jeden každý den? To mi přijde jako skutečné psycho.
Mě tedy přijde spíš jako psycho když bych musel x-krát denně odpovídat různým lidem co dělám a zda/kdy to budu mít hotové, když bychom si to mohli jednou denně prostě říct všichni najednou :-) Ale proti gustu... Jinak, samozřejmě, jiné způsoby existují, ale taky mají své mouchy. Tickety často nejsou aktualizované, odpovídat neustále na dotazy otravné, lidé se často nezeptají, ale předpokládají. Standupy jsou prostě jen nástroj, ne nutně ve všech situacích nejlepší, ale podle mě pokud se používají správně, tak docela dobrý.
Pokud by snad někde skutečně bylo normou, že musíš tu samou věc ten den říkat X lidem, chápal bych to. Já tuhle zkušenost nemám. Mimochodem, jak se v tom standupovém prostředí dá pracovat z domova, to najednou nevadí, že to všichni ten den neslyší, že Pepa napsal funkci X a třídu Y přejmenoval na Z a že si musí přečíst HTTP specifikaci, protože mu něco nechodí? Nebo to v tom super duper pracovním procesu prostě nejde a všichni musí prostě dorazit?
-
A to neexistuje jiný způsob, jak můžou ostatní zjistit, na čem dělá kolega, pokud jim po tom něco je - třeba tak, že se mrknou do trackeru nebo se ho, já nevím, zeptají? A scházet se takhle jeden každý den? To mi přijde jako skutečné psycho.
Mě tedy přijde spíš jako psycho když bych musel x-krát denně odpovídat různým lidem co dělám a zda/kdy to budu mít hotové, když bychom si to mohli jednou denně prostě říct všichni najednou :-) Ale proti gustu... Jinak, samozřejmě, jiné způsoby existují, ale taky mají své mouchy. Tickety často nejsou aktualizované, odpovídat neustále na dotazy otravné, lidé se často nezeptají, ale předpokládají. Standupy jsou prostě jen nástroj, ne nutně ve všech situacích nejlepší, ale podle mě pokud se používají správně, tak docela dobrý.
Pokud by snad někde skutečně bylo normou, že musíš tu samou věc ten den říkat X lidem, chápal bych to. Já tuhle zkušenost nemám. Mimochodem, jak se v tom standupovém prostředí dá pracovat z domova, to najednou nevadí, že to všichni ten den neslyší, že Pepa napsal funkci X a třídu Y přejmenoval na Z a že si musí přečíst HTTP specifikaci, protože mu něco nechodí? Nebo to v tom super duper pracovním procesu prostě nejde a všichni musí prostě dorazit?
Nějakej Alexander Graham Bell před časem představil takovou užitečnou věc, ze které se časem vyvinuly v docela zajímavé aplikace…
A zrovna tohle standupování mi přijde užitečná věc (narozdíl od dalších scrumových šamanstvi): protože často nejdůležitější informace je ta na kterou člověka vůbec nenapadne se zeptat a kterou se dozví tak mimochodem a standup je cesta jak tomu mimochodem vyjít naproti. Taky pro fungování týmu je dobré když členové zhruba vědí na čem pracují ti ostatní.
-
Nějakej Alexander Graham Bell před časem představil takovou užitečnou věc, ze které se časem vyvinuly v docela zajímavé aplikace…
Ptal jsem se, jak se to v praxi v jednotlivych tymech skutecne dela, ne na existenci nejakych aplikaci a udelatek, sorry.
-
Dělá se to tak, že ten, kdo není fyzicky, se připojí online.
A nemusí u toho stát :D
-
Dělá se to tak, že ten, kdo není fyzicky, se připojí online.
A nemusí u toho stát :D
Takze mate nekde v zasedacce zarizeni (laptop?), ktere ma aplikaci, ktera komunikuje s aplikacemi doma/vzdalene pracujicich lidi? Co konkretne pouzivate?
-
Takze mate nekde v zasedacce zarizeni (laptop?), ktere ma aplikaci, ktera komunikuje s aplikacemi doma/vzdalene pracujicich lidi? Co konkretne pouzivate?
Cokoliv na videokonferenci? Google meet, Bluejeans, Zoom, Skype, ... případně alespoň telefon (to je ten vynález od pana A.G. Bella)?
Standupy jsou užitečné, pokud se dodrží pár pravidel:
- není to status meeting, opakuji NENÍ to status a není určen pro reportování šéfovi
- omezená délka, cca 15 minut max
- nediskutují se technická témata, jen se na ně upozorní a potřební lidé se sejdou zvlášť
Standup je jen moderní název pro ranní poradu členů týmu (bez šéfa) u kafe :) Lidi si řeknou s čím potřebujou pomoc nebo na co si ostatní mají dát pozor.
-
Takze mate nekde v zasedacce zarizeni (laptop?), ktere ma aplikaci, ktera komunikuje s aplikacemi doma/vzdalene pracujicich lidi? Co konkretne pouzivate?
Cokoliv na videokonferenci? Google meet, Bluejeans, Zoom, Skype, ... případně alespoň telefon (to je ten vynález od pana A.G. Bella)?
Opakuju - nezajimaji me obecne postrehy, ale realne zkusenosti z praxe. Ze existuje telefon vim, dokonce i Skype jsem zaznamenal. Zbytek prispevku, ktery jsem necitoval, mi dava smysl.
-
Takze mate nekde v zasedacce zarizeni (laptop?), ktere ma aplikaci, ktera komunikuje s aplikacemi doma/vzdalene pracujicich lidi? Co konkretne pouzivate?
Cokoliv na videokonferenci? Google meet, Bluejeans, Zoom, Skype, ... případně alespoň telefon (to je ten vynález od pana A.G. Bella)?
Opakuju - nezajimaji me obecne postrehy, ale realne zkusenosti z praxe. Ze existuje telefon vim, dokonce i Skype jsem zaznamenal. Zbytek prispevku, ktery jsem necitoval, mi dava smysl.
No prakticky to záleží s kým má Vaše firma smlouvu. Ale z těch co znám:
Bluejeans - Používáme dlouho a obvykle funguje. Když se sdílí obrazovka nejdou vidět lidi, takže člověk mluví do monitoru.
Google meet - Používáme občas a spíš až poslední dobou, při sdílení jsou vidět lidi, což je příjemnější. Asi vyžaduje Google účet.
Zoom - Nějaké komunitní projekty okolo kubernetes ho používají, vyžaduje aplikaci, ale taky to jde.
Telefon - Obecně na houby, ale občas to jinak nejde. U delších porad nebo něčeho komplikovanějšího lidi ztrácí pozornost a usínají.
-
Takze mate nekde v zasedacce zarizeni (laptop?), ktere ma aplikaci, ktera komunikuje s aplikacemi doma/vzdalene pracujicich lidi? Co konkretne pouzivate?
Cokoliv na videokonferenci? Google meet, Bluejeans, Zoom, Skype, ... případně alespoň telefon (to je ten vynález od pana A.G. Bella)?
Opakuju - nezajimaji me obecne postrehy, ale realne zkusenosti z praxe. Ze existuje telefon vim, dokonce i Skype jsem zaznamenal. Zbytek prispevku, ktery jsem necitoval, mi dava smysl.
No prakticky to záleží s kým má Vaše firma smlouvu. Ale z těch co znám:
Bluejeans - Používáme dlouho a obvykle funguje. Když se sdílí obrazovka nejdou vidět lidi, takže člověk mluví do monitoru.
Google meet - Používáme občas a spíš až poslední dobou, při sdílení jsou vidět lidi, což je příjemnější. Asi vyžaduje Google účet.
Zoom - Nějaké komunitní projekty okolo kubernetes ho používají, vyžaduje aplikaci, ale taky to jde.
Telefon - Obecně na houby, ale občas to jinak nejde. U delších porad nebo něčeho komplikovanějšího lidi ztrácí pozornost a usínají.
Diky!
-
Takze mate nekde v zasedacce zarizeni (laptop?), ktere ma aplikaci, ktera komunikuje s aplikacemi doma/vzdalene pracujicich lidi? Co konkretne pouzivate?
Cokoliv na videokonferenci? Google meet, Bluejeans, Zoom, Skype, ... případně alespoň telefon (to je ten vynález od pana A.G. Bella)?
Opakuju - nezajimaji me obecne postrehy, ale realne zkusenosti z praxe. Ze existuje telefon vim, dokonce i Skype jsem zaznamenal. Zbytek prispevku, ktery jsem necitoval, mi dava smysl.
Jak už psal kolega, zoom (https://zoom.us).
Existuje pro Android i Apple, dá se nainstalovat do Linuxu.
Funguje i s Averem.
(= používáme to)
-
Opakuju - nezajimaji me obecne postrehy, ale realne zkusenosti z praxe.
Mám zkušenosti s Hangouts, Meetem a dobré. Pro urychlení je dobré mít pořadí lidí určené nějak "algoritmicky", například na místě podle fyzické pozice, remote vyvolává jeden určený člověk podle pořadí v kecátku. Pak se neztrácí čas řešením, kdo má mluvit další. Je dobré mít alespoň avatary, ideálně video, pokud jsou na to technické podmínky. Pokud blbne, tak se s ním akorát ztrácí čas.
Pokud nesedí (vždy) všichni v jedné kanceláři, tak standup nabývá ještě více na důležitosti, protože tam jsou větší komunikační bariéry a přirozený tok informací dost přiškrcený. V kanceláři občas hodíš řeč s kolegou jen tak, ale přes remote těžko.
-
Nějakej Alexander Graham Bell před časem představil takovou užitečnou věc, ze které se časem vyvinuly v docela zajímavé aplikace…
Ptal jsem se, jak se to v praxi v jednotlivych tymech skutecne dela, ne na existenci nejakych aplikaci a udelatek, sorry.
normalne proste daily 10AM hangouts/slack/teams call.
-
Z mna agile/scrum = zbytocnost alebo skor sarlatanizmus
U nas sa to urcity cas praktizovalo, lebo to vyzadoval byvaly veduci, ktory uz odisiel.
Ja ako tam leader som musel v tomto divadle hrat rolu scrum-mastera :D
Myslim si, ze to bolo dobre akurat pre veduceho ktory sa obcas na standupe zastavil a za 5 minut ziskal prehlad co sa robi, aby o tom mohol referovat na svojej porade.
Ale pre nas yvvojarov to bolo uplne trapne a zbytocne, pretoze sme maly team, kde je kazdy vytazeny a vie co ma robit. Potrebne informacie si vymenime medzi sebou aj bez tohto divadla.
(mozno je to dobre pre velke teamy, aby sa tam neflakali darmozraci)
Moj nazor je, ze sa jedna hlave o business pretoze je to je zivna poda pre roznych pofidernych "IT" konzultantov, ktori predavaju zarucene metodiky bez zaruky. Staci si pozriet na internete, kto robi v SK & CZ skolenia o agile, kto o tom vydava publikacie a ake ma prakticke skusenosti s vyvojom software...
-
Z mna agile/scrum = zbytocnost alebo skor sarlatanizmus
U nas sa to urcity cas praktizovalo, lebo to vyzadoval byvaly veduci, ktory uz odisiel.
První chyba. Zásadní, ale bohužel dost častá. Agile/Scrum není nástroj pro micro management lidí a není dobré ho prostě nařídit shora. Celá idea Agile je o samo-organizujícím se týmu zodpovědných lidí a komunikaci.
Ja ako tam leader som musel v tomto divadle hrat rolu scrum-mastera :D
Myslim si, ze to bolo dobre akurat pre veduceho ktory sa obcas na standupe zastavil a za 5 minut ziskal prehlad co sa robi, aby o tom mohol referovat na svojej porade.
Jak říkám..
1) Scrum není jediná Agile metodologie, patří k těm nejvíc náročným na disciplínu a nejvíce zneužívaným
2) To vypadá, že si z něj manažer vzal jen ty standupy a ještě blbě
Ale pre nas yvvojarov to bolo uplne trapne a zbytocne, pretoze sme maly team, kde je kazdy vytazeny a vie co ma robit. Potrebne informacie si vymenime medzi sebou aj bez tohto divadla.
A jak víte co máte dělat? Kdo Vám nastaví priority, pokud je možné práce víc, než se stíhá za definovaný čas?
Naopak. Pokud se to dobře vede, tak to odstíní _dobrý_ tým od neustálého vyrušování ostatních. Lead si s manažerem, PMkem a podobně sednou, definují priority pro následující sprint a pak se tam už nic nepřidává, takže lidi mají čas to udělat bez neustálého vyrušování a změn.
(mozno je to dobre pre velke teamy, aby sa tam neflakali darmozraci)
Přesně k tomuto Agile vůbec neslouží. Není to nástroj pro manažery. Dokonce to není ani dobrý nástroj pro velké týmy (ideální je tým do cca 8-10 lidí vč. QE, dokumentace a produkťáků).
Ale bohužel... jak píšete níže..
Moj nazor je, ze sa jedna hlave o business pretoze je to je zivna poda pre roznych pofidernych "IT" konzultantov, ktori predavaju zarucene metodiky bez zaruky. Staci si pozriet na internete, kto robi v SK & CZ skolenia o agile, kto o tom vydava publikacie a ake ma prakticke skusenosti s vyvojom software...
Tady musím souhlasit. A je to docela paradox, protože certifikace dodržení přesného postupu "Agile" porušuje hned několik základních kamenů Agile manifestu :)
-
Pro me existuje nekolik cilu, kterych je potreba dosahnout
1. Vyrobit to co zakaznik potrebuje
On to sam dost casto presne nevi, a i kdyz vi tak se informace ztrati v komunikaci. Takze je potreba zkratit zpetnou vazbu.... Musi se dodavat casto a v malych davkach a nechat si uzivatele hrat a rikat co chce jinak.
2. Vyvazit prinos a cenu
Zakaznik treba i nekdy vi co chce, ale nema spravnou predstavu o tom co to bude stat. Takze je potreba dat zpetnou vazbu i na jeho pozadavky. Product owner pak muze prioritizovat... To co ma dobry pomer cena/prinos pujde prvni na radu. To co maly prinos za hodne penez/casu se nebude delat vubec
3. Ziskat daty podlozeny prehled o tom kdy se co doda
Diky malym taskum se da lepe hodnotit cena/cas dodani. Po nejakem case se da z historickych dat odhadnout cena za story point. A to potom vede k presnejsim odhadum dodani v case a nakladech.
Jakakoliv metodologie nebo jejich kombinace me k tomu dovede bude uzitecna. Pokud me k tomu nedovede tak je kontraproduktivni.
Jsem presvedcen o tom, ze jakakoliv skoleni a certifikace "agile" vedou spis k tomu, ze se slepe dodrzuji nejaka pravidla bez znalosti cilu a tim padem jsou spis na skodu.
Taky si myslim, ze "agile" se spise hodi na green field vyvoj. Tam kde se aplikuje na support a maintenance je to podle me taky spis na skodu.
-
9:00 SEC: Ahoj, tak ja jsem vcera psal classu X, zasekl jsem se na jedne metode, ale tady Franta mi pomohl. Dneska budu psat classu Y. Odpoledne musim k doktorovi... A takhle kazdy den do zblbnuti....Prinos nula.
-
Proč přínost nula? Já jsem se i z takovéhohle krátkého reportu dozvěděl hned tři důležité věci:
- Pokud čekám na classu X, tak můžu pokračovat
- Pokud čekám na classu Y, tak bude během dneška nebo spíš zítra
- Když tě budu shánět odpoledne a nebudeš tady, tak nemá cenu na tebe čekat, protože jsi u doktora
-
Problémem je, že většina týmu nečeká ani na X, ani na Y, takže je to nezajímá a nudí se u toho, a to že jdeš k doktorovi stejně většina z nich do oběda zapomene (od čeho je sdílený kalendář) :D
-
9:00 SEC: Ahoj, tak ja jsem vcera psal classu X, zasekl jsem se na jedne metode, ale tady Franta mi pomohl. Dneska budu psat classu Y. Odpoledne musim k doktorovi... A takhle kazdy den do zblbnuti....Prinos nula.
Já jsem považován za extrémního asociála, ale tohle mi přijde jako na pohodu. Jediné, co by mi vadilo, je ta ranní hodina. Tak zase nevím, proč bych měl za každou cenu druhým kazit jejich snahu.
-
Problémem je, že většina týmu nečeká ani na X, ani na Y, takže je to nezajímá a nudí se u toho, a to že jdeš k doktorovi stejně většina z nich do oběda zapomene (od čeho je sdílený kalendář) :D
Pardon omlouvám se, měl jsem za to, že když já chodím do práce pracovat, tak to máte stejně. Ale vy se tam evidentně chodíte bavit. Tak to pak jo, potom je fakt nepatřičné, že vás zaměstnavatel týrá nudnými standupy. Doufám, že alespoň v jiných věcech není sketa a nejméně jednou týdně vám tam vpustí spoře oděné děvy. Vždyť se tam přece chodíte bavit.
Ne, vážně, tohle jsme tu už probírali, tedy nemá cenu diskusi opakovat. Viz výše.
-
Pardon omlouvám se, měl jsem za to, že když já chodím do práce pracovat, tak to máte stejně. Ale vy se tam evidentně chodíte bavit. Tak to pak jo, potom je fakt nepatřičné, že vás zaměstnavatel týrá nudnými standupy.
Pravidelne verejne ustni reportovani v situaci, kdy ne kazdy recnik se dokaze vymacknout a ne kazdy posluchac presne vi, o co jde, protoze se ho to primo netyka, je zasadni problem. Hodit to na posluchace, ze ho nezajima, ze nekdo prejmenoval InterfaceZoomAdapter na ZoomIterator, neni uplne fer. Mne zatim vychazi, ze to bude fungovat u tymu, kde vsichni clenove pracuji na vsem nebo maji vlastni vysek produktu, ktery vyvijeji spolecne a mezi lidmi funguje "chemie". Stejne by me ale zajimalo, proc je skoro jako dogma predkladano setkani kazdy den a ne treba 2x az 3x tydne nebo i mene.
-
Stejne by me ale zajimalo, proc je skoro jako dogma predkladano setkani kazdy den a ne treba 2x az 3x tydne nebo i mene.
Aby ti ktori to organizuju mali na dennej baze co vykazovat a vytvarali dojem svojej dolezitosti.
-
Mne zatim vychazi, ze to bude fungovat u tymu, kde vsichni clenove pracuji na vsem nebo maji vlastni vysek produktu, ktery vyvijeji spolecne
Pokud nedělají společně, tak to asi není ten správný tým pro aplikaci Scrumu, že ano... další případ zneužití agile myšlenek pro mikro management?
Stejne by me ale zajimalo, proc je skoro jako dogma predkladano setkani kazdy den a ne treba 2x az 3x tydne nebo i mene.
Dělali jsme v různých týmech obojí. Jak denní, tak 2x - 3x týdně. Takže žádné dogma to není. Naopak, jeden z principů agile je: People and communication over processes. Takže si to nastavte jak Vám to vyhovuje.
-
Takže se dostáváme k pointě.
V 80% IT firem se zkouší zavádět něco co tam nazývají "agile" a "scrum", ale zavádí se to direktivně shora a podle příruček, takže to s původním významem těch slov má jen málo společného.
Takže zdejší dohady nemají smysl, když si pod těmi slovy každý představí něco jiného - a většina právě tu špatnou variantu.
-
Ještě k té Fedoře a správě balíčků. Používám KDE a jako správce balíčků Apper. Neříkám že je dokonalý, ale oproti yumexům dragorám a gnome software centru mi to přijde jako použitelné.
-
Omlouvám se patřilo to jinam :(