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.

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

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

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.