Mají smysl daily standupy?

[czmiho]

Nakonec je to vždycky o lidech a ne o nějakých superfancy vynálezech. Zažil jsem i tým, kde efektivně fungoval waterfall s minimem komunikace mezi členy týmu. No a týmů, kde naopak nefungoval SCRUM jsem viděl už několik ;-)

"zitra rano jdu k doktoru, tak prijdu dyl".

Nech mě hádat, dýl místo později -> Plzeňák? :-)

[Reklama]

[Ink]

Nakonec je to vždycky o lidech a ne o nějakých superfancy vynálezech. Zažil jsem i tým, kde efektivně fungoval waterfall s minimem komunikace mezi členy týmu. No a týmů, kde naopak nefungoval SCRUM jsem viděl už několik ;-)

"zitra rano jdu k doktoru, tak prijdu dyl".

Nech mě hádat, dýl místo později -> Plzeňák? :-)

"k doktoru" je taky typické pro Plzeň a okolí. Už chybí jenom "tuten".

[Exceptions]

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í

typický korporátní způsob to je ale jen v posledních letech, kdy to frčí i v korporátech a zatím jsem v českém prostředí neviděl správně použitý scrum, hlavně, že mají svoje "kmeny".

Pokud vývojáři ví co mají dělat, je asi super je nechat se organizovat samostatně, pokud ale potřebuješ každý dva týdny zadávat podrobně úkoly vývojářům a potřebuješ přesně kontrolovat (a dále procesovat) jejich výstupy, moc dobře to nefunguje, nemusíš se totiž potkat.

Asi bych to negeneralizoval, zkazit se dá každý proces jeho špatnou volbou nebo nedůslednou implementací. Self organised team není zrovna nejlepší, pokud třeba máš QA, potřebuješ zaškolit uživatele a podporu, musíš přetisknout brožury a materiály.

Naopak například při implementaci CI/CD, logávání, monitoringu, IPS/IDS či jiných vyloženě technických věcí je využití scrup, daily stand up většinou naprostá katastrofa a self organized team, který spolu stejně komunikuje celý den, nejlepší. Ta ty úkoly není možné často tak rozsekat do sprintů, není možné úkol označit za dokončený, když existují cyklické závislosti, hodně času se zabíjí vůbec vysvětlování terminologií a fungováním scrum masterovi/product ownerovi atd.

[nehalem]

Naopak například při implementaci CI/CD, logávání, monitoringu, IPS/IDS či jiných vyloženě technických věcí je využití scrup, daily stand up většinou naprostá katastrofa a self organized team, který spolu stejně komunikuje celý den, nejlepší. Ta ty úkoly není možné často tak rozsekat do sprintů, není možné úkol označit za dokončený, když existují cyklické závislosti, hodně času se zabíjí vůbec vysvětlování terminologií a fungováním scrum masterovi/product ownerovi atd.

A co pripad, ked v jednom tyme su vyvojari, ludia co riesia buildy, CI/CD, infrastrukturu atd.? To hovorim z vlastnej skusenosti, nevymyslam si. A co ked to dokonca rotuje sprint od sprintu, ze kazdy robi vzdy nieco ine bez navaznosti a vzdy sa adhoc "nauci" (Stack Overflow + CTRL-C/V) danu vec a potom to bude robit zas za 10 mesiacov? Co take firmy a tymy?

[e3k]

ne nemaju.

je to vymysel na zvysenie produktivity aby bol clovek nuteny stale pracovat aj ked sa mu nechce. v podstate ale treba vediet kazdy den obkecat co najkvetnatejsie co clovek robil/nerobil. tak som to videl fungovat vo vela firmach. suma sumarum strata casu. kto sa chce flakat bude to vediet aj v Agile az na to ze denne spravi to divadielko standup.

[Reklama]

[sofa_king]

Tvle jestli je tohle realita korporátního IT v středoevropské Indii, ehm. ČR, tak to by se mělo dát v popisku práce slovo "lopata" přímo do titulku.

To ani nevypadá, že jste programátoři, ale nějaký ozubený kolečka, který drží tu firmu v chodu. Odejdeš a najde se nový kolečko jako náhrada.

Úkol programátora tak nějak vždycky mělo bejt manažerem - strojů, počítačů. Místo toho ty stroje udělali z vás a manažíruje vás tam nějakej ulíznutej čerák. Akorát vás programuje v Excelu a JIŘE, místo v Cčku.

[Jen tak]

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"

Lidi, co dělají neorganizovaně na něčem, co není ve sprintu, jsou peklo ... člověk pak něco releasuje a nestačí se divit, co tam nějaký hyperaktivní trouba zas naprgal ...

Nejlepší jsou kutilové, co "nad rámec" sprintu zrefaktorujou půlku projektu, a člověk pak žasne, proč se v testech chovají věci, na které nikdo neměl sahat, najednou úplně jinak.

a ad standup - je to čistě o tom, jak se k nim postaví skrumík - není to o korporátnosti ani o ničem jiným, je to jenom o lidech. a přístupu.  zažil jsem projekty, kde jsme standupy neměli (nebyly potřeba, řekli jsme si to jinde), zažil jsem proejkty, kde standupy byly totálně zabitej čas, a zažil jsem projekty, kde na standupu bylo 15 lidí a i tak byl standup za 10 minut hotovej.

a jak tu někdo zminoval hodinový standupy - to je přesne ukázka nezvládnutýho standupu (resp. to není standup) - standup je záležitost na půl minutu / osoba. na standupu se nemají probírat do detailu další věci (např. pokud má někdo zásek, tak se nemá rozebírat, proč má zásek - to je záležitost k dořešení až po standupu).

[Jen tak]

Naopak například při implementaci CI/CD, logávání, monitoringu, IPS/IDS či jiných vyloženě technických věcí je využití scrup, daily stand up většinou naprostá katastrofa a self organized team, který spolu stejně komunikuje celý den, nejlepší. Ta ty úkoly není možné často tak rozsekat do sprintů, není možné úkol označit za dokončený, když existují cyklické závislosti, hodně času se zabíjí vůbec vysvětlování terminologií a fungováním scrum masterovi/product ownerovi atd.

proč by při implementaci zmíněných aktivit neměl mít standup smysl? má smysl úplně stejně , jako při jikakémkoli jiném vývoji - pokud to je opravdu standup, a ne "standup".

na standupu NIKDY NEVYSVĚTLUJE  scrummásterovi, nebo product ownerovi. pokud tomu tak je, tak je to špatně.

[L..]

Lidi, co dělají neorganizovaně na něčem, co není ve sprintu, jsou peklo ... člověk pak něco releasuje a nestačí se divit, co tam nějaký hyperaktivní trouba zas naprgal ...

Nejlepší jsou kutilové, co "nad rámec" sprintu zrefaktorujou půlku projektu, a člověk pak žasne, proč se v testech chovají věci, na které nikdo neměl sahat, najednou úplně jinak.

A jak mu to prošlo přes code review?

[alex6bbc]

Lidi, co dělají neorganizovaně na něčem, co není ve sprintu, jsou peklo ... člověk pak něco releasuje a nestačí se divit, co tam nějaký hyperaktivní trouba zas naprgal ...

Nejlepší jsou kutilové, co "nad rámec" sprintu zrefaktorujou půlku projektu, a člověk pak žasne, proč se v testech chovají věci, na které nikdo neměl sahat, najednou úplně jinak.

A jak mu to prošlo přes code review?

[tomas88]

To ani nevypadá, že jste programátoři, ale nějaký ozubený kolečka, který drží tu firmu v chodu. Odejdeš a najde se nový kolečko jako náhrada.

A co delas tak svetoborneho ty? Klidne 90% programatoru jen udrzuje neco v chodu. Tak to proste je.

[to_je_jedno]

Standup smysl ma pokud se cely agile dela tak nejak spravne. bohuzel vetsinou je to znasilnene, nekteri klienti si chteji popovidat jak venci psa apod.

[kanoe22]

Osobna skusenost, robim na niecom dva sprinty (4tyzdne dokopy), v piatok hotove, ale uz bolo neskoro, a nechcelo sa mi to raz znovu prebehnut pred dorucenim zmien, tak reku urobim to v pondelok. V pondelok to prebehnem, ok, vsetko fajn, dam to este raz buildnut pred dorucenim, a vidim ze sa to ani nebuilduje. Pri kontrole zistim, ze iny tim dorucil v NEDELU!! velky balik zmien o ktorych nikto nebol absolutne informovany. Pritom to mali ako oficialnu sucast sprintu, nebolo to ze by sa niekto nudil a prerobil to lebo nema do coho ineho pichnut, ale aj tak vsetci ktory mali nieco rozrobene a zaviseli na ich komponentach z toho boli v pondelok vyhukany. Ja som potom musel moju robotu urobit skoro od nuly (trvalo to dalsie dva tyzdne, pretoze ten druhy tim zrefaktoroval asi 10 komponentov, z ktorich na 5tich som bol zavisly s mojou robotou).

Niekedy to nie je len o iniciativnom blbcovi, ale je aj o zlyhanej komunikacii medzi timami, takze to ze tu niekto do neba vydzvihuje self organized tim, je kratkozrake. Nieco take moze fungovat na projekte kde vas je 5 a pol aj so scrum masterom a product ownerom. Su projekty kde kazdy sprint prezentujete priamo zakaznikom vysledky, co noveho je implementovane. Tam by tento model asi velmi tazko obstal. takze snahy niektorich tu presadit nejaky model lebo "ja v tom pracujem, je to najlepsie na svete, vsetko ostatne je sr.cka" je akurat tak ukazkou nafukanosti a debility danich ludi. Kazdy jeden princip organizacie prace je urceni pre nieco, ale nie pre vsetko naraz. Nic univerzalne proste neexistuje.

AD standup a jeho trvanie: zazil som aj kratke efektivne standupy, kde kazdy povedal v skratke co robil vcera, co planuje dnes a islo sa dalej. Ak mal niekto problem, povedal mam problem, v skratke ho popisal, na standupe sa vacsinou rovnou niekto ponukol kto na to pozrie, pripadne SM niekoho urcil kto by to mohol vediet (SM ma mat prehlad o skusenostiach/skilloch jednotlivych ludi). Standup trval pri 10tich ludoch 10-15minut.
Zazil som ale aj skoro hodinove standupy (priemer 30minut, rozptyl vacsinou 20-45 minut, 10ludi v time), kde ak vsetko islo hladko, standup trval do 15minut (velmi vynimocne). Vacsinou mal niekto s niecim problem (projekt plny stareho bordelu ktory nikto nemohol upratat lebo to niektory zakaznici stale pouzivali, bol problem implementovat nieco nove aby sa nieco stare nepos.alo), tak standupy trvali dlho, ale to kvoli tomu ze ludia tam proste rozoberali problem a snazili sa na to najst riesenie na standupe. Vacsinou bol standup ukonceni az v momente ked uz to niekomu liezlo na nervy a povedal ze toto na standup nepatri.

Tvle jestli je tohle realita korporátního IT v středoevropské Indii, ehm. ČR, tak to by se mělo dát v popisku práce slovo "lopata" přímo do titulku.

To ani nevypadá, že jste programátoři, ale nějaký ozubený kolečka, který drží tu firmu v chodu. Odejdeš a najde se nový kolečko jako náhrada.

Úkol programátora tak nějak vždycky mělo bejt manažerem - strojů, počítačů. Místo toho ty stroje udělali z vás a manažíruje vás tam nějakej ulíznutej čerák. Akorát vás programuje v Excelu a JIŘE, místo v Cčku.

Tiez ma zaujma co take svetoborne robis. Programujes stroj casu? Pracujes snad na nadsvetelnom pohone? Robis nanotechnologie pre Tonyho Starka? Mas za ulohu urobit prekladac mimozemskeho <-> pozemskeho jazyka? Prides mi akurat tak ako velky nafukanec, ktory si mysli ze zozral celu mudrost sveta a cely vesmir sa toci prave okolo teba.

Standup smysl ma pokud se cely agile dela tak nejak spravne. bohuzel vetsinou je to znasilnene, nekteri klienti si chteji popovidat jak venci psa apod.

Zakaznik na standup nepatri. Ktokolvek, kto nema v titule svojho kontraktu napisane developer, architekt, scrum master alebo product owner, nema co na standupe robit. Standup je cisto pre potreby timu, nikoho ineho. Zakaznik ma byt na review, lebo tam mu tim prezentuje co je noveho. Inak ma komunikovat iba s product ownerom, pretoze on je prostrednik medzi zakaznikom a timom. On si ma zakaznika vypocut, vybrat z toho podstatne a "prelozit to do reci developera" nech sa to implementuje.

[Jen tak]

Zakaznik na standup nepatri. Ktokolvek, kto nema v titule svojho kontraktu napisane developer, architekt, scrum master alebo product owner, nema co na standupe robit. Standup je cisto pre potreby timu, nikoho ineho. Zakaznik ma byt na review, lebo tam mu tim prezentuje co je noveho. Inak ma komunikovat iba s product ownerom, pretoze on je prostrednik medzi zakaznikom a timom. On si mi zakaznika vypocut, vybrat z toho podstatne a "prelozit to do reci developera" nech sa to implementuje.

product owner se v 99% případů běžného zakázkového vývoje = zákazník

[kanoe22]

Zakaznik na standup nepatri. Ktokolvek, kto nema v titule svojho kontraktu napisane developer, architekt, scrum master alebo product owner, nema co na standupe robit. Standup je cisto pre potreby timu, nikoho ineho. Zakaznik ma byt na review, lebo tam mu tim prezentuje co je noveho. Inak ma komunikovat iba s product ownerom, pretoze on je prostrednik medzi zakaznikom a timom. On si mi zakaznika vypocut, vybrat z toho podstatne a "prelozit to do reci developera" nech sa to implementuje.

product owner se v 99% případů běžného zakázkového vývoje = zákazník

To sice moze byt pravda, ale on ako product owner by mal mat proste nejaku sudnost a vediet co na ktory miting patri a nepatri. Ako hej, z pohladu developera je PO pre teba zakaznik, lebo on urcuje co treba. Realny zakaznik (zakaznici) su skryti za nim (ti od ktorich tecu peniaze). To ale nemeni nic na fakte, ze ako PO ma byt oboznameny so systemom prace v time a nemal by na technicke mitingy miesat vencenie psa. Ok ak raz zacas padne na standupe aj ina tema ako len robota, moze to prispiet k uvolnenejsej atmosfere a clovek sa neciti ako robot, ale nie to tam mixovat nasilu a natahovat s tim mitingy.

Ak sa to deje pravidelne, tak mu proste nejak slusne vysvetlit ze toto ne.