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

[to_je_jedno]

v dany cas sa musim ist postavit niekde do kruhu a posuvat tasky na boarde

a tohle se prave na standupu delat NEMA

[Reklama]

[tomtim]

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?

[to_je_jedno]

Pretoze kazdy vidi obtiaznost inak.

Jaky je v tomhle smeru rozdil mezi kartama a hodinama?

[Mastr skram]

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

[XQ]

Vidim ze jste vetsina porad zmateny, tak vam to vysvetlim znova.
...

Další žhavý kandidát na Cenu Brouka Pytlíka. Máš můj hlas.

[Reklama]

[PetrM]

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.

[PetrM]

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

[L.]

(...) 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.

[Mastr skram]

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.

[Mastr skram]

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.

[vu]

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.

[Wal-De-Mar]

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é.

[SB]

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! 
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ě.

[MarSik]

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..

[Wal-De-Mar]

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.