În managementul 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 software la începutul anilor 2000, 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 au fost solicitate de 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. La scară largă de producție, transformarea Agilă poate presupune o reelaborare a activităților de producție în ansamblu, dacă produsul devine rezultatul unui răspuns viu la nevoile actuale ale clienților. Deci, dacă fabrica a produs bazine din plastic și feedback-ul de la client demonstrează nevoia de găleți, atunci adaptarea rapidă cu ajustarea paralelă a nuanțelor (forma mânerului, dimensiunea, 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 caracteristici distinctive ale acestei abordări sunt prezente peste tot:

1. Consumatorul și gradul de implicare a acestuia în crearea rezultatului sunt esențiale pentru personalizarea produsului.
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 „flexibilă” a devenit baza pentru o serie de practici metodologice care diferă unele de altele, dar includ ideile Agile: Scrum, Kanban, Lean, Crystal etc. Metodologia Scrum, de exemplu, este aproape întotdeauna luată în considerare în împreună cu Agile ca sistem unificat de management al proiectelor pentru dezvoltarea de software.

Metoda Scrum demonstrează modul în care o „abordare agilă” poate fi aplicată în practică în operațiuni specifice. Deci, 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. Angajamentele pentru etapa următoare, luate de o echipă cu tip de management Agile, sunt scrise pe tablă (așa-numita 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 considerat un punct forte al abordării în unele cazuri poate duce la probleme în altele. 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ă este blocată de întârzieri birocratice, abordarea Agile oferă o mișcare naturală imediat după lansarea proiectului.

18 octombrie 2017

Dacă te uiți la o companie rusă adevărată de peste 30 de ani și cu peste o mie de angajați și spui cuvântul Agile, reacția va fi cel puțin precaută. Oamenii de acolo au auzit deja povești asemănătoare cu „Cum să-i spui bunicii tale” sau „Cum să-ți spui bunicului tău” și au urmărit toate discursurile lui Gref, au primit o duzină de propuneri de introducere a flexibilității într-o săptămână, unii dintre angajați chiar au lucrat cu Scrum pentru un an, dar rămâne o întrebare:

"Ce ar trebui să facem cu asta? Avem doar un site web de la programare?"

Drept urmare, pentru aproximativ 100% dintre companii, Agile arată ca un șarlamăt.

Dar iată un paradox - în lume, 77% dintre companiile* care folosesc Agile în proiecte nu sunt deloc implicate în dezvoltarea de software.

*Din un studiu anual amplu al companiilor din VersionOne

În loc de o definiție. Ce să spun despre Agile atunci când s-au adunat diferiți oameni din diferite departamente

Agile nu este o metodă de dezvoltare software. Definițiile Wikipedia sunt greu de înțeles dacă nu sunteți dezvoltator.
Acestea sunt principiile de organizare a activităților de proiect și sunt aplicabile în orice domeniu.În practică, cea mai sensibilă diferență pentru oameni este îndepărtarea de la ierarhie și dispariția unui centru pentru generarea sarcinilor descrise cu precizie. Aceasta este munca în echipă cu roluri, responsabilitate pentru rezultatul general și o structură plată a interacțiunilor.

Echipa din jocul "Ce? Unde? Când?" există conform principiilor Agile. Interacțiunile joacă un rol cheie. Căpitanul joacă rolul de client al produsului (răspunsul corect), 2-3 savanți sortează șiruri de informații, cineva ține evidența timpului, există o persoană care analizează, pune întrebări și încurajează comunicarea, oricine poate vorbi și duce la un rezultat sau eșuează totul, dincolo de jocuri au un debriefing (retrospectiv).

Contragreutatea pentru Agile este o metodă de transport (în cascadă) cu o ierarhie strictă și sarcini precise stabilite cât mai aproape de SMART. Conform acestor principii din „Ce? Unde? Când?” căpitanul ar trebui să dea sarcini precise - cui să se gândească în ce direcție și să încerce să le pună cap la cap ca răspuns. Fiecare participant ar trebui să mențină decorul și să vorbească atunci când îi vine rândul. În caz de eșec, cineva ar trebui să fie demotivat sau concediat, iar căpitanul ar lua această decizie.

Motivul principal pentru apariția și dezvoltarea Agile este că tot mai multe proiecte nu au o înțelegere de 100% a ceea ce ar trebui să fie până la urmă. Este pur și simplu imposibil să descrii sarcini exacte. Și au decis că interacțiunile libere sunt mai importante decât instrucțiunile, iar pregătirea pentru schimbare este mai importantă decât planurile.

Metodologiile agile sunt un răspuns la incertitudine; nu se știe complet ce trebuie făcut și care ar trebui să fie rezultatul. S-ar părea, ce este de neînțeles în dezvoltarea, de exemplu, a unui site web sau în construirea unei case sau în pregătirea unui hamburger la McDonald's? Aceste proiecte sunt în curs de desfășurare, unde este incertitudinea?

Dar. Chiar dacă sunteți un studio web și acesta este al miilea dvs. site, pentru client este prima dată. Iar dorințele lui vor rămâne incerte până la sfârșit. Multe studiouri fac 3-4 versiuni ale paginii principale și alocă o săptămână pentru îmbunătățiri neprevăzute. Toți cei pe care îi cunosc lucrează în iterații, urmate de o demonstrație și discuție. Comunicarea cu clientul este mai importantă decât contractul semnat.

În construcția unei case există un plan de proiect, calculul materialelor și costurile cu forța de muncă. Dar, dintr-un motiv oarecare, termenele se prelungesc mereu. Se întâmplă ca fundația să plutească, sau șapa să se usuce, ceva începe să crape, sau cheresteaua este umedă, sau cărămida este prea poroasă, sau cimentul a fost adus de o marcă greșită sau clientul s-a răzgândit și a decis că acum va fi o baie. Maistrul este o orchestră umană, el decide tot ce apare, abatendu-se constant de la plan de dragul rezultatului. O casă normală este mult mai importantă decât o descriere.

Bine, nu există nicio incertitudine cu privire la prepararea unui hamburger McDonald's. Procesul a fost dezvoltat pe parcursul a 70 de ani și reprodus în 125 de țări. Da, aceasta este o bandă transportoare unde este mai bine să nu interferați cu flexibilitatea. Agile nu se aplică proceselor care au fost bine stabilite de-a lungul anilor. Adevărat, deschiderea unui nou restaurant sub o franciză foarte precisă este întotdeauna un proiect unic. Unde va exista o abordare iterativă, reducerea iterațiilor, distribuirea rolurilor, interacțiune deschisă, vizualizarea proiectului pe tabloul Agile, retrospectivă, întâlniri zilnice de planificare.

Valorile cheie totale ale Agile (manifest):

• interacțiune liberă într-o echipă
• eficacitatea proiectului (produs cool)
• comunicarea de parteneriat cu clientul
• pregătirea pentru schimbare

Ce sunt echipele cu roluri?

Într-o echipă tipică există două roluri: Șef și Subordonat, unul este inteligent și celălalt este un prost. În Agile, trei sunt esențial importante: Clientul produsului, Metodologul, Membrul echipei.

În formă simplificată:
Client- spune de ce produs este nevoie, de ce este necesar, organizează discuții în jurul cererilor din piață, ia decizii cu privire la priorități.
metodist- se asigura ca clientul sa nu se transforme in sef. Ei bine, și implementarea altor practici, de exemplu, astfel încât toate sarcinile să fie evaluate sau ca estimările sarcinilor să nu depășească 80% din timpul disponibil, dacă există un astfel de acord.
Echipă- evaluează, distribuie și implementează sarcini. Demonstrează întotdeauna o versiune a produsului, nu piese individuale finalizate.

Pentru a spune foarte simplu, în Agile este necesară o persoană care se asigură că echipa primește cantitatea maximă de informații despre produsul solicitat în toate detaliile din diferite părți și ia parte activ la discuția despre cum să-l implementeze. Nu am primit sarcina ca o directivă de mai sus, ci o descriere și înțelegere a ceea ce ar trebui făcut pentru utilizator atunci când produsul este dezvoltat.

Din exterior, ceea ce deosebește o echipă agilă de una tradițională este prezența sau absența așa-numitei colaborări narative. Dacă există o discuție despre întrebarea „Cum se implementează produsul?” la toate nivelurile, ceea ce înseamnă că echipa este flexibilă. Dacă caută cine este de vină pentru că nu a finalizat o listă de sarcini specifice, atunci totul este ca de obicei.

Întrebarea principală: „Cum să gestionezi resursele când totul este atât de flexibil?”

Toate aceste povești despre echipe responsabile și istoria apariției metodei sunt percepute ca un gunoi complet dacă nu există răspuns la întrebări:
„Cum putem gestiona mai precis resursele?”, „Cum putem înțelege mai devreme că nu au fost suficiente resurse pentru a finaliza un proiect?”, „Întotdeauna am stabilit și distribuit sarcinile între performeri și am putut prezice rezultatul, dar acum ce facem? ” Pentru a vorbi despre Agile, puteți răspunde doar la această întrebare.

Trebuie remarcat faptul că, în general, tot Agile este conceput special pentru a rezolva problema resurselor „Cum să gestionați eficient resursele într-un proiect cu imprevizibilitate.” Metodologia nu s-ar fi născut dacă scopul principal ar fi confortul și libertatea oameni din echipa.

Există mai multe principii și metode importante care vizează în mod clar prognozarea resurselor:

1. Vizibilitatea resurselor necesare. Plăcile Agile sunt indisolubil legate de metodologie. Acesta este momentul în care sarcinile sunt distribuite în coloane, iar coloanele determină stadiul sarcinilor conținute în ele. Acesta este cel mai vizual instrument pentru vizualizarea stării proiectului. În mod ideal, ar trebui să fie clar pentru orice străin în ce stadiu se află proiectul și cât timp mai rămâne până la final. Dacă devine brusc evident pentru toată lumea că nu există suficiente resurse sau prioritățile trebuie schimbate, acest lucru se va întâmpla de la sine.
Problemele de predictibilitate a rezultatelor și managementul priorităților sunt rezolvate tocmai prin vizibilitate.

2. Priorități și restanțe. La planificare, se ține cont de faptul că nu toate sarcinile pot fi îndeplinite în perioada de timp alocată. Există întotdeauna o listă cu ceea ce trebuie făcut și ce ar fi bine de făcut (acesta este restanța). Prioritățile sunt stabilite de echipă în discuție cu clientul intern al produsului. Dacă se întâmplă să mai rămână timp, sarcinile de gradul doi de importanță sunt rezolvate; dacă nu au timp să închidă chiar și sarcinile marcate Obligatoriu (Critic), echipa este încordată și mai mult.

3. Iterații scurte(sprinturi). Această abordare, ca nimeni alta, permite companiilor să încerce ceva din Agile. Conducerea este de acord cu un rezultat intermediar în câteva săptămâni fără a se implica și a atribui sarcini tuturor. Ar fi imposibil să fii de acord cu un astfel de program de lucru timp de șase luni.
Un sprint (iterație) este o perioadă de timp de câteva săptămâni. Pentru noi, cel mai adesea este de 2 săptămâni. Cel mai important lucru într-un sprint este determinarea ce rezultat intermediar trebuie obținut. Acest rezultat este bun pentru a numi o iterație, de exemplu, „Eliberați panouri cu drepturi” sau „Eliberați site-ul pentru testare”. Dacă munca se desfășoară în segmente de timp, dar fiecare segment nu duce la niciun rezultat specific, atunci aceasta nu mai este o abordare iterativă.

4. Estimarea problemelor la marimile tricourilor. Oamenilor nu le place să dea estimări precise sarcinilor, dar estimarea aproximativă pe o scară mare, medie, mică este normală pentru majoritatea. Mai jos sunt cele mai populare metode din lume pentru estimarea problemelor fără o precizie ridicată. Cu procente bazate pe frecvența de utilizare.

Noi îl folosim pe al treilea, dar ratingurile sunt doar 1h, 2h, 4h, 8h.

Scopul abordării este de a evita încercarea de a surprinde pe cineva care face evaluări inexacte asupra muncii sale. Sunt deja exemplare de la bun început. Accentul este pus pe faptul că în timpul sprintului toată lumea s-ar strădui să marcheze numărul maxim de puncte, care sunt aproximativ legate de timp.

5. Diagrama de ardere(program de ardere)
Un lucru foarte simplu este un grafic cu două linii; primul este cât de mult timp a fost ars și aceasta este întotdeauna o linie dreaptă, al doilea este câte sarcini în ceea ce privește resursele au fost închise și sunt posibile fluctuații aici. De fapt, acesta este un răspuns grafic la întrebarea dacă echipa este pe drumul cel bun sau în întârziere.

Doar abordările generale sunt prezentate aici fără detalii; poate că merită să scrieți un material separat cu detalii despre managementul resurselor. Dar dacă rezumăm aici în două rânduri, se va dovedi:

• cea mai frecventă greșeală este încercarea de a atinge estimările foarte precis, echipa nu mai lucrează la rezultat
• cea mai de succes abordare este de a construi o rezervă de timp și de a planifica 80% din resurse

Insider de la cel mai mare, cel mai vechi și mai faimos studio SEO din Rusia- își rezervă resurse de două ori, prima în timpul discuției cu clientul, a doua în timpul planificării interne.

Top 5 cele mai populare practici Agile care sunt pe înțelesul tuturor

Permiteți-mi să subliniez încă o dată că Agile la nivelul de bază al aplicației este simplu. Nu există tehnici super complexe care să dureze mult timp pentru a învăța. Mai jos, ca exemplu, sunt cele mai populare 5 practici (conform aceluiași sondaj de la VersionOne)

Toate sunt aplicabile proiectelor din orice domeniu și sunt suficient de simple pentru a fi utilizate instantaneu. Toți sunt uniți de ideea comună a unei abordări iterative.

1. Planificare iterativă- sprinturi (90% din echipe folosesc)
Lucrul în serii mici cu rezultate intermediare este o practică bună. Un sprint durează câteva săptămâni. Segmentele prea scurte sau prea lungi sunt dăunătoare. Același interval pentru toate ocaziile nu este, de asemenea, potrivit. Sprintul ar trebui să aibă cel mai precis obiectiv, iar durata este determinată pe baza acestuia.
Cea mai frecventă greșeală este că echipele se obișnuiesc să programeze pur și simplu sarcinile o dată la două săptămâni, iar procesele de stabilire a obiectivelor intermediare și de rezumare la final se pierd. Munca se încadrează în fluxul obișnuit de sarcini cu actualizări o dată pe sprint. Problema trebuie rezolvată de metodolog.

2. Întâlniri zilnice de planificare(88% din echipe folosesc)
Scopul este ca echipa să confirme aceeași direcție de mișcare a tuturor participanților în fiecare zi. Conform descrierii clasice, toată lumea din echipă răspunde la trei întrebări:

• Ce s-a realizat până acum de la sprint?
• Ce este planificat pentru azi?
• Ce probleme au apărut sau ce te oprește?

În practica noastră, echipele se plictisesc rapid de acest lucru și devin o raportare de rutină sau formală. Ce ajută:
Modificați ora întâlnirii de planificare - 6 luni. dimineata, 6 luni Seara.
Schimbați liderul întâlnirii de planificare de fiecare dată; nu ar trebui să existe nicio persoană căreia îi raportează. O opțiune excelentă dacă liderul este extras la sorți. Client de produs, împărtășiți poveștile clienților la începutul întâlnirii de planificare. Discutați subiecte generale și abia apoi treceți la întrebări. Nu permiteți altor persoane decât membrii echipei să participe la întâlnirile de planificare.

3. Retrospective(83% din echipe folosesc)
Întâlnire la sfârșitul iterației. Discuție despre ce a funcționat și ce nu. Cel mai important obiectiv este de a trage concluzii despre cum se poate schimba.
Clientul produsului - despre cum să arate cel mai bine așteptările utilizatorilor, metodologul - despre cum să încurajeze dialogul și să îndeplinească acordurile abordărilor alese, echipa - despre cum să țină cont de noi factori emergenti atunci când se fac evaluări. De regulă, retrospectivele sunt distractive - iterația s-a încheiat, puteți expira și discuta rezultatele. Este o bună practică să bei sau să mănânci ceva în pauzele din acest proces.

4. Spectacole iterative(81% din echipe folosesc)
Aceasta este o demonstrație din partea echipei o dată la câteva iterații a rezultatelor proiectului, de obicei sub forma unui discurs. Ideea principală este să aveți o „sesiune” și este în regulă dacă devine ca un raport către conducere. Principala dificultate este să convingi pe altcineva decât echipa să se adune și chiar să înțelegi sensul a ceea ce se întâmplă. În practica noastră, prinde rădăcini doar cu un leadership foarte puternic.

5. Iterații scurte(71% din echipe folosesc)
Ideea este că ar trebui să încercați în mod constant să scurtați ciclul de obținere a rezultatelor intermediare mici. Dacă nu se face acest lucru, ciclurile vor crește în mod natural sau vor fi constante, indiferent de obiectivele intermediare. Cu cât ciclul este mai scurt, cu atât mai puține erori în timpul planificării iterative. Aceasta este sarcina metodologului; merită să ne amintim acest lucru cel puțin o dată la șase luni.

Cum să înțelegeți dacă un proiect este realizat folosind metodologia Agile sau nu încă?

O diagramă cu câte companii schimbă Agile pentru a se potrivi lor arată astfel:

Flexibilitatea abordării se extinde la abordarea în sine. Acesta este primul lucru pe care trebuie să-l învețe o echipă dacă vrea să devină mai flexibilă. Nu poți fi 100% Agil respectând toate cerințele. Nimeni nu respectă cu strictețe regulile în forma lor pură; în practică, fiecare companie are propriile modificări.

Cele mai populare metode Agile sunt ușor de implementat, produc rezultate și nu vor întoarce compania cu susul în jos. Din acest motiv 98% dintre cei care folosesc ceva din Agile spun că abordările au succes.

Dacă începi, de exemplu, cu întâlnirile de planificare de dimineață, atunci nu se va întâmpla nimic rău în echipă, dar simplul dialog zilnic între oamenii din cadrul proiectului face procesul mai flexibil.

Combinația dintre flexibilitate și rigiditate este întotdeauna individuală și depinde de mulți factori: manager, complexitatea proiectului, dimensiunea echipei, buget etc. Dar dacă cel puțin o abordare a fost implementată în mod semnificativ, atunci această companie funcționează conform metodologiei Agile și nu ar fi greșit să anunțăm acest lucru cu mândrie în cadrul echipei.

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 engleză este „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 de software. Dar, din moment ce era prea lung, s-a decis 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ă, timp în care echipa va îndeplini anumite seturi de 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. Acesta este scopul principal al oricărei abordări agile.
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 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. În prezent, 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 să se înțeleagă că ar trebui folosit doar î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. Nu știe detaliile 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 după 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. În acest caz, există o singură metodă eficientă - cuvântul „nu”. Ca proprietar de produs, acest lucru este extrem de important. A spune da nu este greu. 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.

Noi luăm 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ă. Unde sa încep? Cea mai bună opțiune este cooperarea cu o companie care utilizează deja Agile. Antrenamentul î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 plăti generos. Într-adevăr, în lumea modernă, eficiența angajaților joacă un rol important.

Ce rezerva 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 instrumentele de automatizare a procesului de producție. 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 noile tehnologii informaționale. 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.

In cele din urma

Acesta este sfârșitul excursiei către 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.

În managementul 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 software la începutul anilor 2000, 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 au fost solicitate de 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. La scară largă de producție, transformarea Agilă poate presupune o reelaborare a activităților de producție în ansamblu, dacă produsul devine rezultatul unui răspuns viu la nevoile actuale ale clienților. Deci, dacă fabrica a produs bazine din plastic și feedback-ul de la client demonstrează nevoia de găleți, atunci adaptarea rapidă cu ajustarea paralelă a nuanțelor (forma mânerului, dimensiunea, 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 caracteristici distinctive ale acestei abordări sunt prezente peste tot:

1. Consumatorul și gradul de implicare a acestuia în crearea rezultatului sunt esențiale pentru personalizarea produsului.
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 „flexibilă” a devenit baza pentru o serie de practici metodologice care diferă unele de altele, dar includ ideile Agile: Scrum, Kanban, Lean, Crystal etc. Metodologia Scrum, de exemplu, este aproape întotdeauna luată în considerare în împreună cu Agile ca sistem unificat de management al proiectelor pentru dezvoltarea de software.

Metoda Scrum demonstrează modul în care o „abordare agilă” poate fi aplicată în practică în operațiuni specifice. Deci, 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. Angajamentele pentru etapa următoare, luate de o echipă cu tip de management Agile, sunt scrise pe tablă (așa-numita 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 considerat un punct forte al abordării în unele cazuri poate duce la probleme în altele. 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ă este blocată de întârzieri birocratice, abordarea Agile oferă o mișcare naturală imediat după lansarea proiectului.

Dezvoltarea software este o muncă care necesită luarea deciziilor corecte în timp util. CTO, arhitecții, liderii de echipă și dezvoltatorii înșiși fac în mod regulat alegeri în favoarea anumitor instrumente, platforme și cadre.

Dar toate deciziile luate trebuie să fie „sincronizate” cumva. Unul dintre rezidenții Hacker News a remarcat că a trebuit să urmărească cum cinci sute de dezvoltatori dintr-o companie mare li s-a permis să ia anumite decizii pe cont propriu, „izolați” de echipă. Potrivit lui, a fost haos. Și deși echipa a început să lucreze mai repede, nu a mers nicăieri pentru că mai târziu au apărut probleme în timpul etapelor de suport software.

Pentru a evita astfel de situații, se folosește o familie de procese de dezvoltare agile. Implementarea lor permite managementului companiei să crească interesul și motivația angajaților, precum și să accelereze livrarea produsului către client. Recent, acest subiect a devenit din ce în ce mai popular, deoarece șefii celor mai mari corporații atrag atenția publicului asupra unor metodologii Agile.

De aceea am decis să începem o serie de postări despre metodologiile „agile” pentru a arunca o altă privire asupra caracteristicilor acestora, pentru a compara opțiunile și pentru a vă ajuta companiile să optimizeze procesele. Astăzi vorbim despre Scrum, Kanban și Extreme Programming.

Scrum

Scrum este un cadru de dezvoltare software agil care este considerat metodologia „implicit”. Pentru mulți, este sinonim cu Agile. Conform statisticilor din 2016 furnizate de VersionOne, Scrum este folosit de 58% dintre companiile agile. Mai mult, este susținut de multe platforme SaaS. De exemplu, soluția ServiceNow, din care face parte instrumentul Agile Development.

Scrum a câștigat o popularitate imensă de-a lungul existenței sale și este folosit de echipele de dezvoltare chiar și în companiile mari. Cu toate acestea, în acest timp comunitatea a identificat și anumite neajunsuri.

De exemplu, printre aceștia observă o concentrare excesivă pe notarea punctelor. La planificare, echipa selectează povești pe care le poate finaliza până la sfârșitul sprintului, în funcție de viteza etapei precedente. Scopul principal al acestor ochelari este de a face planificarea mai fiabilă și de a oferi o perspectivă clară.

Cu toate acestea, există o problemă aici: deoarece munca dezvoltatorilor este evaluată în puncte, aceștia vor încerca să câștige mai multe dintre ele și să își optimizeze activitățile în consecință. Ceea ce nu îmbunătățește baza de cod nu o face mai simplă.

O altă problemă sunt întâlnirile lungi. Mai mult, întâlnirile se țin sincron cu toți participanții la dezvoltare, ceea ce devine o problemă pentru specialiștii care lucrează de la distanță. Oamenii trebuie să includă în programul lor întâlniri de oră lungi pentru a face schimb de informații care ar putea fi transmise în alte moduri.

În ceea ce privește poveștile care nu se schimbă în timpul unui sprint, acest lucru duce și la probleme la scară largă. Programatorii nu au capacitatea de a redistribui munca atunci când sunt descoperite noi caracteristici. Scrum nu vă permite să reconstruiți nava în timp ce navighează, așa că trebuie să așteptați până la sfârșitul sesiunii pentru a face modificări.

Programare extremă

Particularitatea Scrum este că acest cadru acordă puțină atenție practicilor de dezvoltare. Prin urmare, unele companii agile (aproximativ 10%) îl combină cu Extreme Programming (XP).

Programarea extremă a câștigat atenția la sfârșitul anilor 90. Conceptul a apărut în comunitatea Smalltalk, iar autorii săi sunt considerați a fi dezvoltatorii Kent Beck și Ward Cunningham, care și-au dorit să creeze noi practici în dezvoltarea de software făcută pentru oameni.

Primul proiect creat folosind metodologia Extreme Programming a fost sistemul de control al plăților Chrysler Comprehensive Compensation (C3) la mijlocul anilor nouăzeci. Termenul de „programare extremă” a apărut în 1997.

Conceptul se bazează pe douăsprezece tehnici:

Kanban

Scrum continuă să fie o metodologie eficientă care este populară. Mai ales în combinație cu programarea extremă. Împreună, rata lor de utilizare în rândul echipelor Agile ajunge la 68%.

Cu toate acestea, astăzi multe echipe iau în considerare alte opțiuni și acordă atenție altor metodologii. Unul dintre ei a fost Kanban. ConvertKit CTO Grant Ammons spune că companiile adoptă mai întâi Scrum, care le învață disciplinele necesare pentru dezvoltarea de software, apoi caută o alternativă mai convenabilă și apelează la Kanban.

Kanban este o tehnică de gestionare a dezvoltării în care procesul de dezvoltare este văzut ca o conductă de solicitări de caracteristici care oferă software îmbunătățit.

Kanban a apărut ca parte a sistemului de producție just-in-time al Toyota, astfel încât metodologia elimină acumularea inutilă de sarcini. De exemplu, dacă testerii testează cinci caracteristici într-o săptămână, iar dezvoltatorii și analiștii implementează zece, atunci „debitul total al conductei” este limitat la cinci caracteristici. Acest lucru este pentru a preveni echipa de control al calității să adune de lucru, altfel ar putea începe să taie colțuri și să lase accidental un produs de calitate scăzută pe piață.

În acest caz, este posibilă și redistribuirea resurselor: atunci când programatorii și analiștii și-au îndeplinit cota, ei pot ajuta la testarea și scrierea testelor automate. În viitor, acest lucru permite creșterea debitului transportorului.

Și Kanban identifică cu ușurință astfel de blocaje. În cea mai simplă implementare a sa, este o tablă mare cu coloane căptușite în care sunt plasate carduri cu autocolante. Barele reprezintă etape ale procesului de dezvoltare, iar autocolantele reprezintă sarcini de lucru. Numerele din partea de sus a fiecărei coloane arată câte cărți pot fi „acumulate” în ea.

Cu toate acestea, după cum sa menționat în comunitatea HN, această abordare are și anumite dezavantaje. În Scrum, sprinturile scurte au un efect pozitiv asupra motivației dezvoltatorilor. Programatorii știu că munca la produs se va încheia atunci când întreaga listă de cerințe pentru 30 de zile este finalizată. În cazul Kanban, este un flux constant și fără sfârșit de sarcini. Cu toate acestea, există o cale de ieșire - o scurtă discuție despre listele de sarcini timp de o săptămână (sau două).

De asemenea, datorită specificității sale, kanban nu este potrivit pentru planificarea pe termen lung și este incomod pentru echipele mari de dezvoltare (mai mult de cinci persoane).

În cele din urmă, observăm că utilizarea metodologiilor Agile impune solicitări serioase asupra experienței membrilor echipei și a capacității acestora de a interacționa eficient între ei. Mai mult, fiecare metodologie mai mult sau mai puțin comună are propriile sale puncte tari și puncte slabe, precum și domenii de aplicare. Din acest motiv, apar cadre noi, iar cele „vechi” sunt îmbunătățite.