Fie ca este vorba de un coleg care pleaca din companie si este nevoie sa documenteze ce a lucrat, ca vreti sa extindeti durata sprinturilor sau sa faceti un manual de utilizare (a carui redactare sa nu dureze o vesnicie), un screencast poate reprezenta o solutie rapida si la indemana. Bun, dupa aceasta introducerea de teleshopping (mai lipsea sa pun titlul articolului ceva de genul „Senzational: Screencast-ul care economiseste cu pana la 80% din timpul dvs.” si puteam sa imi schimb linistit jobul), haideti sa vedem care sunt acele situatii cand inregistrarea a ceea ce se petrece pe ecranul computerului poate fi o idee buna. Cand pleaca un coleg Cu totii am trecut prin acea senzatie de raceala in stomac cand unul din oamenii cheie vine si ne spune ca el si-a gasit de lucru in alta parte. Te uiti la el simti literalmente cum iti cade casa in cap. Cine o sa mai intretina increngatura de proceduri stocate de pe server? Dar integrarea cu sistemul vechi de calcul al comisioanelor? Arunci o privire in calendar; mai sunt doua saptamani si un pic. E timp, iti spui incercand sa te linistesti, stiind prea bine ca nu e asa. Cum ar putea cineva sa documenteze in doar doua saptamani ce a lucrat in trei ani di mai bine? Raspunsul, cum banuiti deja, consta in realizarea unui screencast. Iata o modalitate cum se poate face acest lucru: treceti impreuna cu respectivul coleg, sa ii zicem Picasso, prin tipurile de activitati pe care le face in decursul unei saptamani (dezvoltare, suport, bug fixing, optimizare etc.); investigati apoi ce alte activitati s-au intamplat doar o singura dat sau foarte rar in timpul in care a lucrat el (cosmetizarea unui raport, repararea unei baze de date cand adminul a fost bolnav etc.); instalati un soft de screencasting – eu unul prefer fie Camtasia (cam piperat la pret: in jur de 200 de euro licenta, dar extraordinar prin facilitatile pe care le pune la dispozitie), fie CamStudio (un excelent produs free) – si dati-i lui Picasso sa poarte un microfon (de preferinta unul cat mai putin intruziv – o lavaliera wireless, de exemplu; costa pana intr-o 100 de lei si isi face de minune treaba). Pentru ca cele mai bune povesti se spun la o bere, nu in fata camerei de luat vederi; porniti softul de screencasting si puneti-i lui Picasso intrebari din seria „Daca ar fi nevoie sa, cum ai proceda?” –Daca ar fi sa fie nevoie sa mai adaugi o coloana in raportul de vanzari, cum ai proceda? – si urmariti-l pe Picasso cum navigheaza prin mediul de programare, in timp ce explica cu cuvintele lui rezolvarea respectivul task. Nu uitati ca la sfarsitul explicarii fiecarui modul sa puneti o intrebare de tip weakest link: „Daca ar fi cel care vine dupa tine sa intampine o situatie neprevazuta, una pe care noi o trecem acum cu vederea, care ar putea fi ea?”. Veti documenta astfel acele situatii anecdotice care ne fac din cand in cand sa innoptam la birou: „Si ai grija, sa dai drepturi de administrator pe folderul unde isi tine fisierele temporare, ca altfel zice ca nu se poate conecta la server”. Been there, done that, got the T-shirt. Un sfat desprins din practica: incercati sa pastrati durata fiecarei inregistrari sub trei minute (acolo unde se poate). Una este sa refaci un clip scurt si alta este sa realizezi ca mai trebuia sa adaugi ceva in mijlocul unei inregistrari de o ora si jumate. In plus, nu va doriti sa va dea eroare softul de screencasting si sa constatati ca trebuie sa reluati tot ce ati discutat in ultima ora. La sfarsit de tot, faceti un document in care descrieti pe scurt continutul fiecarei inregistrari. Veti putea gasi mai repede in ce fisier anume exista explicata o functionalitate sau alta. Ca mijloc de a obtine feedback rapid Principalul motiv al ciclurilor scurte de dezvoltare este de a oferi clientului posibilitatea sa spuna daca ii place sau nu ceea ce primeste. Dar, odata cu ciclurile scurte, vine la pachet si overhead-ul asociat pornirii si incheierii lor (planning, demo, restrospective). In situatia in care intr-un sprint de 10 zile (doua saptamani) intre 10 si 20% din efortul depus nu este direct productiv – in conditii ideale o echipa experimentata poate rula toate cele trei ceremonii (planning, demo, restrospective) intr-o singura zi, dar de cele mai multe ori este nevoie de doua zile 2:10 = 20% – ajungi sa te gandesti ca nu ar fi o idee rea sa cresti dimensiunea sprintului peste cele doua saptamani obisnuite. Bun, cresti dimensiunea sprintului, dar ce te faci cu Product Ownerul? Sa ii aratati doar o singura data la trei saptamani cum merg lucrurile pare sa te califice drept un tip caruia ii place sa traiasca periculos. Sa te asezi in primul rand la concertul unei formatii de trompetisti si sa musti dintr-o lamaie pare nimic pe langa sa te intalnesti cu un Product Owner care voia o aplicatie web si tu i-ai livrat una desktop. Cat despre partea cu lamaia, va sfatuiesc de cea mai buna credinta sa nu o incercati daca nu sunteti titularii vreunei medalii de aur la alergare (si nici atunci nu e sigur ca veti scapa nevatamati. Caci, vorba aia, sa te pazeasca Dzeu de furia trompetistului – sau si mai tare, a celui de la nai – care in loc sa cante duios saliveaza de mama focului uitandu-se la lamaia din mana ta. Nu bun.) Si iata ca din nou intra in scena prietenul nostru screencast. Deoarece, cu ajutorul unor inregistrari scurte (din experienta va spun ca intr-un clip de sub un minut incape cam tot ce s-a lucrat intr-un sprint intreg) putem tine clientul informat asupra modului in care arata si functioneaza produsul lui, fara sa fie nevoie sa intreprindem toate actiunile necesare pentru a putea rula o demonstratie completa (check-in toata lumea, facut build pe serverul de test si asa mai departe). Cu titlul de sugestie, iata cativa pasi ce pot fi folositi pentru a obtine un screencast […]
↧