Mají smysl daily standupy?

[xyz]

Ahoj,

jaky mate nazor na daily standupy?  Je to pro vas prinos, nebo ztrata casu?

[Reklama]

[alex6bbc]

jo smysl to ma, aspon se ukaze, jestli je nekdo zaseknuty, nebo na necem dela neprimerene dlouho a da se zareagovat.
melo by to byt velmi kratke a problemy co se ukazou resit az potom samostatne po dvojicich, mensich skupinkach.
aby se to neprotahovalo, tak je zajimave to delat ve stoje na jedne noze, nebo pri tom plankovat.

[jouda2]

jaky mate nazor na daily standupy?  Je to pro vas prinos, nebo ztrata casu?

Pokud se dělají správně, probírá se tam co má, neprobírá se co nemá, tak IMHO jsou přínos, ostatně proto se dělají.

Ale pokud někde berou metodiku jako cargokult a standupy dělají protože "tady se píše že je máme dělat a navíc jinde je taky dělaj tak to přece musí být správně" (bohužel je takový přístup občas k vidění), tak asi smysl dávat moc nebudou.

[Jakub Štech]

My jsme dělali standupy ve firmě, kde v podstatě každé oddělení byl jeden člověk. Každý si tam řekl, co zrovna dělá, čemuž nikdo další nerozuměl. Zabilo to hodinu z každého dne.

Dělalo se to přesně proto, že to kravaty viděly u firem svých kamarádů a tak to přece musí fungovat i u nás.

[sofa_king]

Pokud delas standup stylem "status report", tj. co kazdej blb v tymu dela ten den, tak ztracis cas. Akorat ulehcujes cas managerovi, kterej je v dnesni firme spis takova preplacena sekretarka, zapisujici a reportujici progress.

Kdyz naopak udelas standup jako pokecani o tom, ze neco stoji na tomhle a tamhletom, kolikrat se otevre debata, ktera ti usetri ztracenej tyden, kdy nekdo dropnul dulezitej ukol, kdyz se zasek a vrhnul se na dalsi.

Je mezi tima dvema styly docela velkej rozdil, ale malokdo ho vidi.

[Reklama]

[_Tomáš_]

pokud se to dělá tak jak to vídám v bankách, tak rozhodně nemají.

V případně třeba metodiky Kanban jsou skoro životně důležité, jejich hlavní cíl je vyčistit bariéry a zajistit, aby slíbená práce pro celý den neměla žádné překážky a mohla být dokončena, jakmile jsi ve stavu, kdy nejsou daily stand up potřeba, znamená to, že nemáš bariéry k dokončování úkolů, tj. ideální cílový stav. Jejich forma musí být ale krátká, cca minutu na člověka, slouží pouze jako rekapitulace cílů a dokončených úkolů pro zbytek týmu.

[anonacct]

Většinou je to nutné jen tam, kde je hodně lidí co sami od sebe nic neudělají a potřebují dohled. Ještě jsem neviděl aby to bylo nutné v teamu, kde lidi dokážou komunikovat a řešit případné problémy hned sami od sebe.

[_Tomáš_]

Většinou je to nutné jen tam, kde je hodně lidí co sami od sebe nic neudělají a potřebují dohled. Ještě jsem neviděl aby to bylo nutné v teamu, kde lidi dokážou komunikovat a řešit případné problémy hned sami od sebe.

Metodiky jako Scrum a Kanban právě stojí na takových mini setkáváních, není to o hodně lidech v týmu (zpravidla tady jsou 4 až , ale o způsobu práce na úkolech a organizaci práce, zároveň to slouží jako vstup pro další zúčastnené (product owner, scrum master).

Neřikám, že tyhle metodiky jsou kdovíjak boží, ale fungují na určitých principech a tyhle stand upy mají smysl.

Pokud takový denní stand up slouží jen jako povídání o ničem, většinou moc prospěšný není a zažívám to skoro denně.

[Benutzer]

U distribuovaných týmů přínos standupů vidím. Když ale alokace lidí na projekty v organizaci je M:N tak to je docela šílené. Tři standupy po sobě, kdy na jednom řeknu jak to jde a na dalších, že dnes dělám na jiném projektu...

[kanoe22]

Většinou je to nutné jen tam, kde je hodně lidí co sami od sebe nic neudělají a potřebují dohled. Ještě jsem neviděl aby to bylo nutné v teamu, kde lidi dokážou komunikovat a řešit případné problémy hned sami od sebe.

Nesuhlasim.

Scrum nie je od toho aby dohliadal na ludi ci robia alebo nie, od toho je ked uz tak tvoj nadriadeny (tvoj manazer, nie tvoj scrum master).

Scrum, alebo aj ine agilne metody prace su o tom, ze scrum master je tam ako team koordinator, ktory riesi ked ma niekto problem, a je takpovediac hovorcom timu voci vedeniu, alebo inym timom. Asi si v zivote nepracoval na projekte kde je 100 a viac vyvojarov v 10+ timoch (osobna skusenost 90 vyvojarov v asi 12tch timoch). Keby som mal kazdu blbu zmenu ktorou mozem nejak vyrazne ovplyvnit ine timy riesit osobne, tak pol dna nerobim nic ine iba riesim koordinaciu a upozornujem inych ze momentalne sa hrabem v tom a tom. Od toho tam prave boli scrum mastery, ktori tieto veci koordinovali.

Takisto ked ma niekto s niecim problem, scrum master, pripadne po dohode s product ownerom zasiahnu a urobi sa napr. 1) bude na danom probleme robit viac ludi aby sa to stihlo, tim padom sa pravdaze nieco ine posunie do pozadia. 2) dany problem bude riesit niekto iny, pretoze povodny clovek sa proste zasekol a nevie co dalej. 3) dany problem je v sucastnosti neriesitelny a musi sa 3a) implementovat najskor nieco ine, 3b) problem sa declasuje na "nice to have" pretoze blokujuci problem je prilis velky na implementaciu zo sucastneho budgetu, a x dalsich moznych problemov.

Vsetko (a mnohe ine dalsie veci) su proste problemy, ktore ty ako vyvojar nemusis riesit osobne a stracat tim cas, proste raz na daily standupe povies problem je teraz neriesitelny lebo ..., a od najdenia riesenia ako to zosuladit s inymi ulohami je/su tam iny ludia.


Z ineho sudka, teraz robim na projekte kde nas je 15, z toho niektory robia aj na inom projekte, takze vacsinou sme na standupe zhruba 10ti. Koordinacia je treba, pretoze nasledne sa vie kto na com robi, ako uloha napreduje, pripadne ci su tam nejake problemy (nemusi to byt vzdy len otazka toho ze ma nieco blokuje, ale moze to byt aj zaujmavy problem ktory som musel vyriesit aby som splnil ulohu, cize ak to spomeniem na standupe, nabuduce usetrim cas inym pretoze uz budu mat tusenie ako to vyriesit). A podla toho sa planuje dalsi postup. Tazko sa ti bude planovat nasledujuca uloha, ktora zavisi na nejakej aktualne vykonavanej, ked nevies jej stav. Namiesto toho mozes naplanovat nieco ine. Zbytocne budes mat backlog dlhy ako tyzden pred vyplatou ked tam bude chaos v style, moze sa na tasku B robit? Clovek co robil A task ho uz urobil? Kto vie, nemame standupy, skontroluj repozitar ci tam nahadzal zmeny. Nie dakujem, takyto chaos si neprosim.

U distribuovaných týmů přínos standupů vidím. Když ale alokace lidí na projekty v organizaci je M:N tak to je docela šílené. Tři standupy po sobě, kdy na jednom řeknu jak to jde a na dalších, že dnes dělám na jiném projektu...

Navrhujem riesit to tak ze dopredu (aspon tyzden - dva, ak sa da aj cely mesiac) poviete projektom ktore dni pre ne robite a pripadne aj kolko hodin. Tim padom si usetrite si X hodin mesacne sedenim na meetingoch ktore su pre vas aktualne nepodstatne a iba vas rozptyluju.

[xyz]

Většinou je to nutné jen tam, kde je hodně lidí co sami od sebe nic neudělají a potřebují dohled. Ještě jsem neviděl aby to bylo nutné v teamu, kde lidi dokážou komunikovat a řešit případné problémy hned sami od sebe.

Nesuhlasim.

Scrum nie je od toho aby dohliadal na ludi ci robia alebo nie, od toho je ked uz tak tvoj nadriadeny (tvoj manazer, nie tvoj scrum master).

Scrum, alebo aj ine agilne metody prace su o tom, ze scrum master je tam ako team koordinator, ktory riesi ked ma niekto problem, a je takpovediac hovorcom timu voci vedeniu, alebo inym timom. Asi si v zivote nepracoval na projekte kde je 100 a viac vyvojarov v 10+ timoch (osobna skusenost 90 vyvojarov v asi 12tch timoch). Keby som mal kazdu blbu zmenu ktorou mozem nejak vyrazne ovplyvnit ine timy riesit osobne, tak pol dna nerobim nic ine iba riesim koordinaciu a upozornujem inych ze momentalne sa hrabem v tom a tom. Od toho tam prave boli scrum mastery, ktori tieto veci koordinovali.

Takisto ked ma niekto s niecim problem, scrum master, pripadne po dohode s product ownerom zasiahnu a urobi sa napr. 1) bude na danom probleme robit viac ludi aby sa to stihlo, tim padom sa pravdaze nieco ine posunie do pozadia. 2) dany problem bude riesit niekto iny, pretoze povodny clovek sa proste zasekol a nevie co dalej. 3) dany problem je v sucastnosti neriesitelny a musi sa 3a) implementovat najskor nieco ine, 3b) problem sa declasuje na "nice to have" pretoze blokujuci problem je prilis velky na implementaciu zo sucastneho budgetu, a x dalsich moznych problemov.

Vsetko (a mnohe ine dalsie veci) su proste problemy, ktore ty ako vyvojar nemusis riesit osobne a stracat tim cas, proste raz na daily standupe povies problem je teraz neriesitelny lebo ..., a od najdenia riesenia ako to zosuladit s inymi ulohami je/su tam iny ludia.


Z ineho sudka, teraz robim na projekte kde nas je 15, z toho niektory robia aj na inom projekte, takze vacsinou sme na standupe zhruba 10ti. Koordinacia je treba, pretoze nasledne sa vie kto na com robi, ako uloha napreduje, pripadne ci su tam nejake problemy (nemusi to byt vzdy len otazka toho ze ma nieco blokuje, ale moze to byt aj zaujmavy problem ktory som musel vyriesit aby som splnil ulohu, cize ak to spomeniem na standupe, nabuduce usetrim cas inym pretoze uz budu mat tusenie ako to vyriesit). A podla toho sa planuje dalsi postup. Tazko sa ti bude planovat nasledujuca uloha, ktora zavisi na nejakej aktualne vykonavanej, ked nevies jej stav. Namiesto toho mozes naplanovat nieco ine. Zbytocne budes mat backlog dlhy ako tyzden pred vyplatou ked tam bude chaos v style, moze sa na tasku B robit? Clovek co robil A task ho uz urobil? Kto vie, nemame standupy, skontroluj repozitar ci tam nahadzal zmeny. Nie dakujem, takyto chaos si neprosim.

U distribuovaných týmů přínos standupů vidím. Když ale alokace lidí na projekty v organizaci je M:N tak to je docela šílené. Tři standupy po sobě, kdy na jednom řeknu jak to jde a na dalších, že dnes dělám na jiném projektu...

Navrhujem riesit to tak ze dopredu (aspon tyzden - dva, ak sa da aj cely mesiac) poviete projektom ktore dni pre ne robite a pripadne aj kolko hodin. Tim padom si usetrite si X hodin mesacne sedenim na meetingoch ktore su pre vas aktualne nepodstatne a iba vas rozptyluju.

Jo, takhle mi to dava smysl, pokud jde o projekt, kde jsou velke zavislosti mezi vyvojari a je nutna koordinace, tak se to da resit na tech
standupech. Nicmene pokud jde o nejaky mensi projekt a kazdy vyvojar si jede na svem pisecku, dela vetsi task a jsou definovana api,
tak tam ten prinos fakt nevidim. To se standup redukuje na hlaseni: "vcera jsem napsal kus kodu a dneska budu pokracovat"

[alex6bbc]

koordinace se ma provadet v mensich potrebne vhodne velkych skupinkach.
standup je pro kazdeho, ale kazdy jen rekne maximalne delam task 12345 a jde mi to, nebo nejde mi to a scrum master
mu najde pomocnika/mentora, nebo mam hotovo.
vsecko ostatni uz jsou jen nasledne meetingy.

[acerimmer]

Rozhodne maji smysl. Musi se ale delat dobre, coz nemnoho firem/lidi umi. Standup vypada jako trivialita, ale v realu je na nej treba mit zkusene lidi nebo nekoho, kdo ho je shopny vest, dokud se to ostatni nenauci. Vzdy mne fascinuje, kdyz prijdu do firmy a u "standupu" cely team sedi - to jmeno je tam schvalne, aby ten cely tyjatr byl efektivni. Nebo kdyz se standup promeni v hodinovou potycku o pojmenovani promenne. Standup je status meeting, kazdy by mel byt schopny odrikat sve do 1 minuty max a pripadne dalsi detaily diskutovat po nem v uzsim kruhu. Do te jedne minuty davam i pripadne info o tom, ze "zitra rano jdu k doktoru, tak prijdu dyl".

[anonacct]

Mě by zajímalo kolik lidí tu poznalo víc způsobů vývoje a kolik zná jen ten jeden? Já jsem poznal za život asi 4 a za sebe můžu říct, že self organizing teams bylo to nejlepší, s čím jsem se setkal. Scrum + daily standup je takový typický korporátní způsob řízení vývoje, který sice podává nějaký výsledky, ale většinou totálně zabije chuť a kreativitu těch, kteří by toho dokázali udělat mnohem víc než jen "to co mají ve sprintu" - těmto lidem obvykle záleží i na tom jak ten kód vypadá.

Ale jinak je mi to asi jedno - Scrum je skoro všude a firmám ta neefektivita očividně nevadí

[hurvajs spejbl]

@anonacct: také jsem poznal více způsobů. Pokud, jak uvádíte self organizing team, opravdu funguje, je to i za mě ideální varianta. Na druhou stranu, prošel jsem hodně firem (už nejsem nejmladší) a takový tým jsem našel jen u jedné firmy. Většinou byl problém v tom, že programátoři nekomunikovali mezi sebou ani s businessem, takže se třeba měsíc vyvýjelo na slepo.

Na druhou stranu, pokud scrum opravdu funguje, tak je to také fajn. Sice je to krapet byrokracie, ale business má přehled co se děje, kde projekt je. Komunikace na daily standup lidi donutí říkat pravdu a záseky se dají řešit brzy (je jasné, že nikomu se neříká dobře, že se zasek a neví si rady). Pokud jí neříkají, přijde relativně brzy na to, že to tak není. Samozřejmě, je hodně událostí, kdy stojí vývoj, souhlasím. Ale na druhou stranu, jsou placené, tak proč to řešit ne? ;-)

Bohužel, většina firem má Scrum upravený podle svých potřeb. A dle mého názoru, je pravá definice týmu nesmysl, říká se tam, že každý člen je zastupitelný a má stejný výkon i znalosti, což je v realitě kr*v*na. Nehledě na to, že velocita se stanovuje nějakou dobu a nikde není záruka, že bude stejný tým dlouho. Lidé se mění a i "vlastnosti" týmu se mohou dost lišit.