Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: rooobertek 06. 04. 2011, 09:41:16
-
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?
-
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
-
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 :)
-
najprv napisat testy a a z potom navrhnut interface, tak kdesi je chyba...
test vs. implementace, nikoli návrh interface
-
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 (http://en.wikipedia.org/wiki/Agile_software_development).
@martin
Súhlas. Bez kontraktu (interface) toho čo programujem aj testy ťažko napíšem.
-
My (Websupport) bezime uz skoro rok poriadny scrum. Obcas o tom niekto (nas scrum master) ublogne (http://blog.websupport.sk/category/technologie/).
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
Je toho plný internet napr. http://en.wikipedia.org/wiki/Agile_software_development (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 :)
-
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 (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
-
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.
-
Vývoj používá scrum, webmasteři u nás jedou v kanbanu.
-
Agilní programování? Myslí se tím waterfall? ;)
-
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.
-
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.
-
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.