Vlákno názorů k článku Budoucností vývoje velkých e-shopů jsou agilní kontrakty od paranoia - A paranoia neumí psát, omlouvám se za překlepy

A paranoia neumí psát, omlouvám se za překlepy

Ahoj. Nemám co dodat a plně s napsaným souhlasím.

ad 3. Ideální je mít pro role samostatné lidi. Někdy s ohledem na velikost týmu, velikost projektu a rozpočet je z naší zkušenosti ovšem sloučení rolí nutné a vhodné.

ad 4. I to je důvod, proč nejsou agilní kontrakty nasaditelné na všechny projekty ale pouze na ty, kde pracuje více lidí (a mohou se zastoupit) a při delší absenci může být do týmu přidán další zdroj/člověk.

ad 5. Spolupráce klienta se nám u agilních kontraktů ukázala jako naprosto zásadní proměnná. Nechceme po klientovi volné rozpočty (i při agilních kontraktech garantujeme předem pracnost/cenu jednotlivých činností/úprav. Chceme však častý kontakt, prioritizaci, sledování dem a připomínky. I proto píšeme tento článek a pokoušíme se dělat osvětu.

K tomu přemýšlení a meditaci vám připojím link, pokud se sem náhodou ještě vrátíte...
https://www.youtube.com/watch?v=a-BOSpxYJ9M

Tak tedy ad 3- které role nejčastěji slučujete a proč? Pokdu to tedy není supertajná interní informace

Ahoj Petře, pěkný článek, je vidět, že nad agile uvažuješ a medituješ čím dál více:)

Zažila jsem pokusy o agile, agile stylem "nastudujeme si *vyber agilní metodiku*, skočíme na jedno školení a už všecko umíme" a pak jsem měla tu čest působit v týmu, kde se jelo na scrumu. Ale opravdu jelo, včetně aktivní účasti klienta během vývoje. Každodenní scrumy, plánování sprintů, sprint reviews, přesně dané role, okamžité řešení problémů... paráda:)

Jedna věc je mít agile nastudovaný horem spodem, ale jsou faktory, které agile minimálně hodně zadrhnou, ne-li absolutně zastaví. Ze zkušenosti je to hlavně:
1- neochota týmu dělat nové věci- ono je celkem jedno, jakou roli člověk v týmu zastává, pokud má s agilním vývojem nějaký problém, většinou to přenese i na ostatní a motivace i výsledky jdou dolů.
2- z nějakého důvodu nevhodně zvolení scrum masteři a product owneři- neboli role rozdělovače práce na člověkohodiny a člověk odpovědný za směřování vývoje a konečnou podobu produktu. To, že je někdo výborný projekťák ještě neznamená, že má na to být i výborným SM, stejně tak bezvadný analytik není vždycky nejlepším PO
3- jeden člověk ve více rolích- tohle úzce souvisí s dalším bodem. Zažila jsem pokusy sloučit roli scrum mastera a product ownera do jedné osoby, dopadlo to blbě (většinou pro toho člověka, protože toho měl prostě moc a žádný jiný pohled na věc). Stejně tak není dobré mít databázového specialistu, který se ale zároveň stará o kódování designu a ve volné chvíli testuje kolegům hotové úkoly. Taky tester/analytik/dě­večka pro všechno není dobrý nápad. Proč? Člověk tak ztrácí své pevné místo v týmu, svou roli, kupí se mu práce a nastává u něj pracovní schíza, kdy má pět pohledů na jednu věc, kteoru nakonec stejně nestihne, protože se nedovede rozhodnout.
4- nedostatečná kapacita týmu
Viz výše, pokud už jdu do projektu agilně, musím mít dopředu přehled o volných kapacitách a zároveň musím počítat s nejhorším možným scénářem- jeden programátor dlouhodobě nemocný, druhý odejde, scrum master otěhotní a product owner zemře (ad absurdum, já vím:) ). A i když se nedá plánovat vše na 100%, musím se situaci přizpůsobit a nesnažit se přizpůsobovat tým projektu. Protože pak už se každé plánování sprintu stává vlastně přesouváním nedokončených úkolů do dalšího sprintu a člověk je tam, kde byl před agile vývojem
5- nespolupráce klienta
Každý druhý klient si o agile něco načte a pak to strašně vyžaduje, pak už mu ale nedojde, že ho bude během vývoje pořád někdo prudit a chtít po něm konzultace, akceptace, schůzky... zejména z tohoto důvodu u nás v týmu agile není aktuálně dost dobře možný. Klient, jakožto logistická firma, má zaměstnance permanentně vytížené na 110% a na takovou spolupráci jednoduše nemá lidi.
6- absence sprint reviews
Většina lidí to bere jako otravu a zbytečnou schůzku, když přece všichni ví, co šlo v posledním releasu ven, ale chce to komplexní pohled jak na to, co se povedlo, tak taky na to, co se nepovedlo, kde jsou slabiny, na čem je třeba zapracovat. A to všechno pokud možno bez hádek a vzájemného obviňování.

Na svou etapu se scrumem vzpomínám moc ráda, je pravda, že tým sám o sobě byl složen z výjimečných lidí a myslím, že havně díky tomu a pořádnému vedení jsme byli schopni výborně komunikovat a hlavně dodat produkt v očekávané kvalitě bez zpoždění.