Etapele dezvoltării agile. Ce este Agile? La început, echipa explorează realitatea dezvoltării aplicațiilor și domeniul de aplicare. Lucrările ulterioare sunt împărțite în trei cicluri interconectate

Agil („agil”) este un cuvânt care s-a auzit din fiecare fier de călcat în ultima vreme. Dar ce este Agile și, cel mai important, de ce este nevoie de acest Agile?

Dacă este deschis dicţionar, de exemplu, Oxford, atunci puteți citi cel puțin două definiții acolo:

1. Capabil să se deplaseze rapid și ușor.
2. Capabil să gândească și să înțeleagă rapid.

Adică, pentru a fi agil, trebuie să te poți mișca rapid și ușor și să gândești rapid. Par a fi calități destul de utile, mai ales în afaceri. A gândi rapid și a reacționa rapid este exact ceea ce a prescris medicul pentru timpul nostru, altfel pur și simplu nu vei supraviețui: concurenții te vor devora. Sunt din ce în ce mai puține industrii în lume în care acești concurenți nu există. Mai mult, viteza de copiere face practic imposibilă aducerea produsului pe piață și să se odihnească pe lauri. Fără capacitatea de a se adapta rapid la schimbare, ceea ce oferă așa-numita „metodologie Agile”, este din ce în ce mai dificil să supraviețuiești.

Nu întâmplător iau expresia „Metodologie Agile” între ghilimele, pentru că o auzi deseori, dar nu este în întregime corectă. Dacă nu intrați în detalii tehnice, atunci Agile nu este o metodologie, ci un nume colectiv pentru diferite metode și abordări ale managementului care:

1. Concentrați echipa pe nevoile și obiectivele clienților.
2. Simplificați structura și procesele organizaționale.
3. Oferă muncă în cicluri scurte.
4. Utilizați în mod activ feedback-ul.
5. Există o creștere a puterilor angajaților.
6. Ele se bazează pe o abordare umanistă.
7. Ele nu sunt o stare finală, ci mai degrabă un mod de a gândi și de a trăi.

Nimic supranatural, nu? Să mergem punct cu punct și să vedem de ce cele de mai sus sunt importante pentru a fi rapid și agil și cum Agile atinge aceste obiective.

Concentrați-vă pe nevoile și obiectivele clienților

Cred că nu merită să explic de ce cea mai de succes afacere este cea care satisface nevoile clientului său mai bine decât concurenții. Este mai interesant de înțeles ce instrumente din Agile ajută la realizarea acestui lucru.

Cel mai important, concentrarea asupra clientului cu abordarea Agile apare nu numai în capul proprietarului afacerii (există deja acolo), ci în toți cei care lucrează la crearea unui produs sau serviciu. Fiecare participant la proces trebuie să înțeleagă cine este clientul, ce își dorește, ce probleme rezolvăm cu produsul nostru, ce iubește, de ce se teme și așa mai departe. O astfel de concentrare globală vă permite să creați soluții de ordin de mărime mai bune. Am întâlnit în mod repetat o situație în care oamenii care anterior erau responsabili pentru o mică lucrare, după ce au înțeles obiectivele clientului, au început să dea idei minunate, iar oamenii care sunt responsabili cu dezvoltarea produsului au luat note cu surprindere. Sau - cum astfel de idei sunt perfecționate în sesiunile de dezvoltare a produselor de grup oameni diferitiși se completează reciproc, de la doar bun la excelent. Și, desigur, cum sunt apoi implementate.

„Instrumente de lucru” în acest caz sunt sesiuni (întâlniri) scurte, dar intense ale tuturor participanților la lucru sau ale majorității cheie, în care sunt generate și testate diverse idei. Aceleași întâlniri servesc la nivel de înțelegere și concentrare: toți participanții la întâlnirea de ieșire înțeleg ce fac, de ce și de ce este important pentru client. Iar formatul democratic al atelierului, spre deosebire de prezentările plictisitoare, garantează o mai mare incluziune și motivație a tuturor participanților.

Exemple de astfel de instrumente sunt Lean Canvas, Impact Mapping, User Story Mapping și alte metode Agile pentru descrierea ipotezelor și proceselor.

Una dintre pietrele de temelie ale Agile este simplitatea extremă. Iar structura organizatorică a organizației și procesele prin care lucrează oamenii și regulile ar trebui să fie cât mai simple posibil. Acest lucru va permite oamenilor să se concentreze asupra muncii lor, asupra valorii pe care o creează și nu asupra conformării cu reglementările și regulile. Exemple grozave ale acestei abordări pot fi găsite în multe echipe care lucrează pe Scrum, cel mai popular mod de organizare a fluxului de lucru în Agile. De fapt, toate acordurile și regulile unei echipe de 10-11 persoane, sarcinile curente pentru câteva săptămâni, obiectivele, precum și planurile strategice pot încăpea cu ușurință pe 2-3 coli de hârtie A0. Pe o foaie poate exista așa-numitul „sprint backlog”, o listă cu tot ce va face echipa în următoarea iterație. Dacă agățați unul în camera în care lucrați, vă puteți scuti de osteneala de a vă aminti toate acestea. Același lucru este valabil și pentru procese. De exemplu, în Scrum, locul și ora tuturor întâlnirilor sunt fixate în mod rigid. Orice participant știe sigur că, de exemplu, luni la 10-00 este planificată următoarea iterație, iar vineri la 17-30 - o întâlnire pentru a îmbunătăți procesul de lucru.

Și cu cât organizația este mai mare, cu atât beneficiul unei astfel de simplități este mai mare, deoarece complexitatea tinde să crească exponențial, iar Agile este mod bunînvinge această complexitate, sau măcar să-i stăpânească creșterea.

Exemple de simplificare (și aplatizare, dar acesta este un subiect pentru altă discuție) în Agile sunt Scrum, Nexus, LeSS (Large-Scale Scrum, sau Scrum la scară largă), precum și manifestul Agile în sine.

În lumea Agile, nu se obișnuiește să te închizi într-un atelier timp de trei ani pentru a ascuți ceva interesant acolo. Riscul este foarte mare, de a petrece o mare de forță și timp pentru ceva de care nimeni nu are nevoie sau este depășit.

Pentru a evita acest lucru, se utilizează așa-numita abordare iterativă-incrementală, atunci când:

• munca se desfășoară în perioade mici fixe de timp, de exemplu, în una, două sau patru săptămâni,
• și, cel mai important, la sfârșitul fiecărei perioade de timp, nu se creează doar un fel de rezultat intermediar, ci, deși mic, trunchiat, mic, dar versiunea de lucru a produsului, care puteți începe să utilizați.

Ca exemplu cel mai simplu al unui astfel de model de lucru, ne putem imagina standardul programului „calculator” pentru toate computerele, care la început vă permite doar să adăugați două numere, apoi adăugăm scăderea, înmulțirea, împărțirea, numerele transcendentale, funcțiile trigonometrice și asa mai departe, in ordinea frecventei de utilizare. La început, funcționalitatea este mică, dar putem deja să vedem cum arată calculatorul, cât de convenabil este de utilizat și să ne imaginăm cum să-l dezvoltăm în continuare. Și, cel mai important, unii dintre clienți (să zicem, școlari scoala primara) poate începe deja să-l folosească.

Un alt avantaj al acestei abordări, pe lângă intrarea timpurie pe piață și efectuarea modificărilor în stadiile incipiente de lucru, este capacitatea de a măsura progresul mai precis. Nu am făcut doar 15% din muncă, ceea ce este destul de abstract. Am „realizat 15% din funcționalitatea” care deja funcționează.

Toate abordări procesualeîn Agile au cicluri scurte, fie că este vorba de Scrum, Nexus, LeSS, SAFe menționat anterior sau, plus necesitatea de a lucra cu astfel de cicluri este menționată în manifestul Agile în sine.

Utilizarea activă, sistemică a feedback-ului

Acest punct, după părerea mea, este cel mai important pentru orice proces, deoarece vă permite să vă ajustați munca în timp, pe baza experienței, eliminând erorile și pierderile din proces și din produsul creat și adăugând ceva util.

În orice domeniu de activitate umană legat de crearea a ceva nou, vei găsi un similar lucru prin experiment. Rachetă, inginerie aeronautică, farmaceutică, fizică, medicină, construcții, psihologie, economie - orice domeniu de activitate a început cu experimente și prelucrare atentă părere de la ei.

Agile oferă o utilizare sistematică a acestei abordări peste tot: în crearea unui produs (îl lansăm pe piață, sau îl arătăm clientului, sau efectuăm teste și folosim feedback-ul pentru a-l corecta), în procesele de construire (periodic „oprim” lucrul). și să analizeze procesul în sine, pentru a-l îmbunătăți, a scăpa de pierderi și probleme), chiar și în construirea structurii organizației și reglarea relațiilor în echipe.

Din nou, exemplele sunt peste tot: întâlniri retrospective în Scrum, Kanban, Nexus și LeSS, cicluri I&A în SAFe, abordarea Design Thinking pentru crearea de produse etc.

De ce să dai mai multă autoritate când poți da o bucată de hârtie cu instrucțiuni? Există cel puțin trei motive pentru a face acest lucru.

În primul rând, oamenilor implicați în muncă mentală nu le place să se simtă ca niște maimuțe (ei bine, sau roboți), iar prin luarea capacității de a lua decizii de la o persoană, îi luăm munca mentală în sine. Și asta este cu siguranță demotivant.

În al doilea rând, dând mai multă autoritate, dăm mai multă responsabilitate, iar oamenii sunt forțați să învețe să ia singuri decizii și, cel mai important, să poarte responsabilitatea pentru ele. Este lung, greu, dar merită. Lucrarea nu se va opri dacă o echipă auto-organizată întâmpină o problemă necunoscută, necunoscută anterior. Și cine va susține că la locul de muncă, adulții maturi și responsabili sunt mai utili decât copiii mari care nu sunt capabili să gândească singuri?

În al treilea rând, este încă aceeași viteză. Dacă o persoană poate rezolva singură o problemă, în locul lui, fără să întrebe pe nimeni, acest lucru reduce timpul de luare a deciziilor. Nu mai trimiteți întrebarea „în sus” și așteptați un răspuns din partea conducerii. Acest avantaj nu este atât de vizibil dacă ai 3 oameni care lucrează, dar dacă ai 30, sau 300, sau 3000... În organizațiile mari construite pe luarea deciziilor pur ierarhice, paralizia voinței poate fi destul de comună.

Modalitățile populare de construire a muncii în Agile, în special cele bazate pe framework-ul Scrum, implică un sistem de echipe auto-organizate și încurajează conducerea la toate nivelurile.

De ce să tratezi oamenii ca pe oameni? Adică, partea morală a problemei este clară, dar ce beneficii va aduce proprietarului întreprinderii?

Răspunsul este destul de simplu. Dacă nu este nevoie să creați ceea ce vindeți travaliu psihic, ci doar acțiuni mecanice - nu vă puteți deranja. Plătește doar în funcție de munca depusă și atât. Dar de îndată ce creierul lucrătorilor va intra în joc, va trebui să iei în calcul principiile de motivare a muncii mentale. Și spun că posibilitatea de auto-realizare, îmbunătățirea abilităților lor, aducerea pe lume a ceva valoros, independența în decizii și o serie de alți factori sunt importanți pentru oameni. Iar o persoană motivată (a nu se confunda cu o persoană stimulată!) va investi mai mult în muncă, iar rezultatul va fi mai bun și mai rapid. Și, în general, o atmosferă plăcută la locul de muncă se adaugă dorinței de a veni să lucreze acolo - aproape nimeni nu poate contrazice acest lucru.

Și, ce este frumos, dacă sapi în același Scrum, se dovedește că toți factorii cheie pentru motivarea unui lucrător de muncă mentală și/sau creativă sunt deja incluși în el. În fiecare iterație („sprint”), ne stabilim un obiectiv pe care dorim să-l atingem; ni se oferă posibilitatea de a decide cum exact să atingem obiectivul; la final, ne uităm la cât de mult am devenit mai buni (sau mai rău) să lucrăm decât înainte; vedem oameni care sunt interesați de produs și de emoțiile lor în urma cunoașterii acestuia. Este mai ales bine dacă aceste emoții sunt pozitive.

Concluzia este: oameni fericiti funcționează mai bine, iar tehnologiile Agile ajută la stabilirea unui proces în care oamenii se simt mai fericiți. Iar primul punct al manifestului este doar despre asta: oamenii și modul în care comunică sunt mai importante decât orice altceva.

Agile nu este o stare finală, ci un mod de a gândi și de a trăi

Acest punct este despre modul în care Agile este, în general, calea, nu scopul. Nu poți „implementa” Agile și relaxa. Dacă alegeți această cale, veți avea întotdeauna altceva de făcut mai bine, altă provocare la care să răspundeți, altă problemă de rezolvat, altă înălțime de cucerit... Aceasta este mișcarea la nesfârșit, pentru că nu există un proces sau un produs ideal, dezvoltarea și competiția nu se opresc niciodată, așa cum lupta pentru supraviețuire în natură nu se oprește niciodată.

Și dacă totul a avut succes: oamenii din companie înțeleg și împărtășesc valorile și principiile Agile și lucrează în conformitate cu acestea, atunci conducerea nu va trebui să „tragă” nicio schimbare sau să „dea cu piciorul” angajaților pentru ca aceștia să înceapă să facă ceva diferit. Întreprinderea va deveni un singur organism, al cărui management va necesita mai puțin efort și va aduce mai multă plăcere.
Și acolo unde este mai multă plăcere de la muncă, iar rezultatul este mai mare. Acest lucru se aplică nu numai specialiștilor, ci și managementului și într-o măsură și mai mare.

Oricine s-a ocupat vreodată de managementul proiectelor știe cât de dificil este să organizezi o muncă bine coordonată a unei echipe, iar în fața cerințelor în continuă schimbare pentru rezultatul unui proiect, toate eforturile depuse pot deveni zadarnice. Metoda de management agilă a proiectelor este ideală pentru a lucra cu astfel de proiecte.

Metoda Agile de management de proiect este o serie de etape de lucru definite de termene limită grele - sprinturi, permițând echipei să evalueze constant rezultatele muncii depuse și să primească feedback de la client și de la alți participanți la proiect. Această abordare vă permite să faceți modificări instantanee ale produsului atunci când sosesc noi cerințe.

Istoria Agile

Management de proiect evolutiv și dezvoltare adaptivă software apărut la începutul anilor 1970. În 1970, Dr. Winston Royce a prezentat o lucrare intitulată „Managing the Development of Large Software Systems” care a fost critică pentru dezvoltarea secvențială. El a susținut că software-ul nu ar trebui dezvoltat ca o mașină pe o linie de asamblare în care fiecare piesă este adăugată în faze succesive. În astfel de faze succesive, fiecare fază a proiectului trebuie finalizată înainte ca următoarea fază să poată începe. Dr. Royce a recomandat utilizarea unei abordări pe etape, în care dezvoltatorii colectează mai întâi toate cerințele proiectului, apoi își finalizează întreaga arhitectură și design, apoi scriu tot codul și așa mai departe.

În anii 1990, au fost dezvoltate o serie de metode agile de dezvoltare a software-ului ca răspuns la metodele grele predominante. Acestea includ: din 1991 - RAD (dezvoltare rapidă a aplicațiilor); din 1994 - Metoda de dezvoltare a sistemelor dinamice (DSDM); din 1995 - Scrum; Din 1996, Crystal Clear and Extreme Programming (XP); Și din 1997 - Dezvoltare bazată pe caracteristici (FDD). Deși au apărut înainte de publicarea Agile Software Development Manifesto, ele sunt denumite în mod colectiv Agile Software Development.

În februarie 2001, șaptesprezece dezvoltatori de software s-au întâlnit la Snowbird Resort din Utah pentru a discuta despre tehnici de dezvoltare ușoare. Împreună au publicat Manifestul Agile.

Manifestul Agile

Manifestul Agile constă din 4 idei de bază și 12 principii. Fiecare metodologie Agile aplică aceste idei în mod diferit, dar toate se bazează pe ele pentru a gestiona proiectele cât mai eficient posibil.

4 Idei Agile

1. Oamenii și interacțiunea sunt mai importante decât procesele și instrumentele.
2. Software-ul care funcționează este mai important decât documentația.
3. Colaborarea cu clienții este mai importantă decât negocierea termenilor contractului.
4. Dorința de a face schimbări în prioritate, mai degrabă decât de a rămâne la planul inițial.

12 principii ale Agile

1. Satisfacția clienților prin livrarea timpurie și continuă a software-ului. Clienții sunt mai fericiți când primesc software funcțional la intervale regulate.
2. Modificați cerințele produsului pe parcursul procesului de dezvoltare.
3. Livrare frecventă de software de lucru (în fiecare lună, douăsprezece, săptămânal etc.).
4. Cooperarea între părțile interesate (client și dezvoltatori) pe tot parcursul proiectului.
5. Sprijin, încredere și motivare a persoanelor implicate. Echipele motivate au mai multe șanse să-și dea rezultate cel mai bun lucru decât angajaţii nemulţumiţi de condiţiile de muncă.
6. Interactiune fata in fata. Comunicarea are mai mult succes atunci când echipele de dezvoltare sunt capabile să comunice direct.
7. Software-ul de lucru este principala măsură a progresului. Furnizarea de software funcțional către client este factorul final care măsoară progresul.
8. Menținerea unui ritm constant de lucru. Echipele stabilesc o rată de operare repetabilă și susținută la care pot furniza software funcțional.
9. Atenție la detalii tehnice și design. Abilitățile potrivite și design bun permite echipei să mențină impulsul, să îmbunătățească continuu produsul și să lucreze la schimbare.
10. Simplitate.
11. Echipele auto-organizate încurajează arhitectura, cerințele și design-urile excelente. Membrii echipei calificați și motivați, care au autoritatea de a lua decizii, comunică în mod regulat cu alți membri ai echipei și fac schimb de idei care vor asigura crearea unui produs de calitate.
12. Adaptare constantă la condițiile în schimbare, ceea ce va contribui la creșterea competitivității produsului pe piață.

Baza metodei Agile

Baza metodei agile de management de proiect este o serie de elemente cheie:

1. Control vizual. Participanții la proiect folosesc carduri de diferite culori și tipuri în timpul lucrului la proiect, care semnalează ce element al produsului final a fost deja dezvoltat, planificat, finalizat etc. Astfel, echipa are o reprezentare vizuală a stării actuale a lucrurilor. Controlul vizual asigură aceeași viziune asupra proiectului de către fiecare dintre participanți.
2. Toți participanții la proiect lucrează cot la cot, inclusiv clientul. Această abordare nu numai că accelerează multe dintre procesele asociate cu informarea membrilor grupului de lucru, dar și creează atmosferă favorabilă pentru colaborare și muncă eficientă.
3. Management adaptabil. Managerul de proiect nu este o persoană care dă instrucțiuni, ci un lider care stabilește regulile de bază ale muncii și cooperării.
4. Colaborare. Echipa, managerul de proiect și clientul lucrează împreună, ceea ce elimină posibilitatea pierderii de informații și neînțelegerea obiectivelor. De asemenea, transparența tuturor proceselor vă permite să eliminați instantaneu problemele emergente și să găsiți soluții și îmbunătățiri de succes.
5. Lucrare bazată pe împărțirea sferei totale a proiectului în părțile sale componente. Acest sistem de lucru reduce semnificativ complexitatea proiectului și permite echipelor să se concentreze pe fiecare parte în mod individual.
6. Lucrați la greșeli. În timpul lucrului unui ciclu, echipa învață noi abilități și analizează erorile care au apărut, ceea ce exclude apariția lor în ciclul următor.
7. Sprinturi și întâlniri zilnice. Sprinturile - perioade de timp în care echipele îndeplinesc o serie de sarcini - vă permit să vedeți clar rezultatele muncii. Împărțind timpul de lucru la proiect în sprinturi, obținem, de exemplu, 10 sprinturi, fiecare timp de două săptămâni. Și întâlnirile zilnice de cel mult 15 minute vor ajuta fiecare membru al echipei să răspundă la trei întrebări: ce am făcut ieri, ce voi face azi, ce mă împiedică să lucrez?

Astfel, introducerea metoda flexibila Agil este posibil în următoarele condiții:

• sensul proiectului este clar indicat,
• clientul este implicat activ pe parcursul proiectului,
• posibila implementare pas cu pas a domeniului total al proiectului,
• rezultatul muncii este mai important decât documentația,
• grupul de lucru nu este mai mare de 7-9 persoane.

Pe acest moment Metodologia agilă este larg răspândită în domeniul IT și începe să stăpânească domeniul de afaceri, în special marketing, management, training etc. Metoda agilă de management de proiect este folosită de multe companii și agenții guvernamentale, de exemplu, guvernele din Norvegia și New Zealand folosește Agile. În Rusia, Sberbank stăpânește Agile pentru sectorul comercial.

Sisteme de management de proiect bazate pe Agile

Există multe metode bazate pe ideea de Agile, cele mai populare dintre ele sunt Scrum și Kanban.

SCRUM

Scrum este o metodologie de management de proiect care se concentrează pe controlul calității procesului de lucru. Hirotaka Takeuchi și Ikujiro Nonaka, primii care au descris abordarea Scrum, au explicat-o ca fiind „abordarea rugby”, în care scrum luptă pentru minge. Metoda în sine este un proces de dezvoltare împărțit în mici iterații - sprinturi, la sfârșitul cărora utilizatorii primesc o versiune îmbunătățită a software-ului. Sprintul este fixat rigid în timp, iar durata lui este de la 2 până la 4 săptămâni. Munca într-un singur sprint constă în mai multe etape:

1. Planificarea domeniului de lucru pentru un sprint.
2. Întâlniri zilnice de 15 minute pentru a corecta activitatea echipei și a rezuma rezultatele intermediare.
3. Demonstrarea rezultatelor muncii.
4. O retrospectivă de sprint care trece în revistă succesele și eșecurile ultimului sprint.

Scrum este cel mai frecvent utilizat pentru a gestiona dezvoltarea de software și produse complexe folosind metode iterative și incrementale.

Scrum crește foarte mult productivitatea și reduce timpul în avantaj față de procesele clasice „în cascadă”. Procesele Scrum permit organizațiilor să se adapteze fără probleme la cerințele în schimbare rapidă și să creeze un produs care îndeplinește obiectivele de afaceri în schimbare. Scrum vă permite să:

• Îmbunătățirea calității rezultatelor;
• Mai bine să faceți față schimbării;
• Furnizați estimări mai precise, petrecând mai puțin timp pentru a le crea;
• Este mai bine să controlați scenariul proiectului și etapele de lucru.

Kanban

Kanban este un proces conceput pentru a ajuta echipele să lucreze împreună mai eficient. În japoneză, kanban înseamnă „ panou, panou”, iar metoda în sine este preluată și adaptată din sistem de producere Toyota. Esența Kanban este de a face procesul de dezvoltare cât mai transparent posibil și de a distribui sarcina în mod egal între membrii echipei. Kanban promovează colaborarea continuă și încurajează învățarea și îmbunătățirea activă și continuă.

Kanban se bazează pe trei principii:

1. Vizualizarea sarcinilor: vizibilitatea tuturor informațiilor despre proiect vă va ajuta să vedeți deficiențele, erorile și suprapunerile.
2. Control și limitare WIP (luc în curs): acest lucru ajută la echilibrarea abordării threading, astfel încât echipele să nu înceapă și să lucreze prea mult deodată.
3. Controlați timpul pentru a finaliza sarcina și optimizați munca pentru a economisi timp.

Avantajele și dezavantajele Agile

Orice metodologie are avantaje și dezavantaje. Luați în considerare avantajele și dezavantajele Agile.

Avantaje

1. Mai multă flexibilitate în comparație cu metodologia Waterfall.

Metodologia tradițională a cascadei dictează clar etapele de lucru. Cu metodologia Agile, programul și costul sunt principalii determinanți, iar acesta este un domeniu care se modifică pentru a satisface cerințele clienților și consumatorilor produsului.

2. Mai puține defecte în produsul final.

Acesta este rezultatul controalelor de calitate efectuate la fiecare etapă a lucrării. Proces continuu„dezvoltați, construiți și testați” reduce, de asemenea, defectele pe măsură ce ciclurile de iterație continuă.

Defecte

1. Primirea constantă a feedback-ului duce la o amânare constantă a datei de finalizare a proiectului.

Cu feedback-ul instantaneu pe care Agile îl oferă, există un pericol muncă îndelungată. Utilizatorii finali care văd că aceste cerințe pot fi îndeplinite „ușor” (văd doar rezultatul, nu efortul) vor solicita funcții suplimentare. Dacă managerul de proiect și dezvoltatorii nu pot gestiona așteptările, utilizatorii finali vor continua să ceară mai mult până când întreaga echipă este încărcată cu muncă suplimentară.

2. Documentare

Datorită naturii flexibile a Agile, documentația trebuie să urmeze condițiile de proiect în schimbare rapidă. O solicitare de modificare sau de caracteristică ar putea fi discutată în detaliu și convenită cu utilizatorii finali, dezvoltatorii și testerii, dar, cu excepția cazului în care echipa a fost informată, un document critic, cum ar fi un manual de utilizare, un document de arhitectură sau cerință funcțională, va deveni învechit.

3. Întâlniri frecvente

În timp ce Agile recomandă ca aceste întâlniri să fie organizate zilnic pentru a-i ține pe toți la curent cu privire la progresul celuilalt, sustenabilitatea acestei practici afectează progresul iterațiilor. Dezvoltatorii sunt concentrați pe ceea ce fac. Să-i scoți pentru o întâlnire care le-ar putea distrage atenția de la a face munca efectivă, nu este ceva ce vor accepta cu plăcere.

Implementare Agile

1. Alegerea metodologiei. Există diverse metodologii flexibile care sunt dezvoltate în anumite condiții. Primul pas în lucrul cu Agile este să determinați obiectivele sarcinii de lucru, termenele limită, numărul de angajați și multe altele și să alegeți o astfel de metodologie flexibilă de management de proiect, care să îndeplinească toate cerințele.
2. Instruire. Instruirea este necesară pentru ca angajații să înțeleagă principiile de bază ale Agile și să știe cum să lucreze cu ei. În această etapă sunt identificate capcanele care se pot reduce Eficiență agilă. Este echipa pregătită pentru schimbare? Sunt proiectele companiei potrivite pentru practici agile? Acestea și multe alte întrebări primesc de obicei răspunsuri de către antrenorii de afaceri Agile. Printre altele, se va întocmi și o listă de training-uri și un plan, conform cărora se va realiza implementarea Agile în companie.
3. Demo agil. Un fel de test drive Agile, care se desfășoară sub supravegherea unui specialist și arată toate etapele de lucru, explică funcțiile rolurilor, interacțiunea în cadrul echipei și între echipe etc.
4. Crearea unei echipe. Pe lângă selecția angajaților, crearea unei echipe include și definirea responsabilităților, repartizarea sarcinilor, crearea unui program de întâlniri etc. Fiecare metodă este concepută pentru o anumită cantitate de persoana din echipa.
5. Selectarea instrumentului necesare pentru distribuirea sarcinilor, raportare, analize și multe altele.
6. Primul proiect cu Agile.În primul proiect vor exista erori, inconsecvențe, respingerea unor instrumente și alegerea altora. Orice tehnică necesită un fel de adaptare la caracteristicile companiei în care este implementată.

Dacă găsiți o eroare, evidențiați o bucată de text și faceți clic Ctrl+Enter.

Este dificil să găsești o persoană care să nu vrea 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 recunoscut înalt calificat în domeniul dezvoltării software. Și pentru asta trebuie să studiezi. Și în cadrul acestui articol, vom lua în considerare ce este Agile, care este utilizarea acestuia și cum să înțelegem această tehnologie.

informatii generale

În primul rând, să ne ocupăm de problemele tehnice. Ce este Agile? Traducerea (literală) a acestui cuvânt din de limba engleză- „în direct, mobil”, „flexibil” este menționat puțin mai rar. Și apropo, este o abreviere. Numele complet al acestei abordări este Agil dezvoltare de software. Dar pentru că este prea lung, s-a hotărât tăierea lui. Și acum ei spun doar Agile. Traducerea ca „flexibil” este folosită datorită faptului că se potrivește cel mai mult cu situația reală.

Ce este inclus aici?

Continuăm să luăm în considerare ce este Agile. Aici vreau să mă concentrez pe faptul că aceasta este o abordare flexibilă, care se bazează pe multe XP 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 lumea reală în sine. Iar big bang-ul este cea mai dureroasă problemă cu care trebuie să te confrunți - schimbarea listei de cerințe de produs. De obicei, procesele de creație implică utilizarea model de cascadă. În acest caz, totul decurge secvenţial și în etape. Această abordare poate fi exprimată pe scurt: văd scopul - mă duc la el. Și dacă cerințele pentru rezultatul final se schimbă, atunci uneori trebuie să refaceți aproape totul din nou. Ceea ce complică și mai mult această situație este încercarea de a ne preface că totul este bine și că trebuie să mergem înainte.

Și aici este managementul, conceput să facă față tuturor acestor lucruri 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, nu citiți contractul.
3. Documentația nu trebuie să interfereze cu munca.
4. Schimbați-vă cât mai repede posibil.

Poate părea prea vag și nu este exact, dar haideți să detaliem.

Proiectarea procesului

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

1. Selectați un proprietar de produs. Acest rol este potrivit pentru o persoană care vede la ce obiectiv trebuie să mergi ș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 o persoană responsabilă. Aceasta este o persoană care va monitoriza dezvoltarea proiectului și va ajuta echipa să evite 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 înțelege dacă poate fi implementat și de cât timp este nevoie pentru aceasta.
5. Ar trebui să împărțiți întregul domeniu de activitate î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 ne împiedică să luăm înălțimea.
7. Faceți recenzii la sfârșitul săptămânii (două), timp în care echipa vorbește despre ceea ce s-a făcut. În același timp, este necesar să se demonstreze performanța părților produsului.
8. După fiecare perioadă de timp, problemele ar trebui să fie discutate și soluții căutate. 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. aceasta obiectivul principal pe care o urmărește orice abordare flexibilă.
2. Dezvoltare iterativă. În acest caz, este implicată lucrul în cicluri mici.
3. Cel mai important lucru este oamenii și comunicarea dintre ei.

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

1. Clientul dorește un produs minim viabil. În același timp, 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 este crescută, problemele sunt rezolvate rapid, iar șansele ca să existe o surpriză la crearea unui produs sunt reduse.

factor social

Când vorbesc despre ce este Agile, de obicei vorbesc doar despre lucruri pozitive. Într-adevăr, comunicarea în cadrul echipei se îmbunătățește. Toți oamenii se concentrează pe o singură idee, nu își creează secrete între ei, își iau angajamente. Drept urmare, echipa lucrează în condiții confortabile și într-un ritm rapid. Această abordare vă permite să simplificați haosul.

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 practica generală de afaceri, această abordare este încă puțin cunoscută. Prin urmare, cei care nu au întâlnit Agile înainte sunt precauți în privința asta. De asemenea, trebuie să se înțeleagă că ar trebui folosit numai în cazurile în care oamenii se confruntă cu sarcina muncii intelectuale.

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 cunoaște 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 folosi produsul, pot sprijini crearea acestuia sau pot fi implicați în orice 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: sistemul de rezervare a biletelor pentru autobuzele obișnuite Moscova-Sankt Petersburg ar trebui să aibă o căutare pentru zboruri. Peter va ajuta persoanele interesate. Acesta va prelua controlul asupra implementării din ideile de povești ale utilizatorilor. Există și o echipă de dezvoltare. Aceștia sunt oamenii care vor construi sistemul de lucru.

Deoarece metodologia de dezvoltare este agilă, poveștile utilizatorilor nu se acumulează până la o lansare mare, ci sunt lansate imediat după finalizare și cât mai des posibil. Numărul de cereri procesate este debitul săptămânal al echipei. Pentru a nu pierde impuls și a se bloca în testarea manuală, echipa ar trebui să lucreze la integrarea automată. Ce este? Se scrie un test automat pentru fiecare moment de lucru. Dacă sunt prea multe povești, atunci poate exista graba, pierderea motivației, pierderea productivității și a calității. Pentru astfel de cazuri, este prevăzută 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ă ar putea procesa patru povești pe săptămână. Dar cum să navighezi în tot ceea ce este? Să presupunem că utilizatorii încarcă zece povești pe săptămână. Patru sunt în curs de procesare. Astfel, coada va crește constant. În acest caz, există doar unul metoda eficienta- cuvântul „nu”. Pentru proprietarul produsului, 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, este necesar să decideți la ce să acordați atenție acum și la ce ar trebui amânat. Pentru a face bine, 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 doar un bonus frumos. Unele povești vor dura câteva ore pentru a se dezvolta. Alții vor avea nevoie de luni pentru a se finaliza. Mulți desenează adesea o corelație între dimensiunea unei povești și valoarea ei. Dar acest lucru nu este întotdeauna corect. Mai mult nu este același lucru cu mai bine. Complexitatea și valoarea sarcinii la îndemână îl ajută pe Peter să prioritizeze corect. Cum pot fi cuantificate aceste caracteristici? În nici un caz. Acesta este un adevărat joc de ghicituri. Și pentru o mai mare eficacitate, este necesar să implicați o mulțime de oameni în ea. 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 estimari aproximative. 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 probleme, este necesar să oferiți răspunsuri sincere la o serie de întrebări. Aceasta:

1. Facem lucrurile corect? Acesta este un risc de afaceri.
2. Putem implementa ceea ce avem nevoie?
3. Va funcționa proiectul pe această platformă. Acesta este un risc tehnic.
4. Sunt destui bani si vom avea timp? Acestea sunt riscuri legate de termenii de implementare și de cost.

În acest caz, sunt necesare cunoștințe. Ele pot fi considerate opuse ale riscurilor. Când un nivel semnificativ de incertitudine este fixat, atunci dobândim cunoștințe - de exemplu, creăm prototipuri de interfață sau experimente tehnice. Și deținându-le deja, luăm decizii cu privire la direcția în care ar trebui să ne îndreptăm.

Cum să înveți?

Industria IT se dezvoltă extrem de rapid, iar pentru a nu pierde în cele din 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? Cel mai cea mai bună opțiune- aceasta este cooperarea cu o companie în care Agile este deja aplicat. Instruirea în acest caz va fi efectuată de oameni care nu știu din auzite ce este dezvoltarea agilă. Dar, din păcate, acest lucru 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ă obțineți o persoană cu adevărat informată, atunci toate cheltuielile se vor achita considerabil. La urma urmei, în lumea modernă Performanța angajaților joacă un rol important.

Ce este pregătit pentru viitor?

Metodologiile de dezvoltare software sunt în continuă evoluție. Căutăm 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 rezervă viitorul. Probabil, sistemul de dezvoltare flexibil va fi integrat cu instrumente de automatizare Procese de producție. De exemplu, va fi posibilă rezolvarea problemelor chiar dacă vă aflați la 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ă stăpânești noi metode de lucru cu ele. Și în acest caz există o dezvoltare închisă într-un ciclu.

In cele din urma

Așa că excursia către cele flexibile s-a încheiat, dar trebuie amintit că teoria este una, iar practica este cu totul alta. Noile tehnologii informaționale care apar în mod constant provoacă marea comunitate de dezvoltatori. Cum îți poți face echipa mai eficientă? Fiecare găsește singur răspunsul la această întrebare. Informațiile prezentate aici pot fi folosite pentru a forma coloana vertebrală. 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 îndeplini în mod eficient obiectivele.