Agilné programovanie v praxi

[rooobertek]

Ahojte

O agilnom programovaní som už veľa počul aj čítal, ale tuším som ešte nepočul nikoho z okolia, že by niečo z toho úspešne zaviedli. V jednej knihe som sa dočítal, že to akosi v európskych vodách moc nefunguje.
Máte niekto skúsenosti s úspešným zavedením niektorej agilnej metodológie vývoja softwaru? Alebo aspoň čiastkovo? A aké sú dojmy?

[Reklama]

[jan.palencar]

Ahoj,
súhlasím. Je to iný zpôsob práce. Je to v našich končinách (ČR a SR) skôr okrajová záležitosť.
Dobré je si ujasniť čo to vlastne to Agílne programovanie je.

Sám som sa skôr stretol s Agílnymi metodológiami. Pekný obrázok je tu
http://www.sdtimes.com/blog/post/2011/02/16/agile-enterprise.aspx

Do tohto klobúka potom spadá, napríklad SCRUM, XP, Continuous Integration, Iteration a iné metodiky, ktoré môžu a nemusia pomôcť vo vývoji SW v danej spoločnosti.

Niekedy mi to príde ako buzzword/čarovná palička, ktorá odstráni všetky problémy vo vývoji sw. Nie je to tak.
Problémy neodstráni, ale veľmi okato môže pri správnom použití metodík na ne upozorniť. A tak je možné sa novým podmienkam rýchlo prispôsobiť.

Osobne mám skúsenosť so zavádzaním Agílnych metodík. Môj postup bol skôr o pozorovaní už existujúcich procesov a zvyklostí práce v spoločnosti. Na to som naviazal a z "klobúka" som sa snaži postupne pridávať metodiky, ktoré nám môžu uľahčiť vývoj.

Vždy, pri každej pocesnej zmene je dôležité, aby všetci úšastníci (nielen developeri) nový proces poznali a zoznámili sa s ním. Jednak pochopia výhody a môžete v týchto ľuďoch mať oporu zavádzať podobné zmeny.

Jano

[astarus]

Dobré je si ujasniť čo to vlastne to Agílne programovanie je.
...
Do tohto klobúka potom spadá, napríklad SCRUM, XP, Continuous Integration, Iteration a iné metodiky, ktoré môžu a nemusia pomôcť vo vývoji SW v danej spoločnosti.

Suhlasim s tym, ze tazko povedat, co to je. Osobne som sa stretol so Srumom, test driven develoment, ...

Scrum ma velku vyhodu pre veduceho timu, pretoze za par minut ziska prehlad o tom, co sa robilo minuly den. Pre ostatnych ludi mi pride, ze to nema az taky velky prinos.

Test driven - pekna idea, ale ked sa zneuzije, tak je problem. Testy urcite patria k vyvoju, ale pokial ma niekto nuti najprv napisat testy a a z potom navrhnut interface, tak kdesi je chyba... Na druhej strane tento pristup pomaha, pokial nemas dobru analyzu - teda, je dobry, aj ked ju mas, ale ked ju nemas, tak ta prinuti sa zamysliet nad tym, co by tam malo byt a ako by to malo fungovat.

Continues integration - som este nepocul, ze by to malo spadat do AP. Tak ci tak to beriem ako zaklad na projekte, kde je ostro viac ako jeden vyvojar. Je to neuveritelna pomoc a stoji to minimum prace.

Ak mas konkretnejsie otazky, pytaj sa

[martin]

najprv napisat testy a a z potom navrhnut interface, tak kdesi je chyba...

test vs. implementace, nikoli návrh interface

[jan.palencar]

Continues integration - som este nepocul, ze by to malo spadat do AP. Tak ci tak to beriem ako zaklad na projekte, kde je ostro viac ako jeden vyvojar. Je to neuveritelna pomoc a stoji to minimum prace.

@astarus
Je toho plný internet napr. http://en.wikipedia.org/wiki/Agile_software_development.

@martin
Súhlas. Bez kontraktu (interface) toho čo programujem aj testy ťažko napíšem.

[Reklama]

[srigi]

My (Websupport) bezime uz skoro rok poriadny scrum. Obcas o tom niekto (nas scrum master) ublogne.

Moje hodontenie: nie som z toho az taky nahypovany, ale je to zatial to najlepsie co sme skusili. Velkou vyhodou je naozaj dobry prehlad o praci, vsetci sme sa naucili poriadne zadavat/presuvat tasky v project-managment softe (Version One). Manageri tak maju svoje cisla, ktore stale kceli. U programatorov to naopak vedie k nezmyselnemu sutazeniu - kto viac odrobi (hodin). Velmi si ale pochvalujem retrospektivny meeting, je to naozaj pekny sposob revizie iteracie. Soft vyhadzuje naozaj zaujimave cisla.

Co su naopak neskutocna otrava - planing meetingy v prvy den iteracie. Je to snaha o rozkuskovanie planovanej dodanej funkcnosti na backlogy a tasky. Pomocou pokra kazdy hodnoti narocnost backlogu/tasku (v cloveko-hodinach). Je to neskutocne otravny den, ked sa skoro vobec neprogramuje (uz sa stalo, ze sme planing meeting koncili o 17:00) a snazime sa predvidat, co a ako sa bude kodit.

V konecnom dosledku sme ale dosli k peknym vysledkom:
 - oprava bugov zabera teraz cca 15% casu iteracie
 - presnost planovania je cca 85%
 - pomaly sa zacinaju aplikovat "free friday", ale dopoludnie zabere retrospective meeting
 - stihame
 - burrdown graf krasne indikuje schopnost dodat funkcnost v iteracii

Je ale okolo toho dost rezie. BTW zatial vobec neriesime Unit testy.

[astarus]

@astarus
Je toho plný internet napr. http://en.wikipedia.org/wiki/Agile_software_development.

To je prave ten problem - je toho plny internet. Ale nikde nemas presnu definiciu toho, co tam patri a co nie. Je tam obrovska seda zona. Ale snad sa to casom vykrystalizuje (tak za 10 rokov

Co su naopak neskutocna otrava - planing meetingy v prvy den iteracie. Je to snaha o rozkuskovanie planovanej dodanej funkcnosti na backlogy a tasky. Pomocou pokra kazdy hodnoti narocnost backlogu/tasku (v cloveko-hodinach). Je to neskutocne otravny den, ked sa skoro vobec neprogramuje (uz sa stalo, ze sme planing meeting koncili o 17:00) a snazime sa predvidat, co a ako sa bude kodit.

Neviem, ake velke mate projekty, ale u nas tie mitingy nie su zdaleka take dlhe. Minimalne tam nechodi kazdy, ale len hlavni a potrebni ludia. Vacsinou mame za 2 hodiny koniec. Sice je pravda, ze som uz zazil aj poriadne zabite planovanie, ale to bolo hlavne tym, ze tam bol kazdy a kazdy sa mohol vyjadrovat. Mensia diktatura obcas nezaskodi

[jan.palencar]

To je prave ten problem - je toho plny internet. Ale nikde nemas presnu definiciu toho, co tam patri a co nie. Je tam obrovska seda zona. Ale snad sa to casom vykrystalizuje (tak za 10 rokov

@astarus
No praveze si dovolim povedat, ze je to inak.
Napriklad kniha http://www.lulu.com/product/paperback/patterns-of-agile-practice-adoption/1196933 mi pride celkom strucne a dobre spisana. Samozrejme ich je viac a ak ma niekto doplni budem len rad.

JP

[alefo]

Co pocuvam, tak z agilnych technologii si vo firmach nachadza svoje miesto Scrum, napr. v Kosiciach to uz zdaleka nie je uplne obskurna zalezitost.

Scrum ma totiz iste zasady, su nanho kurzy, know-how, planovanie je dostatocne rigidne a filozoficky to nie cista anarchia a hmla ako napr. XP.

[Ondřej Novák]

Vývoj používá scrum, webmasteři u nás jedou v kanbanu.

[WERT]

Agilní programování? Myslí se tím waterfall? 

[Juro]

Nevyhodu takychto metodik vidim v ich ,,ideologickosti''. Dnes mas team 4 programatorov, ktorych bavi TDD a zalozis na tom vyvoj projektu. Zajtra ti dvaja odidu a budes ich musiet nahradit.

Pridu nejake zivotopisy a z toho vzidu nejaki kandidati na pohovor. A ked z toho vzide niekto kompetetny, nezahodis ho len kvoli tomu, ze to neni TDD nadsenec a projekt bude dalsie 4 mesiace stat, lebo hladas ludi.

Pozn: to ze das do inzeratu, XP, SCRUM, TDD neznamena, ze ti tam dojdu len ludia co  o to maju zaujem. Nie kazdy vybera pracu podla metodiky.

[alefo]

Nie je to syndróm všetkého nového? Keby som mal 4 ľudí fičiacich, ja neviem, na Grails a dvaja mi odídu, tak rovnaký problém zohnať človeka, ktorý dokáže veľmi rýchlo naskočiť do projektu a zvládnuť technológiu, aj keby bol expert v niečom inom.

[iwtu]

Nie je to syndróm všetkého nového? Keby som mal 4 ľudí fičiacich, ja neviem, na Grails a dvaja mi odídu, tak rovnaký problém zohnať človeka, ktorý dokáže veľmi rýchlo naskočiť do projektu a zvládnuť technológiu, aj keby bol expert v niečom inom.

skor vsetkeho, co nie je na kazdom rohu.