Daily stand-upon ...

 ( Hevi | 2018. augusztus 13., hétfő - 11:13 )
... odafigyelek és folyamatosan követem, hogy melyik kolléga min dolgozik
26% (59 szavazat)
... figyelgetek, kulcsszavakra reagálok, de gyakran elkalandozom, nem követem szorosan, hogy a kollégák mivel foglalkoznak
31% (70 szavazat)
... egy-két kollégára odafigyelek és tudom mit csinálnak, a többiekre kevésbé/egyáltalán nem
17% (39 szavazat)
... elmondom a mondókámat, a többieké nem érdekel; nagyjából fogalmam sincs, hogy a kollégáim mivel töltik napjaik
5% (11 szavazat)
Egyéb, leírom
21% (47 szavazat)
Összes szavazat: 226

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros."

Na és ezt mikor akarja felvetni, ha nem a standup végén?

"How often have you had to advocate spending an entire sprint tackling tech debt?"

Milyen jellegű technical deptekről van szó? Elmaradt tesztek? Na de akkor nincs kész a task. Refactoring kell? Általában azért lehet rá keríteni időt, ha nagyon kell valamilyen backlog keretén belül - pl. egy kiadós refactoringgal kezdeni ott, amikor hozzá kell nyúlni valamit. Egyébként egyre inkább arra jutok bizonyos esetekben, hogy kéne refactorálni, mert szebb lenne a kód, de valójában minek? Hozzáadott értéke nincs, csak egy szubjektív szépségérzet, cserébe ott van egy biztosan jól működő, tesztelt, akár productionban lévő kód. If it ain't broke, don't fix it.

Másrészt, Spotify esetén egyszerűbb a helyzet, hiszen ott nincs olyan külső nyomás, hogy mit fejlesszenek, mikor, mint pl. egy megrendelésre készült szoftver esetén. Mi is terméket fejlesztünk, de van mögötte megrendelő, aki elvárja, hogy teljesítsünk. A megrendelők meg általában örülnek annak, hogy ha van valami látható haladás. Bérfejlesztésnél ez különösen igaz.

Harmadrészt, nálunk nem egyszer volt már olyan, hogy a szomszéd csapattal egy-egy standupon elejtett megjegyzés kapcsán kiderült, hogy az előző planningen megtervezett dolgok felét át kell tervezni. Nem tudom, hogy milyen a hangulat a Spotifynél, de a standupot én eddig nem úgy kezeltem, mint egy bunkósbot, amivel a fejlesztőket ütik, hogy vajon dolgoznak-e, hanem, mint egy platform, ahol képet tudok kapni, hogy hogy áll a csapat vagy a szomszéd csapat. (Bizonyos okok miatt egyik csapattal összevontan tartjuk a standupot. Mondjuk volt már egy másik csapatban lévő kolléga, aki megjegyezte, hogy addig ameddig a mi sorunknál ült tök jó volt, hogy hallotta a standupunkat, mert addig legalább képben volt azzal, hogy mit csinálunk.)

Mondjuk retrot tényleg akkor érdemes tartani, ha van is miről.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Egyébként egyre inkább arra jutok bizonyos esetekben, hogy kéne refactorálni, mert szebb lenne a kód, de valójában minek? Hozzáadott értéke nincs, csak egy szubjektív szépségérzet, cserébe ott van egy biztosan jól működő, tesztelt, akár productionban lévő kód. If it ain't broke, don't fix it."

Nincs hozzaadott erteke? Majd kevesebb idot kell eltolteni vele, amikor bugot kergettek, mert konnyebben ertheto, illetve fenntartja es osztonzi az igenyesseget, lasd broken windows theory. A szepsegerzet szubjektiv, de egy mindenki altal ismert, reszletes coding style azt is ossze tudja hangolni, es szepsegerzeten tul ott az erthetoseg, ami ugyancsak szubjektiv lehet valamennyire, de kell ra figyelni, de leginkabb mar elso code review-ban, de megtortenhet pl., hogy ott szuletnek a javaslatok, ami alapjan kesobb refaktoraljak.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Egy szóval nem mondtam, hogy csapjuk össze és kódojunk igénytelenül. Azt már code reviewkor vissza kell dobni a francba. Azt mondom, hogy időnként fejlesztőként hajlamosak vagyunk elveszteni a célt a szemünk elől és l’art pour l’art refactorálgatni egy egyébként jól működő, kitesztelt kódot.

Ahelyett, hogy legközelebb ténylegesen akkor nyúlnánk hozzá, amikor arra szükség van.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem azért refaktorál az ember hogy szebb legyen a kód, az csak az egyik szempont. Sokkal inkább azért hogy a fölösleges bonyolításokat kiírtsa, újra felhasználható legyen stb. hasznos szempontok. Legtipikusabb eset mikor ki kell emelni egy ősosztályt vagy átalakítani egy metódust/fügvényt hogy általánosabban használható legyen, esetleg felfedezed hogy az új funkció amit be kell építeni a meglévő kóddal már egy design patternért kiált. Az hogy szép meg olvashatóbb az már csak hab a tortán.

===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

>> "Why do we encourage problems to be discussed once a week? We should address them immediately, not just at retros."
> Na és ezt mikor akarja felvetni, ha nem a standup végén?

Mi például egy landscape-ben ülünk, és standupon kívül is beszélünk egyással. ;)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Szerintem az a lényeg amit ír, hogy ez egy tool kellene, hogy legyen, amit ha van értelme az adott projectben, helyen, akkor lehet alkalmazni. De az, hogy jön egy menedzser alig lát bele igazból, a feladatok megvalósításába és ráhúz egy merev módszertant annak nem lesz vége, mert esetleg csak lóg majd az egész fölött.

Amit hiányolok a cikkből, hogy a fickó nem nagyon számol pl motivációs, meg mindenféle fókusz problémákkal, hanem a team az figyelem elveszések nélkül teljes tűzzel gyalulja amit kell.

Szerintem meg nem tool kérdése az, hogy egy kisebb csoport par percben osszefoglalja, hogy mit haladt és mit tervez. Ha a foszernal ez nem ment az implementacios hiba.

Meg azt sem tudom elfogadni, hogy mennyire kizokkento. Általában a standup negyed-fel órával a hivatalos munkakezdes után van. Az vagy a reggeli KV-ra jo vagy arra jo, hogy valaki fellapozza az előző napi commit logot, hogy mit csinált.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

mondok egy példát: ha a csapat tagjai épp lényegében egyéni feladatokat oldanak meg, akkor semmi értelme nem lesz, hogy naponta elmesélik egymásnak mit csináltak, ilyen esetben be fognak jönni azok a dolgok, hogy senki nem figyel oda, mert nincs is értelme. nem is érti a másik problémáit és nem is akarja érteni. ilyen esetben jobb amit a fickó ír, hogy mindenki veszi le a feladatokat a backlogról és csinálja.

ha a cégnél rugalmas munkavégzés van, akkor nem lehet reggelre rakni a standup-ot, mert a csapat egy része bent sincs.

Pont az az értelme, hogy tudj róla, hogy mi történik a többi csapat többi tagjával meg a projekttel. Nyilván azokat rakják egy csapatba, akik egyazon projekten dolgoznak.

Nálunk pl. pont ezért van együtt két csapatnak a standupja, mert a mi servicenket használja a másik csapat (pici, 2 fő) és időnként tesznek megjegyzéseket arra, hogy mit hogyan kellene. Nyilván nem csak standupkor, viszont hasznos az, hogy van egy formalizált módja, ahol ők is hallják, hogy mi merre haladunk meg mi is halljuk, hogy valószínűleg nekünk merre kell majd még továbbhaladni. Illetve van egy közvetlen feedback is és nem 3 csapatvezető és hasonló felesleges rétegen keresztül jön.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

de a cikk nem azt kérdőjelezi meg, hogy nálatok jól működik. hanem azt, hogy ez egy automatikus valami kellene, hogy legyen. csak annyit mond, hogy legyen maga az mérlegelés kérdése, hogy kell e. ad e valamit tényleg.

Szerintem rossz a csapat alapvető működése, ha ehhez kell egy formalizált stand up meeting. Ha én reggel tudom meg, hogy a mellettem ülő 5-8 kolléga közül valaki egész nap egy helyben kapart, akkor ott komoly problémák vannak, mert vagy a WTF/óra "kijelzése" gyenge vagy a WTF/óra "érzékelése" gyenge.

Miért gondolkozol ennyire végletesen? Senki nem mondta, hogy csak és kizárólag standupon kommunikálnak egymással az emberek és, hogy ha valaki elakadt, akkor tilos a másikhoz szólni. Viszont, ha valaki elkezd WTF-eket szórni, akkor nem kell, hogy egyből bevonja mind a 8 másik kollégát is.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Miért gondolkozol ennyire végletesen?"

Mert tapasztalataim szerint ekkor működik a dolog.

"Senki nem mondta, hogy csak és kizárólag standupon kommunikálnak egymással az emberek és, hogy ha valaki elakadt, akkor tilos a másikhoz szólni."

Sok helyen ezt tapasztaltam. Sok helyen nem is egy kupacban dolgoznak a csapattagok.

"Viszont, ha valaki elkezd WTF-eket szórni, akkor nem kell, hogy egyből bevonja mind a 8 másik kollégát is."

De, be kell vonja.

"De, be kell vonja."

Miért?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Azért, mert ezzel jönnek a megoldások.

Tudod, napi szinten van olyan, hogy a frontendes nekiáll bazmegolni, hogy már egy órája szopik valami nyomorult aprósággal, amit a product owner, a backendes vagy az üzemeltető is simán megold egy vessző áthelyezésével és teljes a boldogság. Ha ez csak másnap derül ki, az minimum egy egész elveszett embernap, de könnyen lehet, hogy egy egész elveszett csoportnap. Nem szabad megengedni azt a luxust, hogy nem használja ki a csapat a cross-competence lehetőségeit és azt, hogy szinte minden rugalmas.

Szóval ha valamivel szopsz, akkor a lehető legjobb megoldás az, hogy felteszed a kezed, hogy "srácok, én már egy órája szopok ezzel, nem látom a végét, nézzetek már rá ti is" és sokszor öt perc alatt van rá megoldás. Lehet, hogy a frontendes problémára egy üzemeltető ad megoldást, mert olvasott valamit valahol... ez az erőssége az agilis fejlesztésnek, a konkrét módszertan csak tüneti kezelés és a formalitás betartás meg faszság.

Akkor félreértettük egymást több fronton. Ha a valaki szop, akkor tök természetes, hogy kér segítséget. Én azt mondtam, hogy az a nem természetes, hogy akkor mind a 8 másik embert is odarángatja. Ha a három közül egyvalaki is elég a vessző áthelyezéshez, akkor nem kell bevonni mind a 3-mat.

És a daily standup nem arról szól, hogy akkor másnapig kuss van.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Ha a három közül egyvalaki is elég a vessző áthelyezéshez, akkor nem kell bevonni mind a 3-mat."

A baj az, hogy nem tudod előre, hogy a nyolcból melyik három az, akinek éppen van ötlete és a háromból melyik lesz az az egy, akinek megoldása is lesz rá.

"És a daily standup nem arról szól, hogy akkor másnapig kuss van."

Nem, nem azt jelenti... de ha van rendes kommunikáció és információ áramlás, akkor semmi újat nem tudsz meg a daily stand up meeting-en.

A daily standup valójában egy minimumkövetelmény.
A csapat ideálisan egy légtérben melózik, kevésbé ideálisan folyamatosan online elérhető és egy perc alatt összerak egy videokonferenciát képernyőmegosztással.

A daily standup legnagyobb jelentősége a scrum-ban kezdő csapatoknál van, hogy szokják a transzparenciát.
Jó esetben kialakul egyfajta csoportnyomás is ami húzza a lustábbakat és felzárkóznak. Rossz esetben a lustákon meg fog látszani hogy lusták és le lehet őket cserélni.

--
Gábriel Ákos

Sok helyen már nincs olyan, hogy hivatalos munkakezdés, csak törzsidő, ami kb a nap közepe, és mivel elvileg csak a törzsidőben vagy köteles ott lenni, így a standup is oda kerül. A csapat egy fele akkor esik be, a másik meg már bent ücsörög 2-4 órája.

Na, itt kezdődik az agilitás, hogy pl. 1-2 sprint után a csapat felveti-e, hogy esetleg mindenki próbáljon meg bejönni 9-re standupra (és ha nem sikerül akkor elküldi mailben a 3 sorát és valaki felolvassa, vagy betelefonál a telkóba). És akkor a csapat dönt úgy, hogy bejön, saját elhatározásból, a projekt érdekében, nem a management.
Láttam ilyet, működik.

Továbbá akkor sincs baj ha valaki 1-2 standupot elmulaszt, senki nem veszi le a fejét. Elnézést kér, küldi a 3-sorost, és ennyi.
Ezt a pszichoszociális biztonságot kell tudni megteremteni, és ez többek között a SM dolga.

A fentit pl. vagy tudja a SM mert járt képzésre vagy baromi jól utánaolvasott, vagy nem. Ha nem tudja, az nem a módszer hibája.

--
Gábriel Ákos

az a baj, hogy ez nem így megy, mert akinek nem úgy van kialakulva az alvás ciklusa, az ha bemegy korábban akkor az jellemzően minusz alvás órák. ami meg jó eséllyel érződik az egész napon.

Uhh ezt a dumát :) Az munkahelyek úgy fognak járni, hogy azokon kívül, akiknek önszántukból is reggel járnának vagy gyereket kell cipelni csak az fog ott dolgozni, akinek nem jut jobb hely.

Uhh olvasd el még egyszer. A kulcsszó: csapatdöntés.
Ha többségben vannak a huszonévesek akik imádnak délig aludni cserébe hajnalig kódolnak, akkor nekik kedvező lesz a döntés. Ha többségben vannak a negyvenesek akik 9-17-ig dolgoznak akkor meg nekik lesz kedvező.

Ha fele-fele akkor meg kötnek egy kompromisszumot.
Egyébként én már csináltam ilyet és a csapatom huszonéves tagjai is képesek voltak akár ágyból betelefonálni a reggeli standupra vagy elküldeni mailben a háromsoros státuszt. És ha elmulasztotta valamelyik akkor se szabtam le a fejét.

--
Gábriel Ákos

igen azt imádom, amikor a gyerekes, akinek emiatt muszáj elindulni korán mert viszi a gyereket és akkor már bemegy korán, azt mondja, hogy ha ő be tud érni, akkor más is megtudja csinálni. pfff :D

Csak az eredmény érdekel :)

--
openSUSE - KDE user

Amikor meg van beszélve, hogy mindenkire három perc jut, én tartom is, de egyes "bőbeszédű" kollegák összesítve mintegy 20-40 percet képesek beszélni, akkor már kevésbé tud érdekelni a mondókájuk.

Pláne, mikor a fél csapat nem is érti, hogy miről beszél. :|

Akkor ott baj van a scrum masterrel - le kéne állítsa őket.
De a csapattal is, mert ennek az első retrón fel kéne jönnie és aztán le kéne szokni róla.

--
Gábriel Ákos

Hasonlót már én is tapasztaltam... Egy ilyen annyira meg tudja ölni a napot, hogy friss levegő, meg valami koffein tartalmú fekete italra is szükség van a rebuildhez.

Akkor az nem standup, hanem egy vicc.
Nalunk standupon 1 perc per fo volt a szabaly, aki tullepte annak vennie kellett valami ragcsalnivalot es bedobni a kozosbe.

korrekt :)
--
Gábriel Ákos

+1, tetszik

Bullshit bingo:

https://www.bullshitbingo.net/

--
trey @ gépház

Szerény véleményem szerint faszság, de ha már van, akkor odafigyelek rendesen.

+1

nincs daily stand-up

Volt, de az érdektelenség miatt áttértünk a hetire :)

Ezt már a többség hasznosnak érzi.

A csávó kidobta a scrummot és kanbant csinál. A kanban akkor működik jól ha a product management megfelelően bontott taskokkal tölti meg a backlogot. A csapat részéről sokkal nagyobb rutint és fegyelemt kíván. A daily standup segít megtartani a fókuszt.
===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

[x] mi az a daily stand-up? Ez a (stáb)értekezlet trendi neve?

Nem, ez a tűz melletti törzsi gyűlés trendi neve, csak többnyire inkább reggel tartják.

_______Peter
I am a stone. I do not move.

Reggeli (már akinek ugye, a lényeg hogy mindenki jelen legyen) megbeszélés, hogy szinkronba kerüljön a teljes csapat. Minél rövidebb, annál jobb. Témák:
- Ha van valami szokatlan / sürgős dolog, azt a lead szóban is hangsúlyozhatja + esetleges csapatot érintő dolgokkal kapcsolatos tájékoztatás.
- Mit csináltál tegnap, hogy haladtál vele.
- Mi a terved mára.

Egyeb.

Mindig talalok valami ertelmesebb feladatot a meetingek idejere, az evek folyaman rajottem, hogy az ilyen osszeruccanasok 90 szazaleka idopocsekolas.

Nézd, vagy te nem tudod, mi az a daily stand up meeting vagy a többiek sem.

Kutya, vagy eb. Mi a kulonbseg?

Q.E.D. :)

Hat akkor vilagosits fel engem.

Engem is néha megpróbálnak felvilágosítani, de mivel közben programozgatok tovább...

[x] mindig "orom" olyan faszkalapokkal kollegakkal együtt dolgozni, akik egy alapvető google keresést sem tudbak megejteni de a fassagot meg tudjak mondani nagy pofaval.

Szóval a standup nem meeting, es minden normális helyen szigorúan timeboxolt beszamolo, hogy ki mit csinált, mi a napi terve es blokkolja-e valami. Minden mas nem daily standup.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Huhh, ez aztan a produktiv idotoltes.

https://upload.wikimedia.org/wikipedia/commons/thumb/4/4a/Daily_sprint_meeting.jpg/1280px-Daily_sprint_meeting.jpg

Koszonom a kioktatast. Stand upoljatok tovabb, nem lennek amugy sem melto ilyen okosokkal mint te egy korben lenni.

Ennek olyan micromanagement szaga van. Szerencsere van hasonlitasi alapom a jelenlegi munkahelyemen, hogy milyen rossz hatassal tud lenni a micromanagement a teamre.

Sajnálom, hogy ilyen rossz élményeid vannak a Scrum-mal kapcsolatban.
Ennek legvalószínűbb oka, hogy előképzettség nélkül álltak neki nálatok Scrum-al próbálkozni és ezért egy csomó hibát elkövetnek, valószínűleg anélkül hogy tudnának róla.

Ami teljesen biztos: a Scrum-nál szó nincsen micromanagementről.
Önszerveződő, érdeklődő, kommunikatív emberek közös munkájáról van szó.
Akik egy célért, a projekt sikeréért dolgoznak.

A Scrum masternek pedig alapfeladata mindenféle menedzsment befolyás elhárítása.

--
Gábriel Ákos

Mégis mit vártál egy ilyen felütés után, amivel gyakorlatilag azt kommunikáltad, hogy fingod sincs miről van szó, de azért megmondod a tutit?

Pont, hogy nincs mikromenedzsment benne. Arról szól, hogy mindenki elmondja 1-2 percben, hogy mit csinált és mi a terve a következő napra és, hogy van-e valami, ami blokkolja, a csapattagoknak. Nem egy vezetőnek, mert nincs kinevezett csapatvezető és hasonló baromságok. Már az is teljesen szabadon alakuló, hogy ki min dolgozik, nincs egy felesleges projektvezető, aki mikromenedzselgeti a csapatot.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Csak nem mindegy, hogy adott cégnél ki számít csapattagnak. Voltam olyan helyen, ahol scrummaster önálló munkakör volt, 2-3 csapattal, délután ment jelenteni a management felé. Másiknál meg egyenesen a projectmanager volt SM, és ment az email a megrendelőnek minden egyes után.

Nem ezt vartam.

Mindig feltalálnak valami progresszív újítást, majd az lesz a progresszív, ha nem csinálják tovább.

A kezdetekben volt heti. Nagy élmény volt hallgatni, hogy a grafikusok egy teljesen más projektben mit csinálnak. Mivel abszolút nem érintett így a dolog igazi időpocséklás volt.

Most egy szünet után daily standup van amiből valami titokzatos ok miatt engem kihagynak újabban. Mikor még nekem is kellett résztvenni rajta olyan volt, mint kisiskolás koromban a felelés.

Mit csináltál tegnap, mit fogsz és akadályoz-e ebben vmi... blöa.

Tapsztalatom szerint 3 fajta programozo van:

Aki latott mar normalis stand upot, ahol mindenki felfogta, hogy az kulcsszavas, <1 perces beszedeket takar, es szereti

Aki latott mar szopasszianszt nem megtorlo minden reggel lezajlo meetinget "standup"-nak hivva, ami akar egy oraig is elhuzodik es vitakkal teli, es gyuloli

Aki talalkozott az utobbival, azt utalja, de felfogja, hogy az elobbi amugy mukodik/mukodne

kérdés van e értelme a rövid stand upoknak. elősegít e valaki vagy üres formalitás. és ez az adott szituációtól függ függeni. az nem érv önmagában, hogy rövid. hiába mondaná el röviden a pék, aki a kiflit süti, hogy mit csinált és milyen gondjai vannak, ha nem kapcsolódom szervesen a feladataihoz. pontosabban max ilyen blikk szintje le.

1, Ha ott vagy a stand up meetingen, akkor azért vagy ott, mert kapcsolódsz a többiek feladatához.
2, Ha nem kapcsolódsz egyáltalán, akkor nem vagy ott.

Ha annak ellenére ott vagy, hogy semmi közöd a feladatukhoz, akkor ott komoly gondok vannak.

+1

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

de ez a kapcsolódás ez nem biztos, hogy szervesen közös munka jellegű. lehet mindannyian ugyanazt csináljuk sacc. de mivel nagy a funkcionalitás kiterjedtsége és összetettek a részproblémák, igazából egy ember merül el a magáéban és nem ad neki semmit, hogy a másik ma mit csinál, meg tegnap mit csinált. mert párhuzamosan dolgoznak valamiken, nem nagyon érnek össze, hiába más szempontból egy csapatot alkotnak.

szerintem ez a scrum akkor lesz értelmes, ha a szállítandó dolog az ténylegesen közös produktum. ha egy prototípus van a végén. ha egy dolgot kell demozni majd közösen. ha a csapat azért egy csapat csak, mert ugyanazon a területen dolgoznak pl. akkor nem biztos, hogy van értelme. de a lényeg itt nem az, hogy tuti van értelme vagy tuti nincs. hanem, hogy ez ne egy szentírás legyen, amit fentről bevezetnek, mindentől függetlenül, hanem a tényleges feladatokhoz csapathoz választható tool legyen. a cikk arról szól, hogy az adott helyzetben javulást hozott bizonyos elemek elhagyása. következtetés: van amikor jobb. ha van amikor jobb, akkor ezt mérlegelni jó. nem automatikusan követni.

másképp megfogalmazva: az állítás az, hogy ha a scrum elemei egy merev, az adott körülményektől független elemmé válnak, akkor csökkenhet az agilitás. hiába ennek az elősegítése lenne a cél. és ami a végső érték.

"ha a csapat azért egy csapat csak, mert ugyanazon a területen dolgoznak pl. akkor nem biztos, hogy van értelme."

Ahol azért van fejlesztői daily stand up meeting, mert mindenki fejlesztő, ott komoly gondok vannak az agilis módszertanok megértésével kapcsolatban...

ha ugyanazon a backlogon dolgoznak, akkor simán lehetnek egy csapat. csak az, hogy mennyire szervesen kapcsolódnak a backlog elemei azok pl meghatározhatják, hogy milyen jellegű kommunikáció a hasznos. (amúgy a hozzászólásokban ír még sok részletet, hogy hogyan dolgoznak. és használnak elemeket csak kicsit másképp, ahogy nekik megfelelőbb. és változtatható, hogy épp mi a jó. milyen jellegű kommunikáció kell)

a lényeg, hogy a tényleges feladatokhoz, tevékenységhez idomuljon a módszertan. és ne egy módszertanba gyömöszöljük bele bármit is kell megvalósítani.

"ha ugyanazon a backlogon dolgoznak, akkor simán lehetnek egy csapat."

Nem a backlog határozza meg az agilis csapatot, hanem az, hogy mennyire függnek egymástól. Ha a backlog egy csomó egymástól teljesen független problémát tartalmaz, akkor vagy a backlog szar vagy pedig a feladat nem backlog kompatibilis. Nem kell és nem lehet mindent agilis keretek között csinálni.

Voltam már olyan helyen, ahol volt értelme.
Ott pl. el tudtuk mondani, ha valaki belefutott egy ordas sz..ásba, kulcsszavakban. Kulcsszavakban, hogy találtad meg, mi volt a megoldás / tanulság. (Így ha valaki belefutna ugyanabba, akkor tudjon róla.)
És egymást a gyors kulcsszavakból is megértettük. A retro meg jó volt arra, amikor ugyanezt a másik csapattal kellett összehangolva valami permanensebb megoldást adni.

Ez olyan mint a kommunizmus, ott sem az elmélet a hibás, csak az összes eddigi megvalósítás.

... fogalmam sincs mi az, de már a tököm kivan vele, hogy minden f*szságra kitalálnak egy trendi ámerikái szót.
--
"Sose a gép a hülye."

Ami neked van arra is kitalálták már az "amerikai szót" :D

--
Gábriel Ákos

Volt egy projektem: tiszta maintenance, szerte ágazó hibajegyek, hatalmas projekt, a management erőltette ránk a daily standupot, ami a 20 fővel legkevesebb 30 percig tartott, ha senki nem kalandozott el. Ezt leszorítottuk heti 1-re, és mindenki örült, a management is, hogy milyen agilisak vagyunk - én csak sírtam hátul, mert az agile manifesto mind a 12 pontját teljesítettük a standup ránkerőltetése előtt, utána jó, ha a felét. :(

Most egy aktív developmentet folytató 8 fős csapat része vagyok, kevés maintenance, inkább development, azok is főleg egy irányba mennek. Itt van értelme a daily standupnak, és soha nem éreztem hátrányát.

Amit rühellek, az a retro. Azt eldobnám a francba. Abból mindig csak az van, hogy felpakolunk cetliket, és következő retron elmondjuk, hogy miért nem foglalkoztunk vele. Sokkal hatékonyabbnak érzem, ha on-the-fly a scrum master rárepül, és igyekszik megoldani a problémákat, amint felmerülnek. :)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Maintenance projektet Kanban-nal kéne csinálni.
Ha a retro-nak látszólag nincs értelme akkor béna a SM, kéne oktatásra menjen.
--
Gábriel Ákos

Azzal csináltuk. A management ragaszkodott a standuphoz, mert "cég policy". Mi meg fejlesztők kapartuk a falat.

Az eddigi retrokból egyetlen egy értelmes action point jutott eszembe, amiből megfelelő output is lett, általában sajnos csak egy felesleges órának érzem, pedig a SM nagyon igyekszik. De a legnagyobb gond szerintem, hogy ott nem lehet csirkézni, mindenképp mondani kell valamit, én meg az elmúlt két hétben csak fejlesztettem, ha bajom volt, mindig mondtam standupon, több egyszerűen nem jut eszembe.

Ja, és igen, a vége mindig ugyanaz, hogy ugyanaz a 3 probléma kerül fel, és veget nem érően beszélünk róla, hogy miért zavar még mindig, ráhatásunk a megoldásra nincs a legkisebb mértékben sem.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Ezt szerettem :)

:)))))))))

:D
--
"Sose a gép a hülye."

Köszi, nem volt meg még, de elkönyvjelzőztem, ha fel kell sorolni az ÖSSZES létező félreértést, és elkövethető hibát a SCRUM-mal kapcsolatban. :)
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Daily standup helyett daily sitdown and work...

https://bit.ly/2MOH5Wf
--
Gábriel Ákos