Eu cred în capacitatea programatorilor deosebiți de a crea aplicații unice în moduri în care nu s-au mai făcut niciodată. Acest articol este povestea devenirii mele ca parte a unei echipe, alături de care am bătut un drum lung, de la un proces de dezvoltare software tradițional la unul agile.
În vara anului 2010 eram în căutarea unui nou loc de muncă. Întâmplarea a făcut să ajung la compania Syneto. Aici am fost repartizat la un proiect mai vechi, acum retras din dezvoltare. Cariera mea de programator de până atunci a constat în programare individuală. Mai precis, realizare programelor de dimensiuni mai reduse pentru companiile la care activam pe post de administrator de rețea.
Înainte să ajung la Syneto, atât la școală precum și la joburile precedente, am folosit tehnici de management de proiecte Waterfall. Începându-mi activitatea la această companie pe un proiect planificat într-o manieră similară, nu am putut decât să fiu fericit că voi activa într-un mediu cât de cât familiar. Puțin știam eu atunci despre ce mă așteaptă.
După câteva luni însă, anumite probleme legate de proiect au început să devină evidente. Lansările noilor versiuni erau mereu în întârziere și bugetul proiectului era pe cale să fie epuizat înainte de termen. Așadar o nouă viziune, gândire și mod de lucru erau absolut necesare.
Între anii 2000 și 2005 compania a avut o metodă de dezvoltare haotică. Pur și simplu se implementau funcționalități când și cum cereau clienții. Acest lucru poate părea agile la prima vedere, dar nu a fost așa. Nu exista o viziune pentru produs. Nu exista o metodă bine definită de ierarhizare a importanței a task-urilor. Managerul pur și simplu repartiza activitatea pe niște bilețele programatorilor. Nimeni nu știa exact ce e de făcut și încotro ne îndreptăm.
Până la mijlocul anului 2008 procesul de dezvoltare a devenit însă mai organizat. S-a trecut de la haos la Waterfall. Încă o aparență înșelătoare de progres. Nu numai că nu s-a îmbunătățit calitatea produsului, dar odată cu introducerea Waterfall, a crescut numărul de bug-uri și timpii de întârziere. Mai mult, bugetul asumat de un an și jumătate permitea doar trei lansări de noi versiuni considerând perioada de șase luni planificată cu mare grijă prin diagrame Gantt și documente complexe.
O schimbare era absolut necesară.
Orice echipă poate fi definită prin practicile de lucru care le aplică zi de zi. Găsirea și adoptarea continuă de noi astfel de practici în vederea îmbunătățirii procesului de dezvoltare este una din provocările majore în agile. Noi la Syneto, suntem ferm convinși că cea mai bună metoda de a găsi practicile potrivite pentru proiectul curent este de a adopta astfel practici potențiale, de a le face cu rigurozitate șase luni și de a evalua la finalul perioadei utilitatea lor. Dacă găsim o practică inutilă, renunțăm. Dacă o găsim perfectă, o continuăm. Dar cele mai multe ori identificăm doar părți izolate ale unei practici care ne pot fi de folos. În aceste cazuri, adoptăm aceste bucățele ca parte a procesului nostru în ansamblu.
Și acum țin minte acea zi însorită de primăvară când managerul nostru de atunci, Flavius, a venit cu o oră întârziere la lucru. Foarte necaracteristic lui, care de regulă era prima persoană sosită la serviciu.
La puțin timp după l-a trimis pe Bogdan, un coleg de-al nostru, să cumpere ceva. Eram prea concentrați și ocupați cu programarea, așa că inițial nu am acordat mare atenție evenimentelor. După câteva minute Bogdan s-a întors cu mai multe foi de A3, un munte de sticky notes și o grămadă de carioci. Pentru un moment lucrurile parcă erau interesante … dar programarea era mai interesantă. Ne-am "ascuns" toți în spatele monitoarelor noastre și ne-am continuat activitatea de coding.
Nu îmi pot da seama cât timp a trecut înainte ca Flavius să ne întrerupă din activitate. Spre surprinderea tuturor, pe perete, a fost construit un fel de planning board. Nu prea ne-am dat seama despre ce este vorba, dar Flavius a continuat cu explicații riguroase. Prima coloană "Release Backlog" va conține tot ce trebuie făcut în viitor. După aceea, vom lucra în iterații, și vom discuta ce vom face în fiecare iterație. Aceste lucruri vor fi puse pe "Sprint Backlog". După care, fiecare dintre noi își va alege ceva de făcut și va muta sticky note-ul în coloana "Development". Când e gata, notița se va muta în coloana "Done". Simplu, așa-i? Nu chiar…
Eu mă așteptam ca acest board să aibă un efect mai profund. Să aducă un pic de ordine în haosul nostru, care încet cu încetul a revenit peste planurile Waterfall. În continuare făceam prea multă planificare prealabilă și ierarhizam prea puțin task-urile.
A apărut însă un alt efect deosebit. Board-ul ne-a oferit o cale surprinzător de eficientă de a vizualiza activitatea noastră. Am început să conștientizăm ce și cât mai avem de făcut. Am putut să vedem la ce se lucrează, și mai presus de toate am putut să vedem tot ce s-a făcut.
Board-ul nostru era organizat destul de simplu. O coloană de Release Backlog conținea tot ce trebuie să facem până la următorul release. Sprint Backlog conținea ceea ce urma să facem în săptămâna curentă. Development conținea task-urile în lucru, iar Done cele terminate.
Am făcut primul pas în transformarea noastră agile. Am acceptat prima schimbare, aceea de a urmări întreaga activitate de development prin acele sticky notes.
Cu trecerea timpului, în mod treptat, Flavius ne-a introdus și în celelalte aspecte ale scrum-ului. După câteva săptămâni am avut prima retrospectivă, după aceea am început să facem planificare de sprint-uri - cu ocazia asta am învățat termenul de sprint. Culminând în miniretrospective de sprint și în daily standups.
Dar nu numai ședințele de scrum erau noi, ci și felul în care am început să comunicăm. Am învățat împreună termeni precum user story, story points, technical tasks, standup meeting, definition of done, etc. . Nu toate aceste lucruri erau noi în ceea ce privește activitatea noastră, dar până atunci nu erau bine definite și formalizate în spatele unor expresii.
După primele câteva lansări de versiuni noi am început să simțim efectele pozitive ale retrospectivelor și ale urmăririi activității cu grafice burndown. În anii ce au urmat am experimentat cu mai multe tipuri de retrospective, dintre care ne-au marcat activitatea două: good-bad-actions și the sinking ship.
Cândva pe la mijlocul lui 2011 am început să folosim board-ul într-un mod tot mai avansat. Iată câteva aspecte cheie ale revizuirii întreprinse:
Coloana de Development a fost împărțită în altele trei: una de design pentru activitățile de planificare API și UI, una de programare efectivă, numită în continuare tot Development și una de testing. Orice task trebuia să treacă printr-o procedură de testare de către o altă persoană înainte să fie considerată terminată.
Fiecare coloană a fost îmbunătățită cu o definiție a lui done. Politica era că numai un task ce îndeplinește toate condițiile poate fi mutat în coloana următoare.
Au fost create categorii pentru activitățile noastre: story, pentru îmbunătățiri și funcționalități noi , bugs, pentru defecte, technical tasks, pentru activități adiacente proiectului, cum ar fi instalarea unui server de compilare sau testare automată.
Scrum era bun pentru disciplină, dar am identificat câteva probleme cu el. Alocarea resurselor era una din ele. Așa că am început să studiem și să aplicăm tehnici lean în cadrul proiectului nostru.
Am încercat să ținem cont de toate principiile lean, dar două din ele au ieșit în evidență: eliminarea pierderilor - prin eliminarea timpilor morți în lanțul dependințelor dintre programatori cu ajutorul pair-programming-ului, sau prin încurajarea unor activități de minor bugfixing în timpii morți - amplificarea învățării - prin participarea la conferințe, cursuri, încurajarea experimentărilor prin code retreat-uri și oferirea unei biblioteci de specialitate exhaustivă.
Inevitabil, după o schimbare de cunoștințe și practici, o schimbare a board-ului era necesară.
Iată schimbările esențiale:
Nu mai este coloană Working On. În schimb toate coloanele sunt de aceeași prioritate, fără subcoloane.
Nu mai avem Design, avem în schimb Design Spikes, un concept de Agile Architecture definit de Rebecca Wirfs-Brock.
Fiecare coloană are o limită maximă de task-uri ce se poate acomoda. Această limită nu poate fi depășită, și dacă se atinge trebuie luate măsuri pentru eliberarea task-urilor întârziate.
La un moment dat am identificat o problemă cu board-ul fizic: era mult prea dificil să organizăm și să identificăm task-uri pe backlog. Așa că am trecut la un board digital, sub forma unei aplicații. Acesta ne-a permis identificare și organizare rapidă, însă a introdus o problemă profundă și neașteptată. Oamenii nu mai aveau ceva vizibil tot timpul în față, ci din contra, trebuiau să facă o acțiune conștientă de a deschide un web browser și a naviga la pagina aplicației. Iar cum programatorii sunt leneși notorii, board-ul digital a fost un eșec inițial.
Totuși un televizor pe perete a rezolvat problema vizibilității. După ce programatorii s-au obișnuit să aibă mereu un tab cu aplicația deschisă, chiar și televizorul a devenit inutil.
Probabil cel mai important lucru pe care l-am învățat este că singura constantă în viață este schimbarea. Indiferent că este vorba de viața personală, profesională sau de proiectul favorit, felul în care ne manifestăm și ne organizăm este în continuă schimbare.
Schimbarea este determinată de mai mulți factori, externi și interni nouă, cum ar fi cerințe noi ale pieței, respectiv monotonia locului de muncă.
Până la urmă este irelevant ce determină schimbarea. Trebuie să fim pregătiți pentru ea. Cu siguranță va veni, inevitabil.
Acest articol este unul mai sumar, punând accent pe punctele cheie din studiul agile prezentat în detaliu pe site-ul Agile Alliance ca parte a Agile Experience Reports Program.
de Ioana Varga , Ioana Costea
de Lucian Pop
