Allan Kelly, specializat în zona de business a dezvoltării software, axat pe training-ul şi consilierea companiilor în procesul de dezvoltare software Agile, vine pentru prima dată în România, în cadrul evenimentului Agile Day.
Allan Kelly va susţine masterclass-ul "Requirements, User Stories and Backlogs" pentru persoanele care doresc să devină experţi în procesul de dezvoltare software Agile, în 16 Septembrie 2015. Allan Kelly a vizitat şi Silicon Valley, cunoscut drept casă pentru multe dintre cele mai importante companii de înaltă tehnologie şi consideră că acest loc este „inima industriei noastre de software”.
Libero Events: De ce ai început să lucrezi cu metodele Agile?
Allan Kelly: Întotdeauna am considerat că prima mea muncă Agile a fost în 1997. Îmi amintesc cum whiteboard-ul era amplasat deasupra biroului meu pentru a urma fiecare pas, făcând primele teste de dezvoltare, parcurgând lunar release cycles, adică suma stadiilor de dezvoltare. Dar asta se întâmpla înainte ca acest cuvânt, Agile, să fie folosit. Şi când mă uit la munca din 1994, realizez că Agile de atunci arăta diferit.
L.E.: Raportându-ne la experienţa ta profesională, care sunt avantajele Agile
A.K.: Oamenii se simt mai bine cu privire la munca lor. Văd progresul, primesc în mod regulat o asigurare a faptului că lucrurile se îndreaptă într-o direcţie bună. Grupurile de dezvoltare realizează faptul că pot finaliza deadline-uri, că pot să livreze ceea ce dezvoltă în software în aproximativ timpul necesar de care au nevoie. Şi cu cât fac asta mai mult, cu atât sentimentul e mai pozitiv cu privire la ce primesc. Şi companiile realizează astfel că dezvoltarea software nu e un pahar pe jumătate gol, ci un pahar pe jumătate plin.
L.E.: Metodele agile sunt foarte apreciate, dar ne poţi pune în temă şi dezavantajele folosirii acestor metode?
A.K.: Când începi să foloseşti Agile, lucrurile arată întâi cel mai rău înainte să se contureze în ”mai bine”. Unele unelte Agile te ajută să progresezi, cum sunt, de exemplu, iteraţiile. Dar cele mai multe unelte din kit-ul Agile te ajută să înţelegi problemele existente. Multe dintre probleme există deja, dar poate tu nu le mai poţi rezolva, trăieşti cu aceaste probleme şi renunţi să mai încerci să le schimbi. Introdu Agile şi toate aceste probleme le vezi mai bine. Dacă nu le foloseşti, nu obţii ceea ce e mai bun din proces.
Dacă eşti norocos, metodele Agile au o soluţie pentru problema pe care o întâmpini, dar s-ar putea să fie nevoie să inventezi propriile soluţii sau să accepţi realitatea.O problemă pe care am observat-o în mod evident este atunci când cineva din echipă nu îşi face partea. Poate pentru că nu au calităţile necesare, poate că şi-au pierdut din încrederea în echipă sau poate că vor ceva diferit. E dificil atunci când cineva nu este persoana potrivită pentru a face parte din echipă.
L.E. În ce mod ţi s-a schimbat perspectiva despre software în timpul vizitei în Silicon Valley?
A.K.: Am fost norocos că am putut ajunge în Silicon Valley şi că am trecut de la boom-ul .com la nereuşita .com. În câţiva ani, o sumedenie de idei nemaiîntâlnite au fost fondate, căci tehnologia le-a făcut posibile. Însă odată ce nereuşita a început, a fost necesar să faci vânzări. Deci primul lucru învăţat aici a fost: nu contează cât de inteligentă e tehnologia, curând sau foarte curând e necesar să generezi venituri. Dacă nu reuşeşti să generezi venituri, atunci poate nu e ceea ce te pricepi să faci.
Al doilea lucru pe care l-am învăţat a fost acela că problemele din industria software sunt universale. Nu există un loc minune unde programatorii să scrie codul perfect, unde testerii sa nu fie nevoie să raporteze bug-uri (erori) sau oamenii din producţie să nu fie frustraţi de ritmul de dezvoltare.
Este inima industriei noastre de software şi aştept să rămână la fel cel puţin până la finalul carierei mele! Toţi ar trebui să ne dorim să avem un pic de Sillicon Valley în noi.
L.E.: În ceea ce priveşte experienţa profesională, ai lucrat cu Virgin Atlantic Airways, Merrill Lynch, lastminute.com (part of Sabre Tavelocity), BBC, Fugro, Thompson-Reuters. Privind în urmă, cum au fost aceste experienţe?
A.K.: Companiile mari aduc cu ele multe probleme. De aceea, prefer să lucrez cu companiile mici. Şi acestea au problemele lor, însă e mult mai uşor să treci de ele pentru a ajunge la clienţi şi la ceea ce au nevoie cu adevărat. Companiile mari se învelesc în proceduri, bugete, schimbări de programe şi îngreunează ceea ce ai de realizat. Asta nu înseamnă însă că e imposibil să lucrezi într-o companie mare, poţi realiza lucruri frumoase acolo şi resursele disponibile îţi oferă oportunitatea să faci mai multe ca într-o companie restrânsă. E parte din motivul pentru care marile companii se asociază cu startup-uri şi chiar le cumpără, căci acestea pot creşte repede, pot să inoveze.
L.E.: Ai scris 2 carti despre software. Care sunt subiectele abordate?
A.K.: Sunt trei deja. Xanpan este ultima, propria mea contopire între Exteme Programming şi Kanban, cum arată şi titlul. Xanpan este diferită, pentru că am scris-o cu LeanPub, care este o platformă foarte diferită în scriere şi publicare. Prima mea carte, Changing Software Development se axează pe rolul cunoaşterii şi învăţării în dezvoltarea software. Defineşte complet filosofia mea: crearea de software este o activitate de învăţare. Mai ales dacă ne gândim la aceasta din perspectiva în care toate se aranjează la locul lor.
Cea de-a doua carte, Business Patterns for Software Developers e complet diferită, abia menţionează Agile sau Lean. E o carte dedicată tacticilor şi strategiilor folosite de inventatori de succes din domeniul software pentru a ajunge la business-ul de succes. În unele cazuri, e denumită greşit, oamenii se gândesc la „dezvoltatorii” din titlul cărţii şi îi asociază cu programatorii şi testerii, dar nu, chiar înseamnă „echipe care creează software”.
L.E.: Care sunt planurile de viitor cu privire la alte publicaţii?
A.K.: După Business Patterns am spus: „fără alte cărţi”, dar apoi am început să „mă joc” cu LeanPub şi aşa a apărut Xanpan. De fapt, această carte a fost un accident. (zâmbeşte) Mai sunt multe de spus, aşa că am şi Xanpan 2 în sistemul Lean Pub, dar progresul este destul de încet. În mare parte şi pentru că am ales să scriu o serie de articole despre User Stories pentru Johanna Rothman’s Agile Connection community (http://www.agileconnection.com/). Acum pare că aceste coloane vor fi incluse într-o altă carte despre LeanPub.
L.E.: Eşti specializat în business software development. În această toamnă, vei participa la Masterclass-ul Agile Day. Ce vor învăţa dezvoltatorii şi managerii de software la acest masterclass?
A.K.: Mă bucur că ai întrebat, tocmai am terminat de aşezat slide-urile. Voi avea slide-uri, dar de fapt va fi un curs interactiv. Vreau ca lumea sa experimenteze user stories, requirements şi backlogs, aşa că am planificat deja câteva exerciţii. Cea mai mare parte a timpului va fi dedicată exerciţiilor practice.
La un nivel de bază, aş vrea ca persoanele care vin la eveniment să plece cunoscândfoarte bine User stories (relatările utilizatorilor). Acestea sunt cele mai comune cerinţe tehnice din Agile, dar de cele mai multe ori acestea sunt folosite greşit.Câteodată glumesc că aceste User stories sunt atât de prost folosite pentru că sunt atât de uşoare.
Pe lângă acestea, e necesar să ai în vedere obiectivul general, să înţelegi cerinţele ca fiind distincte de specificaţii, şi mai important decât orice altceva: cunoaşterea beneficiilor.
E uşor să scrii cerinţe şi relatări de la utilizatori, dar câţi oameni stiu cât valorează fiecare relatare? Ce beneficii aduce? Dacă sunt mai importanţi banii decât o relatare? Acesta este unul dintre lucrurile pe care aş vrea să îi învăţ pe participanţi: cum să estimeze valoarea. E un exerciţiu pe care l-am pus în scenă şi înainte şi vă garantez că va fi şi amuzant.
