HOVD 2018 - Kedvenc projektvezetési módszertan

Címkék

chat window, email szabályok nélkül
9% (44 szavazat)
crystal
0% (0 szavazat)
egyéb agile módszertan
3% (13 szavazat)
főnöknek szólok, ha elkészültem, szól, ha van új feladat
25% (121 szavazat)
kanban, lean
15% (72 szavazat)
scaled agile (safe, less, dad)
1% (3 szavazat)
scrum
14% (67 szavazat)
sima ticketing rendszer + assign + prioritás szintek egyéb szabályok nélkül
27% (131 szavazat)
waterfall
3% (16 szavazat)
xp, pair programming
3% (12 szavazat)
Összes szavazat: 479

Hozzászólások

Latod gee, milyen jol szerepelnek a nem szabalyozott megoldasok, amiket "agile coach"-kent kukaztal volna olyan opciokert, amikrol meg csak te hallottal meg max masik 3 szavazo total? :P

A Waterfall szavazataranyat pedig egyetemi oktatok figyelmebe ajanlom.

A waterfall termeszetesen nem mukodik jol a gyakorlatban. De szamomra erdekes volt fiatalabb kollegakat hallgatni, hogy a tervezes az csak a waterfall resze, es az egy elavult dolog. (Ergo tervezni nem kell.) Meg persze a v-modellt is keverik a waterfallal.
Az mara nyilvanvalo, hogy a waterfall szigoru projektfazisai nem tarthatoak a gyakorlatban, de attol meg minden waterfall fazishoz tartozo tevekenysegnek helye kell legyen egy mas modszertanban, csak maskepp szervezeve. A leggyakoribb tevhit a modern modszerek kornyeken, hogy ha nincsenek fazisok, akkor nem kellenek kovetelmenyek, nem kell tervezes, eleg a kod meg a unit teszt. Ez pont annyira rossz, mint a szigoru waterfall.
Nem tudom persze, hogy mit oktatnak manapsag, de valoaban a lean es agile modszertanok hajlmaosak kifejezetten kod kozpontu modszertankent megjelenni a fejekben, pedig nem feltetlenul azok. Ha pedig nem csak szoftvert fejlesztunk, hanem olyan termeket, amelynek mas komponensei is vanak, akkor meg izgalmasabb a helyzet.

A waterfall termeszetesen nem mukodik jol a gyakorlatban.

Ezt így nem jelenteném ki. A waterfall is egy eszköz, amit egy konkrét probléma megoldására alkottak, ahogy az agile is, amit azokra a problémák megoldására alkottak, amik akkor jelentkeztek, amikor waterfall módon próbáltak másféle követelményeket és problémákat támasztó feladatokat leszállítani.

Szerintem mindkettő működik, ha a feladathoz a megfelelő eszközt választjuk és nem az eszközünket próbáljuk mindenre ráerőltetni.
Az igaz, hogy a mai világban szoftverfejlesztésben sokkal kevesebb olyan feladat van, ahová a waterfall illeszkedik jól. És sok helyen próbálják használni, ahol nem kéne. Ott valóban nem működik jól a gyakorlatban.

a tervezes az csak a waterfall resze, es az egy elavult dolog. (Ergo tervezni nem kell.)

Sok mendemonda, mítosz terjedt el az agile-ról. Nem kell tervezni, nem kell dokumentálni, gyorsabb lesz a fejlesztés, olcsóbb lesz a fejlesztés, stb.

Iteraciokra akkor is szukseg van, ha a kovetelemenyek nem valtoznak. Ha nem trivialis a feladat, tehat nem latok mindent pontosan elore, akkor a fejlesztes kulonbozo szakaszaiban szuksegkeppen lesznek olyan informacioim, amikkel vissza kell, hogy terjek a korabbi szakaszokhoz, ahol modositasokat kell vegrehajtanom.

Régen is azt tanították, hogy miért sikertelen a szoftverfejlesztési projektek nagy része (jóval több, mint 50%-a), csak amikor én jártam a főiskolára, akkor az volt a problémák felismerése után a megoldási javaslat, hogy több analízis kell, több tervezés kell, több dokumentáció kell, vagyis a waterfall-t kell erősíteni, és attól majd jobb lesz.

Érdekes kultúrtörténeti, oktatástörténeti kérdés, hogy ki miatt került be a magyar oktatási anyagba az SSADM. Brit kormányzat használta tudtommal, szóval arra tudok gondolni, hogy valamelyik magyar oktató részt vett egy brit kormányzati projektben, megismerte, elkezdte oktatni, és így került be a magyar tananyagba több egyetemen.

A waterfall az nem "több tervezés, több dokumentáció", hanem visszacsatolás/iteráció nélküli fejlesztés. Aki azt hiszi, hogy az agilitás kimerül abban, hogy nem tervezünk, meg nem dokumentálunk, mert úgyis minden változik, az azon kapja magát, hogy lesz 1 év után egy agilisen fejlesztett spagettikódja, amit ugyan lefednek tesztek, de senki nem tud hozzányúlni.

:-)

Többféle lehetőséget be akartam dobni.

Egy kicsit sokat akart ez a szavazás, szerintem.
Én vagy nem bontottam volna szét a dolgokat, szóval pl. agile alá mehetett volna scrum is, xp is, lean és kanban is, plusz lehetett volna mindenféle egyéb, vagy úgy gondoltam, ha már bontunk, akkor nézzük meg azt, hogy azon a területen ki mit kedvel.
Voltaképp szerintem ezekből az opciókból ki lehetett volna hozni két kategóriát.

Több javaslatot tettem, a teljes szétbontás le lett szavazva. (Lehet, hogy annak a szavazásnak az eredménye egyébként is csak engem érdekelt volna). Nincs ezzel semmi baj. A másik javaslat két javaslat meg bement.

A waterfall egy érdekes dolog. Én pl. elég sok emberrel találkoztam, akik úgy kezdték a beszélgetést, hogy az agile szar/humbug. Ezek az emberek jellemzően azt mondták (nem mind), hogy a korábbi rendszer (waterfall) jobb volt.

Az egyetemi oktatók hogyan jöttek a képbe?

Hat valahogy nem sikerult olyan kategoriakat letrehozni, amik diszjunktak lennenek. De amugy is mindenbol az arra erdemes elemeket hasznalom, mert egyik modszer sem igazan csodafegyver, csak nehany kiragadott (nem feltelenul altalanosan adaptalhato) felismeres eroltetese. (A felismeresek nagy tobbsegehez egyebkent siman jozan paraszti esszel es elegendo tapasztalatal is el lehet jutni.) A modszertan a projekthez es a szervezethez kell igazodnia, es igy idorol idore valtozik. De a tapasztalatom az, hogy a modszertan tok mindegy, ha jo a csapat es hagyjak oket dolgozni, jo lesz az eredmeny. Ha meg rossz a cspat, vagy a management / szerevezet, akkor teljesen mindegy, hogy milyen modszert probalnak rajuk eroltetni, egyik sem fog mukodni.

Az azért kérdéses. hogy a triviális "jó csapat akiket elkefél a vezetés" mellett van-e olyan, hogy egy rossz csapat valamelyik vezetési elmélet szerint irányítva legalábbis középszar tud-e lenni. (Azaz hogy igazából ven-e olyan "rossz csapat", aki a körülmények hatására rossz.)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Igen, ez egy erdekes felvetes. Egy csapat nagyjabol ket modon lehet rossz. Szakmai hianyossagok (esetleg tapasztalatlansag), vagy belso feszultsegek (rossz csoportdinamika), illetve ezeknek tetszoleges kombinacioja.
Kerdes, hogy meg lehet-e konstrualni azt a sajatos esetet, ahol a cspat kepes lenne megoldani a feladatot (eleg felkeszultek), de nem tudjak az odavezeto utat (hianyzik a megfelelo modszer), szerintem ez inakbb paradoxon. Vagy a masik eset, amikor a csapat eleg felkeszult, de csoportdinamka okan egymast akadalyozzak. Hogy ez utobbit egy modszertani valtas feloldja-e, szerintem nem, de lehet hogy volt mar ra pelda.

En az agile / lean modszerek bevezetesenk alapvetoen ket motivaciojaval talakoztam:
- fejelsztoi oldalrol: kaosz / munketerheles csokkentese azaltal, hogy az idoegyseg alatt elvegzett feladatokat transzparensse tesszuk (a feladatok eroforrasigenyenek lefedeset illetve a feladatok priorizalast igy visszatoljak a management oldalra)
- management oldalrol: kontrolalni akarja, hogy a fejlesztok mit csinalnak, mert meg van gyozodve, hogy minden tovabb tart a szuksegesnel, mindent bevonnak arannyal, meg kulonben sem azt csinaljak, ami kell, ha meg igen, akkor nem a fontossagi sorrendben

En az agile / lean modszerek bevezetesenk alapvetoen ket motivaciojaval talakoztam

Keress rá a State of Agile survey kifejezésre. Nézd meg, hogy milyen okokat választottak sokan annál a kérdésnél, hogy miért vezették be az Agile-t a cégnél (ez persze a cég, managmenet oldal, nem a fejlesztők válaszoltak)

Az érdekes inkább a benefits. Azaz, hogy mit ad az agile, miért jó. Például a szoftverminőség nem lesz tőle sokkal jobb, cserébe rugalmasabban lehet basztatni a fejlesztőket a prioritások változtatgatásával, és jobban illik a businessvilághoz a fejlesztés. A project cost reduction pedig a legeslegutolsó helyen szerepel, a maintainability utolsó előtti. Pedig ezeket szokás felhozni az agile mellett, nem pedig azt, hogy az IT mérnökség befekszik a businessnek, pedig ez történik.

Na de érted, az agile egyik selling pointja a szoftverminőség növelése, miközben nem ez a valóság. Be kéne már vallania a sok consultantnak, hogy nem a process meg a methodology, hanem az ember az, aki a szoftverminőséget befolyásolja. A process meg a methodology csak arra való, hogy középszar embereket kordában tudjon tartani, de attól még nem lesz top-notch a szoftver.

Persze. Scrum tanfolyamon is a legelső dolog az, hogy a minőség mindig magas legyen, legfeljebb a scope kisebb egy sprint során.
De hát linkelhetünk ilyet is:
https://www.atlassian.com/agile/advantage/agile-is-a-competitive-advant…
"Agile helps organizations in multiple industries improve product quality, time to market, and employee satisfaction."
Első selling point a quality.

Hmm...

Az, hogy a minőség magas legyen, legfeljebb a scope kisebb, azt én is szoktam mondani az embereknek, amikor az Iron Triangle-t mutatom meg nekik. De itt a magas minőség nem azt jelenti, hogy magasabb, mint amikor nem agile-lal fejlesztenek, csupán azt, hogy nem akarunk a minőségből lejjebb adni. Vagyis azért, hogy mondjuk az üzlet által vágyott időre az üzlet által vágyott scope-ot késznek lehessen jelenteni, nem fogjuk kihagyni a visszatérő értékek ellenőrzését meg a tesztek írását stb.

Az iron triangle pont a waterfall és az agile megközelítés különbségéről szól, de mindkettő esetben középen a quality az, amihez nem nyúlunk.

A második ponthoz hozzászólva (persze nem tudom, hogy mire gondolt a költő), én úgy gondolom, hogy a product quality az nem feltétlenül azt jelenti, hogy az elkészült kódban kevesebb lesz a hiba, amikor kiadom a kezemből. Én inkább úgy gondolnám, hogy a quality az, hogy a program azt csinálja, amit a felhasználók és a megrendelő szeretne. Amit a rövid iterációk és a gyors feedback loopok segítenek. Ugyanígy, ugyanezek miatt esély van arra, hogy bugokat és rossz minőségű kódot hamarabb észrevesznek (mert egy sprint végére már valamennyi tesztelés és kód review megtörtént), és ezért hamarabb neki lehet állni a javításnak (mondjuk ahhoz képest, hogy mondjuk egy év fejlesztés után kezdődik a tesztelés, és akkor kezdik el felfedezni a bugok garmadáját. Dolgoztam már olyan projekten, ahol egy csóka kb. három hónap alatt lefejlesztett egy számla formázást egy számlázórendszerbe, és amikor elméletileg elkészült, akkor nézték meg mások, és kaptak a fejükhöz, mert egy szemétdomb volt az egész).

Nem azt mondom, hogy nem mennek konzultánsok ügyfelekhez ezzel az üzenettel, igazából fogalmam sincs, hogy a konzultánsok mivel próbáljál eladni az agile megközelítést (nem volt részem ilyenben).

Akikkel én találkoztam, ott az ügyfeleknek jellemzően két vágyuk volt az agile bevezetéssel kapcsolatban: 1) rugalmasság 2) gyorsabb és olcsóbb fejlesztés. Azt nem tudom, hogy valaki ezt így adta el nekik, vagy csak valahol hallottak olyan mendemondákat, hogy ezt jelenti az agile.

Állás interjú során kérdezték már tőlem többször is, hogy hogyan mérném a kód minőséget agile fejlesztés esetén, és erre én általában azt szoktam mondani, hogy a bugok számát ugyanúgy, mint waterfall esetén, de mellette mérek pl. lead time-ot és cycle time-ot.
Aztán fene tudja, hogy ezt akarták-e hallani :-)

Amit még erről el tudnék mondani az agile problémái kapcsán, azt Fowler tökéletesen leírta itt: https://martinfowler.com/articles/agile-aus-2018.html
Azok a dolgok, amiket akarnak az Agile Manifesto eredeti kitalálói, ma már inkább software craftmanship néven fut, az agile totál mást jelent a menedzserek fejében.

"a szoftverminőség nem lesz tőle sokkal jobb"

Az Agile 2000 körül született, amikor még sok helyen az volt a nagy csoda, ha CVS-t használtak, nem pedig egy megosztott meghajtóra másolták fel a kódot, kézzel összefésülve. Automatizált tesztelés és CI a legtöbb helyen ismeretlen fogalmak voltak, no meg a cross-functional (fejlesztő + tesztelő) csapat is. A "Working software is the primary measure of progress." Agile principle egyszerűen hangzik, de amit ennek a nevében csináltak, azért istenítik igazán az Agile-t.

"rugalmasabban lehet basztatni a fejlesztőket a prioritások változtatgatásával"

Nem, ezt az Agile ki is mondja: "Build projects around motivated individuals." Ha össze-vissza dobálod az embereket, nem csak működő termék nem lesz, de a motiváció is meghal.

Nekem úgy tűnik, hogy a legtöbben az Agile szemére vetik azt, ha a szereplők az Agile nevében valami egészen mást csinálnak. Én is elkezdhetnék a modern tömegközlekedés nevében kockakerekű rollereket osztogatni, de attól még én vagyok a hülye, nem a modern tömegközlekedés a rossz.

"Nem, ezt az Agile ki is mondja: "Build projects around motivated individuals." Ha össze-vissza dobálod az embereket, nem csak működő termék nem lesz, de a motiváció is meghal."
vs ezt is kimondja ám az Agile:
"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. "
A fejlesztők magukra vállalják, hogy nyugodtan lehet bármikor követelményt változtatni. Akkor ne csodálkozzanak, ha ez lesz a fő előnye az agilitásnak, hiszen a waterfall fő hátránya pont a rugalmatlanság. Az, hogy a folyamatos változástól valaki motiválatlan lesz, az már a fejlesztő gondja, ő mondja, hogy agilitás jó, oldja meg magának.

Ha megnézed az egész agile manifestot, és a principles behindot, mindenhol a business előnyök a lényegek, nem a technical merit. Csak azt mondja, hogy az agilitást javítja a technikai jóság (Continuous attention to technical excellence and good design enhances agility. ), de a waterfallt is javítja a technikai jóság és a jó design. Ebben semmi új nincs.

A kézzel összefésülés helyett verziókezelő csodaként lévő használata meg nem agiltiás, hanem professionalism, és semmi, de semmi köze az agilitáshoz, sem a waterfallhoz. Ezek technikai dolgok. A waterfall meg az agilitás meg a software delivery mikéntjéről szól. Egyfajta business language körülírása a release early, release oftennek.

"mindenhol a business előnyök a lényegek, nem a technical merit"

Akkor a principlesből pár foszlány: "continuous delivery" (CI + DevOps + ...), "working software" (=automatizált teljes körű tesztelés), "Give them the environment and support they need" (=szarból nem építünk várat), "sustainable development" (=nincs ostor), "Continuous attention to technical excellence and good design", "best architectures". Legalább a fele a cuccnak kifejezetten a fejlesztőkről szólnak.

"Az, hogy a folyamatos változástól valaki motiválatlan lesz, az már a fejlesztő gondja, ő mondja, hogy agilitás jó, oldja meg magának."

Nem a változástól lesz motiválatlan, hanem attól, hogy egy barom össze-vissza rángatja a kormányt, így nem tud olyat alkotni, amire aztán büszke is lenne. (Ez bullshit szagú, de attól még nem hülyeség.) Itt nem csak a fejlesztő bajáról van szó, hanem nem jön ki érték a végén, ami mindenkinek rossz.

"nem agiltiás, hanem professionalism"

Igen, ez teljesen jogosnak tűnik. Csakhogy ezt a fajta professzionalizmust az Agile szemlélet tette elterjedté.

"A waterfall meg az agilitás meg a software delivery mikéntjéről szól."

Is. Meg az egész értékteremtés koncepciójáról.

A sustainable development nem azt jelenti, hogy nincs ostor, hanem azt, hogy nem akadunk meg soha technikai gondok miatt. Ostor folyamatosan van, mert a business mondja meg, mi legyen, changes welcome.
"Nem a változástól lesz motiválatlan, hanem attól, hogy egy barom össze-vissza rángatja a kormányt"
Changes welcome even in the late, ugyebár.

A working software nem egyenlő automatizált teljes körű teszteléssel, egyáltalán nem. A working software azt jelenti, hogy a szoftver működik. Az, hogy hogyan éred ezt el, tök mindegy. Az agilitás nem azt mondja, hogy úgy érd ezt el, hogy teljes körű tesztelésed legyen. Az csak egy eszköz. Elérheted úgy is, hogy teljes körű tervezésed van előre, és minden rész le van vezetve formálisan. Csak éppen ahhoz nem fér meg a "changes welcome" kultúra, cserébe sokkal biztosabb a "working software".

Az egész unit testing, meg CI/CD automatizálás arról szól, hogy a "changes welcome" üzleti kultúráját miként lehet megtámogatni szoftveres eszközökkel. Az agilitás fő kulcsa a changes welcome, minden más pedig az, hogy milyen eszközökkel lehet átlagos fejlesztőkkel ezt elérni.

Kétségtelen, hogy nagyon sokat adott a changes welcome kultúra a szoftvereszközök terén, de sok mindent el is vett. Elvette például az alapos átgondolást - hiszen úgyis changes welcome, szóval változás lesz, felesleges átgondolni a dolgokat. Legyen meg a két hetes sprint, hurrá. Ez is milyen hülye név, aki folyamatosan sprintel, jobban elfárad, mint aki szépen a saját tempójában, megfontoltan halad előre, és tovább is jut.

Az agilitással pont ez a megfontoltság veszett el, hiszen két hétre előre felesleges megfontoltnak lenni, utána meg úgyis minden megváltozhat, és a tesztek úgyis lefednek mindent, nem érdekes.
Pedig a technical excellence, és a problémák folyamatos megértése az nem megy úgy, hogy kéthetente, havonta kibökünk valamit, ami működik, le van fedve teszttel, de magát a problémát még igazán nem értjük és nem ismerjük.
Fred Brooks MMM könyvében lévő szabály jut eszembe: plan to throw one away. Meg kell építened először a komplett rendszert ahhoz, hogy utána rájöjj, hol van benne a valódi probléma, megértsd a rendszer lényegét, és utána le tudd tisztázni. Ez pont ellentétes a changes welcome-mal. Prototipizálásra kiváló, baromi gyorsan lehet iteratív módon ötleteket kipróbálni, megnézni, eldobni, újrahasználni.

De egy rendes fejlesztéshez az kell, hogy azt mondjuk, hogy oké gyerekek, most kérünk két hónapot, amíg rendesen ledokumentálunk mindent, specifikáljuk, hogy mi hogyan működik (hogy ne csak a tesztkódban legyen lefektetve a specifikáció), hogy esetleg más csapattal is lehessen a kód megosztása nélkül a szoftverről beszélni, integrálni azt. Ez nem megy agilisen.

"Az agilitással pont ez a megfontoltság veszett el, hiszen két hétre előre felesleges megfontoltnak lenni, utána meg úgyis minden megváltozhat, és a tesztek úgyis lefednek mindent, nem érdekes.
Érdekes helyen dolgozhatsz(dolgozhattál) ha ez a meglátásod. Jobban mondva érdekes emberekkel. Nálunk 2 hetes sprintek vannak és egyik csapat se ilyen hozzáállással megy neki a dolgoknak. (100+ csapat) Ha kell akkor inkább rolled-over de amíg nincs teljesen körüljárva a probléma, fejlesztői és tesztelői tekintetből is. Persze lehet vannak olyan cégek akik sz@rnak a dolgokra és bármit kiadnak a kezükből ami működik. Ellenben visszatértünk oda, hogy maga a minőség a csapattól függ nagyban. A módszertan a buisnessnek segtíség, hogy közelebb kerüljenek a csapathoz, valamint a csapatnak, hogy megmaradjon a motiváltság.

return signResponse.getSignForUser("zeletrik").map(SignResolvable::getSign).orElse(StringUtils.EMPTY);

Ha körül van járva a probléma, akkor felesleges iterálni, nem? Hiszen mindenki ért mindent, és nincs értelme az agilitásban jelentkező visszacsatolásnak. Vagy kiderül, hogy mégsem ért mindenki mindent, aztán lehet újratervezni a 2 éves kódbázisokat.

A minőség a csapattől függ, a módszertan pedig a businessnek szól. Pont ez a lényeg. Az agilitástól nem lesz jó a minőség, ez egy hamis selling point. Az agilitás eszközkészlete pedig a waterfall projektekben is ugyanolyan jó.

Ellenben visszatértünk oda, hogy maga a minőség a csapattól függ nagyban.

Szerintem az, hogy erre mód van, nem csak a csapat érdeme. Simán lehet olyan üzlet, akik azt mondják, hogy ez nekik nem érdekes, csak gyorsan üssenek a fejlesztők össze valamit amit ki lehet tenni.

Nem minden cégnek ugyanazok a dolgok fontosak.

> Ostor folyamatosan van, mert a business mondja meg, mi legyen, changes welcome.

Azert alljon mar meg a menet!

A business _kerhet_ feature-t, a business _prioritizalhat_, de a business technikai kerdesekben nem kompetens. A business se nem esztimalhat, se nem mondhatja meg, hogy technologiailag adott dolgot hogy kellene megvalositani. A feljesztoi csapat nem valami kozgazt, meg 2 ev managementet vegzett emberek rabszolgacsoportja, akiket ide-oda ugraltathat kenyere-kedvere.

Azt persze mondhatja, hogy a fejleszto csapat nem eleg gyors, nem eleg rugalmas, es lecserelheti az egeszet a francba.

Kar, hogy ezek utan, mikor a szarbol epult kartyavar osszedol, az ezen donteseket meghozok mar nincsenek az adott cegnel / pozicioban, hogy szamon lehessen rajtuk kerni a fogalmatlan donteseik kovetkezmenyeit.

#define nem megy

Nem lehet a szarul definialt, szarul meretezett ticketet fel nap alatt production-be rakni?

A project manager nem kepes prioritizalni, aztan csodalkozik, hogy fel napok elmennek ugy nevezett "context-switch"-ekkel?

Business ember beteszi a Nagyon Fontos Meetingjeit a nap kozepere, hogy az ember meg veletlenul se tudjon koncentralni egy huzamban 2 orat?

A ceg, es foleg a business oldal MEG MINDIG erolteti az open-officet, ahelyett, hogy nyugodt, szeparalt irodakba rakna a csapatokat? Nyilvan, hiszen igy rajta tudja tartani a szemet az o kis "kiralysagocskajan", gyonyorkodni, ahogy az "alattvalok turjak a folde kodot".

Egy project a szoftver-mernokokon bukik el legvaloszinubben? Na ne nevettess...

Nem is esztimál, és a technológiába se szól bele, ez így is van rendjén. Viszont ő mondja meg, hogy milyen change kell, mi a business driver, mit tud a versenytárs. Ő diktálja, hogy mit kell megcsinálni, és főként: mikorra. Mert ő fizeti a zenészt, ezért ő kéri a dalt. Az egy dolog, hogy a csapat ezt hogyan, mikorra, és mennyi pénzből tudja megcsinálni, ha meg tudja csinálni.

Viszont a changes welcome kultúra pont azt mondja, hogy vagyunk annyira faszák, meg mindenféle eszközzel felszereltek, hogy lazán követjük a változásokat. Pedig eközben valójában a világ programozóinak többsége nem ilyen.

Viszont az agile manifesto készítői anno nem is az átlagfejlesztők voltak, szerintem ők sem gondoltak arra, hogy lesznek majd 6 hónapos programíró-iskolák meg két éves developer boot campek, és bizony, az onnan kikerülő embereknek kéne tudnia, hogyan kell tesztelhető kódot írni, hogyan kell refaktorálni, milyen refaktorálási minták vannak, amiket alkalmazni kell ahhoz, hogy az agilitás működjön. Ehhez viszont előtte éveket kell tanulni, vagy tapasztalni. Egyetemistákat belerakhatsz egy agilis projektbe, abból jó nem fog keletkezni.

Top-notch emberekkel persze ezek a dolgok természetesek, de a jelenlegi ütemben, amikor a programozók többsége kevesebb, mint 3-5 év tapasztalattal rendelkezik, ez csak álom.

Igaz amit mondassz.

Amugy pont ezert vagyok a belso kepzes ideaja mellett. Vannak mar csirai, brown bag lunch, meg kulonbozo knowledge-share kezdemenyezesek, de en a. legalabbis egy alap, 1-2 hetes kurzust beiktatnek az uj kolleganak a kod es annak mnosegi kovetelmenyeirol, architecturalis kerdesekrol, toolok, code review es soft skill mellett, vagy b. 'a pont' + folyamatos, es legfokepp _szervezett_ es _tematikus_ oktatasi programot szerveznek, senior kollegak megfelelo osztonzesevel.

Az alulrol jovo kezdemenyezesek alapvetoen jok, de termeszetszeruleg valtozo minoseguek, szoval egy jo ceges training program csakis a megfelelo emberek kozremukodesevel alakithato ki. Gondolok itt organisational psychologysttol kezdve magas technologiai tudassal rendelkezo architectekekre es seniorokra, erdekes business eloadasokra, stb.

A szajhagyomany utjan terjedo informacio a legrosszabb, sose tudhatod, hogy ez csak hallomas, vagy konkret teny.

Ugyanugy nem megoldas a confluence se, mert egy jol strukturalt, interaktiv eloadas sokkal hamarabb megerteti az emberrel a dolgokat. Nem is beszelve arrol, amikor odaloknek az ember ele egy ceges online learning accountot, hogy "nesze, tanulj".

Nyilvan, legyen az ember onallo a tanulasban, de azert ha a ceg dont egy technologia mellett, akkor aldozzon mar arra is, hogy megfelelo minosegben es melysegben betanitja azt a kollegaknak.

Az IT tul nagy ahhoz, hogy csak ugy tok velelenul egybe essen a hobbim a ceges iranyvonallal. Marpedig az utobbival jobb lenne csak ceges kereteken belul foglalkozni, ugy oszinten.

Szerk: felreertesek elkerulese vegett, nem a sult galambot varom, hanem van amihez en ertek jobban (es tartok belole eloadast), van amihez meg mas. Meg vannak olyanok is, akik nem szeretnek eloadast tartani, hiaba nagy a tudasuk...

"Ő diktálja, hogy mit kell megcsinálni, és főként: mikorra."

Ez nem is feltétlenül probléma. Pl. ha a vevőd karácsonyi szeretne villantani valamivel, akkor nem veszi jó néven, ha csúszol pár hónapot. Azt viszont meg lehet tenni, hogy szólsz, hogy minden várhatóan nem fér bele, vannak kockázatok stb. Ekkor át lehet beszélni, hogy mi beáldozható.

És menet közben is tudsz szólni, ha valami csúszás van vagy gyorsabban kész lett. Ez a dinamikus kapcsolat azért jó, mert az üzleti döntések kompetens emberek kezében lesznek. Pl. a vevő mondhatja, hogy a dinamikus skálázódás nem a legégetőbb probléma, de az adatbázis konzisztencia igen, mert az a felhasználói élményt súlyosan befolyásolja. Vagy valami kis mütyür még kéne. A "changes welcome" nem gond, amennyiben érthető, miért is lesz így még tutibb a cucc.

"ők sem gondoltak arra, hogy lesznek majd 6 hónapos programíró-iskolák"

De miért akarnál 10 tehetségtelent megfizetni, ha 2 tehetséges jóval olcsóbb és sokkal termelékenyebb? 10 x 400eFt helyett csak 2 x 1MFt és 100x annyi eredmény. Avagy miért akarnál rollerrel betont szállítani?

"De miért akarnál 10 tehetségtelent megfizetni, ha 2 tehetséges jóval olcsóbb és sokkal termelékenyebb? "
Mert mondjuk nincs 2 tehetséges, mert munkaerőhiány van. Ez a nagy valóság.

Ha van 100 betonszállító, de 1000 helyre kell betonszállító, akkor 900 helyen rollerrel fogják megoldani.

Persze, csak egyre kevésbé buli. :)

Egyébként meg nem csak a végletek léteznek, a néha más dimenzióba emelkedő lisp guruk és a 2 hetes gyorstalpalót végzett kódmázoló biorobotok között szerencsére van átmenet. Követelményektől függően bőven elég lehet 2 közepes fejlesztő és mellé 2-3 szakmunkás ugyanazért/kevesebb pénzért, mint 2 csodabogár. Max 5 év múlva, mire már teljesen spagetti állapotba kerül a kód újraíratod az egészet a bánatba, esetleg akár egy frissített kurzussal (úgyis elavulnak a használt frameworkök is). Nem feltétlenül sokkal drágább mint a folyamatos refaktorálgatás, megint csak követelmény függő.

Cserébe ha egy fejlesztőd dobbant, vagy ne adj isten átmegy rajta a fél hatos gyors, kevésbé vagy nyakig a szarban. Azért ez se elhanyagolható szempont.

Nem, nem, nem és nem! A "Changes welcome" azt jelenti, hogy amint a projekttel előrehaladva jobban látjuk a dolgokat, esetleg rájövünk, hogy más fontosabb. Nem toljuk végig a tervet, ha látjuk, hogy úgy nem lesz jó a végeredmény. De ezek nem eszement váltások.

"Elérheted úgy is, hogy teljes körű tervezésed van előre, és minden rész le van vezetve formálisan."

Igen. Csak az esetek túlnyomó többségében senki nem tudja előre, hogy pontosan mit is akar, vagy ha igen, akkor menet közben rájön, hogy tévedett. Ez igaz az össze résztvevőre a vevőtől a kódolóig. És ekkor jön be az Agile és az olyan alkalmazott eszközök, mint a CI és a tesz automatizálás. Ahol nincs rá szükség, ott ne használjanak Agile-t.

"két hétre előre felesleges megfontoltnak lenni, utána meg úgyis minden megváltozhat"

Hát, az elég nagy baj volna. Az, hogy a cél nem tű éles még nem at jelenti, hogy az M7-esen rájössz, hogy a Balcsi helyett az Alpokba mennél síelni.

"Prototipizálásra kiváló"

Prototipizálásra az Agile nem jó. Lásd "continuous delivery of valuable software".

"kérünk két hónapot, amíg rendesen ledokumentálunk mindent, specifikáljuk, hogy mi hogyan működik"

Az Agile nem mond olyat, hogy terv nélkül dolgozz. Te egyszerűen nem az Agile-ról beszélsz.

Nem vonom ketsegbe, hogy lehet az agile-t jol is hasznalni. De nekem is az volt a tapasztalatom, hogy a gyakorlat sokszor nem igazolja vissza az elmeletet. Ennek az az oka, hogy nem teljeskoruen ertik meg a modszert, csak az kell belole, ami a business-nek tetszik. Szervezet fuggo, hogy a business mennyire tud beleszolni a muszaki reszbe, mennyire van egyeb modon (koltseg, hataridok, stb.) befolyassal.

Ergo nem is igazán agile-ról beszélünk. Én is dolgoztam olyan helyen ahol elméletileg agile volt közbe meg csak valaki ovlasott valamit, valahol ami szerinte jó lesz, ráhúzták az egészet, megbukott == szar az agile. Hát persze.

return signResponse.getSignForUser("zeletrik").map(SignResolvable::getSign).orElse(StringUtils.EMPTY);

Az agile nem csodafegyver, ugyanugy emberek alkalmazzak, jol vagy rosszul. A vita arrol szolt (szerintem), hogy az agile milyen problemakat old(hat) meg vagy akar generalhat, es hogy mik az ervek mellette / ellene, es ezek hogyan jelennek meg a gyakorlatban. Szerintem szinvonalas es erdekes volt, amit ritkan lat az ember, sajnos itt a HUP-on sem ez a jellemzo. A tema sokkal komplexebb, minthogy egyszeru hitvita-szeru "agile jo" vagy "agile szar" kijelenteseket lehessen tenni. Szerintem pont ez jott ki nagyon szepen a fentiekbol.

Persze ne érts félre nem is ezt cáfoltam.
" Ennek az az oka, hogy nem teljeskoruen ertik meg a modszert, csak az kell belole, ami a business-nek tetszik. "
Ezt a mondatot vitattam mindössze. Ha csak pár dolgot veszünk át akkor azt ne hívjuk agile-nak. Attól mert mondjuk valakinek tetszik és átveszik azt, hogy na akkor mostmár sprintekben fogunk dolgozni attól nem lesz hirtelen agile a módszertan. Aztán meg ha bedől akkor azt szidják. Egyébként pont egy ilyen helyzetben voltam. Semmi de semmi nem volt meg az agile-hoz majd behozták, hogy akkor legyenek 2 hetes sprintek és onnantól mindenki abban a hitben élt, hogy akkor ez agile. Amikor meg kezdett összedőlni az egész akkor az ellen volt mindenki.

return signResponse.getSignForUser("zeletrik").map(SignResolvable::getSign).orElse(StringUtils.EMPTY);

Igen, jol ismerem az ilyesmit. :-) Valami ilyesmi beszlegetes remlik az egyik cegtol, ahol a management eroltette az agile bevezeteset, mert termeszetesen a korabbi projekt problemak nem management hibak hanem modszertani hianyossagok voltak, haha. Mondom, hogy azt tudod, hogy akkor biztositani kell, hogy egyszerre csak egy feladatra koncentralhassak (jellemzoen volt 5-8 parhuzamos taszkom). Siri csond a tololdalon....

Hány olyan fejlesztőt látsz, aki agile csapatban akar dolgozni, utána meg panaszkodik, hogy folyamatosan változnak az igények? Aki agile csapatban akar dolgozni, mert megtanították neki, hogy a waterfall egy szar, utána ne panaszkodjon, hogy folyamatosan változnak a követelmények.

Olyan emberre nem emlékszem, aki azért panaszkodott, mert folyamatosan változtak az igények. Olyan embert viszont igen, aki felháborodott azon, hogy amin dolgozott két hónapig, az hirtelen obsolete lett és gyakorlatilag kidobták.

Gondolom, ez kb. ugyanaz pepitában.

De én inkább úgy értettem a kérdést, hogy szerintem a fejlesztő nem igazán vállalják magukra ezt vagy azt. Nem kérdezi meg őket senki, hogy ez vagy az az agile principle mehet-e.

De azt hiszem, értem, hogy mit akartál mondani. Én is találkoztam sok olyan emberrel, akik hallottak agile-ról, dolgoztak scrum projekten, de fogalmuk se volt, hogy igazából mi miért történik.

+1

Problémákat felismerni és ötletet lopni a megoldásukhoz jók ezek a módszertanok, egy kevésbé vén róka (de nem tehetségtelen) projektvezetőnek mankót tudnak adni, a tapasztalatszerzési folyamatában bizonyos szinteket segíthetnek kevesebb szívással megugrani. De messze nem csodaszerek, egy tehetségtelen csapat/projektvezetőn, láma menedzsmenten vagy kókler fejlesztői csapaton bármilyen módszertan mellett ugyanúgy ki fog siklani a projekt.

Illetve indikátornak még jó tud lenni, ahol kipécéznek egy ilyen módszertant és szolgalelkűen azt nyomatják orrvérzésig, ne adj isten milliókért kiképzett fekete öves 5 danos kanban scrum ninjutsu rocksztár viszi a projektet, akkor erősen gyanítható, hogy a fentebb felsoroltakból legalább a kókler csapaton kívül mind fennáll.

Egyetértek abban, hogy a csapaton múlik nagyrészt a minőség. Viszont a módszertanon múlhat a csapat moralitása. Egy jól szervezett csapat jobban dolgozik mint akik csak úgy el vannak engedve esetleg néhány szabály van csak felállítva. Dolgoztam sima ticket rendszerben, az nagyon demotiváló tud lenni, főleg ha gyorsabb vagy mint a csapat többi tagja és napokat-heteket(!) ülsz a semmin mert épp nincs mit csinálni, nincs hozzád assignolva semmi. Ellenben most egy Scrum/Kanban keverékben dolgozok, szépen szervezve (igaz nagy multi) és hihetetlen pörgős tud lenni. Mindenki tudja a helyét, nincs fejetlenség, mindenki a saját dolgára tud figyelni így abból a legtöbbet kihozni.

return signResponse.getSignForUser("zeletrik").map(SignResolvable::getSign).orElse(StringUtils.EMPTY);

A kedvencem a "főnöknek szólok" kezdetű, mert számomra az okozza a legkevesebb adminisztrációt vagy overhead-et, de ettől még nem tartom a leghatékonyabbnak :)

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

email, waterfall és szólok a főnöknek szürreális keveréke a nagy magyar rögvalóság.

Az agilitás talán működhet, ha infósoknak készül a termék. De inkább nem.

--
GPLv3-as hozzászólás.

Ha már pont ezt dobta elém ma a hup, akkor itt is felvetem, hátha jön értelmes ötlet: tegnap azon gondolkoztam, hogy mit lenne érdemes használni projekt szervezésre, ha olyan, önkéntes programozói munkát akarok szervezni, aminek jellemzője az 1-2 aktívabb ember (heti 5-10 óra hasznos munkavégzés), 1 valamennyire aktív projektmenedzser (napi negyed óra max.) és 5-10 olyan arc, akik heti/havi 1-5 órákat tudnak még beletenni a projektbe. A meló ritkán egy emberes (vagy azért, mert mondjuk nincs rá full stack dev, vagy mert tényleg nem egy emberes :D ). Azt már kezdem vágni, hogy mi az a módszertan, ami overkill, de hátha van valakinek releváns és hasznosítható tapasztalata. Sajnos a nyílt forráskód használata sem igazán lehetséges, habár azt érzem, hogy ez egy logikus út lenne afelé, hogy minél több erőforrást be lehessen csatornázni egy-egy projektbe. Szóval bármilyen ötletet, jó tanácsot szívesen fogadok :)

Ez így egy-az-egyben átvéve leginkább apró fejlesztések, bugfixek outsourceolására működhet (mondjuk tál rizsért dolgozó ázsiai szakmunkásoknak), ha egyébként van egy normális munkamenetben dolgozó core teamed, aki az irányokat megszabja, nagyobb fejlesztéseket (legalább) elkezdi, code review-t végez pr esetén, kapcsolatot tart a "melósokkal"; azaz a lényegi munkát végzi.

Összetettebb, komolyabb kollaborációt igénylő feladatokat ilyen rendszerben nem igazán lehet elvégezni. Egyrészt issue trackeren keresztül napos delayekkel passzolgatva a labdát nem lehet megbeszélni semmi összetettet, másrészt ha csak nem árazod durván felül az ilyen feladatokat nem fogja őket bevállalni senki, nehezen megfogható a rászánandó időablak (főleg ha máson is múlik, kollaborálni kell hozzá), mindenki az egyszerűnek tűnő fél órás gyors bugfixekre fog lecsapkodni, mint gyöngytyúk a takonyra.

Ezt szinte bármi módon megoldhatod.

Ha tudjátok előre, hogy ki mennyit tud dolgozni, akkor simán mehet pl. Scrum is, és a sprint tervezéskor figyelembe kell venni a kapacitást.

Ha előre nem ismert, hogy ki mennyit tud dolgozni, akkor én simán felállítanék egy Kanban boardot, aztán mindenki felvehet róla azt, amit tud, amikor van szabad kapacitása.

Persze azt, hogy a több emberes feladatokat hogyan oldjátok meg, azt nektek kell kitalálnotok.

Ha csak különböző skillek kellenek, de egyébként nem kell kézenfogva dolgozni, akkor csak fel kall bontani a kifejlesztendő feladatokat részfeladatokra skillek szerint.

Ha konkrétan együtt kell dolgozni, akkor nektek kell kitalálnotok, ez hogyan oldható meg, ez nem a projekt vezetési módszertan feladata.

Sajnos nem tudunk azzal sem tervezni, hogy ki, mennyit és mikor ér rá. Amúgy igen, a javaslatodhoz hasonlóan én is azt próbálom/próbáltam meg, hogy minél atomizáltabb részekre bontsam a dolgokat, minél kisebb issue-kra, aztán szabad rablás van. A hátránya ennek, hogy a pm oldalra rak többlet feladatot, de hát persze olyan nem lesz, hogy senki sem dolgozik és minden elkészül :D

Az "egyéb agile módszertan" opciót választottam.
Azt a szervezetlenséget ami nálunk van, mutogatni kellene elrettentő példa gyanánt.
--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-

Mit érdemes szerintetek elolvasni annak, aki nagyvonalakban meg akarja ismerni ezeket a mai divatos módszertanokat lehetőleg elfogulatlan forrásokból?

wikipedia

Persze kérdés, mennyire akarod részletesen megismerni.

Wikipedia tényleg jó, ha csak annyit akarsz tudni, hogy eszik-e vagy isszák.

Mindegyikről vannak könyvek, de azok, amiket ismerek, nagyon részletekbe menőek, szóval ha a kettő szint között kellene valami, abban nem tudok segíteni.

Köszi azért. Wikipedia jó forrás, néztem is, viszont sajnos túl tényszerű, és száraz. Ráadásul egy szócikk egy bizonyos módszertannal foglalkozik, sokkal izgalmasabb lenne valami komolyabb tapasztalatra építő áttekintést olvasni. Amiből ugyan szintén találtam, csak túl részrehajlónak éreztem őket. Persze ha eleget olvasok, akkor azért lesz valami balansz, szóval végül is megvagyok :)

Minden módszertan kialakulásához valami jellemző probléma vezetett, amit meg akartak a módszertan segítségével oldani. Próbáld esetleg ebből az irányból megközelíteni a kérdést.

Pl.
waterfall - reakció a tervezés és a dokumentáltság teljes hiányára
xp majd agile - reakció a waterfall merevségére és a rossz alkalmázásból származó nagy overheadjére
stb.

Hogy melyik agile módszer éppen mit tűz zászlajára (scrum -> sprint szemlélet, kanban -> board szemlélet, stb.) az jól mutatja, hogy mit tart fontosnak, ergo miylen problémát akar megoldani.

De ugyanúgy, ahogy a programnyelvek esetén, itt sincs szent grál. A szervezet és a feladat nagyon komolyan befolyásolja egy módszer alkalmazhatóságát és sikerességéet. Ráadásul egy csomó helyen félreértelmezve fogják alkalmazni, és annak alapján alkotnak véleményt, tehát amiket olvasol nem feltétlenül hitelesek.