Viața înainte de SCRUM

De fiecare dată când cineva pornește o discuție despre SCRUM zilele astea stai să te gândești dacă nu cumva SCRUM, o metodologie agilă menită să facă viața dezvoltatorilor de software ceva mai bună, nu cumva este de fapt unealta diavolului în iadul de lux numit dezvoltarea de software. Este cât se poate de „la modă” să te iei de SCRUM, pentru foarte mulți fiind cea mai importantă metodologie folosită pentru creat software. SCRUM e peste tot, dar majoritatea celor care vorbesc despre SCRUM habar n-au ce zic, așa că hai să vorbim un pic despre chestia asta.

Viața înainte de metodologiile Agile

Vii la birou, și afli că arhitectul a băgat pe toată lumea în ședință. Toată lumea nu te include, tu ești un simplu dezvoltator, dar arhitecții soluției software și project managerii sunt într-o ședință prelungită în care li se explică încă o dată cum trebuie să implementezi treaba. Știi că e rău lucrul ăsta. Practic, o să trebuiască să arunci din nou la gunoi vreo patru luni de muncă pentru că lucrurile #nu-trebuiau-făcute-așa. Ultimul release a fost acum trei ani, un dezastru în producție pentru care a trebuit să stai trei nopți să îl repari la sediul clientului comunicând non-stop cu echipa. Nimeni nu a dormit vreme de o săptămână la release.

De data asta e varianta ușoară. Arhitectul a văzut soluția în timp ce era la cei de la testare, care elaborau suita de teste pentru ea. Au avut o nelămurire, și arhitectul, care acum lucra la cu totul alt proiect, a trebuit să lase totul, să scoată documentele de specificații pe care clientul și-a dat acordul, și să îi bage în ședință pe PMi. E scandal, nimeni nu doarme la noapte. Toată munca din ultimele patru luni trebuie refăcută. Clientului nu-i va plăcea soluția.

Ce se întâmplă în ședința aia? Aș vrea să glumesc, dar se va analiza fiecare frază dintr-un document de 120 de pagini, fiecare virgulă și fiecare cuvânt aruncat aproape întâmplător într-o engleză de baltă pe care, deodată, arhitectul vrea s-o dea ca fiind extrem de precisă, și n-am înțeles noi gramatica frazei lui de Eminescu. Urmează o noapte nedormită, și după aia trei săptămâni de crunch eroic. Mai e o lună până la instalarea la client, și dacă ți se pare că am zis doar trei săptămâni, asta e pentru că ultima săptămână o s-o petreci în sediul clientului, cu tipul de la testare și din când în când ăla de la suport on-site, care îți mai aduce câte-o gogoașă și o Cola și îi explică clientului de ce totul durează atât de mult.

Metodologiile Agile rezolvă o problemă pe care nu o cunoști

Majoritatea oamenilor care lucrează acum în software development sunt oameni care nu au trecut prin așa ceva. E un calcul simplu, în anul 2000 erau vreo 680.000 de dezvoltatori în SUA, si probabil vreo 2 milioane la nivel mondial, acum sunt vreo 27 de milioane la nivel mondial. Mulți din oamenii care au activat acum 25 de ani probabil că s-au retras din meserie, sunt șanse foarte mici ca cineva care scria software în 2000 să scrie software și în 2023. Și cam oricine a trecut prin câteva șarje de genul ăsta nu o să poată niciodată să urle emfatic că „SCRUM is cancer”.

Când oamenii citesc despre dezvoltatorii eroici precum Carmack din anii ‘90, lumea ignoră să înțeleagă că oamenii de la Id Software nu făceau ceva deosebit de restul industriei. Crunch time-ul era ceva obișnuit, pe care nu mira pe nimeni. Michael Abrash a venit în Id Software de la Microsoft, practic vârful corporatismului de software, și pus față în față cu cultura de crunch a celor de la Id nici măcar nu a clipit.

The Agile Manifesto a fost o mișcare de revoltă contra genului ăsta de exploatare a dezvoltatorilor de software. Chiar dacă încă din anii ‘90 lucrurile începeau să se schimbe, cu diverse metodologii încercate, cu o tonă de încercări și experimente sortite eșecului: procesul Rational, de exemplu, ne-a lăsat una din cele mai mari plăgi intelectuale din software development, și anume UML. XP, sau eXtreme Programming, presupunea orice metodă oricât de tâmpită de a spori productivitatea, o etichetă pe care o puneai pe orice experiment psihologic făcut pe oameni. Two guys one keyboard? XP. Cineva care să dicteze codul altcuiva? XP. Cumva, XP mereu ajungea să ceară mai puține tastaturi decât oameni, dintr-un motiv care tinde să ne scape.

The Agile Manifesto a prins în aceeași încăpere niște oameni care nu au nimic în comun decât că aveau foarte multă experiență în software development. E o chestie de prioritizare în care pui:

Indivizii şi interacţiunea înaintea proceselor şi uneltelor
Software funcţional înaintea documentaţiei vaste
Colaborarea cu clientul înaintea negocierii contractuale
Receptivitatea la schimbare înaintea urmăririi unui plan

Pun accent pe chestiile din dreapta pentru că ele sunt problemele pe care încercau să le rezolve cu acest manifest Agile. Cei mai mulți dezvoltatori din ziua de azi nu prea cunosc ce înseamnă acele lucruri, nu știu cum e să trebuiască să faci planificarea cu Gantt charts în MS Project și să-ți faci schemele de arhitectură în Rational Rose. Nu știu ce înseamnă ca prima oară când clientul vede software-ul pe care l-a comandat e când rulează la el în incintă pe serverul lui, deservind clienții reali din producție. Și nu știu cum e să citești documente de mii de pagini care descriu software banal care e outdated încă de la concepție.

Agile manifesto a fost primit cu entuziasm de software developeri, care în sfârșit se vedeau pomeniți pe partea bună a schimbării. Dar lipsea și o metodologie care să funcționeze. Primul care a ieșit în față cu metodologia nouă, care să arunce procesele și uneltele vechi la gunoi, a fost metodologia lui Ken Schwaber, care în 2002 deja vindea certificări în această metodă pe care el încerca să explice că a văzut-o funcționând.

Ce introduce SCRUM

Când ai făcut software development doar de 10-15 ani nu prea ai apucat să vezi un proces neinfluențat de SCRUM, deci n-ai de unde să știi cum anume se făceau lucrurile înainte și de ce e necesar să le faci. SCRUM introduce câteva lucruri noi salvatoare pentru dezvoltatori.

1. Daily standups

Ședințele scurte de la începutul zilei, care durează 15 minute, sunt, probabil, cel mai vizibil aspect al metodologiei. Oamenii discută ce au făcut în ziua anterioară, ce dificultăți au întâmpinat, și la ce vor lucra în ziua în curs. Ședințele astea sunt de fapt cel mai puternic element al metodologiei, care fac să dispară o groază de probleme.

• Nu ar mai trebui să ai oameni care să frece menta aiurea, pentru că după ce câteva zile la rând repetă același lucru, lumea începe să-i miroasă.
• nu mai ai oameni care lucrează pe același lucru în același timp.
• oamenii sunt informați în legătură cu ce se întâmplă pe proiect, și încep să cunoască diverse aspecte ale proiectului la care în general nu aveau acces.
• toată lumea e implicată. Motivul pentru care e tradițional văzută ca stand-up meeting (adică în picioare) este că statul în picioare presupune că oamenii vor să termine ședința mai repede dar și că pentru că nu pot face altceva sunt atenți la cei cu care stau în aceeași cameră. Evident, treaba asta nu se prea întâmplă online, dar intenția asta e.

2. Sprinturi scurte

Totul se face în iterații scurte, care durează de la o săptămână la o lună, cu cea mai mare perioadă pe care am văzut-o de 6 săptămâni. Asta înseamnă că toată lumea e secționată în așa fel încât să ai ceva livrabil într-un timp foarte scurt. Pentru că urmează…

3. Ceremoniile de sfârșit și început de sprint

Iarăși niște aspecte urâte de toată lumea, atunci când nu sunt făcute cu cap. Ai următoarele ceremonii:

• sprint review, momentul în care arăți reprezentantului clientului ce ai realizat în ultimul sprint.
• sprint retrospective, în care te uiți peste experiența din ultimul sprint, ce a mers bine, ce a mers rău, ce s-ar putea face pentru a îmbunătăți lucrurile, ce lipsește din procesul de dezvoltare.
• sprint planning, în care, cu backlogul (vezi mai jos) actualizat și reprioritizat cu reprezentantul clientului, echipa de dezvoltare află care sunt prioritățile actualizate, și se poate concentra pe noile priorități știind că munca pe care o vor depune este în deplin acord cu necesitățile clientului și este considerată cea mai bună direcție pentru proiect.

Este, așadar, loc pentru toată lumea să reacționeze, dar, foarte important, nu e loc pentru ședințe în care clientul vine să-i facă terci pe dezvoltatori, sau arhitectul să-i facă zob pe project manageri. Fiind făcute cu o frecvență destul de mare, orice pas greșit poate fi corectat foarte rapid, și clientul are mereu o imagine clară cu ce poate folosi, ce va primi când produsul va fi gata, etc. Practic, o modalitate de a împăca pe toată lumea, în care toată lumea contribuie la succesul soluției, de la dezvoltator la client.

4. Backlogul

Prea puțină lume vorbește despre asta, dar backlogul este probabil una din cele mai utile lucruri pe care le aduce orice metodologie Agile. Backlogul e munca ce va trebui făcută - bucățită și pregătită pentru a fi implementată de dezvoltatori. Operațiunea de îngrijire a acestui backlog (grooming) e probabil cea mai importantă din tot procesul acesta, pentru că stabilește direcția în care o vor lua lucrurile fără a lua niște angajamente în sensul ăsta. Itemii din backlog trebuie definiți, documentați, și se poate lucra pe ei independent de munca curentă; în ceremonia de planificare cei care își dau cu părerea în legătură cu complexitatea muncii cerute de un anumit item sunt cei care vor și implementa acel lucru, și care va face spargerea în subprobleme.

SCRUM, și metodologiile Agile în general pun foarte mult accent pe acest aspect, e locul unde lucrurile se îmbunătățesc. Este ceea ce înlocuiește documentele de mii de pagini de documentație care cel mai des nu au nicio legătură cu realitatea - acum poți evalua ce e fezabil, ce e util, ce e important să ai în software-ul tău.

SCRUM e o etichetă

Pentru că a fost prima metodologie care putea fi certificată, SCRUM a prins un val extraordinar. Problema este, însă, că SCRUM e o metodologie care s-a construit într-un anumit mediu cultural și social, pentru acel mediu social și cultural. În foarte scurt timp SCRUM a devenit sinonim cu Agile, mai ales datorită succesului în zona bănoasă a software developmentului, în SUA. Oricine își dorea să-și sporească productivitatea în producția de software a început să folosească SCRUM, fie că știau despre ce e vorba sau nu, fie că aveau certificarea sau nu, fie că se aplica echipei sau situației în care erau sau nu.

SCRUM a devenit, așadar, o etichetă pentru orice încercare de a aduce niște procese umane în câmpul producției de software. Sigur, unele procedee din SCRUM au fost copiate fără prea multă înțelegere a procesului, și se vorbește foarte mult despre cargo-culting. Da, oameni care nu pricep despre ce e SCRUM practică SCRUM fără să aibă habar de ce fac lucrurile pe care le fac, și care sunt aspectele pe care ar trebui să pună accentul.

Realitatea e că foarte puține lucruri s-au schimbat în software development. Lucrurile din dreapta de la manifestul Agile sunt încă necesare sau încă folosite, dar acum s-a adăugat și partea de „Agile”, pentru că cineva vrea și lucrurile din dreapta, și lucrurile din stânga. Vrea și planificare pe termen lung, dar și zero rezistență la schimbare. Cu dânsa dorsal și sufletu-n rai, ca să nu folosim exprimări care ar putea deranja sensibilitățile vreunui tânăr care n-a auzit așa cuvinte.

Nimeni nu face SCRUM ca la carte pentru că nicio metodologie nu poate fi aplicată ca la carte. Fiecare echipă e diferită, și putem vorbi la infinit despre felul în care orice metodologie poate eșua. Poți să faci pe deșteptul să zici că „Scrum is like communism. It fails everywhere, every time, but they tell you you aren’t doing it right.”, dar SCRUM nu eșuează - echipa ta eșuează, SCRUM e doar o cale de a face drumul spre eșec mai evident, să-l facă mai vizibil, să aducă eșecul mai rapid și să împartă responsabilitatea la toată lumea.

Și asta pentru că tot software-ul e eșuat într-o formă sau alta. Da, unele soluții sunt folosite pe termen lung, cu rezultate defectuoase, iar măsura succesului e întotdeauna dată de subdimensionarea eșecului. Într-o lume obsedată de planned obsolescence, de făcut bani cât mai repede de pe următoarea versiune, software-ul nu e cu nimic diferit. Echipa ta va eșua, și SCRUM te poate ajuta să vezi mai repede și mai bine cum, și chiar îți oferă unelte pentru a eșua cât mai târziu, dar trebuie să le și folosești.

Nu, SCRUM nu e tot ce e mai rău pe univers

În general, când mai vezi pe cineva urlând de cât de rău e SCRUM, dați-i una peste ochi. În primul rând, pentru că nu face SCRUM, nimeni nu face, nici măcar Ken Schwaber nu e capabil să facă SCRUM. În al doilea rând, metodologiile Agile presupun adaptare, dacă omul îți urlă că e incredibil de rău, înseamnă că nu a înțeles că adaptarea înseamnă inclusiv adaptarea procesului. Am asistat în mai multe rânduri la procesele astea de reglaj de proces „în zbor”, și de fiecare dată lucrurile au fost mai bune pentru toată lumea, chiar dacă a trebuit să fie șifonate câteva atitudini de la niște sociopați. Asta este, trebuie un pic de caracter pentru a face lucrurile mai bune.

Acesta e micul mare secret al unei organizații de succes. Adaptarea. Autoexaminarea. Astea sunt elementele cheie ale SCRUM, ale Agile. Restul e ceremonie, necesară pentru că oamenii sunt oameni și au nevoie de ritualuri, au nevoie de comunicare, au nevoie de reamintire a unor principii, și au nevoie să lucreze împreună.

Și mai e încă o treabă: SCRUM, și metodologiile Agile, te învață cum anume să integrezi eșecul în munca ta pentru a face lucrurile mai bine. Este un principiu incredibil de iertător, dacă vreți să-i zicem așa, și înțelegător de bună seamă. Așa că data viitoare când crezi că SCRUM e problema, e mai posibil ca problema să fii, de fapt, tu.