Názory k článku AMD se těší z Ryzenu. Prodeje vzrostly o čtvrtinu, roste i cena akcií

@ded.kenedy

Ach ty manifesty. Už jenom ona sama agilní metodika je jakýsi proces a nástroj k řízení, který se musí nějak dodržovat.
Agil jsem zažil, sami si ho i občas přizpůsobili a vylepšili nebo operativně změnili podle potřeb, ale nepamatuji si, že by šéf už nebyl šéf, majitel nebyl majitel, zákazník nebyl zákazník nebo smlouva nebyla smlouva a ani se nepamatuju že by bylo jakkoliv žádoucí např. obejít schválení šéfem (processes) nebo ignorovat seznamy požadavků/úko­lů/výsledků a repozitářů (tools) přestože s individualita a interakce byly na denním pořádku . . .

Ani nevim, z ktereho konce zacit opravovat vsechna nepochopeni.

Agilni metodika neni nejaka jedna konkretni metodika, ale cela rodina metodik softwaroveho vyvoje sdilejici podobne hodnoty, viz manifest agilniho vyvoje. Proto fakt, ze jsi zazil nejaky "agil" bez uvedeni dalsich podrobnosti ma nulovou vypovidajici hodnotu.

obejít schválení šéfem (processes) nebo ignorovat seznamy požadavků/úko­lů/výsledků a repozitářů

Agilni softwarovy vyvoj neznamena, ze se jedna o jeden velky bordel, kde si kazdy dela, co chce. Pravidla jsou nastavena, ale muzou se menit podle aktualnich potreb a situace. Neni to ten pristup, ktery tady propaguje Petr M. "jednou se schvali pravidla/procesy a pak uz jen drz hubu a poslouchej".

To same se tyka pouziti nastroju. Agilni softwarovy vyvoj neni v rozporu s pouzivanim nastroju jako jsou repozitare. Ale je proti tomu, aby konkretni reseni problemu explicitne vyplyvalo z pouzivanych nastroju. Napriklad, potrebuje-li zakaznik hotfix nejakeho konkretniho problemu, neni mozne ho nutit udelat upgrade celeho informacniho systemu jenom proto, ze vsechen produkcni kod jde pres jednu hlavni vetev v cenralni CVS/SVN a zadne pomocne vetve nejsou povoleny, protoze procesy a nastroje.

To je právě ta Agilní metodika. Vybereš si co potřebuješ a co ti nepasuje, tak přizpůsobíš. A jak tam píši, tak jsme si to mnohokrát ohnuli "za chodu" protože to bylo potřeba. Jediné co dělá nakonec bordel je "Individuals and interactions over processes and tools", protože když už si něco agilně nastavíš a pak to i agilně občas poupravíš jak potřebuješ je ti k ničemu, když ti ty procesy v interakcích mezi inidividuály nikdo nedodržuje a každý pružně pruží jak se mu zachce.
Ano, nástroje by ti neměly určovat metody jak pracovat, na druhou stranu ale všichni kdo máme nějaké praktické zkušenosti a dobře víme, že každý nástroj má nějaké své výhody a nevýhody a jelikož nemůžeš předpokládat co bude chtít klient za 3 roky, tak se ti prostě může stát že tě použitá technologie prostě nepustí některé věci udělat a nebudeš např. kvůli 2 hotfixům za rok, které potřebuješ ideálně nasadit o 2 dny dřív migrovat půl firmy a přeškoloval 20 lidí. Protože to by často trvalo dýl než ty 2 dny. Ale tak bys mohl argumentovat stejně tak, že GIT je naprd agilní, protože nesmíš upravit věci přímo např. na serveru, ale musíš to prohnat commity, mergy a pull/push, testy, schválením a pod . . . . . To je prostě realita. A zažil jsem i přímo požadavky/zadání klienta, které prostě některé věci přímo použití agilních metod u některých věcí vyloučily a nebo hódně zkomplikovaly. A vyhodíš kvůli tomu velkého a stálého klienata? Určitě ano :-) Ale co, to je život a jak jsem psal, manifest je manisfest, papír snese všechno. Je hezké mít náročný cíl, ale IMO to co popsal Petr M je prostě pohled čelem k realitě. Tak to vidím já.

To je právě ta Agilní metodika.

Ne, neni. Prosim, precti si k tomu aspon heslo na wikipedii. Usetri nam to obema spoustu vysvetlovani.

když ti ty procesy v interakcích mezi inidividuály nikdo nedodržuje a každý pružně pruží jak se mu zachce

Ale toto neni agilni softwarovy vyvoj. To je jen bordel, ktery jste si zavedli, a zacali tomu rikat: "Agilni metodika"

To je prostě realita. A zažil jsem i přímo požadavky/zadání klienta, které prostě některé věci přímo použití agilních metod u některých věcí vyloučily a nebo hódně zkomplikovaly.

Ano, jsou projekty, kde je potreba mit zavedene procesy, protoze to zakaznik vyzaduje. Tak se proste agilni metodiky nepouziji. Tento argument nechapu.

to co popsal Petr M je prostě pohled čelem k realitě.

Spis je to pohled vyvojove software v jednom urcitem segmentu trhu.

Nevím jestli by sis ty spíš neměl uvědomit, že Agilní metodika je akorát jiný způsob řízení procesů, abychom si tady ten čas skutečně ušetřili.
Pominu ten "bordel" který jsi samozřejmě ani neviděl, tudíž víš kulové k čemu ses právě vyjádřil a uznávám že nechápeš ( viz. "Tento argument nechapu."), jak je možné vést projekt agilně a přesto udělat několik nutných, vyžádaných vyjímek, protože i tak si tím agilem třeba pomůžeš a nebudeš na jeden projekt nasazovat kvůli 2 věcem úplně jiné prostředí než na zbylých 10. Ale můžeš, to ti samozřejmě neberu.
No, pohled @Petr M je evidentně pohled vyvojáře, když je asi vývojář, ale ono se to v podstatě pro ty vývojáře zas tolik nemění - požadavek, plán, termín, odpovědnost, šéf/majitel, testy, výkazy/evidence . . . . . to je pořád stejné, v podstatě jde jenom o ten přístup a ty procesy - v reálu. Manifest je manifest.

a pak během projektu na ty pravidla nesahejte.

Cimz se ti z toho naprosto vytrati ta agilnost a dostanes v podstate tradicni pristup s kratkymi iteracemi. Coz se v korporatu, kde se jedna aplikace vyviji roky ztrati. V pripade internetovych firem, kde doba vyvoje je kratka (jednotky mesicu) a projekt prochazi dynamickym vyvojem (prototyp, MVP, stabilni produkt s platicimi zakazniky) je to vrazedne.

Jen dodam jeden z dvanacti principu agilniho vyvoje: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agilní vývoj znamená, že jeden sprint = (standardně) jedna verze, která se změní.

Ne, neznamena. http://agilemanifesto.org/

A je třeba, aby na sebe sedly tři věci - nástroje, procesy a projekt.

To je tak jedine, s cim mohu souhlasit.

@ded.kenedy

Takže v podstatě třeba Scrum, kde jsou nějaká obecná pravidla a podle nich se jede a nemění se, podle tebe není agilní způsob vývoje ale klasický korporátní moloch :-)

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Ano, ale tím "how to become more effective" bývá délka sprintu, počty chyb, špatné/dobré odhady, odhady zbývajícího času do termínu a pod., ne že najednou v půlce přejdeš třeba na Kanban, zrušíš pravidelné porady a odstraníš "roli" product ownera (pokud to tam máš) . . .

Cimz se ti z toho naprosto vytrati ta agilnost a dostanes v podstate tradicni pristup s kratkymi iteracemi.<\em>

Během projektu se agilně reaguje na změny zadání, třeba že chce zákazník najednou změnit komunikační protokol nebo překopat pár obrazovek. Udělá se sprint (jo, je to krátký waterfall, který se opakuje v cyklu - nikdo nic lepšího, než analyzovat, nakódit, otestovat a releasnout nevymyslel) a zákazníkovi se dodá demo nebo výsledek (podle toho, co požaduje).

Pevně daný pravidla jsou pro tohle výhodou, protože:
1) Jedno pravidlo určuje délku sprintu. Když je to týden, je to týden, když měsíc, tak měsíc. Je navázaný většinou na smlouvu se zákazníkem, kde je perioda dodávání nových verzí. Měnit to je konina.
2) Velikost teamu je x lidí a team má stabilní složení. Změň to a rozhodí se plánování sprintů, měnit to je konina.
3) Je daný nějaký způsob správy zdrojáků, který všichni znají. Čím projektu pomůže, když v jednom sprintu se budou pracovní branche nazývat #3135 podle čísla tiketu, v dalším _pepa_fix525? Měnit způsob práce s GITem je konina, pak je v tom jenom binec.
4) Release SW je zase spojený se smlouvou se zákazníkem. Požadavky na kvalitu/testování, dohodnutý způsob předání, čísla verzí, provázání interně na fakturaci práce, ... Měnit tohle je konina na kvadrát.

Máš jiný nápad, jaký mantinely chceš vlastně během práce na projektu několikrát flexibilně měnit tak, aby to pomohlo projektu?

Ne, neznamena. http://agilemanifesto.org/

Manifesty v praxi většinou nefungují. Dělat cokoliv bez pravidel můžeš v situaci, kdy jsi nezávislý. A to nejsi nikdy. Podívej se třeba na komunistický manifest, vzletný slova o rovnosti všech a někteří makali jak koně, jiní (KGB, STB, Stasi) se jenom vezli na šikanování a likvidaci "sobě rovných". A to ještě ani nebyl pravý komunismus.

Vlastně jediný manifest, který jsem viděl, že jakž takž funguje, byl TXpManifest v Delphi 7.

je to krátký waterfall, který se opakuje v cyklu

Ale toto neni agilni vyvoj, ale pouze iterativni model vyvoje.

Pevně daný pravidla jsou pro tohle výhodou, protože:

2) Velikost teamu je x lidí a team má stabilní složení. Změň to a rozhodí se plánování sprintů, měnit to je konina.

Pokud mas projekt, ktery ti prochazi postupny vyvojem, nejdriv na nem delaji 2-3 lidi architekturu, zakladni implementaci, pak se pridavaji dalsi + dalsi profese jako grafik, UX, tester (zapojovat je do projektu driv by bylo zbytecne, protoze by se kopali do prdele), pak projekt prechazi do faze maintenance, kde je pocet programatoru, grafiku a dalsich profesi mensi.

Release SW je zase spojený se smlouvou se zákazníkem.

Pokud vyvijis projekt nejdrive jako in-house, pak ma 1-2 prvni zakazniky a pak nejakych 100+, po kazde mas jine naroky. Kdyz si nastavis pravidla pro release management ve fazi vyvoje, tak jako by to byl projekt se 100+ platicimi zakazniky, bude to jen zdrzovat. Opacne to bude problem taktez.

Manifesty v praxi většinou nefungují.

Ja jsem s tim puvodne nechtel zacinat, ale kdyz jsi zacal... To, ze si nekdo vezme nejake myslenky a ohne si je tak, aby odpovidaly jeho "praxi", je symbolem totalitarniho mysleni, jake tu predvadis v nejcistsi forme ty a NULL. Vase pojeti agilniho vyvoje ma s agilitou asi tolik spolecneho jako demokracie v nazvu Korejske lidove demokraticke republiky.

Ale toto neni agilni vyvoj, ale pouze iterativni model vyvoje.

Agilní vývoj probíhá vždycky v iteracích. Říká se jim sprinty.

Pokud mas projekt, ktery ti prochazi postupny vyvojem, nejdriv na nem delaji 2-3 lidi architekturu, zakladni implementaci, pak se pridavaji dalsi + dalsi profese jako grafik, UX, tester (zapojovat je do projektu driv by bylo zbytecne, protoze by se kopali do prdele), pak projekt prechazi do faze maintenance, kde je pocet programatoru, grafiku a dalsich profesi mensi.

Team má být stabilní, 5-6 lidí. Jeden team se specializuje na UX, jiný na DB,... K projektu pak nepřiřazuješ vývojáře, ale teamy. Každý team má zkušenost se svou specializací, zlepšuje statisticky odhady,... Tak to funguje ve velkých firmách.

Ve středních firmách se kompetence teamů sdílí, že jeden team dělá architekturu + UX, druhý DB + backend,...

V malé firmě nebo startupu o 10 lidech dělají všichni všechno a nemáš kde brát specialisty.

Pokud vyvijis projekt nejdrive jako in-house, pak ma 1-2 prvni zakazniky a pak nejakych 100+, po kazde mas jine naroky. Kdyz si nastavis pravidla pro release management ve fazi vyvoje, tak jako by to byl projekt se 100+ platicimi zakazniky, bude to jen zdrzovat. Opacne to bude problem taktez.

Proč? To je problém obchodníků a technické podpory, ne tvůj. Tvůj úkol je "vyrobit binárku" a opravit chyby z bug trace.

Standardně release začíná tím, že hodíš push do GITu do vývojové větve. Jenkins zkusí CI, když projde, vybleje testovací biínárky. Když tesťáci dovolí, následuje patchování produkční větve, Jenkins vyhodí binárky, scp na distribuční server, rozeslání mailu s notifikací. Kolik lidí si ty binárky stáhne, tě nezajímá. Ty řešíš, jestli Jenkins release zvládl, nebo je to rozbitý.

U bug trace tikety přiřazuje tecnická podpora a tesťáci. Odfiltrovat "bugy mezi židlí a klávesnící u zákazníka" a sloučit duplicitní bugy je práce technické podpory. Přiřazují je na scrum mastera, ten je deleguje dál.

A díky takhle nastavenýmu procesu nezjistíš, že najednou volá 50 zákazníků denně a nemáš čas na práci. Zase, nic se nemění, krom počtu lidí na technické podpoře a obchodníků. Takže parametry procesu, ne proces jako takový.

Ja jsem s tim puvodne nechtel zacinat, ale kdyz jsi zacal... To, ze si nekdo vezme nejake myslenky a ohne si je tak, aby odpovidaly jeho "praxi", je symbolem totalitarniho mysleni, jake tu predvadis v nejcistsi forme ty a NULL. Vase pojeti agilniho vyvoje ma s agilitou asi tolik spolecneho jako demokracie v nazvu Korejske lidove demokraticke republiky.

1) Demokracie je o řízení společnosti, ne lidí.
2) I v demokracii jsou pravidla a instituce, co jejich dodržování kontrolují (třeba policie a trestní právo).
3) Agilní vývoj je agilní tím, že
- rychle dodá aspoň minimální verzi aplikace
- rychle a průběžně reaguje na požadavky zákazníka
- na základě statistik z dosavadního průběhu projektu se dá predikovat další průběh projektu
- není potřeba dopředu půl roku sepisovat, co to má umět
- zjednodušuje čerpání financí od zákazníka/mana­gementu - "vidíte, že se projekt pohnul, před týdnem tam tahle featura nebyla"
4) Agilní vývoj není o tom, že se vývojáři dohadují, jestli je pro 100 zákazníků potřeba věci dělat stejně, jako pro 99 zákazníků a jestli se má od verze 4.0 změnit coding style.
5) Programátor je zaměstnanec podle stejnýho zákona, jako sekretářka, uklízečka nebo frézař. Poslouchat šéfa a respektovat firemní procesy proto musí úplně stejně.

Nejsi náhodou ona slečna po přeoperování genitálií?

Agilní vývoj probíhá vždycky v iteracích.

Ale ne vse, co probiha v iteracich je agilni vyvoj. Doporucuji nastudovat rozdil mezi implikaci a ekvivalenci.

Team má být stabilní, 5-6 lidí. Jeden team se specializuje na UX, jiný na DB,... K projektu pak nepřiřazuješ vývojáře, ale teamy.

Dobre, jde videt, ze opravdu nechapes, o cem je agilni vyvoj. Agilnost plyne z toho, ze mas v tymu lidi, kteri jsou schopni vyresit jeden pozadavek jako celek. Opet upozornuji, ze je tu implikace ne ekvivalence.

Jeden team se specializuje na UX, jiný na DB,...

Takze pokud potrebujes pridat jedno vstupni pole do formulare. Musi to nejdriv vyresit DB tym, tym vyvijejici aplikacni logiku, pak to prevezme tym UX a nakonec si to vezme tym testeru. A request, ktery by sel vyresit za pul dne se vsim vsudy resis mesic. Pouziju-li tva slova Tak to funguje ve velkých firmách.

Standardně release začíná tím, že hodíš push do GITu do vývojové větve...

V teto diskuzi se, ale celou dobu bavime o koncepci a rizeni vyvoje ne o technickych detailech, jak se co nekde dela nebo da delat.

Proč? To je problém obchodníků a technické podpory, ne tvůj.

Osobne jsem si prosel vyvojem nekolik projektu od sameho zacatku az po jejich nasazeni a udrzbovost a potreby projektu se v kazde fazi menily. Dokazes si uvedomit, ze treba prvnich nekolik tydnu neni a ni co testovat nebo dokonce spoustet. K cemu je ti v te fazi jenkins nebo testeri?

Demokracie je o řízení společnosti, ne lidí.

Evidentne si nepochopil. Doporucuji vedle implikace nastudovat i pojem prirovnani.

Nejsi náhodou ona slečna po přeoperování genitálií?

Sorry jako, ale s clovekem, ktery se uchyluje k osobnim urazkam na urovni ctvrte cenove skupiny nehodlam nadale diskutovat.

Ano, a pak ses tady zacal rozplyvat nad procesama. Kazdy si udela obrazek sam.

Tys nepochopil, že bez procesů to prostě nejde? A že některý jsou daný zákonem?
- BOZP - podepíšeš papír, kde jsou popsaný pravidla, když se ti něco stane, řeší se to na téhle úrovni. Zákon to tak požaduje, mají to tak absolutně všichni.
- Lékařská prohlídka zaměstnance - požadováno zákonem, kdy a jak se objednat k dokktorovi a jak žádat o proplacení už je interní proces
- Zpracování mezd - kdy odevzdat výkaz práce, co v něm má být, kdo schvaluje dovolenou - interní proces, i když v malé firmě často nepsaný
- Fakturace projektu - kdo a kdy dodá podklady, co tam má účetní započítat - interní proces
- RZD - kdy komu dodat podklady a kdy to kde podepsat = proces (často i jednorázově popsaný v mailu jednou ročně)
- ...

Coz jde udelat pouze u cinnosti, ktere se rutinne opakuji.

Ne nutně. Můžeš mít definovaný proces, který není rutinní a ani nechceš, aby se jím stal. Například zpracování reklamace, vyhazov zaměstnance,...

Ano, redukujeme cloveka na chodiciho robota...

Takže proto, že je někdo "tvůrce", nebude akceptovat standardní postup nákupu licencí, nebude dodržovat pravidla pro používání GITu, který se dohodly, výkaz práce za duben odevzdá v červnu a firma fakturu za jeho práci uvaří z vody. A daně odvede, až se mu bude milostivě chtít. Zaměstnanec je prostě zaměstnanec, bez ohledu na to, jestli pracuje hlavou, rukama nebo přirozením.

Ale pravdu máš v tom, že v "lean manufacturingu" je jako jeden ze sedmi druhů plýtvání i tzv. "overporcessing" a to byl jeden z důvodů, proč jsem dal v korporátu výpověď. Korporát se totiž od malé firmy liší tím, že v malé firmě si musí člověk na sebe vydělat, takže jedinec, co se jenom drápe na zadku a jenom prezentuje, co všechno ve firmě vylepšil (formou vymýšlení závazných nesmyslných směrnic) dokáže zabít produktivitu dokonale. Co jsem v korporátu zažil, to by vydalo na knížku.

A pripadas si pri tom rvani na lidi dulezitejsi?

Ne, ale pokud někdo nemá dost inteligence, aby normálně pochopil, že pro dosažení výsledku musí spolupracovat a že není takový eso, aby se kvůli němu přepisovaly zákony a měnil chod firmy, tak první stupeň je vysvětlení, proč to tak je. Když na tom trvá, druhý je kartáč na koberečku.

"Ne nutně. Můžeš mít definovaný proces, který není rutinní a ani nechceš, aby se jím stal. Například zpracování reklamace, vyhazov zaměstnance,..."

:-D Tak sem se dneska od plic zasmál :-D

@Petr M

V pořádku, jenom mě rozesmálo to s (ne)rutinou a vyhazovem :-D
Já proti procesům nic nemám, aspoň je jasno a ne že pak někdo za týden přileze a začne rozumovat, co se mělo, nemělo a mohlo . . . a pak, místo vymýšlení splnění možného i nemožného s čím by kdo mohl pružně přilézt, má člověk jakýsi klid na práci a zlepšení.

Tys nepochopil, že bez procesů to prostě nejde?

Tys nepochopil, že bez procesů to prostě nejde?

A tys nepochopil, ze nejsem proti procesum en bloc. Ale jsem proti tomu, aby ve firme byl proces na kazdy prd, vcetne toho, kdo posle vdove kvetiny v pripade nehody.

Ne nutně. Můžeš mít definovaný proces, který není rutinní a ani nechceš, aby se jím stal. Například zpracování reklamace, vyhazov zaměstnance,...

Nebo danou vec resit jako clovek podle aktualni situace.

Zaměstnanec je prostě zaměstnanec, bez ohledu na to, jestli pracuje hlavou, rukama nebo přirozením.

Ano. Spisovatel, grafik nebo obrabec kovu, vsichni musi plnit normy a drzet hubu.

Kdyz jsou ty procesy tak bajecne, proc velke korporace vsechny "nove myslenky" resi nakupem malych firem nebo vytvorenim "internich startupu", ktere jsou odstineny od tradicnich zabehlych internich procesu?

Ale jsem proti tomu, aby ve firme byl proces na kazdy prd, vcetne toho, kdo posle vdove kvetiny v pripade nehody.

To já taky, ale proč furt dokola vymýšlet kolo? Ona standardizace procesu může být i nepsaná, když v nějaké situaci zkušenější zaměstnanec ukáže míň zkušenýmu, jak to řešili posledně.

Nebo danou vec resit jako clovek podle aktualni situace.

Jasně, a elektrikář bez znalosti souvislostí bude improvizovat a řešit jako člověk, že mu zavazí trubka v pohodlnějším přístupu, umístěním rozvaděče NN na druhou stranu zdi. A vůbec mu při tom nevadí, že dá bednu v IP20 do EXové zóny, že... Zákazník to neproplatí a dolož tomu, "co to řešil jako člověk", že porušil nařízení, když žádný neexistuje...

Ano. Spisovatel, grafik nebo obrabec kovu, vsichni musi plnit normy a drzet hubu.

Pokud je zaměstnanec, diskutovat může maximálně neformálně u oběda. Pokud jde o kšeft, tak se prosadí názor toho, kdo to platí - managementu, zákazníka, akcionáře, ... Přebít je může jenom legislativa. To je prostě realita. Schválně, zkus zákazníkovi říct, že jste si odhlasovali, že mu dodáte stroj s polovičním výkonem. Nebo říct šéfovi, že jsi se s kolegou shodnul, že 64GB RAM je pro zákazníka škoda, tak jste mu dali jenom 32GB a po 16GB jste si vzali domů...

Kdyz jsou ty procesy tak bajecne, proc velke korporace vsechny "nove myslenky" resi nakupem malych firem nebo vytvorenim "internich startupu", ktere jsou odstineny od tradicnich zabehlych internich procesu?

Příklad z praxe. Měli jsme oddělení o pěti lidech, co mělo řešit průšvihy ohledně bezpečnosti práce, školit BOZP a přijímat bezpečnostní opatření. Ale na školení stačil jeden, pár měsíců se nikdo nezranil. Potřebovali vykázat činnost, tak psali směrnice.

Byli jsme v třípatrovým baráku bez výtahu. Jeden týden vyšla směrnice o nošení břemen, která ukládala držet nesenou věc oběma rukama. Druhý týden vyšla směrnice pro chůzi po schodech, která říkala, že při chůzi po schodech musí být v kontaktu se schodama zaměstnanec v každým okamžiku minimálně třema končetinama, tj. zvedneš nohu, tak druhá noha musí být na schodku a dvě ruce na zábradlí. Zkus tam "legálně" dostat pětikilovou krabici 30x30x30cm o patro výš bez pojebu.