Share
Agile sau Agile de Dezvoltare - auzim aceste cuvinte mai des în zilele noastre. Dar știm cu adevărat despre ce este vorba? Cum ne poate ajuta să devenim mai eficienți, având o mulțime de distracție în dezvoltarea de software? Cum îl putem folosi pentru a comunica cu oamenii de afaceri și pentru a face această comunicare ușoară și constructivă pentru ambele părți?
Au existat o grămadă de băieți foarte talentați și experimentați care au dezvoltat programe grave. Acești dezvoltatori au observat alte companii și echipe de dezvoltare și modul în care procesele lor au făcut munca mai ușoară. Ei și-au compilat observațiile pentru a crea Manifestul Agil. Și ei au spus:
Descoperim modalități mai bune de dezvoltare a software-ului făcând-o și ajutându-i pe alții să o facă. Prin această lucrare am ajuns la valoare:
Adică, în timp ce există valori în elementele din dreapta, apreciem elementele din stânga mai mult.
În acest articol, voi prezenta douăsprezece teorii și tehnici ale dezvoltării agile. Acesta este doar primul pas spre noua lume a procesului de dezvoltare software.
Prioritatea noastră cea mai înaltă este de a satisface clientul prin livrarea timpurie și continuă a unor produse software valoroase, dar nu și complete. Aceasta înseamnă că dezvoltăm software și adăugăm cel puțin o caracteristică, pe iterație.
Să ne imaginăm că vrem să creăm un motor de blog; am putea face acest lucru folosind următorul proces:
Este o abordare simplă, dar clientul vede progresul real al software-ului său și vă oferă feedback imediat despre fiecare caracteristică nouă. Poate fi perfect sau necesită alinierea, dar puteți răspunde rapid la schimbări: o situație win-win.
Chiar și la sfârșitul ciclului de dezvoltare, procesele Agile vă permit să întâmpinați schimbări pentru avantajul competitiv al clientului.
Clientul dorește ca proiectul să se termine rapid și cât mai aproape de designul atins în mintea lor. Acest lucru este ușor de atins prin simpla ascultare a contribuției lor și fiind gata pentru schimbări. Dacă suntem capabili să reacționăm rapid la cerințele în schimbare, suntem, probabil, cea mai bună alegere pe care a făcut-o vreodată clientul nostru. Agile este vorba despre comunicare și schimbări. Facem lucrurile așa cum ni se cere să le facem, făcând procesul de dezvoltare a software-ului să se termine mai repede. Acest lucru se realizează deoarece dezvoltăm mici bucăți de software, iar o schimbare a cerințelor nu ne afectează cu adevărat.
Ar trebui să furnizăm actualizări de la câteva săptămâni la câteva luni; cu cât perioada de timp este mai scurtă, cu atât mai bine.
clienții se simt mai încrezători în noi și în produsul nostru, așa cum este actualizat
Din experiențele mele, clienții se simt mai încrezători în noi și în produsul nostru, așa cum este actualizat - ceea ce este vital pentru relația noastră cu ei. Un alt avantaj este feedback-ul de la clientul nostru; permițându-ne să reacționăm schimbând clasele, caracteristicile, modulele sau chiar arhitectura. Nu ne vom trezi după zile sau luni de muncă, doar pentru a vedea că totul se duce în coșul de gunoi. Să luăm în considerare o situație ipotetică:
Vi sa solicitat să creați un modul care să afișeze un text simplu într-un manager de conținut. Dintr-o dată, cerințele se modifică și trebuie să adăugați un formular care ar trebui să trimită un e-mail la o adresă configurată. În plus, formularul trebuie să fie personalizabil, astfel încât utilizatorul să poată adăuga câmpuri noi și să definească validatori. Deci, practic trebuie să uitați de cerința originală a textului simplu. Cât de curând ați vrea să știți despre această schimbare?
Dacă lucrați la un proiect cu clientul dvs. și vă difuzați frecvent, veți ști mai repede despre aceste modificări, iar modificări precum acestea vor deveni mai ușor pentru voi.
Acest lucru se poate dovedi a fi cel mai dificil principiu de obișnuit, dacă ați dezvoltat software-ul în vechiul stil de cascadă. Sunteți, ca dezvoltator, de obicei nu vorbiți aceeași limbă ca și clientul dvs., dar puteți găsi modalități de a menține o comunicare semnificativă cu aceștia. Una dintre cele mai bune căi, în opinia mea, este să descriu totul cu o poveste simplă care ne spune, dezvoltatorului, pentru care este caracteristica, care este responsabilitatea sa și de ce avem nevoie de ea deloc. Desigur, acest lucru devine mai ușor cu cât lucrăm mai mult cu clientul nostru. O altă abordare utilă este Behavior Driven Development (BDD), dar acesta este un subiect pentru un articol diferit.
Dați oamenilor pe care îi lucrați mediul și sprijinul de care au nevoie și, mai presus de toate, să aveți încredere în ei pentru a-ți face treaba.
Este important să oferiți o atmosferă interesantă și toate instrumentele necesare pentru a crea un software bun. Companiile își pierd cei mai buni muncitori, mai ales pentru că nu le pasă cu adevărat de ei. Convingerea că dezvoltatorii pot scrie, testa și implementa software pe un anumit server folosind un client FTP și editarea fișierelor de producție live s-au pierdut undeva. Dacă nu ați condamnat aceste vechi obiceiuri școlare, ar fi mai bine să o faceți acum.
Menținerea angajaților este doar un beneficiu; puteți dezvolta software mai bun și mai mare într-un ritm mai rapid. Doar gândiți-vă: scrierea unui cod reutilizabil, teste automate și implementarea automată pe orice server (printre altele) poate afecta în mod pozitiv timpul de dezvoltare. De obicei, credem că încetinesc un proiect deoarece trebuie să învățăm să folosim instrumente utile, cum ar fi Jenkins, GIT, SVN, Gerrit, Behat etc. Cu siguranță ne facem, dar putem reutiliza apoi aceste instrumente și concepte în viitoarele proiecte.
Este cea mai eficientă și eficientă metodă de transmitere a informațiilor clienților noștri și echipei de dezvoltare.
Cine nu sa copleșit și / sau supărat, văzând 6255384 de e-mailuri în căsuța de e-mail, deoarece compania dvs. cere ca toate conversațiile să fie "pe hârtie"? Am văzut personal asta de câteva ori în viața mea și nu recomand să lucrez într-o companie cu astfel de obiceiuri. Discuțiile față în față fac comunicarea mai ușoară și mai ușoară și ne permit să oferim mai multe informații. Putem folosi modalități de comunicare verbale și non-verbale pentru a arăta colegilor noștri la ce ne gândim. În mod evident, este mai rapid decât trimiterea de e-mail reciproc.
Dar, mai presus de toate, trebuie să ne încredem reciproc; încrederea este câștigată cu ușurință într-un mediu care încurajează comunicarea față în față.
Aceasta este una dintre regulile mele preferate; ne permite să lucrăm liber în conformitate cu propriile noastre procese. Dezvoltatorii de software diferă de ceilalți angajați; astfel încât, firește, ar trebui tratate ca atare. Din experiența mea personală, am învățat să nu judec pe nimeni din echipa de dezvoltare atât timp cât se termină treaba. Dezvoltatorii nu dorește să creeze software rău și sunt mai puțin susceptibili să facă acest lucru dacă îi lăsăm să lucreze în funcție de propriile preferințe. La urma urmei, clientul este fericit atâta timp cât lucrarea pe care a comandat-o se face corect; nu le pasă cum sa făcut.
Procesele agile promovează dezvoltarea durabilă, permițând menținerea unui ritm constant pe termen nelimitat.
Avantajele cele mai bine cunoscute ale Agilei (cum ar fi acceptarea cerințelor în schimbare, reacția rapidă la feedback etc.) sunt apreciate pe scară largă, dar cel mai bun avantaj, în opinia mea, este capacitatea de a determina cu precizie perioada de timp în care un proiect sau o facilitate a consuma. După câteva livrări, echipa dev va produce cel mai valoros număr de activitate: capacitate. Capacitatea este cantitatea de muncă pe care echipa o poate face într-o singură iterație. Numărul de capacitate este stabil după câteva iterații și putem evita termenele ridicole și estimările de timp care sunt "scoase dintr-o pălărie", prezentând oferta companiei noastre clientului.
Mulți oameni spun că este imposibil și planificarea se dovedește a fi mai exactă. Nu sunt de acord; programul presupune că nu vor exista greșeli sau întârzieri inevitabile.
Este un plan perfect pentru o echipă perfectă și asta nu există.
O atenție continuă pentru industria noastră sporește agilitatea.
Suntem de așteptat să evoluăm și să progresăm. Trebuie să continuăm să învățăm în fiecare zi, deoarece industria se mișcă într-un ritm atât de rapid. Atât hardware-ul, cât și software-ul devin mai bine, trebuie să fim la curent cu datele; în caz contrar, ne vom pierde în "marea noii" și va fi greu să ne întoarcem pe pistă.
Refactorizarea este soluția la majoritatea problemelor. Prin refacerea constantă (atunci când este necesar), putem aplica cu ușurință noi tehnici și mai bine arhitectura noastră software.
Bill Gates a spus odată:
Dacă am o treabă complicată de făcut, o voi da celui mai lazy persoana pe care o am, pentru că vor găsi cel mai simplu mod de a face acest lucru.
Simplitatea este regula de aur. Acest lucru nu înseamnă că trebuie să fii leneș, dar înseamnă că dezvoltatorii își complică munca în majoritatea timpului. Dacă faceți doar treaba pe care clientul o dorește, fără alte funcționalități și îmbunătățiri suplimentare, sarcina dvs. de lucru va fi mai ușoară și veți atinge obiectivele. În cele din urmă, acesta este tot ce îi pasă de client.
Cele mai bune arhitecturi, cerințe și modele provin din echipele de auto-organizare.
Suntem numai oameni; nu putem prezice totul.
Ați fost vreodată într-o situație în care ați dezvoltat o aplicație mare și consumatoare de timp și după ce ați petrecut nenumărate ore în fața ecranului scriind mii de linii de cod și articole de lectură, tutoriale și cărți, te-ai așezat în căutarea unor rău (dar de lucru) codul de gândire, "Acum știu cum să scrie mai bine"? Cred că am avut toate aceste momente.
Aici intră regula a unsprezecea. Avem o echipă de dezvoltatori care poate urma principiile Test Drive Development (TDD), unde refactorizarea face parte din proces. În mod magic, software-ul nostru este util, frumos, bine scris, testat și creat rapid. Suntem numai oameni; nu putem prezice totul.
Toate acestea provin din ideea unei echipe de auto-organizare, în care fiecare membru are un rol - nu este dat sau forțat - ci unul care a apărut după o anumită perioadă de timp împreună. Aceasta este frumusețea muncii în echipă.
La intervale regulate, echipa dvs. dev trebuie să reflecte asupra modului în care să devină mai eficientă și să-și ajusteze comportamentul în consecință.
Acest lucru poate necesita câteva cicluri de dezvoltare, dar echipa va lucra în armonie perfectă. Chiar adăugarea de noi persoane în această echipă nu ar fi dăunătoare. O echipă de dezvoltare Agile are de gând să-și facă treaba. Dacă lucrează într-un mediu prietenos, ei vor găsi "melodia muncii" și veți vedea cât de repede se poate dezvolta software-ul.
Există câteva metodologii derivate și bazate pe principiile Agile. Nu le voi descrie pe toate, deoarece fiecare metodologie poate fi acoperită în propriul articol. Cu toate acestea, voi sublinia unele dintre cele mai cunoscute abordări Agile. Un lucru de reținut este că nu există o metodologie care să le guverneze pe toate. Alegeți una care să se potrivească cel mai bine nevoilor dvs. și chiar să o "configurați" pentru a se potrivi cerințelor dvs. specifice.
Creat de Ken Schwaber și Jeff Sutherland, SCRUM este un cadru orientat spre afaceri pentru gestionarea proceselor de dezvoltare software. Există multe tipuri diferite de SCRUM; amintiți-vă că obiectivul principal este să lucrați eficient și eficient și să nu respectați regulile.
Creat de Kent Back, XP este o listă cu cele mai bune practici pe care dezvoltatorii ar trebui să le urmeze în timp ce creează software. Este numit adesea "extensia SCRUM". Această metodologie a normelor orientate spre dezvoltare sa născut, datorită faptului că SCRUM este mai degrabă orientat spre afaceri.
Două dintre principiile principale ale lui Lean sunt: DALAP (decideți cât mai târziu posibil) și DAFAP (livrați cât mai repede posibil). Eu personal recomand să citiți mai multe despre această metodologie, deoarece poate fi foarte utilă.
Există mai multe metodologii în familia Agile; Am menționat pur și simplu cele mai populare opțiuni. Dacă decideți să utilizați Agile în procesul de dezvoltare, trebuie să știți ce sunt aceste metodologii, pentru a alege cea potrivită pentru dvs..
Tehnicile Agile funcționează într-adevăr?
Tehnicile Agile funcționează într-adevăr și metodologiile sunt la fel de magice ca oricine spune? Nu intotdeauna.
Problema pe care am întâlnit-o în companii, unde metodele Agile nu au oferit rezultate (sau chiar au înrăutățit lucrurile), a fost o metodă aleasă prost și lipsa convingerii printre utilizatori (membri de afaceri, echipa de dezvoltare etc.). De aceea, în opinia acestui scriitor, trebuie să fii sigur că toți cei implicați în proces înțeleg regulile și știu "despre ce este vorba".
Vă mulțumim pentru lectură!
Accentsconagua