Supporting the community

Noua Metodologie

 

In ultimii ani de zile a aparut o explozie de un nou stil de metodologie software - aici ma refer la metodele agile. Caracterizandu-se alternativ ca un antidot al birocratiei sau licenta de hackuire, au starnit interesul peste tot in peisajul software-ului. In acest eseu voi explora motivele pentru metode agile, focusul fiind nu atat de mult pe greutatea lor ci pe natura lor adaptiva si focusarea pe oameni.

Probabil, cea mai remarcata schimbare in gandirea procesarii software-ului din ultimiii ani a fost aparitia cuvantului "agile". Vorbim despre metode de software agile, de cum sa introducem agility intr-o echipa de dezvoltare sau cum sa rezistam furtunii de agilisti determinati sa schimbe bunele practici stabilite.

Aceasta noua miscare s-a nascut din efortul a mai multor oameni care dezvoltau software in anii 90, ce i-a facut sa vrea si sa caute o noua abordare aprocesului software.Majoritatea ideilor nu erau noi si intr-adevar multi oameni credeau ca mult software de succes a fost construit in acel fel de mult timp. Era oricum o parere cum ca aceste idei au fost asfixiate si nu au fost tratate destul de serios, in special de oamenii interesati de procesul de software.

Acest eseu a fost initial parte a acestei miscari. Prima oara l-am publicat in Iulie 2000. L-am scris , precum masjoritatea eseurilor mele, in parte ca sa inteleg subiectul. In vremea respectiva foloseam Extreme Programming de cativa ani, dupa ce am avut norocul sa lucrez cu Kent Beck, Ron Jeffries, Don Wells si restul echipei de la Chrysler C3 in 1996. De atunci am avut conversatii si am citit carti de la alti oameni care au avut idei similare despre procesul software-ului dar care nu vroiau neaparat sa o ia pe calea de Extreme Programming, Asa ca in eseu am vrut sa explorez care erau similaritatile si diferentele intre aceste metodologii.

Concluzia mea atunci, cea in care cred si astazi, este ca erau niste principii fundamentale ce unifica aceste metodologii si aceste principii erau un contrast notabil de la presupunerea metodologiilor stabilite.

Acest eseu a continuat sa fie unul dintre cele mai populare eseuri pe situl meu, ceea ce inseamna ca ma simt cumva rugat sa il tin la zi updatat. In forma lui originala, eseul explora aceste diferente in principii si furniza un studiu a metodelor agile cum le intelegeam eu atunci. Pre multe s-au intamplat cu metodele agile de atunci ca eu sa tin pasul cu partea de studiu dar va pun la dispozitie niste link-uri ca sa continuati sa explorati. Diferentele in principii inca raman si am pastrat aceasta discutie


De la Nimic, la Monumental, la Agile

Majoritatea dezvoltarii de software este o activitate haotica, deseori caracterizata de fraza "codeaza si repara". Software-ul este scris fara prea multe planuri ce stau la baza si design-ul sistemului este carpit dupa decizii pe termen scurt. Asta functioneaza foarte bine daca sistemul este mic dar cum sistemul creste, devine din ce in ce mai greu sa se adauge noi optiuni sistemului. In plus, erorile devin raspandite si din ce in ce este mai greu remedierea lor. Un semn tipic a unui asemenea sistem este o faza de testare pe termen lung dupa ce sistemul este "feature complete". O faza lunga de testare face ravagii cu programul din moment ce testarea si depanarea sunt imposibil de stabilit din timp.

Miscarea originala ce a incercat sa schimbe acest lucru, a introdus notiunea de metodologie. Aceste metodologii impun un proces disciplinat asupra dezvoltarii de software cu scopul de a face dezvolarea de software mai previzibila si mai eficienta. Fac asta dezvoltand un proces detaliat punand accentul pe planificare, inspirati fiind de alte discipline ingineresti -  de aceea as vrea sa fac referire la ele ca metode ingineresti (un alt termen des folosit pentru ele este tehnologii bazate pe un plan).

Metodologiile ingineresti sunte de ceva vreme. Nu au fost remarcate ca fiind un succes teribil. Ele sunt chiar si mai putin remarcate ca fiind populare. Ceamai frecventa critica asupra acestor metode este ca sunt birocratice. Este foarte mult de facut ca sa urmaresti metodologia incat tot procesul de dezvoltare incetineste.

Metodologiile Agile a fost dezvoltata ca o reactie laaceste metodologii. Pentru multi oameni atractia spre aceste metodologii agile este reactia lor la birocratia metodelor ingineresti. Aceste noi metode fac un compromis util intre niciun proces si prea mult proces, oferind suficient proces pentru a obtine o plata rezonabila.  

Rezultatul a toate aceste este ca metodele agile au facut schimbari importante importante in accent cu metodele ingineresti. Imediata diferenta consta in faptul ca sunt mai putin orientati pe document, in mod uzual punand accent pe o documentatie mai mica pentru un task. In multe feluri sunt mai degraba orientati pe cod; urmarind o cale ce spune ca partea importatna a undei documentatii este codul sursa.

Oricum, nu cred ca asta este ideea principala la metodele agile. Lipsa documentatiei este o simptoma a prea multe diferente mai adanci:

  • Metodele agile sunt mai mult adaptive decat previzibile. Metodele ingineresti tind sa planifice o mare parte al procesului de dezvoltare software in mare detaliu pe o lunga perioada de timp iar asta functioneaza bine pana cand lucrurile se schimba. Iar natura lor este sa se opuna schimbarii. Metodele agile imbratiseaza schimbarile. Ei incearca sa faca proceduri ce se adapteaza si prospera la schimbari, chiar si pana se reinventeaza.
  • Metodele agile sunt mai orientate catre om decat spre procedura in sine. Scopul metodelor ingineresti este sa defineasca un proces ce o sa functioneze bine, indiferent cine il foloseste. Metodele agile afirma ca niciun proces nu o sa inlocuiasca priceperea echipei de dezvoltare, asa ca rolul unei proceduri este sa sustina echipa de dezvoltatori in munca lor.

In sectiunile urmatoare o sa explorez aceste diferente in detaliu, asa ca o sa intelegeti ce este o procedura centrata pe oameni, beneficiile ei si problemele si daca este ceva ce ar trebuie sa folosesti: fie ca dezvoltator sau client de software.


Predictiv sau Adaptiv

Separarea de Design si Constructie

In mod normal, inspiratia pentru metodologii sunt disciplinele ingineresti precum ar fi cele civile sau ingineria mecanica. Asemenea discipline pun mult accent pe planificare inainte sa te apuci de construit. Acesti ingineri lucreaza la o serie de desene ce indica precis ceea ce trebuie construi si cum trebuiesc puse lucrurile impreuna. Multe decizii de design, precum ar fi cum sa faci fata incarcarii pe un pod, sunt facute in timp ce desenele sunt efectuate. Schemele sunt predate unui alt grup de oameni, deseori o alta companie urmeaza sa construiasca. Se presupune ca procesul constructiei o sa urmeze schitele. In practica, constructorii o sa dea de niste probleme dar aceste sunt de obicei mici.

Din moment ce shitele specifica piesele si cum trebuiesc puse impreuna, acestea sunt precum fundatia unui plan de constructii. Cu un asemenea plan poate sa isi dea seama ce treburi trebuiesc facute si ce dependente exista intre sarcini. Aceasta permite sa preconizezi un program si un buget pentru constructie. De asemenrea arata in detaliu cum oamenii ce fac munca in constructii, ar trebui sa isi faca munca. Aceasta permite constructiei sa fie mai putin priceputa din punct de vedere intelectual, cu toate acestia au fosrte bune abilitati manuale.

Deci ceea ce vedem aici sunt doua activitati fundamental diferite. Designul ce este greu de prevazut si necesita oameni scumpi si creativi si constructia care este mai usor de previzionat. Odata ce avem designul, putem planifica constructia. Odata ce avem un plan pentru constructie, putem sa ne ocupam de constructie intr-un mod mai previzibil. In ingineria civila este mult mai mare ca si cost si timp decat design si planificare.

Deci abordarea pentru metodologiile software ingineresti arata cam asa: vrem o procedura predictibila ce se adapteaza pe oameni cu abilitati reduse. Pentru a face asta trebuie sa separam designul de constructie. Deci si prin urmare avem nevoie sa ne dam seama cum sa facem designul pentru software in asemenea fel incat constructia sa poata fi simpla odata ce planul este gata.

Deci ce forma urmeaza sa capete acest plan? Pentru multi, acesta este rolul proiectantilor cum ar fi UML. Daca putem lua toate decizile importante folosinf UML, putem sa facem un plan de constructie si dupa sa dam schitele programatorilor ca o avtivitate de construire.

Dar aici apare intrebarea existentala. Poti sa faci un design care sa fie capabil sa transforme codarea intr-o activitate previzibila de constructie? Si daca da, costa destul de putin incat sa merite aceasta abordare?

Toate astea ma fac sa ma duc cu gandul la cateva intrebari. Prima problema este cat de dificil este sa faci un design ca UML intr-un format ce poate fi dat programatorilor.  Problema cu un design ca UML consta in faptul ca pe hartie arata foarte bine dar are defecte cand pe bune sa programezi acel lucru. Modelele pe care inginerii civili le folosesc sunt bazate pe multi ani de practica ce sunt deja coduri ingineresti consacrate. In plus, problemele cheie, precum ar fi fortele ce se joacarol important intr-un design, pot fi supuse unei analize matematice. Singura verificare ce o putem face intr-o diagrama UML este inter pares. In timp ce aceasta ajuta, poate cazua erori in design ce adesea sunt descoperite in timpul programarii si testarii. Pana si designerii cu experienta, precum eu ma consider ca sunt, suntem adesea surprinsi cand reusim sa transpunem un asemenea design in software.

O alta problema este cea a costului coparativ. Cand construiesti un pod, costul cu efortul designului este 10%, restul fiind constructia. In software, timpul petrecut programand este mult mult mai mic. McConnel sugereaza ca la un proiect mare, doar 15% din proiect este cod si test, adica o inversare aproape perfecta a ratiei constructiei podului. Aceasta naste o intrebare importanta despre natura designului in software comparat cu rolul sau in alte laturi ale ingineriei.

Aceste tipuri de intrebari l-ai facut pe Jack Reevessa sa sugereze cum ca codul sursa este o schema de design si ca faza constructiei este de fapt folosirea compilatorului si linkuirii. Intr-adevar, orice poti trata ca pe o constructie, poate si trebuie automatizata.

Putem trage concluzii importante de pe urma acestui tip de gandire:

  • In software: constructia este atat de ieftina casa fie gratuita
  • In software toate eforturile constau in design si astfel necesita oameni creativi si talentati
  • Procedurile creative nu sunt usor de planificat si asa predictibilitatea s-ar putea sa fie o tinta imposibila
  • Ar trebui sa fim foarte precauti la metaforele traditionale ingineresti pentru construirea de software.

Este un alt fel de activitate si necesita procese diferite

Impredictibilitatea Cerintelor

Exista o retinere ce am auzit-o la fiecare problema de care m-am lovit. Dezvoltatorii vin la mine si spun "ca problema cu acest proiect este ca se schimba mereu cerintele". Lucrul ce eu il gasesc surprinzator legat de aceasta situatie este ca toate lumea este surprins de el. in constructia de sostware pentru business, cerintele sunt normale, intrebarea este ce facem in aceasta privinta.

O cale ar fi sa tratam schimbarea cerintelor ca un rezultat al slabelor cerinte ingineresti. Ideea din spatele cerintelor ingineresti este intelegerea perfecta a imaginii de ansamblu inainte de a te apuca de construit software, obtine aprobarea clinetului si apoi fa proceduri care limiteaza schimbarea cerintelor.

O problema cu aceasta este ca e destul de greu doar sa intelegi necesarul cerintelor. Este chiar si mai greu pentru ca organizatiile ce dezvolta, in mod normal nu pun la dispozitie costul informatiei necesarelor. Sfarsesti prin a fi pus in situatia unde s-ar putea sa ai niste dorinte pentru un acoperis solar pentru masina ta dar vanzatorul daca se adauga 10 dolari la costul masinii tale sau 10.000 de dolari. Fara a avea idee de cost, de unde iti poti da seama daca vrei sa platesti pentru acoperis?

Estimarea este grea din mai multe motive. Una dintre ele ar fi ca dezvoltarea de software este o activitate de design si prin urmare, greu de planificat si costa. un motivar fi ca materialele de baza continua sa se schimbe repede. Un alt motiv ar fi ca depinde foarte mult de tipul de oameni implicati iar oamenii sunt greu de previzionat si quantificat.

Natura intangibila a software-ului intervine si ea. Este foarte complicat to sa constientizam ce valoare are o potiunea a unui soft, pana cand o vedem pe bune. Doar cand vezi o versiune de inceput a al software-ului incepi sa intelegi pe bune ce imbunatatiri sunt valoroase si ce parti nu sunt.

Prin asta putem trage concluzia ironica cum ca ca oamenii se asteapta ca cerintele sa se schimbe. La urma urmei, sofware-ul se presupune sa fie fin. Deci nu sunt numai cerintele schimbabile, ele trebuie sa fie schimbabile. Necesita multa energie sa pui clientii software-ului to schimbe cerintele. Este chiar si mai rau daca ei cocheteaza cu ideea ca ei insusi sa se ocupe cu dezvoltarea de software pentru ca atunci ei vor "stii" ca software-ul este usor sa se modifice.

Dar chiar si daca ai putea sa stabilesti toate astea si sa faci rost de un set de reguli stabile si corecte, probabil este tot supus pierzaniei. In economia de astazi fortele fundamentale ale afacerii schimba valoarea software-ului prea redepe. Ce arputea sa fie un set bun de cerinte acum, nu o sa mai fie de actualitate in sase luni de zile. Chiar daca clientii pot repara cerintele, lumea afacerilor nu o sa stea in loc pentru ei. Si multe schimbari in lumea afacerilor sunt complet imprevizibile: oricine zice altceva ori minte sau a facut deja un miliard la bursa prin tranzactii.

Orice altceva in dezvoltarea de software depinde de cerinte. Daca nu poti avea cerinte stabile, nu poti sa prezici un plan.

Este previzionarea imposibila?

In general, nu. Sunt unele dezvoltari de software unde predictabilitatea este posibila. Organizatii precum programul software-ul rachetei spatiale NASA sunt un exemplu unde predictibilitatea dezvoltarii software-ului se poate face. Este nevoie de multa pregatire, timp, o echipa mare si cerinte concrete. Exista proiecte ale navetelor spatiale. Oricum, nu cred ca mult software de afacere intra in aceasta categorie. Pentru asta ai nevoie de un altfel de procedeu.

Unul dintre marile pericole este sa pretinzi ca poti sa urmaresti un proces previzibil cand chiar nu poti. Oamenii ce lucreaza la metodologie nu sunt foarte buni in identificarea conditiilor limite: locurile cand metodologia trece din adecvat in neadecvat. Multi metodologisti vor ca metodogiile lor sa fie folosite de catre toata lumea asa ca nu inteleg, nici nu publica conditiile lor limita. Aceasta duce la folosirea de catre oameni a unei metodologii in circumstante gresite, precum ar fi folosirea unei metodologii previzibile intr-o situatie neprevizibila.

Exita o puternica tentatie spre asta. Predictabilitatea este o proprietate foarte dorita. Oricum, daca crezi ca poti sa fi predictibil atunci cand nu poti, duce la situatii unde oamenii construiesc din timp un plan, apoi nu au grija de situatie cum trebuie atunci cand planul se destrama. Vezi planul si cum se indeparteaza usor usor de realitate. Pentru o perioada lunga de timp poti pretinde ca planul este inca valid. Dar la un moment dat alunecarea devine prea mare si planul esueaza. De obicei caderea este dureroasa.

Deci daca esti intr-o situatie ce nu este previzibila, nu poti sa folosesti metodologia previziunii. Asta este o lovitura dura. Inseamna ca multe dintre modelele de contol a proiectelor, multe dintre modelele pentru intreaga relatie cu clientii, pur si simplu nu mai sunt adevarate. Beneficiile predictibilitatii sunt atat de mari, incat este greu sa nu le bagi in seama. Precum se ntampla in cazul multor probleme, partea cea mai grea este sa constientizezi ca problema exista.

Oricum ar fi, sa renunti la predictibilitate nu inseamna ca trebuie sa dai inapoi revenint la haos necontrolabil. In schimb, ai nevoie de un proces ce iti da control peste o situatie neprevazuta.
Iar despre asta este vorba in adaptivitate.

Controland un Proces Imprevizibil - repetari

Deci cum ne controlam noi insine intr-o lume nepreavazuta? Cea mai importanta si inca cea mai grea parte este sa stii cu exactitate unde ne aflam. Avem nevoie de un mecanism corect de feedback ce ne poate spune care este situatia exacta la intervale frecvente.

Cheia acestui feddback este dezvoltarea repetata. Asta nu este o idee noua. Dezvoltarea repetata a exsitat de ceva vreme sub diferite nume:incremental, evolutional, pe etape, spirala ... multe nume. Cheia dezvoltarii repetative este ca frecvent sa produca diferite versiuni functionale ale sistemului final ce are un subgrup a cerintelor necesare. Aceste sisteme functionale sunt scurte in functionalitate dar altfel trebuie sa fie fidele cerintelor sistemului final. Ar trebuie sa fie integrate total si testate atent preum produsul final.

Concluzia este canu exista nimic precum un sistem testat, integral pentru a aduce o doza de realitate in orice proiect. Documentele pot ascunde taote tipurile de erori. Cod netestat poate ascunde o gramada de defecte. Dar cand oamenii chiar stau pe bune in fata unui sistem si lucreaza cu el, atunci defectele devin aparente pe bune: atat cand vorbim despre erori precum si despre cereri neintelese.

Dezvoltarea repetata face sens si in procesele predictibile. Dar este esential in procesele adaptive pentru ca un proces adaptiv trebuie sa fie capabil sa faca fata schimbarii cu cerintele cerute. Asta duce la un stile de planificare unde planurile pe termen lung sunt foarte fluide si singurele planuri solide sunt cele pe termen scurt ce sunt facute pentru o singura repetare.Dezvoltarea repetata iti da o fundatie solida in fiecare repatare pe care iti poti mula planurile pe viitor.

O intrebare cheie pentru aceasta este cat de lunga o repetare sa fie. Diferiti oameni dau diferite raspunsuri. XP sugereaza repetari de una sau doua saptamani. SCRUM sugereaza o lungime a lunii. Crystal s-ar putea sa se lungeasca mai mult. Oricum, tendinta este sa faci fiecare repetitie pe cat de scurta posibil incat sa rezolvi treaba cu ea. Asta iti ofera feedback mai frecvent, deci vei stii mai des unde te aflii.

Clientul Adaptiv

Acest fel de proces adaptiv cere o relatie diferita cu clientul decat cele ce adesea sunt considerate, mai ales cand dezvoltarea este facuta de o firma separata. Cand angajezi o firma externalizata sa faca dezvoltare de soft, majoritatea clientilor ar preferea un contract cu pret fix. Spune dezvoltatorilor ce vrei, cere o oferta, aceepta oferta si raspunderea pica in carca organizatie dezvoltatoare ca sa construiasca software-ul.

Un contract cu pret fix cere cerinte stabile si de aici apare procesul de previziune. Procesele adaptive si cerintele instabile implica faptul ca nu poti lucra cu notiunea obisnuita de pret fix. Incercand sa faci un model de pret fix aspra unui proces adaptiv, sfarseste intr-o explozie foarte dureroasa. Partea nasoala a acestei explozii este ca, clientul este ranit la fel de mult precum compania ce dezvolta soft. La urma urmei, clientul nu ar avea nevoie de software daca business-ul lui nu ar avea nevoie de asa ceva. Si daca nu seintampla, atunci afacerea are de suferit. Deci chiar daca nu platesc nimic companiei ce dezvolta software-ul, ei tot au de pierdut. Intr-adevar, pierd mult mai multi bani decat ar fi avut de plata pentru software (de ce sa plateasca pentru software daca valoara afacerii acelui soft ar fi mai mica?)

Deci este pericol pentru ambele parti sa semneze un contract traditional cu pret fix in conditiile in care un proces predictiv nu poate sa fie folosit. Asta inseamna ca clientul trebuie sa munceasca diferit.

Asta nu inseamna ca nu poti bugeta inavans. Asta inseamna ca nu poti sa stabilesti timpul, pretul si scopul. Abordare uzuala dar agila are rolul sa stabileaza timpul si pretul si sa permita ca scopul sa varieze intr-o maniera controlata.

Intr-un proces adaptiv, clientul are control avansat asupra procesului de dezvoltare software. La fiecare repetare amadoi verifica progresul si pot altereaza directia dezvoltarii software-ului.

Asta inseamna ca nu poti sa stabilesti timpul, pretul si scopul. Abordare uzuala dar agila are rolul sa stabileaza timpul si pretul si sa permita ca scopul sa varieze intr-o maniera controlata.

Intr-un proces adaptiv, clientul are control avansat asupra procesului de dezvoltare software. La fiecare repetare amadoi verifica progresul si pot altereaza directia dezvoltarii software-ului. Asta duce la relatii mai apropiate cu dezvoltatorii de soft, un adevarat parteneriat de afaceri. Acest tip de angajament nu este la indemana oricarei organizatii si nici fiecarul dezvoltator de software; dar este esential sa faci un proces adaptativ sa functioneze corect.

Toate acestea rezulta intr-un numar de avantaje pentru client. Pentru inceput primeste software de o mai buna calitate. Un sistem usabil dar minimal poate intra in productie imediat. Clientul poate apoi sa-si schimbe capabilitatile conform schimbarilor in planul de afaceri si de asemenea invatand cum este sistemul folosit in realitate.

Fiecare bucata este la fel de importanta precum asta este de o vizibilitate mai mare in adevaratul stadiu al proiectului. Problema cu procesul predictiv consta in faptul cum ca calitatea procesului este masurata in conformitate cu planul. Asta il face dificil iar oamenii nu pot semnala cand realitatea si planul se schimba. Rezultatul uzual consta intr-o intarziere a proiectului. Intr-un proiect agil exista o reprelucrare constanta a planului cu fiecare repetare. Dca vestile proaste pandesc, atunci or sa apara mai repede cand inca este timp sa faci ceva in sensul asta. Intr-adevar acest control de risc este avantajul cheie cand faci dezvoltare repetativa.

Metodele agile duc mai departe ideea, pastrand repetarile sa fie putine, dar de asemenea facand variatiuni pe aceiasi tema. Mary Poppendieck a rezumat aceasta diferenta din punctul meu de vedere ce functioneaza cel mai bine cu fraza "O schimbare tarzie in cerinte reprezinta un avantaj competitiv". Cred ca majoritatea oamenilor au observat ca este foarte dificil pentru oamenii de afaceri sa inteleaga pe bune ce au nevoie de la un software in prima etapa. Vedem des ca oamenii invata in timpul procesului ce elemente sunt valoroase si care nu sunt. Adesea cele mai valoroase caracteristici nu sunt deloc evidente pana cand clientul are sansa sa se joaca cu software-ul. Metodele agile cauta sa obtina un avantaj din aceasta, incurajand oamenii de afaceri sa invete nevoile lor in timp ce sistemul este construit si sa construiesti sistemul in asemenea fel incat schimabrile sa poate fi integrate rapid.

Toate astea au o directie foarte importanta ce constituie succesul unui proiect. Un proiect predictiv este deseori masurat dupa cat de bine are planul facut. Un proiect care este gata la timp si se incadreaza si ni buget, este considerat un proiesc de succes. Aceasta masura este un nonsesn intr-un mediu agil. Pentru agilisti intrebarea este valoarea businessului - a primit clientul software care este mai valoros pentru el decat costul platit. Un bun proiect predictiv o sa decurca in conformitate cu planul, un bun proiect agil o sa construiasca ceva diferit si mai bun decat a fost prevazut in planul initial.


Punand Oamenii pe Primul loc

Executand un proces adaptativ nu este usor. In special cerinta de baza este o echipa de programatori foarte capabila. Echipa trebuie sa fie eficienta atat in calitatea individului cat si in felul in care echipa se lucreaza impreuna. Este de asemenea o sinergie interesanta; nu doar adaptivitatea necesita o echipa puternica dar si majoritatea dezvoltatorilor buni prefera un proces adaptativ.

Unitati Programabile Conectate Compatibil

Unul dintre telurile metodologiei traditionale este dezvoltarea unui procedeu unde oamenii implicati sunt componente interschimbabile. Cu asemenea procedura poti trata oamenii ca resurse care sunt disponibile in diferite feluri. Ai un analist, un programator, niste testeri, un manager. Oamenii individuali nu sunt atat de importanti, doar rolurile lor sunt importante. In felul asta, daca proiectezi un proiect, nu conteaza ce analist si ce tester ai, doar ca stii cati ai deci stii cum numarul resurselor iti poate afecta planul.

Dar asta ridica o intrebare cheie: sunt oamenii implicati in dezvoltarea de software parti schimbabile? Una dintre caracteristicile cheie ale metodelor agile este ca ei resping aceasta presupunere.

Poate cea mai explicita respingere a oamenilor ca resursa este Alistair Cockburn. In cartea lui Characterizing People as Non-Linear, First-Order Components in Software Development, sugereaza faptul ca procesele predictibile necesita componente ce se comporta intr-un mod previzibil. Oricum, oamenii nu sunt componente previzibile. In plus, studiile lui despre proiectele software l-au dus sa concluzioneze ca oamenii sunt cel mai important factor in dezvoltarea software.

In titlul [acestui articol] ma refer la oameni ca si cum ar fi "componente". Asta este cum sunt tratati oamenii in proces/metodologiein literatura de design. Greseala in aceasta abordare este ca "oamenii" sunt foarte variabili si nu sunt liniari, cu modele unice de succes si esec. Acest factori sunt in primul rand factori de neneglijabili. Esecul procesului si metodologiei designerilor este cel ce contribuie la tipurile de traictorii neplanificate ale proiectului ce vedem atat de des.

-- [Cockburn non-linear]      

Unii se pot intreba daca nu cumva natura muncii dezvoltarii software-ului este impotriva noastra. Cand programam un calculator, controlam in mod inerent un serviciu previzibil. Din moment ce ne aflam in aceasta activitate pentru ca sunt buni in a o face, sunt perfecti sa stricam lucrurile cand ne confruntam cu fiinte umane.

Chiar daca Cockburn este foarte explicit in viziunea lui axata pe oameni in dezvoltarea software-ului, notiunea de oamenii sunt pe primul loc este o viziune comuna printre multi dintre cugetatorii softisti. Problema ce apare adesea este ca metodologia s-a opus notiunii de oameni ca primul lucru important cand vine vorba de succesul unui proiect.

Asta creeaza u efect de feedback puternic si pozitiv. Daca te astepti ca toti dezvoltatorii tai sa fie unitati programabile conectate compatibil, nu incerci sa-i tratezi individual. Asta scade moralul (si productivitatea). Oamenii buni cauta un loc mai bun in care sa se afle si tu sfarsesti a avea ceea ce miriti: unitati programabile conectate compatibil.

Decizand ca oamenii sunt pe primul loc, este o decizie mare, una ce necesita multa determinare ca sa se intample. Notiunea de oameni ca resursa este adanc impregnata in gandirea de business, radacinile aceste idei ne duc la impactul ce l-a avut Frederick Taylor in abordarea Managementului Stiintific. Daca conduci o fabrica, aceasta abordare Tayloristica s-ar putea sa faca sens. Dar pentru cei creativi si profesionisti, ceea ce cred eu ca este dezvoltarea de software, nu functioneaza. (Si chiar si manufacturarea moderna tinde sa se indeparteze de modelul Taylorist)

Programatorii sunt Profesionisti Responsabili

Un element cheie a notiunii Tayloriste este ca oamenii ce fac munca respectiva, nu sunt capabili sa isi dea seama cum sa faca cel mai bine posibil munca respectiva. Intr-o fabrica posibil sa fie adevarat pentru cateva motive. In mare parte pentru ca muncitorii din fabrica nu sunt foarte inteligenti sau creativi iar aceasta se datoreaza faptului ca exsita tensiuni intre management si muncitori pentru ca managementul castiga mai multi bani iar muncitorii mai putini.

Istoria recenta ne arata cat de neadevarat este acest lucru in dezvoltarea de software. Oameni destepti si capabili sunt atrasi de dezvoltarea de software, atrasi de farmecul acestuia cat si de potentialele castiguri mari. (Exact ce m-a tentat si pe mine ca sa plec de la Ingineria electronica). In ciuda faptului ca la inceputul anilor 2000 a fost o incetinire, inca exsita mult talent si creativitate in dezvoltarea de software.

(S-ar puta ca aici sa fie un efect generalizat. Unele dovezi anecdotice ma face sa ma intreb daca mai multi oameni inteligenti s-ar fi indreptat spre dezvoltarea de software in ultimii 15 ani. Daca asa stau lucrurile, atunci asta ar fi un motiv pentru care afacerile cu calculatoarea sunt precum un crez in randul tinerilor iar precum toate crezurile, trebuie sa existe un gram de adevar in asta).

Cand vrei sa angajezi si sa pastrezi oameni buni, trebuie sa recunosti ca sunt profesionisti competenti. Ca atare, ei sunt cei mai in masura sa decida cum sa se comporte cu privire la munca tehnica. Notiunea Taylorista de a separa departamentul de planificare ce decide cum sa se faca lucrurile functioneaza doar daca cei ce fac planul inteleg cum sa faca treaba mai bine decat cei ce o fac. Daca ai oameni inteligenti, motivati ce fac munca, atunci treaba de maisus nu se poate aplica.

Administrand un Proces Orientat catre Oameni

Indreaptarea spre oameni se manifesta intr-un numar de diferite feluri in procesul agil. Conduce la efecte diferite, nu toate dintre ele fiind consistente.

Unul din elementele cheie este acela de acceptare a procesului fata de impunerea procesului. Adesea, procesarea software este impusa de cifrele manageriale. In felul asta, programatorii se opun, mai ales cand conducerea sta departe mult timp de dezvoltara activa. Acceptand oprocedura necesita angajament si implicarea activa a echipei.

Cu aceasta sfarsim cu interesantul rezultat ca doar dezvoltatorii insusi pot alege sa urmeze un proces adaptiv. Asta este adevarat in mod particular pentru XP, care necesita multa disciplina ca sa fie facuta. Crystal este considerata ca o abordare mai putin disciplinata ce este adecvata pentru o audienta mai larga.

Un alt punct de vedere este acela cum ca dezvoltatorii trebuie sa fie capabil sa ia toate decizile tehnice. XP ajunge la inima problemei unde in planificarea procesului spun clar ca numai dezvoltatorii pot face estimari a cat de mult timp o sa dureze sa faca niste munca.

Asemenea directie tehnica este o mare schimbare pentru multi oameni in pozitii de management. O asemenea abordare necesita o imparteala de responsabilitati unde dezvoltatorii si managerii au un loc egal in conducerea proiectului. Observa ca spun egal. Managementul inca are rolul sau dar recunoaste expertiza dezvoltatorilor.

Un motiv important pentru asta este rata de schimbare a tehnologiei in industria noastra. Dupa cativa ani, cunostiinta tehnica devine invechita. Aceasta jumatate de viata a abilitatilor tehnice este neegalata in alta industrie. Pana chiar si oamenii tehnici trebuie sa recunoasca ca intrand in management inseamna ca abilitatile lor or sa se mareasca repede. Fostii dezvoltatori trebuie sa recunoasca ca abilitatile lor tehnice or sa dispara repede sic a au nevoie sa se increada si sa se bazeze pe dezvoltatorii actuali.

Greutatea Masurii

Daca ai o procedura unde oamenii care zic cum sa fie facut munca si difera de ceea ce fac oamenii pe bune, sefii au nevoie de un fel de masurare a cat de efectivi sunt cei ce o fac. In Managementul Stiintific a fost un imbold puternic pentru a dezvolta apropieri obiective in a masura aportul oamenilor.

Asta este relevant petnru software datorita dificultatii de a aplica masuratori software-ului. In ciuda celor mai bune eforturi ale noastre nu am fost in stare sa masuram cele mai simple lucruri cand vine vorba de soft, precum ar fi productivitatea. Fara masuratori bune pentru aceste lucruri, orice fel de control externe este supus pierzaniei.

Introducand masurarea managementului fara masuratori bune, duce la la propriile probleme. Robert Austin a facut o discutie excelenta asupra acestui lucru. El subliniaza faptul ca atunci cand masori performanta trebuie sa iei in calcul toti factorii importanti masurabili. Orice lipseste are inevitabilul rezultat ca cei ce fac munca vor modifica ceea ce fac pentru a obtine cele mai bune masuratori, chiar daca asta reduce efectul adevarat a ceea ce fac ei. Aceasta disfunctie este calcaiul lui Ahile al masuratorilor bazate pe management.

Cocluzia lui Austin este ca trebuie sa alegi intre management bazat pe masuratori si management ce deleaga (unde cei ce fac munca decid cum sa o faca). Managementul bazat pe masuratori este cel mai bun pentru munca simpla repetitiva cu putine cerinte despre cunoastere si cu rezultate usor de masurat - exact opusul dezvoltatii de software.

Toate ideea asta consta in faptul ca metodele traditionale au functionat sub asumptia ca managementul bazat pe masuratori este cel mai eficient mod de management. Comunitatea agila recunoaste cum ca, caracteristica dezvoltarii de software precum cele ce masoara managementul de baza, duc la nivele foarte mari de disfunctionalitati in masurare. De fapt este mai eficient sa folosesti un stil de management in care delegi, care este si felul de abordare care se afla la baza puntului de vedere agilistic.

Rolul de Lider in Afaceri

Dar oamenii tehnici nu pot sa faca intregul proces ei insusi. Au nevoie sa se muleze pe nevoiele afacerii. Asta duce la un alt aspect importatn de adaptivitate: au nevoie de contact apropiat cu expertiza tehnica.

Asta merge dincolo de implicarea majoritatii procedurilor afacerii. Echipele agile nu pot exista cu comunicare ocazionala. EI au nevoie de acces continuu asupra expertizei afacerii. Mai mult, acest acces nu este ceva ce este condus la nivel managerial, este ceva ce este prezent pentru orice dezvoltator. Din moment ce dezvoltatorii sunt profesionisti capabili in propria lor disciplina, ei trebuie sa poata sa munceasca ca egali alaturi de alti profesionisti in alte discipline.

O parte parte a acestei situatii, desigur, se datoreaza naturii dezvoltarii adaptative. Din moment ce intreaga prezumtie a dezvoltarii adaptative este ca lucrurile se schimba repede, trebuie contact constant ca sa-i sfatuiesti pe toti asupra schimbarilor.

Nu exista nimic mai frustrant pentru un dezvoltator decat sa vada munca lor este irosita. Asa ca este important sa te asiguri ca exista expertiza de afaceri de calitate buna care este


Procesul auto Adaptiv

Pana acum am discutat despre adaptivitate in contextul unui proiect prin care isi adapteaza software-ul frecvent ca sa faca fata schimbarilor cerute de clientii sai. Oricum, exista un alt unghi adaptabilitatii: acela al procesului ce se schimba in timp. Un proiect ce incepe sa foloseasca un proces adaptiv nu o sa aiba acelasi proces un an mai tarziu. In timp, echipa o sa gaseasca ceea ce functioneaza pentru ei si o sa modifice procesul ca sa se potriveasca.

Prima parte a auto-adaptarii personale sunt revizuirile regulate ale procesului. In mod normal faci acest lucru cu fiecare repetare. La sfarsitul fiecarei repetari, sa ai o sedinta scurta si sa te intrebi urmatoarele intrebari (culese din Norm Kerth)

  • Ce am facut bine?
  • Ce am invatat?
  • Ce putem face mai bine?
  • Ce nu ne iese?

Aceste intrbari intrebari o sa te duca la idei de a schimba procesul pentru urmatoarea repetare. In acest fel, un proces ce incepe cu probleme se poate imbunatii pe masura pe procesul merge mai departe, adaptandu-se mai bine echipei ce il foloseste.

Daca auto adaptivitatea se intampla intr-un proiect, este chiar mai mult marcat intr-o organizatie. O consecinta a auto adaptibilitatii este ca nu ar trebui sa te astepti sa gasesti o singura metodologie corporatista. In schimb, fiecare echipa nu ar trebui doar sa aleaga propriul proces dar de asemea ar trebui in mod activ sa-si tuneze procesul pe masura ce avanseaza cu proiectul. in timp ce ambele procese publicate precum si experienta altor proiecte pot sa joace un rol in inspiratie si in ideea de baza, responsabilitatea profesionala a dezvoltatorilor este sa adapteze procesul sarcinii la indemana.


Aromele Dezvoltarii Agile

Termenul "agil" se refera la o filosofie a dezvoltarii software-ului. Sub aceasta larga umbrela stau multe abordari specifice precum Programarea Extrema, Scrum, Lean Development, etc. Fiecare din aceste abordari au propriile lor idei, comunicati si lideri. Fiecare comunitate reprezinta un grup distins propriu dar ca sa fie corect numele de agil ar trebui sa urmareasca aceleasi principii de baza. Fiecare comunitate de asemenea imprumuta din idei si din tehnicile celorlalti. Multi practicieni se muta intre diferite comunitati impartasind in jur diferite idei - in intregime este un ecosistem complicat dar vibrant.

Pana acum mi-am spus parerea de ansamblu asupra definitiei a ce inseamna agil. Acum vreau sa va introduc undel comunitati diferite de agili. Pot doar sa va dau o vizualizare rapida aici dar includ referinte asa ca poti sapa mai departe daca preferi.

Din moment ce urmeaza sa dau mai multe referinte, acesta este un bun punct ca sa punctez niste surse pentruinformarea generala a metodelor agile. Centrul web este Agile Alliance, o organizatie non profit care are rolul de a incuraja si sa cerceteze dezvoltarea softului agil. Patru carti as sugera si anume prezentari de Alistar Cockburn si Jim Highsmith. Cartea lui Craig Larman despre dezvoltarea agila ce contine o istorie foarte utila a dezvoltarii repetative. Pentru a vedea mai multe din parerea mea despre metodele agile, uita-te la sectiunile mele cu articole si blog.

Urmatoarea lista nu este deloc completa. Reflecta o selectie personala a aromelor agile ce m-au interesat si m-au influentat in ultima decada sau si mai bine

Agile Manifesto

Termenul "agil" a fost deturnat pentru aceasta activitate la inceputurile lui 2001 cand o gramada de oameni ce erau implicati in acest tip de munca au aparut cu Manifesto for Agile Software Development.

Inainte de asta, un numar de grupuri diferite au dezvoltat idei similare desore dezvoltare ade software. Majoritatea, dar in niciun caz toata, munca a venit de la comunicatea de software orientat pe obiect care de ceva timp tot isi doreau asemenea abordari. Eseul a fost scris initial in anul 2000 pentru a incerca sa strang la un loc toate aceste trend-uri. La vremea respectiva nu era un nume pentru aceste abordari dar au fost intitulate categoria usoara. Multi dintre oamanii implicati n-au simtit ca ar fi un termen bun pentru ca nu cuprindea acuratetea esentei acestor abordari si despre ce era vorba cu ele.

Au fost niste discutii despre probleme mai mari in aceste abordari in anul 2000 la un
atelier gazduit de Kent Beck in Oregon. Desi acest atelier era focusat pe Extreme
Programming (comunitatea la vremea respectiva a castigat cea mai marea atentie) dar au
aparut si cativa ce nu se ocupau de XP. Una dintre discutiile de atunci era daca ar fi
mai bine XP sa fie raspandita peste tot sau sa fie mai concentrata.Kent prefera o
comunitate mai focusata si mai coerenta.

Workshop-ul a fost organizat, daca imi aduc aminte exact, in primul rand de catre Jim Highsmith si Bob Martin. Ei au contactat oamenicare au simtit ca sunt activi in comunitatile cu aceste idei similare si au strans 17 dintre ei pentru atelierul Snowbird. Ideea initiala era doar sa se stranga si sa inteleaga mai bine abordarea celuilalt. Robert Martin era dornic sa obtina o declaratie, un manifest care ar fi putut sa fie folosit sa-i stranga pe toti din industrie sa adopte aceste tehnici. De asemenea am decis sa alegem un nume care sa actioneze precum o umbrela pentru diferita abordari.

In timpul Workshop-ului am decis sa folosim "agil" ca numele umbrela si au aparut parti valoroare ale manifestului. Sectiunea de principii a fost inceputa in Workshop dar a fost in mare parte dezvoltata pe platforma wiki.

Efortul a lovit un nerv, cred ca eram toti foarte surprinsi de nivelul de atentie si apreciere primita de manifest. Chiar daca manifestul nu se poate despre el ca fiind o definitie riguroasa a miscarii agile, el furnizeaza o afirmatie concentrata ce ajuta la impamantnirea ideilor. La putin timp dupa ce am terminat manifestul, Jim Highsmith si cu mine am scris un articol pentru SD Magazine ce furniza niste comentarii la manifest.

Mai tarziu in acel an, majoritatea celor 17 care au scris manifestul, s-au reunit impreuna cu mai multi la OOPSLA 2001. Era o sugestie cum ca autorii manifestului ar trebui sa inceapa o miscare agila dar autorii au cazut de comun acord ca ei sunt doar oameni ce au venitla acel workshop si au produs un manifest. In niciun caz acel grup de oameni nu ar fi putut sa preaia conducerea intregii miscari agile. Noidoar am lansat nava si este disponibila pentru oricine doreste sa navigheze cu ea. Deci acesta a fost sfarsitul celor 17 autori ce ca un grup organizat.

Totusi a fost un pas urmator, cu implicarea activa a multora dintre acesti autori s-a format alianta agila. Acest grup este o organizatie nop-profit ce are ca intentie promovarea si cercetarea metodelor agile. Printre altele, sponsorizeaza o conferinta anuala in Statele Unite.

XP (Programare Extrema)

In timpul popularitatii timpurii a metodelor agile la sfarsitul anilor 90, Programarea Extrema era cea ce a primit atentie maxima. In multe feluri inca primeste.

Radacinile XP se afla in comunitatea Smalltalk si mai ales in colaborarea apropiata a lui Kent Beck si Ward Cunningham la sfarsitul anilor 1980. Amandoi si-au rafinat practicile a numeroase proiecte in timpul anilor 90, extinzand ideile de dezvoltare software ce erau si adaptive si orientate catre om.

Kent a continuat sa isi dezvole ideile in timp ce era consultant, mai exact la proiectul Chrysler C3, care a devenit cunoscut de atunci ca si proiectul de creatie a Programarii Extreme. A inceput sa foloseasca termenul "extreme programming" prin 1997. (C3 a fost de asemenea primul meu contact cu programarea exrtema si inceputul prieteniei cu Kent).

La sfarsitul anilor 90 lumea programarii extreme s-a raspandit, initial prin descrierea in siturile de stiri si pagina de Wiki a lui Ward Cunningham, unde Kent si Ron Jeffries (un coleg de la C3) au petrecut mult timp explicand si dezbatand ideile. In sfarsit, un  
numar de carti au fost publicate spre sfarsitul anilor 90 si inceputul anilor 2000 care explicau in detaliu varioasele aspecte ale abordarii. Majoritatea acestor carti au luat cartea alba a lui Kent Beck ca pe o fundatie. Kent a produs o a 2-a editie a cartii albe in 2004 care reprezinta o abordare importanta a abordarii acestei miscari de programare.

XP incepe cu cinci valori (Comunicatia, Feedback, Simplicitate, Curaj si Respect). Dupa care le elaboreaza pe acestea in 14 principii si 24 de practici. Ideea este ca procedurile sunt lucruri solide ce o echipa le poate face zi ce zi, unde valorile sunt cunostiintele de baza si intelegerea lor se afla la baza abordarii. Valori fara practica sunt greu de pus in practica si se pot aplica in multe feluri incat este greu de stiut de unde sa se inceapa. Practicile fara valori sunt activitati fara scop. Atat valorile cand si practica sunte necesare, dar se afla un gol mare intre ele - principiile ajuta la umplerea golului dintre ele. Multe dintre practicile XP incearca si testeaza tehnici, ce adesea sunt uitate de catre multi, incluzand cele mai planificate proceduri. Precum si resuscitarea acestor practici de XP ii inmana intr-un intreg total unde fiecare este reintarit de catre ceilalti si le da scop si valoare.

Una dintre cele mai frapante, initial ce ma atragea, este  punerea accentului pe testare. in timp ce toate procesele mentioneaza de testare, majoritatea o fac fara sa accentueze prea mult acest lucru. Oricum XP pune testarea la fundatia dezvoltarii, cu fiecare programator ce scrie teste in timp ce scriu cod. Testele sunt integrate intr-o integrare continua si proces de constructie ce genereaza o platforma foarte stabila pentru viitoarele dezvoltari. Abordarea XP este descrisa sub titlul de Test Driven Develoopment (TDD) a influentat chiar si locurile ce nu au adoptat XP.

Exista multe publicatii despre programarea exptrema. Oricum, o zona unde se face confuzia, este schimbarea dintre prima si a doua carte alba. Am zis mai sus este o reiteratie a programarii extreme, in felul ca abordarea este la fel dar este descrisa altfel. Prima editie (cu patru valori, 12 practici si niste principii importante dar adesea ignorate) a avut o mare influenta asupra industriei software si majoritatea descrierilor de programare extrema au fost scrise pe baza descrierilor din prima editie. Retinenti acest lucru in tiimp ce cititi materiale despre XP, mai ales daca acestea sunt inainte de 2005 scrise. intr=adevar majoritatea dupa net despre Xp, sunt bazate pe prima editie a cartii.

Locul natural sa incepi sa descoperi mai mult este a-2a editie a cartii albe. Aceasta carte explica fundalul si practicile XP intr-un pachet scurt (160 de pagini). Kent Beck a editat o serie colorata a cartilor despre programare extrema la inceputul schimbarii secolului iar daca as fi fortat sa aleg una pentru o recomandare, atunci as alege-o pe cea purpurie si retineti ca majoritatea materialului este bazat pe prima editie.

Exista mult materiale pe web despre XP dar majoritatea este bazat pe prima carte. Una din putinele descrieri pe care le stiu sa faca referire la a2-a carte, este o lucrare a noului XP (PDF) scrisa de catre michele Marchesi care initial desfasura in sardinia conferinte XP. Pentru discutii despre XP exista o lista de emailuri Yahoo

Scrum

Scrum a fost dezvoltat in anii 80 si 90 cu OO cercuri de dezvoltare ca si o metodologie foarte repetititiva. Dezvoltatorii ei cei mai cunoscuti erau Ken Schwaber si Jeff Sutherlna si Mike Beedle.

Scrum se concentreaza pe acele aspecte ale managementului ale dezvoltarii de software, impartind dezvoltarea in repetitii de 30 de zile (numite "sprints") si aplicand monitorizare mai amanuntita si control cu intalniri zilnice bazate pe scrum. Pune accent mai putin pe practicile ingineresti si multi oameni combina abordarile sale de management al proiectului cu practici ingineresti bazate pe programarea extrema. (Practicile de management XP nu sunt foarte diferite).

Ken Schwaber este unul dintre cei mai activi sustinatori ai miscarii Scrum, websitul sau este un loc bun ca sa incepeti sa cautati mai multe informatii si cartea lui este probabile cea mai buna prima referinta.

Crystal

Alistar Cockburn a fost una dintre principalele voci ale comunitatii agile. A dezvoltat metodele de dezvoltare Crystal ca un grup de abordari croite pe diferite marimi de echipe. Crystal este vazut precum o famile pentru ca Alistar crede ca diferite abordari sunt necesare pentru ca echipele variaza in marimi si cricalitatea schimbarilor erorilor.

In ciuda variatiunilor sale, taote abordarile Crystalimpartasesc functiuni comune. Toate metodele crystal au trei prioritati: siguranta (in finalizarea proiectului), eficienta, locuibilitatatea (dezvoltatorii pot sa locuiaca cu crystal). De asemenea mai impartasesc proprietati comune dintre care cele mai importante trei sunt: Livrarea Frecventa, Imbunatatiri Reflexive si Comunicare Constanta.

Prioritatea locuibilitatii este o parte importanta a modului de gandire crystal. Cautarea lui Alistar (asa cum o vad eu) este sa gaseasca ceea ce inseamna cel mai mic proces ce poate fi facut si sa reuseasca cu presupuneri ce stau la baza disciplinei ce este inevitabila apentru oameni. Casi rezultat, Alistar vede in Crystal o metoda ce necesita mai putina disciplina decat programarea extrema, dandla schimb eficienta redusa pentru o locuibilitate mai mare si sanse reduse de esec.

In ciuda conturului Crystal, exista o descriere cuprinzatoare a tuturor manifestarilor sale. Cel mai bine descrie Crystal Clear, ce ofera o descriere moderna a cartii. De asemenea exista si site wiki pentru aprofundare si discutii despre Crystal.

Testare Bazata pe Context

Inca de la inceput, dezvoltatorii software sunt cei care au condus comunitatea agila. Oricum, multi alti oameni sunt implicati in dezvoltarea softeare si sunt afectati de aceasta noua miscare. Un grup evident dintre acestia sunt testerii. care adesea traiesc intr-o lume ce contine gandire in cascada. Cu ghidaje normale ce subliniaza rolul testarii este sa asigure conformitatea software-ului  cu sfecificatii scrise in avans, deci rolul testerilor intr-o lume agila este departe de a fi clar.

Dupa cum se dovedeste, cativa oameni din comunitatea testerilor au pus la indoiala testarea in masa, gandindu-se pentru o vreme. Asa a dus la un grup de oameni cunoscuti precum testori de continuri. Cea mai bua descriere a acesteia se afla in cartea Lessons Learned in Software Tsting. Aceasta comunitate este de asemenea foarte activa pe net, uitati-va la websiturile hostate de Brian Marick (unul dintre autorii manifestului Agil), Brett Pattichord, James Bach so Cem Kaner.

Dezvoltare Lean

Imi amintesc acum cativa ani tinand un discurs despre metodele agile la o conferinta pentru dezvoltarea de software si am discutat cu o femeie interesata despre paralelele dintre ideile agile si miscarea lean. Mary Poppendieck (si sotul Tom) au inceput sa devina suporteri activi ai comunitatii agile, in special uitandu-se dupa suprapuneri si inspiratii intre producia lean si dezvoltare software-ului.

Miscarea lean a fost pionierat de catre Taiichi Ohno de la Toyota si este adesea cunoscuta ca Sistemul de Productie Toyota. Producerea Lean a fost o inspiratie pentru multii dintre primii agilisti - familia Poppendiecks sunt cei mai in masura sa descrie cum aceste idei interactioneaza. In general, nu sunt adeptul acestori tipuri de ratiuni prin analogie, intr-adevar separarea inginereasca intre design si constructie ne-a bagat in acest bucluc in prima parte. Oricum, analogiile pot sa duca la idei bune si cred ca ideile line au introdus multe idei folositoare si unele in miscarea agila.

 Cartea familie Poppendieck si websit-ul are locurile de pornire evidente pentru mai multe informatie.

Proces (Rational) Unificat

Un alt binecunoscutproces care a aparut din comunitatea bazata si orientata pe obiect este Procesul Rational Unificat (uneori se refera la el ca Procesul Unificat). Ideea de baza era precum modelul limbajului unificat UML. Din moment ce RUP a aparut cam in acelasi timp precum metodele agie, exista multe discutii daca cele doua sunt compatibile.

RUP este o colectie de practici este un proces bazat pe framework-uri mai degraba decat pe proceduri. Mai degraba dai un singur proces pentru dezvoltarea software cauta sa puna la discpozitie un set comun de practici din care echipele pot alege dintr-un proces individual sau cum RUP le numeste, cazuri de dezvoltare.

Aspectele comune ale RUP este ca e bazat pe Use Case Driven (dezvoltarea este condusa prin functiuni vizibile utilizatorului), repetative si centrate pe arhitectura (exista o prioritate in construirea arhitecturii timpurii pe care sa reziste proiectul).

Experienta mea cu RUP estec a problema lui este variabilitatea lui infinita. Am vazut descrieri a folosirii RUP care porneau de la cascade rigide cu "analiza repetitiei" ca sa devina agil. Am fost uimit de faptul ca dorinta oamenilor sa marcheteze RUP ca un singur proces a dus la un rezultat unde oamenii pot face cam orice si sa-l numeaca ca fiind RUP - rezultand ca RUP sa devina o fraza fara sens.

In ciuda a tuturor acestora sunt oameni puternici in comunitatea RUP care sunt aliniati cu gandirea agila. Am fost impresionat in toate intalnirile mele cu Phillippe Kruchten si cartea lui este cel mai bun punct de pornire pentru RUP. Craig Larman a dezvoltat de asemenea descrieri a muncii cu RUP intr-un sitl agil in cartea lui introductiva despre designul OO.

Sa te apuci de Agil?

Sa folosesti o metoda agila nu este pentru oricine. Sunt o gramada de lucruri de luat in calcul daca decizi sa urmaresti aceasta cale. Oricum, eu cred cu certitudine ca aceste metodologii sunt foarte des aplicate si ar trebuie folosit de mai multi decat se credea in mod normal.

In mediu de astazi, cea mai comuna metodologie este sa codezi si sa repari. Aplicand mai multa disciplina decat haos, in mod ajuta si abordarea agila are avantajul ca este mai mult un pas mai important decat folosirea metodelor grele. Aici metodele agile sunt un avantaj clar. Procese similare vor urma cand nu esti obisnuit cu proceduri.

Pentru cineva nou in aplicarea metodelor agile, intrebarea este de unde sa inceapa. Pentru ca cu orice tehnologie sau proces nou, trebuie sa ii faci propria evaluare. Asta iti permite sa vezi cum se potriveste in mediul tau. Ca si rezultat, mult din sfatul meu ce l-am dat asupra noilor abordari, aduce amintiri despre cand discutam prima oara despre tehnicile orientate spre obiect.

Primul pas este gasirea de proiecte sustenabile pe care sa incercati metode agile. Din moment ce metodele agile sunt fundamental orientate spre oameni, este esential sa incepi cu o echipa ce vrea sa incerce si sa munceasca in modul agil. Nu doar o echipa ce se impotriveste si este greu de lucrat cu ea, impunand metode agile asupra oamenilor ce nu cred in asa ceva este impotriva metodelor agile.

Este valoros sa lucrezi cu clienti (cei ce au nevoie de software) ce vor sa lucreze in acest fel colaborativ. Daca clientii nu colaboreaza, atunci nu vei vedea avantajele totale unui proces adaptativ. Am avut ocazia sa lucram cu clienti care nu vroiau sa colaboreze dar si-au schimbat modul de gandire dupa primele luni cand au inceput sa inteleaga abordarea agila.

Multi oameni sustin ca metodele agile nu pot fi folosite pe proiecte mari. Noi (ThoughtWorks) am avut un mare succes cu proiectele agile cu 100 de oameni pe multiple continente. In ciuda acestui fapt as sugera sa alegeti ceva mai mic cu care sa incepeti. Proiectele mai mari, in mod inerent, mai dificile, deci este bine sa incepeti un proiect ce are o marime flexibila.

Unii oameni sfatuiesc sa alegeti un proiect cu putin impact asupra business-ului cu care sa incepeti, in felul acesta daca ceva nu merge bine, nu s-a stricat nimic. Oricumm un proiect neimportant, adesea este testat putin pentru ca nimenui nu ii pasa de rezultat. Prefer sa sfatuiesc oamenii sa aleaga un proiect care este mai dificil decat cu ce sunteti confortabil. 

Poate ca cel mai important lucru ce il puteti face este sa gasiti pe careva mai experimentat in metodele agile care sa te ajute sa inveti. Oricand cineva face ceva nou, inevitabil o sa faca greseli. Gasiti pe careva ce a facut multe greseli ca sa poti evita sa le faci si tu. Din nou, asta este ceva adevarat aplicabil pentru orice tehnologie noua sau tehnica, deci un mentor bun valoreaza greutatea sa in aur. Desigur, acest sfat este un autoserviciu din moment ce ThoughWorks  si multi dintre prietenii mei cred in importanta gasirii unui mentor bun.

Si odata ce ai gasit un mentor bun, sa-i urmezi sfatul. Este foarte usor sa iti dai cu presupusul asupra multora dintre acestea si am invatat din experienta ca multe tehnici nu pot fi intelese pana cand nu le incerci. Unul dintre cele mai bune exemple ce le-am auzit a fost despre un clinet de al nostru ce a decis sa faca teste pe programarea extrema pentru cateva luni. In timpul acelei perioada au zis clar ca ar face orice le spune mentorul - chiar daca credeau ca este o idee proasta. La sfarsitul perioadei de evaluare ei s-au oprit si au decis daca vor sa duca mai departe vreuna dintre idei sau sa revina la felul vechi de lucru. (In caz ca va intrebati, au decis sa continue cu XP).

Una dintre intrebarile deschise despre metodele agile este unde se afla conditiile granitei. Una dintre problemele aparute cu orice tehnica noua este ca nu esti pe bune constient ce merge si ce nu, pana cand nu te lovesti de ele si esuezi. Metodele agile sunt inca prea tinere ca se poate remarca unde sunt granitele. Asta face sa fie greu de tras o concluzie sa decizi ce inseamna succesul si esecul in dezvoltarea de software, precum si multi factori variabili ce pot pune la pamant sursa promelor.

Deci unde nu ar trebui sa folosesti o metoda agila? Cred ca ramane la latitudinea oamenilor acest lucru. Daca oamenii nu sunt interesati in colaborarea intensa ce este necesara muncii agile, atunci urmeaza sa fie un mare chin sa-i faci sa munceasca in felul asta. IN mod particular cred ca asta inseamna ca niciodata nu ar trebui sa impui metoda agila unei echipe ce nu vrea sa incerce asa ceva.

S-a castigat multa experienta cu metodele agile in ultimii 10 ani. La ThoughWorks noi intotdeauna folosim o abordare agila daca clientii nostrii sunt dispusi iar mare majoritate a timpului sunt. Eu (si noi) continuam sa fim mari fani a acestei metode de munca.

Translated by: Irina Vasilescu

Link to the original page: Click Here

We love giving back to the community

We believe in helping people and that matter to us more than anything else. Since the very beginning of our company, our team have been willing and wishing to help.

View more of our social work →