Facebook. VKontakte. Excursii. Pregătirea. Profesii pe internet. Autodezvoltare
Cauta pe site

Agile: cum și când se aplică această metodă. Ce este Agile: metodologie, echipă, evaluarea performanței Dezvoltare flexibilă de software

Asemenea abordări mai sunt uneori numite cadre sau metodologii agile.

Agile își are originea în mediul IT, dar apoi s-a răspândit în alte domenii - de la ingineria industrială la inteligența artificială.

Când folosim Scrum cu echipe profesioniste, alegem adesea un ciclu de 2-3 săptămâni cu întâlniri retrospective pentru a ține totul sub control.

Dacă vorbim despre ce este agilitatea, m-aș limita la această frază - este un set de valori în cadrul căruia ne construim munca cu produse și procese din cadrul organizației.

(Managing Partner ScrumTrek Alexey Pimenov la Rusbase)

Un cuvânt de la experți

Vladimir Ovelyan

Proprietar și director general Dostaievski

În funcție de sarcini, folosim diferite metode în cadrul filozofiei - agile, scrum, kanban.

Scrum vă permite să vă dezvoltați în angajați calitati necesare– proactivitate, independență, organizare, abilități de comunicare și previziune. Principalul punct al metodei este de a îndeplini sarcini în echipe auto-organizate, unde fiecare are propriul rol și fiecare este responsabil pentru partea sa din muncă. Folosind Scrum, efectuăm sondaje ale personalului și întocmim programe cu viteza așteptată de finalizare a sarcinilor.

Folosim Agile în comunicatii interne. Am organizat recent un alt sprint pentru a elimina întârzierile angajaților. Toți managerii și specialiștii implicați în proiect au petrecut întreaga zi într-o întâlnire discutând realizările, problemele și sarcinile viitoare în noul sprint.

Acum implementăm în mod activ metoda kanban în companie. Scopul introducerii kanban este de a crește flexibilitatea producției și de a se adapta mai bine la cerințele în schimbare ale pieței. În practică, metoda ne-a ajutat să obținem consistență între stocurile din depozit și produsele efectiv utilizate în producție.

Vitali Sotnikov

Director de creație al Biroului de Comunicații Vizuale „Chernika”

Ilya Shikhaleev

Dezvoltator principal și Scrum Master iSpring

Scrum a adus ritm și înțelegere echipei noastre - indiferent dacă suntem sau nu la timp. Vedem viteza de lucru a echipei, nu există un sentiment de fakap constant. Anterior, au existat situații în care înainte de lansări dure scrum a dispărut undeva și toată lumea a început să se încurce - acum am pierdut asta, există un sentiment constant că suntem la timp. Dacă apar riscuri, le discutăm cu PD într-un stadiu incipient, ajustăm planul sau reducem sfera sarcinilor într-un fel.

Munca a devenit mai transparentă, ziua de lucru a început să se încadreze în norma de 8 ore și, parcă, am început să facem mai multe. Înțelegem că atunci când ai sentimentul că nu ai timp, simți că trebuie să lucrezi mai mult - acest lucru are un efect foarte rău asupra productivității, trebuie să scapi de el.

Evgheni Rossinsky

Director de tehnologie la cinema online ivi

Pentru claritate și deschidere a activității departamentului de dezvoltare, am agățat o tablă specială cu notele „de făcut”, „în curs”, „revizuire”, „testare”, „terminat”, în care toți membrii echipei lipesc autocolante cu sarcini. (în coloana „de făcut”) și, pe măsură ce sunt finalizate, sunt mutate în punctele ulterioare. Iar finalul fericit este punctul final „terminat”. Acest lucru ajută la crearea unei imagini de ansamblu și vă permite să vedeți la ce lucrează fiecare participant.

Foarte punct important metoda (și organizarea fluxului de lucru): după ce toate sarcinile („de făcut”) sunt aprobate, lista este blocată pentru includere. În acest fel, noile sarcini primite nu distrage atenția de la proces și nu încetinesc munca.

Toți participanții evaluează, de asemenea, fiecare sarcină pentru timpul și costurile materiale care vor fi necesare pentru a o îndeplini. Iar cireașa de pe tort sunt întâlnirile săptămânale la o anumită oră (Daily Scrum), unde fiecare membru al echipei vorbește pe scurt despre ce urmează să facă astăzi, ce a făcut ieri (și dacă a întâmpinat vreun obstacol). Acest lucru este important pe drumul către obiectivele pe termen lung - așa puteți înțelege în timp că este timpul să vă schimbați strategia.

ÎN management modern Modelul de management „flexibil” este considerat în trei contexte diferite, care (fiecare în felul său) definesc ce este Agile.

Trei volume de semnificație ale lui Agile

În primul sens, mai restrâns, acest termen a început să fie folosit în domeniul dezvoltării încă de la începutul anilor 2000. software, când în statul american Utah, la o stațiune montană, experții din industrie s-au adunat pentru a discuta despre metode și practici de creare a produselor software care sunt la cerere consumatorul final. Rezultatul acelei întâlniri a fost Manifestul Agile pentru dezvoltarea de produse software, cu 12 principii, care se refereau în primul rând la domeniul restrâns al activităților autorilor, dar care ar putea fi extins la alte proiecte de afaceri.

În al doilea sens, mai larg al termenului, principiile Agile sunt aplicate conducerii aproape oricărei afaceri și sunt folosite ca componente, de exemplu, în conceptul de „lean startup” (Lean Startup). În acest sens, Modelul Agil este înțeles ca urmând o metodologie flexibilă de dezvoltare a proiectelor, care urmează o schemă caracteristică în mai multe etape.

  1. Lucrările la proiect se desfășoară în iterații - cicluri scurte (sprinturi). (În cazul dezvoltării software, durata acestor cicluri variază de la 1 săptămână la 1 lună).
  2. La sfârșitul fiecărui ciclu, este lansat un produs care poate fi deja utilizat în afaceri. Pentru software, un astfel de produs poate fi o aplicație sau doar o parte a acesteia, dar chiar și software-ul „brut” poate și trebuie încercat în acțiune.
  3. Produsul este testat de către client sau utilizatori, care mențin un feedback constant cu dezvoltatorii. O abordare orientată către client este aplicată pe parcursul întregului proiect (toate iterațiile).
  4. Orice comentarii sunt incluse rapid în revizuire, iar modificările care ne permit să corectăm imediat dezvoltarea produsului pe parcurs sunt binevenite, deoarece acest lucru ne permite să evităm acumularea erorilor globale ale sistemului.

Într-un al treilea sens, chiar mai larg, Agile face parte din modelul de management folosit la fabricile Toyota și este acum una dintre componentele de bază ale managementului aproape oricărei producții de succes. Fundamentele Agile în acest context sunt similare cu bazele înțelegerii tehnologiei în alte contexte.

Feedback rapid în stabilirea formatului final de producție la fabricile Toyota a fost oferit de orice muncitor care ar putea deveni inițiatorul opririi transportorului și autorul ajustărilor pentru reglarea fină a ciclului de producție. Pe parcursul producției, transformarea Agilă poate presupune reechipare activitati de productieîn general, dacă produsul devine rezultatul unui răspuns viu la nevoile curente ale clientului. Deci, dacă o fabrică producea bazine de plastic și feedback cu un client demonstrează nevoia de găleți, apoi adaptarea rapidă cu ajustarea paralelă a nuanțelor (forma mânerului, mărimea, culoarea) va fi exact în stilul de management Agile (dacă sunt respectate alte principii).

Principiile managementului agil

Managementul agil al proiectelor ca model de management al proceselor de afaceri este folosit de mii de echipe din întreaga lume, iar următoarele sunt prezente peste tot: caracteristici distinctive această abordare:

  1. Esențial pentru personalizarea produsului este consumatorul și gradul de implicare a acestuia în crearea rezultatului.
  2. Pentru a lua o decizie, echipele trebuie să fie foarte eficiente și coezive.
  3. Lucrul pas cu pas și ciclic devine baza procesului. Proiectul este împărțit în părți mici care sunt finalizate până la o anumită dată înainte de finalizarea proiectului în ansamblu.
  4. Accentul evaluării performanței este pe prezentările frecvente ale stărilor intermediare ale proiectelor.
  5. În munca lor, echipa se bazează pe legea Pareto, conform căreia 20% din eforturi dau 80% din eficiență, ceea ce face posibil să nu se perfecționeze fiecare ciclu individual înainte de a prezenta rezultatul consumatorului. Produsul se îmbunătățește în mod natural cu fiecare nouă iterație.
  6. Este de așteptat ca o etapă să fie finalizată înainte de a trece la următoarea.

Abordarea „agile” a devenit baza pentru o serie de practici metodologice care diferă unele de altele, dar includ ideile de Agile: Scrum, Kanban, Lean, Crystal etc. Metodologia Scrum, de exemplu, este aproape întotdeauna luată în considerare în conjuncţie cu Agile ca sistem unificat management de proiect de dezvoltare software.

Metoda Scrum demonstrează modul în care o „abordare agilă” poate fi aplicată în practică în operațiuni specifice. De exemplu, lucrul cu cerințele proiectului este implementat folosind patru „artefacte”:

  • Product backlog presupune generarea unei liste de cerințe, create după un singur șablon (User Story) și sortate după prioritate. Dacă nu există cerințe, proiectul se încheie.
  • Sprint backlog reprezintă cerințele celei mai apropiate sprinturi (etape), împărțite în sarcini fără posibilitatea de a adăuga noi cerințe în timpul sprintului. Angajamentul pentru etapa următoare luat de o echipă cu tipul Management agil, sunt scrise pe tablă (așa-numitele Kanban).
  • Sprint Goal - obiectivul general al sprintului - un ghid pentru luarea deciziilor alternative.
  • Sprint Burndown Chart - „diagrama arderii”. Arată cât de departe a progresat echipa în timpul etapei.

Formatul de management de proiect Agile nu este potrivit pentru toată lumea și nu întotdeauna. Structurile guvernamentale, ale căror activități se bazează pe legislație neschimbată și sunt conservatoare în obiectivele și implementarea lor, nu au nevoie de o astfel de optimizare.

Greșeli tipice în implementarea Agile și dezavantajele abordării

Același factor care este luat în considerare în unele cazuri punct forte abordare, în altele poate duce la probleme. Prin urmare, „flexibilitatea” devine adesea motivul pentru focalizarea neclară. În lipsa unei baze metodologice, are loc o pierdere a ghidurilor și înlocuirea primarului cu secundar. Pentru a preveni astfel de „distorsiuni”, aceștia folosesc metodologii gata făcute sau propriile lor dezvoltări care reglementează mai strict conținutul și succesiunea operațiunilor în timpul implementării proiectului. Cu toate acestea, în acest caz, erorile sunt posibile în Agile-management.

Erorile comune de implementare includ următoarele:

În ciuda tuturor dificultăților de implementare a unei abordări flexibile, în general, este mai eficientă decât producția tradițională „lentă” atunci când vine vorba de crearea rapidă a unui nou produs orientat către client. În timp ce producția tradițională se blochează în întârzieri birocratice, abordarea Agile oferă o mișcare naturală imediat după lansarea proiectului.

Este greu să găsești o persoană care să nu dorească să fie tratată cu respect. Dar trebuie să existe un motiv pentru această stare de lucruri. De exemplu, atunci când o persoană este un specialist foarte recunoscut în domeniul dezvoltării software. Și pentru asta trebuie să studiezi. Și în cadrul acestui articol, vom lua în considerare ce este Agile, care sunt beneficiile acestuia și cum să înțelegem această tehnologie.

Informații generale

În primul rând, să ne ocupăm de problemele tehnice. Ce este Agile? Traducerea (literală) a acestui cuvânt din Limba engleză- „viu, mobil”, „flexibil” este menționat puțin mai rar. Și apropo, aceasta este o abreviere. Numele complet al acestei abordări este Agil dezvoltare software. Dar, din moment ce era prea lung, s-a hotărât să se scurteze. Și acum ei spun doar Agile. Traducerea ca „flexibil” este folosită pentru că corespunde cel mai bine situației reale.

Ce este inclus aici?

Să continuăm să ne uităm la ce este Agile. Aici aș dori să mă concentrez pe faptul că aceasta este o abordare flexibilă, care se bazează pe multe XP-uri diferite, Kanban, Lean). Pentru a înțelege mai bine subiectul, să facem paralele. Să spunem că tehnologiile Agile sunt procesul de naștere a Universului. Produsul final este însăși lumea existentă. Iar marea explozie este cea mai dureroasă problemă cu care trebuie să te confrunți - schimbarea listei de cerințe pentru un produs. De obicei, procesele de creare implică utilizarea unui model de cascadă. În acest caz, totul se întâmplă secvenţial și în etape. Această abordare poate fi exprimată pe scurt: văd un scop - merg spre el. Și dacă cerințele pentru rezultatul final se schimbă, atunci uneori trebuie să refaci aproape totul din nou. Ceea ce face această situație și mai dificilă este încercarea de a pretinde că totul este normal și că trebuie să mergem înainte.

Și acum managementul este conceput pentru a combate toate acestea datorită flexibilității sale. Acest amestec minimizează diverse riscuri prin utilizarea unor seturi de principii. Toate acestea sunt reflectate în Manifestul Agile, lansat în 2001. Pe scurt, sună așa:

  1. Principalul lucru sunt oamenii, nu lucrurile.
  2. Colaborați în loc să citiți contractul.
  3. Documentația nu trebuie să interfereze cu munca dvs.
  4. Schimbați-vă cât mai repede posibil.

Poate părea prea vag și nu precis, dar să fim mai specifici.

Proiectarea procesului

Având în vedere ce este Agile, să ne întoarcem la una dintre cele mai populare metodologii, cunoscută sub numele de Scrum. Ce oferă ea? Pentru a începe aveți nevoie de:

  1. Selectați proprietarul produsului. O persoană este potrivită pentru acest rol, ceea ce vede, ce scop trebuie atins și ce se va întâmpla în cele din urmă.
  2. Decideți o echipă. Acest lucru necesită un grup de trei până la zece oameni care au abilitățile pentru a obține rezultate.
  3. Alegeți un specialist responsabil. Aceasta este persoana care va monitoriza dezvoltarea proiectului și va ajuta echipa să depășească dificultățile.
  4. Faceți față dificultăților. Toate cerințele existente ale produselor trebuie colectate într-un singur loc și prioritizate. Proprietarul produsului ar trebui să colecteze toate dorințele sale aici. Apoi echipa le evaluează și își dă seama dacă poate fi implementat și cât timp va dura.
  5. Întregul domeniu de activitate ar trebui împărțit în perioade de timp, de o săptămână sau două, în care echipa va efectua anumite seturi sarcini.
  6. Întâlnirile ar trebui să aibă loc zilnic, nu mai mult de cincisprezece minute. Pe ordinea de zi ar trebui să se discute ce s-a făcut ieri, care sunt planurile pentru astăzi și obstacolele care vă împiedică să atingeți înălțimi.
  7. Faceți recenzii la sfârșitul unei săptămâni (două), timp în care echipa vorbește despre ceea ce s-a făcut. În acest caz, este necesar să se demonstreze funcționalitatea părților produsului.
  8. După fiecare perioadă de timp, problemele trebuie discutate și căutate soluții. Mai mult, toate evoluțiile trebuie implementate imediat.

Cum să recunoști Agile?

Metodologia de management, indiferent de direcția aleasă, are întotdeauna următoarele caracteristici:

  1. Minimizarea riscurilor. Acest obiectivul principal, care este urmărită de orice abordare agilă.
  2. Dezvoltare iterativă. În acest caz, ne referim la lucrul în cicluri mici.
  3. Cel mai important lucru este oamenii și comunicarea dintre ei.

Să ne imaginăm un râu. Pe de o parte este clientul. Al doilea este echipa. În acest caz, metodologia de dezvoltare agilă are avantaje pentru toată lumea:

  1. Clientul are nevoie de un produs minim funcțional. Cu toate acestea, condițiile se pot schimba în timpul creării sale.
  2. Este util pentru echipa să comunice cu colegii și cu clientul. În acest caz, riscul de a fi înțeles greșit este minimizat, transparența proceselor crește, problemele sunt rezolvate rapid, iar șansele ca să existe o surpriză la crearea unui produs sunt reduse.

Factorul social

Când oamenii vorbesc despre ce este Agile, de obicei vorbesc exclusiv despre aspecte pozitive. Într-adevăr, interacțiunea în cadrul echipei se îmbunătățește. Toți oamenii se concentrează pe o singură idee, nu își creează secrete între ei și își asumă obligații. Drept urmare, echipa lucrează în condiții confortabile și într-un ritm rapid. Această abordare vă permite să aduceți ordine în haos.

De la formarea sa, a fost capabil să găsească recunoaștere în industriile tehnologice. Pe în acest moment utilizat pe scară largă pentru proiectarea de noi produse software. Dar în cadrul practicii generale de afaceri, o astfel de abordare este încă puțin cunoscută. Prin urmare, cei care nu s-au întâlnit înainte cu Agile se feresc de el. De asemenea, trebuie înțeles că ar trebui să fie folosit numai în cazurile în care oamenii se confruntă cu sarcina muncii intelectuale.

Un mic exemplu

Să aruncăm o privire la modul în care funcționează aceste metodologii de dezvoltare software. Să presupunem că îl avem pe Peter, proprietarul produsului. El nu știe detalii tehnice, dar are o viziune asupra imaginii de ansamblu. El știe de ce este nevoie de produs, ce probleme va rezolva și pe cine va satisface. Există și părți interesate. Aceștia pot utiliza produsul, pot sprijini crearea acestuia sau pot fi implicați în alt mod în crearea acestuia. De asemenea, puteți adăuga povești de utilizatori care exprimă dorințele părților interesate. De exemplu: un sistem de rezervare a biletelor pentru autobuzele Moscova-Sankt Petersburg trebuie să aibă o căutare pe zbor. Peter va ajuta părțile interesate. El va prelua controlul asupra implementării ideilor de user story. Există și o echipă de dezvoltare. Aceștia sunt oamenii care vor construi un sistem funcțional.

Deoarece se folosește o metodologie de dezvoltare agilă, poveștile utilizatorilor nu se acumulează până la o lansare majoră, ci sunt lansate imediat după finalizare și cât mai des posibil. Numărul de solicitări procesate este capacitatea echipei pe săptămână. Pentru a evita pierderea impulsului și blocarea în testarea manuală, echipa ar trebui să lucreze la integrarea automată. Ce este? Se scrie un test automat pentru fiecare moment de lucru. Prea multe povești pot duce la grăbire, pierderea motivației și pierderea productivității și calității. Pentru astfel de cazuri, este furnizată metoda „vremea de ieri”. Constă în faptul că trebuie să stabiliți limite stricte ale volumului de muncă și să alegeți cu atenție ce anume va fi implementat. „Kanban” menționat anterior sugerează stabilirea unei limite de sarcini.

Ce să faci cu coada?

Bine, deci echipa a decis că se pot descurca cu patru povești timp de o săptămână. Dar cum să navighezi în tot ceea ce este? Să presupunem că utilizatorii trimit zece povești pe săptămână. Patru sunt procesate. Astfel, coada va crește constant. Există doar unul pentru acest caz metoda eficienta- cuvântul „nu”. Ca proprietar de produs, acest lucru este extrem de important. A spune da nu este dificil. Este mult mai dificil și mai important să decideți ce să nu faceți. Mai mult, este de asemenea necesar să ne asumăm responsabilitatea pentru acest lucru. Prin urmare, ar trebui să decideți la ce să acordați atenție acum și la ce ar trebui amânat. Pentru a face acest lucru corect, proprietarul produsului trebuie să înțeleagă valoarea și scopul fiecărei povești.

Luam decizii

Unele dintre povești sunt extrem de necesare. Altele sunt pur și simplu un bonus frumos. Unele povești vor dura câteva ore pentru a se dezvolta. Alții vor dura luni pentru a crea. Mulți oameni desenează adesea o corelație între dimensiunea unei povești și valoarea ei. Dar acest lucru nu este întotdeauna corect. Mai mult nu înseamnă mai bine. Peter este ajutat să ia în considerare corect prioritățile de complexitatea și valoarea sarcinii îndeplinite. Cum se cuantifică aceste caracteristici? În nici un caz. Este un adevărat joc de ghicituri. Și pentru a fi mai eficient, este necesar să se implice destul de multă lume. Aceasta este echipa de dezvoltare, care va informa despre domeniul de activitate și părțile interesate. Dar trebuie înțeles că toate datele obținute în acest fel sunt presupuneri grosiere. Nu există numere exacte aici. Inițial vor fi rateuri. Dar pe măsură ce câștigi experiență, numărul și amploarea lor vor scădea.

Riscuri posibile

Pentru a evita problemele, trebuie să oferiți răspunsuri sincere la o serie de întrebări. Acest:

  1. Facem lucrurile corect? Acesta este un risc de afaceri.
  2. Putem implementa ceea ce este necesar?
  3. Va funcționa proiectul pe această platformă? Acesta este un risc tehnic.
  4. Vom avea suficienți bani și îi vom face la timp? Acestea sunt riscurile legate de timpul și costul implementării.

În acest caz, sunt necesare cunoștințe. Ele pot fi privite ca fiind opusul riscurilor. Când este detectat un nivel semnificativ de incertitudine, dobândim cunoștințe - de exemplu, creăm prototipuri de interfață sau experimente tehnice. Și având-le deja, luăm decizii în ce direcție ar trebui să ne îndreptăm.

Cum să înveți?

Industria IT se dezvoltă extrem de rapid, iar pentru a nu pierde până la urmă este necesar să înveți constant, să îmbunătățim abilitățile și eficiența muncii. Prin urmare, problemele de instruire și implementare sunt mai relevante ca niciodată. De unde să încep? Cele mai multe cea mai buna varianta- aceasta este o cooperare cu o companie care folosește deja Agile. Instruirea în acest caz va fi efectuată de oameni care știu de la sine ce este dezvoltarea agilă. Dar acest lucru, din păcate, nu este întotdeauna posibil. Cel mai adesea, este implicat un specialist terță parte care știe ce este Agile. Implementarea acestei abordări se realizează sub supravegherea sa. Adevărat, serviciile unui astfel de specialist costă bani. Dar dacă ai o persoană cu adevărat informată, atunci toate cheltuielile tale se vor achita considerabil. La urma urmei, în lumea modernă Eficiența angajaților joacă un rol important.

Ce ne rezervă viitorul?

Metodologiile de dezvoltare software sunt în continuă evoluție. Ei caută noi modalități și oportunități de îmbunătățire a eficienței activităților și muncii. Este destul de problematic să spunem ce ne așteaptă în viitor. Este probabil ca sistemul de dezvoltare flexibil să fie integrat cu instrumente de automatizare procesele de productie. De exemplu, va fi posibil să se rezolve probleme chiar și atunci când se află la o distanță de locația companiei. În multe privințe, viitorul este determinat de nou tehnologia de informație. La urma urmei, atunci când apar, trebuie să înveți noi metode de lucru cu ei. Și în acest caz, dezvoltarea are loc, închisă într-un ciclu.

În concluzie

Acesta este sfârșitul excursiei în cele flexibile. Dar trebuie amintit că teoria este una, iar practica este cu totul alta. Noile tehnologii informaționale care apar în mod constant reprezintă provocări pentru marea comunitate a dezvoltatorilor. Cum să faci activitățile unei echipe mai eficiente? Fiecare găsește singur răspunsul la această întrebare. Informațiile prezentate aici pot fi folosite pentru a formula scheletul. Dar, în practică, va trebui să lucrați cu modelul existent și să aduceți starea de fapt la o stare de conformitate cu provocările existente. Atunci echipa își va putea atinge obiectivele în mod eficient.

Vă spunem care este metodologia de bază, dezvăluim conceptele de bază, explicăm cum este structurată o echipă agilă și cum este evaluată eficiența acesteia.

Agile este o întreagă familie de metodologii management flexibil proiecte. Este interesant că însuși conceptul de management aici se dovedește a nu fi în întregime corect. Ar fi mai corect să folosiți formula „Agile este o modalitate de interacțiune în echipă care vă permite să creați împreună produse.” Cu toate acestea, suntem prea obișnuiți cu puterea conexiunilor verticale, ierarhice, motiv pentru care utilizarea cuvântului „management” a devenit și aici stabilă.

Întrebări incomode

  • Cum să vă asigurați că o întârziere în activitatea unui departament nu oprește restul?
  • Cum să vă asigurați că dezvoltarea unui plan de proiect nu durează până la 30% din timpul întregii sale implementări?
  • Cum, în cele din urmă, ne putem asigura că aceste planuri sunt urmate?

Managerii de la toate nivelurile, de la manageri de nivel inferior la directori corporativi și oficiali guvernamentali, se confruntă cu această problemă de zeci de ani. Dar atâta timp cât singura modalitate cunoscută de creare mai mult sau mai puțin controlată de produse și de dezvoltare a proiectelor a rămas pas cu pas, una după alta, nu se putea face nimic cu aceste provocări.

Pentru a trece la un nivel calitativ nou munca de proiect, era necesară o schimbare fundamentală de paradigmă.

S-a dovedit că pur și simplu nu era nevoie să cauți răspunsuri la majoritatea acestor întrebări dureroase. Ele trebuie eliminate, iar conceptele care le-au dat naștere, dacă este posibil, desființate. Așadar, în locul dezvoltării cascadei pas cu pas, au apărut metodologii flexibile.

Fă-o imediat!

Principala măsură a eficacității adoptată în metodologia agile este produsul. În timp ce alții doar pregătesc documentația, echipele agile se străduiesc să prezinte un prototip funcțional. Aceasta este ca și celebra formulă motivantă „mai bine făcut decât perfect”. Implementați prima funcție și începeți să o testați, creând-o pe următoarea și așa mai departe iar și iar - aceasta este regula principală.

Etapa de dezvoltare în Agile, acest lucru „din când în când”, se numește iterație. Iterațiile au aceeași durată pe tot parcursul proiectului și au o medie de două săptămâni. Într-o singură iterație, se realizează o sarcină specifică, a cărei principală proprietate este că soluția sa ar trebui să actualizeze produsul la noua versiune sau să-i sporească eficacitatea. Pe această bază sunt selectate astfel de sarcini.

Cum oferă o abordare iterativă flexibilitate? Datorită faptului că procesele individuale pot rula în paralel și independent unele de altele. Da, trebuie să recunoaștem că acest lucru poate crește timpul final de dezvoltare de la o idee la un produs complet finit. Dar adevărul este că un produs funcțional, funcțional, care este deja capabil să întâlnească concurenții și să mulțumească utilizatorii, este creat în Agile mult mai devreme, iar natura ciclică a îmbunătățirilor ne permite să realizăm o dezvoltare mult mai bună a unor astfel de funcții și capacități care ar nu au fost atinse în timpul lucrărilor planificate niciodată.

Organizare orizontală

O echipă Agile este construită pe principiile auto-organizării și egalității relative a tuturor participanților. Chiar și persoana pe care mulți o imaginează ca șef al proiectului, proprietarul produsului, este de fapt doar o personificare a cerințelor pentru produs. El joacă rolul unui purtător de cunoștințe despre ceea ce se așteaptă să fie rezultatul final, dar nu este nicidecum un manager în sensul standard. Deoarece obiceiul ierarhiei este greu de eradicat, în multe echipe proprietarul produsului, din păcate, trebuie să preia funcții de supraveghere. Dar idealul dezvoltării agile este responsabilitatea colectivă membrii echipei unul în fața celuilalt.

Principiile pentru formarea echipelor agile variază în funcție de proiectul specific. De exemplu, în serviciul de muzică Spotify sunt construite astfel:

O altă valoare importantă a echipelor agile este partajarea cunoștințelor. Un membru al echipei nu ar trebui să fie limitat la propriul său domeniu îngust, ci ar trebui să lupte pentru interdisciplinaritate. Acest lucru nu înseamnă că un programator trebuie să fie și un agent de vânzări, iar un designer trebuie să fie un marketer.

Dar au cunoștințe de bază despre specializări aferente în dezvoltarea agilă este necesar.

Inițial, sa presupus că acest lucru ar crește pur și simplu eficiența muncii și nivelul de înțelegere reciprocă în echipă, dar astăzi, odată cu dezvoltarea neuroștiinței, a devenit clar că această abordare asigură și menținerea creierului în formă bună și crearea dinamică de noi conexiuni neuronale. Această polenizare încrucișată a cunoștințelor în Agile se numește formă de T. Ilustrația de mai jos va explica de ce acest lucru este atât de mai bun decât orice cuvânt.

Cum se implementează Agile?

Trecerea de la dezvoltarea în cascadă, încă comună în multe organizații, la metode agile de lucru pe proiecte poate fi destul de dureroasă.

În primul rând, trebuie să aboliți ierarhia și, în același timp, să vă asigurați că toți participanții la procese pot împărți în mod egal responsabilitatea pentru rezultat.

În al doilea rând, Trecerea la dezvoltarea iterativă vă va forța să vă concentrați pe asigurarea faptului că fiecare etapă este garantată să aducă ceva nou produsului. Acest lucru nu este ușor, inerția dezvoltării planificate vă va bântui în primele câteva luni.