Instrumente agile. Ce este abordarea Agile și de ce are nevoie de ea afacerile? Metodologii agile versus managementul de proiect tradițional

Pentru început. Scrum și Agile - care este diferența? Pe scurt, Agile este o filozofie, o familie de abordări flexibile ale dezvoltării software. Scrum este o astfel de abordare. Are un frate - Kanban. Aceasta este, de asemenea, o abordare utilizată în Agile.

Elena Truskova spune:

Săptămâna aceasta am finalizat un antrenament de două zile Agile/Scrum (pronunțat „agile” și „scrum”). Conform metodologiilor de dezvoltare agile software S-a scris multă literatură abstrusă și nu atât de abstrusă, am citit mult. Dar abia după două zile de scufundare în subiect am adunat în sfârșit o înțelegere de bază a subiectului din care scriu această notă.

Agile și Scrum ajută la organizarea procesului de lucru în echipă în așa fel încât să lanseze un produs care este interesant utilizatorului în mod regulat și des.

În unele bănci, drumul unei idei către utilizatori datorită agile a fost scurtat de la doi ani la șase luni, în alte companii, ciclul de dezvoltare de șase luni a fost comprimat în trei; În vremurile noastre agitate, acest lucru este adevărat. avantaj competitiv, în special pentru jucătorii mici.

Principiile Scrum pot fi aplicate la absolut orice: de exemplu, pentru a lucra la un produs creativ. Acest lucru, desigur, nu este „agil canonic”; Dame sau pleci?

Unele lucruri din Agile și Scrum pot fi incluse chiar și în munca individuală. Asigurați publicarea regulată a postărilor, măsurați încărcătura asupra interpretului, estimați sarcinile viitoare în termeni de timp și nu uitați să analizați calitatea muncii efectuate - uite, totul a fost deja gândit pentru noi. Tot ce rămâne este să o implementăm.

Agil

(eng.agile - „agil, agil, iute la minte”)

Conceptul de flexibilitate:

Înlocuiți tipul dvs. de activitate cu cuvântul „dezvoltare” - și aceste principii vor deveni apropiate și de înțeles.

„Un produs de lucru este principalul indicator al progresului”, „simplitatea ca artă a minimizării muncă suplimentară” și „oamenii și interacțiunile sunt mai importante decât procesele și instrumentele” - nu sună rezonabil?

Scrum

(Scrum engleză - agitație în lupta pentru minge în rugby)

Merită să ne amintim aici că acesta este punctul meu de vedere personal și subiectiv despre Scrum. Aici reflectez asupra aplicabilității elementelor Scrum ca în proiecte creative, departe de IT, și în munca individuala(sa zicem pe un blog). Pentru a face acest lucru, va trebui să omiteți o mulțime de detalii precise; Încerc să păstrez textul simplu și să nu supraalimentez cititorul cu terminologie.

Duritatea Scrum constă în structură. Există un anumit set de abordări care funcționează mai bine împreună decât separat. Sper că nimeni nu-ți va interzice să scoți ceva și să-l folosești.

De obicei, Scrum apare acolo unde există un anumit produs care are valoare pentru utilizatori și clienți și trebuie să înțelegem cât mai repede posibil pe drumul către obiectiv dacă mergem acum în direcția corectă - sau dacă trebuie să corectăm curs. Formatul Scrum vă permite să lansați următoarea versiune mai des, să primiți în mod regulat feedback și să rafinați rapid produsul, precum și să îmbunătățiți procesul de lucru.

Dacă lucrați în echipă, Scrum îi instruiește pe toți cei din proces să depună eforturi pentru interschimbabilitate, capacitatea de a „prelua” o sarcină slabă dacă un vecin este bolnav, împărtășirea abilităților și responsabilitatea colectivă pentru produs. Există puțin individualism în Scrum. Deciziile sunt luate în mod colectiv (după principii stricte, nimeni nu poate pune presiune și nu-i poate obliga să aleagă o altă soluție dacă echipa este sigură că a ales-o pe cea potrivită).

A avea acest tip de încredere în Scrum nu este înfricoșător, deoarece fiecare marș forțat durează exact un sprint (o perioadă clară de timp, de obicei de la una până la patru săptămâni). După terminarea sprintului, vine momentul analizei: cum am trecut peste el? Ce ai putea face și mai bine data viitoare?

Prin urmare, chiar dacă am alergat cu toții cu încredere în direcția greșită, vom avea ocazia la finalul sprintului să-l corectăm și să reparăm ceea ce ne trimite în direcția greșită. O echipă Scrum se auto-organizează și se autoajustează.

Echipa în Scrum

Mărimea standard a unei echipe Scrum este de 7 plus sau minus 2 persoane. Adică de la cinci la nouă. Scrum Scaling are loc: puteți construi un sistem de lucru la o sarcină gigantică din 25 de echipe. Dar unitatea de bază a Scrum este echipa.

Fiecare echipa are:

• participanți (în cazul IT - dezvoltatori, cine sunt acești șapte oameni - decideți singuri)
• proprietar de produs (proprietar de produs). Rolul său: înțelege piața și utilizatorul, formulează sarcini în limbajul afacerilor și utilizatorilor, ține cont de conștientizarea direcției în care ar trebui să se dezvolte valoarea și beneficiul, inventează și selectează sarcini pentru dezvoltarea produsului. Ceva ca un manager de produs (nu o echipă).
• Scrum master (scrum master, evanghelist scrum). Rolul lui: monitorizarea procesului, observarea vieții interne a echipei, motivarea oamenilor, eliminarea obstacolelor. Ceva ca un antrenor.
  În jurul echipei există utilizatori și părți interesate (clienți). Proprietarul produsului se adresează acestor persoane pentru sfaturi.

Dispozitiv Sprint

Munca Scrum constă în sprinturi. Toate sprinturile sunt structurate la fel. Se presupune că cu fiecare sprint ulterior echipa devine din ce în ce mai colaborativă și mai eficientă. În Scrum, înveți din greșelile tale, dar rapid - la fiecare sprint analizezi exact ce ai făcut și cum vrei să repari.

Proprietarul produsului are o listă de idei de afaceri pentru a-i face pe utilizatori fericiți. Se numește backlog de produse, o listă de idei de produse. Sortează ideile după importanță și semnificație.

Fiecare sprint are un backlog de sprint - o listă sortată de idei pe care echipa a decis să le facă în următorul sprint. Ideea Scrum este că echipa însăși evaluează complexitatea fiecărei sarcini și decide care sarcini vor fi incluse în următorul sprint.

O sarcină într-un sprint are o pondere cunoscută echipei (se știe cât timp va dura), i se atribuie un executant și este de înțeles și important. Dacă nu știți cât timp va dura o sarcină, trebuie să o descompuneți în părți mai mici.

O echipă își planifică întotdeauna prost la începutul vieții. Aceasta este realitatea obiectivă. Dar ține statistici despre ceea ce reușește să realizeze în timpul sprintului și planifică din ce în ce mai precis în timp. Ea este ajutată de întâlnirea finală a sprintului - o retrospectivă. Acolo poți discuta punctele slabe ale sprintului de ieșire și poți găsi modalități de a face lucrurile diferit.

De obicei, un sprint se potrivește pentru 5 plus sau minus 2 idei. Dacă ideile sunt prea mari, echipa le împarte astfel încât în ​​fiecare sprint să se poată arăta ceva mic.

În Scrum, ideile se numesc user stories (povestiri despre utilizatori) și sunt formulate după cum urmează: „Ca (rol?) vreau (ce?) pentru a (de ce?)”. Astfel, echipa vede nu doar funcționalitatea, ci și sensul creării sale, și pentru un rol anume: utilizator, client, cumpărător.

Rezultatul unui sprint este întotdeauna ceva de arătat pentru el. Echipa își arată munca pe demo la sfârșitul sprintului.

În opinia mea, procesul Scrum este similar cu lucrul pe un blog de echipă. Un astfel de proces ar ajuta la menținerea regularității, ar reuni experiența autorilor și nu ar colecta atât de mult încât să nu ai timp să o faci.

Structura sprintului

Sprintul începe cu planificarea: echipa se așează și discută: vom lua această idee, nu o vom lua pe aceea. În IT, acest proces poate dura câteva ore, deoarece discuția merge până la detalii. În cazul lucrului cu un blog, acest lucru se poate transforma într-o discuție de subiecte și planuri pentru articole, pe care apoi trebuie doar să te așezi și să le scrii - înțelegând ce scriem, când și de ce.

În fiecare zi are loc o întâlnire stand-up de 15 minute. Este important să o faci în picioare: dacă cineva începe să vorbească, restul se va muta elocvent de la picior la picior și se va zgâria urechile. Puteți folosi un obiect astfel încât doar un participant să vorbească la un moment dat și să îl transmiteți în cerc.

Fiecare participant la stand-up la rândul său răspunde la trei întrebări:

• ce am facut ieri
• ce voi face azi
• ce mă încetinește

Toate conversațiile detaliate care apar în timpul procesului merg dincolo de stand-up. Stand-up-ul este un punct în care poți prinde probleme sau poți afla că din anumite motive colegul meu și cu mine facem același lucru în același timp, ceea ce înseamnă că unul dintre noi poate face altceva.

În general, Scrum Master ar trebui să fie responsabil pentru menținerea tuturor acestor reguli clare de comportament. Aceștia sunt de obicei ideologi ai tehnologiei, care cred în ea și sunt gata să construiască un proces pentru eficiența maximă a timpului petrecut împreună. Fără un Scrum Master, procesele vor degenera în minimum posibil, pentru că persoana este leneșă și economică.

La sfârșitul sprintului există o demonstrație (demonstrație) care arată ceea ce am reușit să creăm în timpul sprintului, un sprint review (sprint review) cu o revizuire a backlog-ului de produse și conversații despre CE facem, precum și o retrospectivă. (retro ) - ceea ce nu am făcut în cel mai bun mod pe tot parcursul sprintului și dorim să ne îmbunătățim în continuare - despre CUM o facem.

„Dacă aș avea opt ore pentru a tăia un copac, aș petrece șase ore ascuțind securea.” (atribuit tăietorului de lemne și președintelui Abraham Lincoln)

Ați lucrat vreodată la proiecte sau cel puțin ați luat parte la munca de proiect? Dacă da, probabil ați observat că a obține o echipă de lucru poate fi destul de dificil. Și chiar dacă se stabilește, există riscul ca toate eforturile să fie în zadar, deoarece cerințele pentru rezultatul dorit se schimbă adesea.

Cu toate acestea, puteți simplifica semnificativ munca la un proiect și puteți învăța cum să-l gestionați, crescând astfel eficiența echipei, folosind un sistem flexibil de management de proiect numit Agile („Agile” sau „Agile”). În general, am vorbit deja pe scurt despre asta în (a patra lecție), dar acum vom vorbi despre acest subiect mai detaliat.

Metoda Agile: Definiție și scurt istoric

Indiferent cât de neobișnuit ar suna, dezvoltarea serioasă de software și managementul proiectelor au început deja în anii 70 ai secolului trecut. În 1970, informaticianul american Winston Royce a compilat un document numit „Managing the Development of Large sisteme software" În acesta, el a criticat dezvoltarea secvențială, subliniind că dezvoltarea de software nu ar trebui să fie ca lucrul pe o linie de asamblare (cum se face, de exemplu, în producția de automobile), unde piese noi sunt adăugate în faze succesive.

În loc să aștepte ca fiecare etapă (fază) să fie finalizată una câte una, Royce a propus o abordare pe fază. Esența sa este că sunt colectate inițial toate cerințele necesare proiectului, după care se finalizează întreaga arhitectură, se creează designul, se scrie codul etc.

Pe baza acestui fapt, în anii 90 a fost posibil să se creeze un set de metode flexibile de dezvoltare a software-ului care ar putea înlocui metode complexe și consumatoare de timp. S-a întâmplat așa:

• În 1991, a fost introdusă metoda de dezvoltare rapidă a aplicațiilor RAD.
• În 1994, a apărut o metodă de dezvoltare sisteme dinamice DSDM
• În 1995, a apărut platforma Scrum (cadru) pentru dezvoltare flexibilă.
• În 1996, a apărut metodologia de dezvoltare agilă Crystal Clear, precum și XP Extreme Programming
• În 1997, a apărut metodologia de dezvoltare software iterativă FDD

Împreună, aceste metode sunt unite sub denumirea generală de metode flexibile de dezvoltare software.

Patru ani mai târziu, în 2001, șaptesprezece dezvoltatori de software s-au adunat în stațiunea Snowbird din Utah (SUA). În urma discuției despre metodele de dezvoltare, a fost publicat „Manifestul privind dezvoltarea agilă a software-ului” (tradus din engleză, conceptul „agil” înseamnă „agil”, „agil” sau „rapid”, dar în majoritatea cazurilor este tradus tocmai ca „flexibil”) . El a stabilit ritmul pentru toate lucrările ulterioare privind crearea de software.

Manifestul Agile

Manifestul, creat de programatori, include 4 idei de bază și 12 principii management eficient proiecte. Oricare dintre sistemele de management de proiect bazate pe Agile (vom vorbi despre sisteme mai târziu) se bazează tocmai pe aceste idei și principii, deși le folosește în diferite variante.

1. Oamenii și interacțiunile lor sunt mai importante decât procesele și instrumentele
2. Software-ul care funcționează este mai important decât documentația
3. Clienții și cooperarea cu aceștia sunt mai importante decât un contract și negocierea condițiilor
4. Disponibilitatea de a face schimbări este mai importantă decât planul inițial

Principii agile:

1. Satisfaceți clienții prin livrarea software-ului din timp și în mod constant (clienții sunt mulțumiți când software-ul funcțional sosește regulat și la intervale regulate)
2. Modificați cerințele pentru produsul final pe parcursul ciclului său de dezvoltare
3. Livrați software-ul funcțional cât mai des posibil (o dată pe săptămână, la două săptămâni, o lună etc.)
4. Sprijiniți colaborarea între dezvoltatori și clienți pe tot parcursul ciclului de dezvoltare
5. Sprijiniți și motivați pe toți cei implicați în proiect (dacă își face față sarcinilor mult mai bine decât o echipă ai cărei membri sunt nemulțumiți de condițiile de muncă)
6. Oferă interacțiune directă între dezvoltatori (posibilitatea contactului direct contribuie la o comunicare mai reușită)
7. Măsurați progresul numai prin intermediul software-ului funcțional (clienții ar trebui să primească doar software funcțional și funcțional)
8. Menține un ritm continuu de lucru (echipa trebuie să dezvolte o viteză optimă și menținabilă de lucru)
9. Acordați atenție designului și detaliilor tehnice (mulțumită abilităților eficiente și designului bun, echipa de proiect este capabilă să îmbunătățească în mod constant produsul și să lucreze pentru a-l îmbunătăți)
10. Încercați să faceți fluxul de lucru cât mai simplu posibil, iar software-ul simplu și ușor de înțeles
11. Permiteți membrilor echipei (dacă dezvoltatorii pot lua propriile decizii, se pot organiza și comunica cu alți membri ai echipei, schimbând idei cu ei, probabilitatea de a crea un produs de calitate crește semnificativ)
12. Adaptarea constantă la un mediu în schimbare (din această cauză produsul finit va fi mai competitiv)

În timp ce învățați Agile, pe lângă prezentarea de ansamblu a ideilor și regulilor, asigurați-vă că vedeți acest scurt videoclip în care specialistul în management de proiect, consultant și antrenor de afaceri Alexey Tachenkov vorbește despre elementele de bază ale sistemului.

Pentru a pune în practică ideile și principiile de mai sus, trebuie să respectați mai multe reguli. Doar atunci poate fi eficient managementul de proiect Agile.

Puncte cheie în utilizarea Agile

Metodologia agilă se bazează în primul rând pe control vizual. Cel mai adesea, participanții la proiect folosesc cartonașe colorate speciale atunci când lucrează pentru a obține rezultate. O culoare semnalează finalizarea planificării pentru un element al produsului final, o alta indică finalizarea dezvoltării sale, o a treia indică disponibilitatea etc. Inspecție vizuală permite echipei să aibă o imagine clară a stării curente a procesului și asigură că toți membrii echipei au aceeași viziune asupra proiectului.

Membrii echipei și clientul lucrează împreună și cot la cot în majoritatea cazurilor. Datorită acestui fapt, multe procese de lucru care sunt asociate cu informarea participanților la proiect sunt accelerate semnificativ. În plus, lucrul împreună ajută la crearea unei atmosfere sănătoase pentru fructuoase și cooperare eficientăși obținerea rezultatelor cât mai repede posibil.

Atunci când managerul de proiect, echipa și clientul lucrează împreună, nu există riscul de înțelegere greșită a obiectivelor și pierderea de informații. Toate procesele de lucru devin cât se poate de transparente, ceea ce înseamnă că orice probleme care apar pot fi rezolvate aproape instantaneu și pot fi găsite cele mai bune opțiuni pentru rezolvarea lor.

O atenție deosebită trebuie acordată managerului de proiect. El nu poate fi numit o persoană care dă instrucțiuni în stânga și în dreapta. Managerul de aici acționează mai mult ca un lider care stabilește direcția și stabilește regulile de cooperare și de lucru. Cu alte cuvinte, managementul Agile este adaptabil.

încă unul punct important Metodologia agilă este împărțirea întregului domeniu de aplicare al proiectului în mai multe altele mai mici componente. Această abordare simplifică foarte mult procesul de dezvoltare, iar grupuri separate ale echipei se pot concentra fiecare pe sarcina lor specifică.

Lucrând pe un singur ciclu, participanții la proiect stăpânesc noi abilități și dobândesc noi cunoștințe și, de asemenea, analizează greșelile făcute în acest proces. Toate acestea reduc probabilitatea de a face greșeli similare în viitor (în ciclurile ulterioare și alte proiecte) la aproape zero.

Și, în sfârșit, ultimul element semnificativ al abordării sunt sprinturile și întâlnirile zilnice. Sprinturile sunt perioade de timp limitate de anumite termene limită în care o echipă reușește să îndeplinească anumite sarcini. Datorită sprinturilor, echipa poate vedea rezultatele acțiunilor lor.

Dacă împărțim tot timpul alocat proiectului în mai multe sprinturi, vom obține un anumit număr dintre acestea; să fie 15 dintre ei. Fiecare sprint durează, de exemplu, două săptămâni. În aceste două săptămâni (timpul alocat sprintului) participanții se întâlnesc în fiecare zi pentru a discuta despre procesul și progresul.

Întâlnirile zilnice nu trebuie să depășească 15 minute. Acestea sunt organizate astfel încât fiecare membru al echipei să-și dea singur răspunsul la trei întrebări:

• Ce am facut ieri?
• Ce voi face azi?
• Ce mă oprește să lucrez?

Răspunsul la aceste întrebări vă permite să păstrați controlul asupra procesului, să înțelegeți în ce stadiu se află fiecare membru al echipei și să eliminați potențialele probleme pe drumul către obiectiv. Pentru a rezuma, implementarea metodologiei Agile este posibilă dacă sunt îndeplinite mai multe condiții:

1. Semnificația proiectului este clar precizată
2. Clientul participă activ la procesul de implementare
3. Domeniul total de activitate se realizează pas cu pas
4. Ar trebui să vă concentrați pe un anumit rezultat
5. Numărul unui grup de lucru: de la 7 la 9 persoane

În prezent, managementul de proiect cu suport Agile este cel mai frecvent comun în sectorul IT, totuși sfera de afaceriîncepe să-l stăpânească. Acest sistem este utilizat în formare, marketing și afaceri. Managementul agil al proiectelor este adoptat de multe companii și agenții guvernamentale.

Exemple: guvernul Noii Zeelande, guvernul nigerian, fondul de pensii norvegian, compania Return Path (software), compania Oreo (producția de cookie-uri), compania Aviasales (cel mai mare motor de căutare a biletelor de avion), compania Hewlett-Packard (cea mai mare companie IT americană), Sberbank " (probabil știi ce este asta J).

Acestea și multe alte organizații folosesc o varietate de metode de management de proiect bazate pe Agile. Și a vorbi despre aceste metode nu este mai puțin important decât a vorbi despre metodologia în sine.

Metode populare de management de proiect

Există multe metode de management de proiect care sunt folosite de diferiți companiile moderne. Dar Scrum și Kanban sunt considerate pe bună dreptate cele mai faimoase și mai solicitate dintre ele.

Metoda Scrum

Dintre toate metodele sistemului Agile, Scrum diferă prin faptul că pune accent principal pe controlul calității procesului de lucru. Specialiștii japonezi care au descris-o primii management strategic Hirotaka Takuechi și profesorul de știință și tehnologie Ikujiro Nonaka numesc metoda „abordarea rugby”, în care Scrum „luptă pentru minge”.

Metoda este că dezvoltarea proiectului este împărțită în sprinturi, la finalul cărora clientul primește software îmbunătățit. Sprinturile sunt strict cronometrate și pot dura de la 2 până la 4 săptămâni. Fluxul de lucru într-un singur sprint include mai multe etape:

• Domeniul de activitate este determinat
• În fiecare zi au loc întâlniri de 15 minute, astfel încât membrii echipei să își poată ajusta munca și să însumeze rezultatele intermediare
• Rezultatele obtinute sunt demonstrate
• Sprinturile sunt discutate pentru a găsi succes și decizii proasteși acțiuni

În cele mai multe cazuri, Scrum este utilizat în lucrul cu software complex și pentru dezvoltarea de produse folosind metode incrementale și iterative. Datorită acesteia, productivitatea echipei este crescută semnificativ și timpul petrecut la muncă este redus.

Scrum îmbunătățește rezultatele, ajută proiectul să se adapteze la schimbare, oferă estimări mai precise cu mai puțin efort de analiză și vă permite să controlați mai eficient etapele de lucru și scenariul proiectului. Toate acestea se potrivesc perfect cu obiectivele de afaceri.

Metoda Kanban

Kanban este o altă metodă care face munca în echipă mai eficient și mai productiv. Sensul său se rezumă la a oferi procesului de dezvoltare transparență maximă și distribuție uniformă volumul de muncă în rândul participanților la proiect. O altă caracteristică importantă a Kanban este că îi motivează pe oameni să colaboreze, să se îmbunătățească și să învețe constant.

Lucrarea folosind metoda Kanban este construită pe mai multe principii. În primul rând, toate informațiile despre proiect trebuie să fie vizualizate, ceea ce vă permite să vedeți suprapuneri, erori și deficiențe și să le eliminați în mod activ. În al doilea rând, munca la o sarcină ar trebui să fie efectuată simultan de întreaga echipă - acest lucru ajută la echilibrarea eforturilor și a rezultatelor obținute și elimină distribuția neuniformă a sarcinii. Și în al treilea rând, timpul necesar pentru a finaliza toate sarcinile este strict controlat, optimizând astfel procesul și economisind timp.

Spre deosebire de Scrum, Kanban a câștigat popularitate mult mai târziu, dar acest lucru nu îi diminuează în niciun fel meritele sau îl face mai puțin eficient. Metoda este utila atat in domeniul IT, cat si in cel al afacerilor.

Acestea sunt doar exemple de practici de bază de management de proiect Agile. Dar nu trebuie să neglijați alte metode, precum PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall și altele. În plus, Agile, alături de avantajele sale, are și unele dezavantaje.

Avantaje și dezavantaje ale Agile

Când învățați Agile, este important să cunoașteți atât aspectele pozitive, cât și cele negative ale acestei metodologii. Să începem cu aspectele pozitive.

În primul rând, este de remarcat faptul că managementul Agile este foarte flexibil. Dacă, de exemplu, metodologia tradițională indică etape specifice de lucru, atunci Agile se adaptează cu ușurință la utilizatorul produsului final și la cerințele clientului.

De fapt, numărul de defecte ale produsului final este minimizat, deoarece este rezultatul unui control amănunțit al calității, care se efectuează la sfârșitul fiecărei etape de sprint.

În plus, Agile este rapid de pornit, ușor de răspuns la schimbări și permite echipei de dezvoltare și clienților să mențină o comunicare constantă în timp real. Avantajele sunt evidente, dar haideți să vorbim despre dezavantaje.

Dezavantajele metodologiei sunt că, în primul rând, feedback-ul constant poate duce la amânarea permanentă a termenului limită al proiectului, creând astfel amenințarea de a continua munca la nesfârșit. Dacă clientul vede doar rezultate, de exemplu, dar nu are idee despre efortul necesar pentru a le atinge, el va cere constant îmbunătățiri.

Al doilea dezavantaj este necesitatea de a adapta documentația de proiectare la condițiile în schimbare ale proiectului. Dacă echipa nu este informată în mod corespunzător despre modificări sau caracteristici suplimentare, cerințele funcționale sau documentele de arhitectură pot să nu fie relevante pentru echipă. momentul actual timp.

Al treilea dezavantaj semnificativ al Agile este nevoia de întâlniri frecvente. Ele, desigur, ajută la îmbunătățirea eficienței muncii, dar totuși, distragerea constantă a membrilor echipei poate avea un impact negativ asupra procesului, deoarece atenția oamenilor se îndepărtează sistematic de sarcinile în cauză.

Aceasta include și lucruri precum nevoia de prezență constantă a clientului, incapacitatea de a face planuri pe termen lung și nevoia de specialiști motivați și de înaltă calificare. Apropo, acesta din urmă se referă în mare măsură la implementarea managementului Agile în activitățile organizației. Și, în timp ce înțelegeți Agile, trebuie, de asemenea, să vă familiarizați cu subiectul implementării acestuia.

Implementarea Agile

Există destul de multe exemple de introducere a Agile în activitatea companiilor. Și aproape toți spun că necesită o serie întreagă de măsuri importante.

Pentru început, este selectată o metodă specifică, care depinde de condițiile proiectului. Apoi sunt determinate sarcinile și obiectivele, termenul limită principal și datele de sprint, dimensiunea echipei și alte componente ale proiectului. Este important să alegeți o metodă care să îndeplinească numărul maxim de cerințe.

După cum am spus, implementarea Agile necesită o echipă de profesioniști. Toți membrii săi trebuie să cunoască ideile și principiile de bază ale metodologiei și să le poată aplica. Dacă compania nu are astfel de oameni, angajații trebuie să fie instruiți. Conducerea unei companii care a decis să treacă la utilizarea Agile trebuie, de asemenea, să înțeleagă clar dacă organizația este pregătită pentru schimbări, dacă sistemul poate fi aplicat proiectelor sale etc. Cel mai adesea, pentru a răspunde la aceste întrebări, trebuie să apelezi la specialiști Agile.

Pe următoarea etapă Este invitată o persoană cu experiență în lucrul cu sistemul. O demonstrează, explică esența sprinturilor și acțiunilor, funcțiile membrilor viitoarei echipe, caracteristicile interacțiunii dintre ei și alte probleme. Și numai după aceasta se formează echipa noua, sunt distribuite rolurile, sarcinile și responsabilitățile, sunt selectate instrumente de analiză, raportare etc.

Etapa finală va fi prima experiență cu Agile, adică. primul proiect care îl folosește. Trebuie să înțelegeți că erorile, neajunsurile, inconsecvențele și întârzierile sunt inevitabile. Va trebui să renunți la unele instrumente și să le înlocuiești cu altele și, poate, să schimbi rolurile între oamenii din echipă. Prima experiență este un proces de adaptare, iar adaptarea este bidirecțională: compania se obișnuiește cu metodologia, iar metodologia se adaptează companiei.

Concluzie

Pentru a rezuma această recenzie, să ne amintim că teoria și practica sunt două lucruri diferite. Noile metode și tehnologii și implementarea lor sunt un fel de provocare pentru echipă și modul de realizare eficiență mai mare– este întotdeauna o chestiune individuală. Agile nu este un panaceu sau o garanție a succesului, dar vă permite să stabiliți cursul corect și să găsiți linii directoare pe parcurs.

Pentru a implementa orice proiect, cu siguranță va trebui să schimbi ceva, să cauți soluții noi, . Doar adaptându-ne la condițiile de muncă în continuă schimbare și la cerințele clienților putem găsi modalitățile potrivite de a acționa. Iar metodologia flexibilă de management de proiect Agile poate deveni un asistent fidel în această problemă.

• Traducere

„Orice afacere durează întotdeauna mai mult decât se aștepta, chiar și ținând cont de legea lui Hofstadter.”
- Legea lui Hofstadter

Cel mai vizionat videoclip de pe YouTube pe tema agile. 744.625 de vizualizări la momentul publicării acestui articol. Stil de prezentare ușor, imagini și doar 15 minute - cele mai bune pe care le-am văzut. TED ia o pauză.

Roluri

Acesta este Pat proprietar de produs. Ea nu cunoaște detaliile tehnice, dar are o viziune asupra imaginii de ansamblu, știe ea Pentru ce facem un produs, ce probleme va rezolva și pentru cine.

Acest părţile interesate. Ei vor folosi produsul, îl vor sprijini sau vor fi implicați în alt mod în dezvoltare.

Acest poveștile utilizatorilor. Ei exprimă dorințele părților interesate. De exemplu, „într-un sistem de rezervare a unei companii aeriene, utilizatorul ar trebui să poată căuta după zbor”.

Părțile interesate au o mulțime de idei, iar Pat ajută la transformarea ideilor în povești pentru utilizatori.

Acest echipa de dezvoltare. Cei care vor construi sistem de lucru.

Lățimea de bandă

Deoarece comanda folosește metodologie flexibilă de dezvoltare, nu tezaurizează toate aceste povești până la marea lansare, dimpotrivă, le lansează imediat și cât mai des. De obicei, ei lansează 4-6 povești de utilizator pe săptămână. Este al lor debitului . Este foarte simplu de măsurat - numărul de povești de utilizator în 7 zile.

Pentru a menține acest ritm și pentru a nu se bloca în testarea manuală de regresie, echipa lucrează din greu la testare automatăși integrare continuă. Prin urmare, trebuie să scrieți autotestări pentru fiecare caracteristică, iar cea mai mare parte a codului are autotestări încorporate.

Problema este că sunt foarte multe părți interesate și cererile lor nu pot fi satisfăcute cu 4-6 povești pe săptămână.

De fiecare dată când implementăm o poveste de utilizator, aceștia vin cu alte câteva idei, care duc la și mai multe solicitări.

Ce se întâmplă dacă facem tot ce ne cer ei să facem? Vom fi supraîncărcați.

Să presupunem că echipa se angajează să facă 10 povești noi în această săptămână Dacă intrarea este 10 și rezultatul este 4-6, atunci echipa va fi supraîncărcată. Se va grăbi, va comuta între sarcini, își va pierde motivația și, ca urmare, productivitatea și calitatea vor scădea. Aceasta este evident o strategie de pierdere.

În acest caz, Scrum și XP folosesc metoda „vremii de ieri”. Echipa spune: „În ultimul timp am făcut 4-6 funcții pe săptămână, ce 4-6 funcții vom face săptămâna viitoare?”

Sarcina proprietarului produsului este să aleagă cu înțelepciune ce povești de utilizator vor fi implementate în această săptămână.

Kanban recomandă să vă limitați la câteva sarcini - limita WIP. Să presupunem că echipa decide că 5 este un număr acceptabil de povești de utilizator la care pot lucra simultan, fără supraîncărcare, fără să sară de la una la alta.

Ambele abordări funcționează bine și ambele creează o coadă de sarcini, care în Scrum se numește Backlog sau o listă prioritizată de sarcini.

Această coadă trebuie gestionată, de asemenea, dacă părțile interesate solicită 10 povești pe săptămână, iar echipa oferă 4-6 povești, atunci această coadă va deveni din ce în ce mai mare. Și în curând Backlog-ul tău va fi programat cu șase luni în avans. Adică, o poveste va aștepta 6 luni pentru lansare.

Există o singură modalitate de a vă menține lista de sarcini sub control - cuvântul „nu”

Acesta este cel mai important cuvânt pentru un proprietar de produs. Trebuie să o exerseze în fiecare zi în fața oglinzii.

A spune „da” este ușor. Dar sarcina mai importantă este decide ce sa nu faciși să poarte responsabilitatea pentru asta. Proprietarul produsului determină, de asemenea, succesiunea a ceea ce facem acum și ce mai târziu. Aceasta este o muncă complexă și ar trebui făcută împreună cu echipa de dezvoltare și cel puțin o parte interesată.

Pentru a stabili prioritățile corect, proprietarul produsului trebuie să înțeleagă valoarea fiecărei povești și scopul acesteia.

Luarea deciziilor

Unele povești sunt absolut necesare, iar unele sunt doar caracteristici bonus. Unele povești vor dura câteva ore pentru a se dezvolta, altele vor dura câteva luni.

Care este relația dintre dimensiunea poveștii și valoare? În nici un caz. Mai mult nu înseamnă mai bine. Valoarea și complexitatea unei sarcini este ceea ce îl ajută pe Pat să prioritizeze.

Cum determină un proprietar de produs valoarea și scopul unei povești? În nici un caz. Este un joc de ghicituri. Și este mai bine ca toată lumea să participe la el. Pat comunică în mod constant cu părțile interesate pentru a cunoaște valoarea fiecărei povești, comunică cu echipa de dezvoltare pentru a cunoaște domeniul de activitate, dar toate acestea sunt presupuneri aproximative, fără numere exacte. Intotdeauna vor exista greseli la inceput si asta e normal. Comunicarea este mult mai valoroasă decât numerele ultra-precise.

De fiecare dată când dezvoltatorii lansează ceva nou, aflăm mai multe informații și putem naviga mai bine.

Numai prioritizarea nu este suficientă. Pentru a lansa povestiri rapid și des, trebuie să le împărțiți în bucăți care pot fi realizate în câteva zile. Vrem povești mici și clare la începutul pâlniei și cele mari și vagi la sfârșit. Făcând această defalcare la timp, putem profita de ultimele noastre descoperiri despre produs și nevoile utilizatorilor. Toate acestea se numesc curățarea Backlog-ului.

Pat găzduiește o întâlnire de curățare a Backlogului în fiecare miercuri, între orele 11:00 și 12:00. De obicei, reunește întreaga echipă și, uneori, mai multe părți interesate. Conținutul întâlnirilor variază. Concentrați-vă pe evaluare, pe defalcarea poveștii, pe criteriile de acceptare.

Proprietarul unui produs IT trebuie să comunice constant cu toată lumea

Proprietarii experimentați de produse identifică două componente ale succesului: pasiunea pentru muncă și comunicare. Ce probleme rezolvă proprietarul produsului împreună cu echipa?

Echilibrarea complexității dezvoltării și valoarea poveștii utilizatorului

Într-un stadiu incipient, bilanţul este ameninţat de incertitudine şi mai multe riscuri simultan.

Riscuri

Risc de afaceri: „Facem ceea ce trebuie?”

Risc social: „Putem face ceea ce trebuie să facem?”

Risc tehnic: „Va funcționa proiectul pe această platformă?”

Riscuri legate de cost și timpul de implementare: „Vom reuși la timp și vor fi suficienți bani?”

Cunoașterea poate fi considerată ca opusul riscului. Când incertitudinea este mare, ne concentrăm pe dobândirea de cunoștințe - prototipuri de interfață, experimente tehnice,

Schimb între valorile cunoștințelor și valorile clienților

Din punctul de vedere al clientului, curba arată astfel:

Din perspectiva valorii clientului, curba arată astfel. Pe măsură ce incertitudinile sunt reduse, ne putem concentra pe valoarea clientului. Știm ce și cum să facem. Tot ce rămâne este să o faci. După ce am implementat poveștile principale, vom crea funcții bonus sau vom lansa un nou proiect.

Compartimentul dintre gândirea pe termen scurt și pe termen lung

Ce să implementezi mai întâi? Remediați urgent erorile sau începeți să dezvoltați o funcție uimitoare care va uimi utilizatorii. Sau faceți o actualizare complexă a platformei care va accelera munca în viitor. Există o nevoie constantă de a găsi un echilibru între munca reactivă și cea proactivă.

Faceți lucrurile corect, faceți lucrurile în mod corect sau faceți lucrurile repede?

Ideal, toate trei în același timp, dar în realitate trebuie să alegi.

Să zicem că suntem aici. Încercăm să creăm produsul perfect cu ajutorul arhitecturii perfecte. Dacă petrecem mult timp, este posibil să pierdem fereastra de marketing și să ajungem cu probleme cu banii.

Realizam un prototip rapid al produsului. Acest lucru nu este rău pe termen scurt. Pe termen lung, avem risc tehnic. Și viteza de dezvoltare va scădea la zero.

Suntem aici, creând un templu frumos în timp record. Dar utilizatorul nu avea nevoie de un templu, avea nevoie de o furgonetă.

Există o tensiune sănătoasă între rolurile din Scrum

Product Owner se concentrează pe construirea lucrurilor potrivite. Echipa se concentrează pe construirea corectă a lucrurilor. Scrum Master sau Agile Coach se concentrează pe scurtarea ciclului feedback.

De asemenea, merită subliniată importanța vitezei, deoarece o buclă scurtă de feedback accelerează învățarea. Acest lucru ne permite să învățăm rapid ce lucruri sunt corecte și cum să le construim corect.

Compartiment între dezvoltarea unui produs nou și îmbunătățirea unuia vechi

Un produs nu poate fi niciodată complet finisat pentru că are nevoie constant de schimbări. Când o echipă începe să lucreze la un produs nou, ce se întâmplă cu cel vechi? Transferul unui produs de la o echipă la alta este foarte costisitor și riscant. De obicei, echipa menține un produs vechi în timp ce dezvoltă unul nou. Prin urmare, mai degrabă, conceptul de „backlog” se referă nu la produs, ci la echipă. Un backlog este o listă de lucruri pe care proprietarul produsului le dorește de la echipă. Și un set de povești pentru diferite produse. Proprietarul produsului trebuie să selecteze în mod constant pe cele relevante pentru implementare.

Program de distrugere a poveștii

Din când în când, părțile interesate îl vor întreba pe Pat: „Când va fi lansată funcția mea?” sau „Câte funcții vor fi lansate până la Crăciun?” Proprietarul produsului trebuie să fie capabil să gestioneze așteptările utilizatorilor. Și gestionați așteptările în mod realist.

Două tendințe - optimiste și pesimiste (le poți vedea cu ochii). Distanța dintre tendințe arată cât de instabilă este viteza echipei. În timp, aceste tendințe se vor stabiliza, iar conul de incertitudine va scădea.

Să presupunem că o parte interesată întreabă când va fi realizată această caracteristică?

Aceasta este o întrebare cu un conținut fix și o perioadă nedeterminată. Pat folosește două linii de tendință pentru a răspunde. Răspunsul este în aprilie sau mai.

O parte interesată îl întreabă pe Pat: „Cât se va face până la Crăciun?” Aceasta este o întrebare cu un termen limită fix și un conținut nedeterminat. Liniile de tendință taie la scară verticală segmentul probabil a ceea ce vor avea timp să implementeze.

O parte interesată întreabă: „Vom avea timp să terminăm aceste funcții până la Crăciun?” Aceasta este o întrebare cu un interval de timp fix și un conținut fix. Concentrându-se pe tendințe, Pat răspunde: „Nu”. Adăugând: „Vom avea timp să facem atât de multe până la Crăciun, dar atât timp ne va dura să finalizăm toată această muncă complet.”

De obicei, este mai bine să reduceți conținutul unui proiect decât să măriți timpul. Dacă reducem conținutul, vom avea ocazia să amânăm termenul limită. S-ar putea să lansăm câteva aici și restul mai târziu.

Proprietarul de produs face calcule săptămânal și folosește doar date empirice, mai degrabă decât iluzii. Vorbește sincer despre incertitudine. Echipa menține ritmul de lucru, iar Pat nu-i presează să accelereze.

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 flexibile de management de proiect. 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, așa că și aici utilizarea cuvântului „management” a devenit 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 diferite niveluri, de la manageri de nivel inferior la directori corporativi și oficiali guvernamentali, se luptă cu acest lucru 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 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ă procese separate pot rula paralel și independent unul de celălalt. 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 ar trebui să fie și un vânzător, iar un designer ar trebui 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 luni.

Sistemul de operare al uzinei Toyota a devenit deja un model de management clasic și de succes. Fiecare angajat al întreprinderii a avut posibilitatea de a opri transportorul în orice moment pentru a elimina un defect, o defecțiune sau a-și realiza singur. propunere de raționalizare. Filosofia Agile se bazează pe această abordare. Inițial, metodologia Agile în urmă cu aproximativ 10-15 ani era o metodă de dezvoltare software în echipe mici. În acest moment, metodologia Agile este o nouă cultură pentru gestionarea întreprinderilor mari. Astăzi, orice manager progresist știe ce este Agile.

Produsele și serviciile sunt create, de regulă, după o singură schemă clasică. Acest lucru se aplică în special industriei IT. Această schemă se numește cascadă sau metodologie de dezvoltare iterativă și în engleză– dezvoltarea cascadei („cascada”). Din ce motiv schema are acest nume? Chestia este că, dacă ați aprobat deja un plan pentru un produs software, nu îl puteți suspenda sau face ajustări înainte de implementare. Există un principiu complet diferit Metodologie agilă. Cascada este un concept care nu i se aplică. Aceasta este o abordare nouă din punct de vedere calitativ pentru crearea de produse. Baza metodologiei este o idee simplă - fiecare participant are posibilitatea de a face propuneri utile pentru optimizarea procesului, oprirea transportorului pentru a regândi sarcinile și cauza comună.

Metodologia Agile are un cadru cu o serie de caracteristici. Printre acestea:

• Răspuns rapid la schimbări.
• Organizație independentă procesul de productie.
• Previzibilitate.
• Disponibilitate de feedback continuu și constant.
• Delimitarea riscului.

În multe întreprinderi de dezvoltare de produse, specialiștii care rezolvă probleme importante pentru producție sunt repartizați în diferite departamente, adesea în conflict între ei. Acest lucru este valabil mai ales pentru angajații departamentului de operațiuni, dezvoltatori și testeri. Dacă produsele nu pot fi vândute în mod corespunzător și nu se pot genera venituri din acestea, părțile în conflict se învinovățesc reciproc. În același timp, toată lumea este de obicei de vină în astfel de situații.

Metodologia agilă este o abordare care implică prezența tuturor celor care se dezvoltă produs software. În același timp, fiecare specialist își face treaba. Metodologia agilă face posibil să vedem că toți participanții la proces sunt uniți de un singur obiectiv - crearea de produse de înaltă calitate pentru clienții lor.

Când se aplică metodologia Agile, întreaga cultură de afaceri a companiei se schimbă. Programele de MBA conțin un curs cu drepturi depline despre structura organizatorică a unei întreprinderi, atunci când studiezi, care poți întâlni termenul de „echilibru”, când în companiile nou-înființate și start-up-urile toți angajații și participanții rezolvă probleme comune. Practica arată că în astfel de întreprinderi echipele sunt mai unite și lucrează cu eficiență și eficacitate ridicate. Când vine vorba de aducerea de idei noi pe piață și creșterea eficienței, metodologia Agile este instrumentul optim.

Desigur, unele companii nu au nevoie de metodologia Agile. Vorbim, de exemplu, despre departamentele guvernamentale, întrucât la baza activităților lor se află normele legislative. Interacțiunea cu statul este imposibilă dacă regulile jocului se schimbă în mod regulat.

Adică, infrastructura organizațională poate fi prezentată în două versiuni, radical diferite una de cealaltă. Prima este o firmă birocratică strictă care respectă o serie de formalități. Această opțiune are dreptul de a exista și funcționează excelent în anumite condiții. Al doilea tip sunt startup-urile în stadiu incipient care unesc oameni cu același punct de vedere și un scop comun, care creează ceva fundamental nou. Metodologia agilă este cu siguranță mai aproape de echipa emoțională care lucrează pentru a produce un produs de calitate. Dacă apar probleme în orice etapă, toți specialiștii întreprinderii sau participanții la startup le rezolvă în cadrul metodologiei Agile.

Principiile de bază ale metodologiei Agile

Există un manifest Agile, care vorbește despre principiile de bază ale metodologiei:

1. Cel mai important lucru este să livrați un produs valoros în mod regulat și în avans, satisfacând astfel nevoile clientului. În conformitate cu acest principiu al metodologiei Agile, creatorii de produse sunt obligați nu numai să implementeze cerințele prezentate în documentele de proiectare, ci și să informeze consumatorul cât mai curând posibil despre ce fel de produs va fi acesta, cu ce caracteristici și caracteristici. In cazul in care produsul nu satisface clientul, este urgent necesara corectarea lui tinand cont de comentarii. Deoarece la introducerea unui produs nou în mediul de piață, există un risc mare de a face greșeli, este logic să folosiți cerințe tehnice pentru a crea un produs minim viabil (MVP), a cărui sarcină principală este de a verifica cât de multe calități-cheie sunt solicitate în rândul cumpărătorilor și de a evalua nivelul cererii.
2. Cerințele pot fi modificate, iar acest lucru va fi perceput pozitiv dacă vorbim de îmbunătățirea calităților competitive ale produsului. Ele sunt de obicei modificate la sfârșitul etapei finale de dezvoltare. Acest principiu al metodologiei Agile este foarte important astăzi, deoarece produsele din zonele high-tech în cât mai repede posibil devine învechit și face loc unuia nou. Puteți formula o serie de cerințe pentru un produs deja la sfârșitul creării sale. Acest lucru este cauzat de obicei de schimbările de pe piață sau ale concurenților. Să observăm că implementarea acestui principiu este imposibilă dacă vorbim despre un model de management în cascadă, sau este real, dar va costa sponsorului o sumă ordonată. Dar cu cât se îmbină mai multe tehnologii, cu atât va deveni mai important să pregătim următoarea versiune a produsului pentru a rămâne înaintea concurenților.
3. Echipa și clientul trebuie să interacționeze continuu în toate etapele creării produsului. Această regulă este aproximativ aceeași natură cu dorințele clientului. Acesta este cel mai important lucru. Dacă nu există o interacțiune constantă, este dificil să-ți atingi obiectivele.
4. Metodologia Agile prevede că proiectele ar trebui implementate exclusiv de către profesioniști motivați. Aveți grijă să creați condițiile adecvate și aveți încredere în specialiști. În acest caz, probabilitatea implementării de înaltă calitate a proiectului este foarte mare. Știința modernă sugerează că munca intelectuală este dificil de stimulat cu stimulente financiare. Prin urmare, ar trebui să cooperați numai cu acei specialiști pentru care principala motivație este proiectul în sine. Tot ce au nevoie este să poată lucra în condiții acceptabile și să câștige încrederea clientului.
5. Cel mai bun mod comunicatii - contact personal. Este de dorit ca toate persoanele implicate în proiect să fie situate pe un teritoriu comun. Să fie o singură clădire. În mod ideal, clientul însuși ar trebui să fie acolo.
6. Proiectul progresează dacă produsul funcționează. Clientul este interesat produse finite cu anumite caracteristici. O altă etapă finalizată cu succes a procesului nu înseamnă nimic pentru el. Clientul trebuie să vadă că produsul se dezvoltă și, cel mai important, funcționează și îndeplinește cerințele declarate. Dacă forma și conținutul acestuia sunt apropiate de modelul dorit, înseamnă că dezvoltatorii acționează eficient.
7. Sponsorii, clienții și dezvoltatorii trebuie să fie preocupați de asigurarea unui ritm constant de activitate. Dacă toți participanții la proces funcționează într-un ritm constant, ei încetează să-și mai facă griji cu privire la probabilitatea unei urgențe sau a termenelor nerespectate.
8. De asemenea, ar trebui să se acorde atenție excelenței tehnice și calității designului. Metodologia Agile prevede că dezvoltarea proiectelor trebuie să fie flexibilă, fără a compromite calitatea produsului sau a simplifica caracteristicile acestuia. Rețineți că se recurge adesea la aceasta pentru a accelera procesul de creare a unui proiect și pentru a-l optimiza.
9. Nu uita de principiul simplității. Folosind-o, reduceți la minimum probabilitatea de a efectua acțiuni inutile. Ideea nu este de a simplifica caracteristicile produsului, ci de a scăpa de operațiunile inutile și de a nu include în proiect ceva inutil pentru utilizarea prevăzută.
10. Echipele auto-organizate generează întotdeauna cele mai bune idei planuri arhitecturale, tehnice și de altă natură. Autorii Manifestului Agile sunt siguri de acest lucru. Prin urmare, toți membrii echipei trebuie să dezvolte cerințe și să ia decizii împreună. Dacă membrii echipei au interese comune și obiective comune, auto-organizarea devine mai eficientă.
11. Condițiile externe sunt în continuă schimbare. În acest sens, ar trebui să se analizeze și să se adapteze în mod constant la situație și să caute metode de îmbunătățire a eficienței activităților. Metodologia Agile se concentrează în mod special pe flexibilitatea dezvoltatorului. Pentru asta trebuie să te străduiești.

Opinia expertului

Perspective pentru metodologia Agile în Rusia

Andrei Koceșkov,

Analist șef al editurii OJSC Prosveshcheniye

Metodologia agilă are o serie de avantaje, dintre care principalul este flexibilitatea și capacitatea de adaptare, adaptare la orice situație și proces organizatoric. Metodologia agilă este cea mai bună opțiune pentru proiectele al căror final este „deschis”. Aceasta ar putea fi crearea unui joc pe computer, a unui sistem de operare sau a unui serviciu de internet. Cu toate acestea, flexibilitatea poate duce în cele din urmă la pierderea concentrării și la reducerea predictibilității.

Este extrem de important să distingem greșelile atunci când utilizați o abordare agilă de deficiențele metodologiei Agile. Va dura ceva timp până când beneficiile metodologiei vor fi realizate. Este necesară adaptarea abordării la situația actuală dintr-o anumită afacere, iar în această perioadă este posibil să se facă multe greșeli. Dar adevărul rămâne: metodologia agilă devine una dintre cele mai populare paradigme atât în ​​Rusia, cât și în întreaga lume.

Metodologii flexibile: Agile, Lean, Scrum și altele

Manifestul Agile definește principii specifice. Pe baza acestora s-a format o metodologie de dezvoltare flexibilă numită Agile.

• Modelare agilă (AM). Aici se aplică procedurile de modelare (inclusiv verificarea cu codul modelului) și documentația în timpul creării software-ului. Se acordă mai puțină atenție procedurilor de proiectare și construire a diagramelor în UML. Nu se menționează domenii precum dezvoltarea, testarea, managementul proiectelor, implementarea și întreținerea.
• Agile Unified Process (AUP) este o versiune unificată a metodologiei RUP (IBM Rational Unified Process) creată de Scott Ambler. AUP definește un model de dezvoltare software pentru aplicații de afaceri.
• Agile Data Method (ADM) este o metodologie iterativă pentru dezvoltarea agilă de software într-un complex care pune accent pe dezvoltarea de soluții și cerințe. Diferite echipe interfuncționale colaborează între ele.
• Metoda de dezvoltare a sistemelor dinamice (DSDM) este o metodă incrementală și iterativă bazată pe Dezvoltarea rapidă a aplicațiilor (RAD). Accentul se pune pe maximizarea implicării consumatorului final în crearea produselor.
• Proces unificat esențial (EssUP). Autorul abordării este Ivar Jacobson. Abordarea este dotată cu metode de creare iterativă de software. Accentul se pune pe arhitectura produsului și practicile de echipă împrumutate de la RUP, CMMI și Agile Development. Esența ideii este de a folosi doar acele metode și tehnici care sunt utilizate într-un anumit caz. Alegerea lor este baza pentru determinarea procesului țintă. Această abordare diferă de RUP prin metode și practici interconectate. Există, de asemenea, flexibilitate și capacitatea de a izola elementele necesare de tot ceea ce este disponibil.
• Programare extremă (XP) sau programare extremă. Esența metodei este de a folosi cele mai bune tehnici deja disponibile în domeniul creării de software și de a le îmbunătăți. Această abordare și practica obișnuită diferă unele de altele, în special prin faptul că, în ultimul caz, programatorul efectuează o verificare secvențială a codului scris de colegul său. Programarea extremă presupune testarea paralelă, care contribuie la lansarea mai rapidă a produsului, dar în același timp crește riscurile.
• Dezvoltare bazată pe caracteristici (FDD). În cadrul utilizării metodei, există o interdicție principală, și anume ca implementarea fiecărei funcții să fie efectuată în termen de două săptămâni și nu mai mult. În mod ideal, dezvoltarea sa se face dintr-o singură mișcare. Dacă acest lucru nu este posibil, funcția este împărțită în mai multe și implementată fără probleme.
• Getting Real (GR) - atunci când se utilizează metoda, nu recurg la procedurile de specificații funcționale utilizate pentru aplicațiile web. Dezvoltarea începe cu reversul, adică mai întâi se gândesc la design și interfață, iar apoi la conținutul funcțional.
• OpenUP (OUP) - dezvoltarea abordării se bazează pe RUP. Metoda definește o metodă iterativă-incrementală de a crea software. În cadrul abordării despre care se spune ciclu de viață dezvoltare (faze de lansare, rafinare, dezvoltare și transfer către client). Metoda este implementată în mai multe etape, verificând anumite puncte de control, ceea ce ajută la creșterea eficienței controlului și monitorizării implementării proiectului. Toate deciziile referitoare la proiect sunt luate la timp.
• Dezvoltare software Lean. Baza abordării este conceptul de lean management al unei companii de producție (lean production, lean manufacturing).
• Scrum este una dintre cele mai populare metode pentru dezvoltarea agilă de software și definește reguli pentru gestionarea procesului de producție folosind metode binecunoscute. În acest caz, se pune accent pe implicarea clientului în dezvoltare (când este finalizată etapa următoare, este posibilă modificarea sau clarificarea cerințelor pentru produsul care se creează). Acest lucru vă permite să identificați deficiențele și să ajustați produsul.

Metodologia Agile Scrum este una dintre tehnologiile populare

Aproape cea mai comună metodologie Agile este Scrum. Numele vine de la rugby. În prezent, acesta este numele celei mai structurate metodologii de dezvoltare flexibilă, Agile. „Scrum” în terenul de sport este o acțiune intensivă de echipă care vizează atingerea scopului - obținerea mingii pentru atacul ulterior al inamicului.

Perioada Scrum este scurtă. Cei mai buni sportivi cu o pregătire excelentă iau parte la această fază a rugbyului, deoarece este destul de traumatizantă. Dacă nu există jucători antrenați și puternici, Scrum pur și simplu nu se realizează. Metodologia Scrum devine din ce în ce mai răspândită în Rusia. Să ne uităm la asta mai detaliat.

Baza Scrum este sprinturile. Acesta este numele pentru acțiunile fixe pe termen scurt pentru a crea și a oferi consumatorului un produs funcțional cu noi caracteristici. Capacitățile sale le depășesc în același timp pe cele care au fost anterior. Perioada de sprint este fixă, iar de ea depinde predictibilitatea și flexibilitatea procesului de creație. Dacă intervalul de timp este scurt, indicațiile pentru flexibilitate și predictibilitate devin mai mari, dar costul relativ al fiecărei iterații, precum și timpul petrecut organizându-se și întâlnirii cu clienții și membrii echipei, cresc și ele.

Un element important al metodologiei este stocul de produse. Aceasta este o listă de cerințe pentru rezultatul final. Cerințele de aici sunt clar structurate pe nivel de importanță. Din listă sunt preluate sarcinile pentru sprinturile ulterioare. Puteți face ajustări și completări la listă pe măsură ce caracteristicile sunt clarificate și produsele sunt vândute.

Există o etapă de planificare în care sunt determinate noi calități funcționale ale produsului creat pentru următorul sprint. După rezolvarea problemei, este creat un Sprint Backlog. Acesta rămâne neschimbat pe toată durata sa.

Metodologia definește, de asemenea, roluri structurate în proiect:

• Scrum Master este intermediarul între echipă și client.
• Product Owner reprezintă clientul, formează, prioritizează Product Backlog și acceptă rezultatele intermediare ale lucrării.
• Echipa – o echipă de proiect în care nu există roluri separate. Este un sistem de auto-organizare care include profesioniști multifuncționali, motivați.

Metodologia oferă finanțatorilor o serie de avantaje, și anume:

• oferă o oportunitate de a economisi bani prin nelucrarea la documentele de proiect pentru o perioadă lungă de timp;
• vă permite să controlați pe deplin bugetul proiectului;
• face posibilă efectuarea de ajustări fără pierderi financiare semnificative pentru întreprindere;
• vă permite să lansați produse din timp și să primiți primul venit din acesta.

Problema principală în acest caz este întrebarea înregistrare legală acest tip de activitate și interacțiune cu echipa externă de dezvoltare.

De ce aveți nevoie de metodologie de management Agile?

• Sistemul vă permite să vă simțiți bine în timpul unei crize și în situații incerte, să obțineți venituri, să vă protejați afacerea și să utilizați în mod competent resursele și oportunitățile disponibile.
• Metodologiile agile sunt preferate atât de marile întreprinderi implicate în implementarea unor metode flexibile de management, cât și firme mici. Pentru cea mai recentă metodologie Agile – cea mai buna varianta. Aici vorbim de unități de catering. clinici dentare si birouri, showroom-uri auto; În plus, metodologia Agile vă permite să „ajustați” procesele de afaceri în domenii precum organizarea activitatea economică externă, construirea sistemelor de vânzări și managementul crizelor.
• Metodologia agilă este utilizată în management, marketing, industria financiară și managementul personalului. Datorită acesteia, puteți obține implementarea proiectelor ultra-rapidă și rezultate excelente.
• Metodologia agilă se referă în primul rând la gândirea flexibilă și abia apoi la instrumente. Pentru a-l folosi cu succes, trebuie să intri anumite modificariîn mentalitatea și cultura de a lucra cu proiecte la întreprindere.
• Există multe metode în Agile. Cele mai populare astăzi sunt Scrum și Kanban.
• Metodologia agilă vă ajută să vă duceți afacerea la următorul nivel, ținând cont de capacitățile existente, resursele și abilitățile practice ale angajaților.
• Metodologia agilă este potrivită pentru orice întreprindere axată pe generarea de venituri mai mari și creșterea influenței în mediul de piață.
• Metodologia agilă asigură căutarea și introducerea de noi tehnologii asociate cu descoperiri, dezvoltarea de interne activitate antreprenorială, creativitate de abordare și gândire în organizațiile mari.

Toate cele de mai sus sunt doar începutul. Mulți experți în afaceri și directori mari intreprinderi Suntem încrezători: metodologia agilă este viitorul industriei economice moderne.

Opinia expertului

Implementarea metodologiei Agile pentru îmbunătățirea eficienței personalului

Maria Onuchina,

Director al Departamentului de management al activelor la Becar Asset Management Group, Moscova

Ne-am modificat spațiul de birouri pentru a trece la managementul Agile:

Etapa 1.Organizarea locurilor de munca.

Pe parcursul unei luni, am studiat locurile de muncă ale personalului, am identificat departamente în care este necesară liniștea completă pentru a desfășura o muncă eficientă (aceasta este, de exemplu, contabilitate) și am acordat atenție departamentelor care angajează specialiști care sunt permanent plecați și nu mai cheltuiesc. mai mult de 3 ore pe zi la birou. Am primit un program care arată numărul de angajați și specificul responsabilităților lor de muncă. Ținând cont de informațiile primite, am început reconstrucția biroului.

Pentru angajații ale căror activități necesită prezență constantă la locul de muncă au fost dotate locuri permanente. Personalul mobil a fost dotat cu spațiu temporar în zona open-space. Poți să vii acolo, să iei locul tău preferat și să pornești acces la distanță. Am acordat atenție și zonelor informale: camere pentru relaxare, negocieri și o cafenea de lucru.

Am încercat să organizăm spațiul din birou astfel încât angajații să aibă posibilitatea de a schimba locația în orice moment:

• dacă este necesar, fii singur;
• alăturați-vă în mini-grupuri;
• ține o întâlnire între departamente din orice compoziție.

Numărul de astfel de zone din cadrul proiectului a fost influențat de ce parte din afacere îi aparține procesul.

Etapa 2.Adaptarea lucrătorilor.

În continuare, am oferit specialiștilor asistență în adaptare. Mulți oameni se tem de schimbările pe care le presupune metodologia Agile, chiar dacă sunt în bine. Pe măsură ce au trecut câteva săptămâni, a devenit clar că angajaților le-a plăcut totul și și-au părăsit birourile. În această etapă, merită să faceți personalului să înțeleagă că, dacă nu există schimbări în procesele de afaceri, întreprinderea riscă să părăsească spațiul pieței.

Etapa 3.Introducerea unor soluții neobișnuite.

Am introdus o serie de caracteristici: am organizat un cinematograf în zona comună, unde sunt prezentate prezentări în timpul lucrului și filme seara, precum și un perete cu poza unui copac pe care sunt scrise valorile companiei.

Noul birou este neobișnuit, dar confortabil. L-am dotat cu mobilier pe mai multe niveluri: taburete de bar, scaune beanbag, canapele din piele si stofa, mese din sticla. Managementul agil este caracterizat de astfel de detalii precum:

• soluții moderne de inginerie;
• infrastructura IT;
• mobilier confortabil;
• suprafețe pentru înregistrarea ideilor în timpul negocierilor etc.

Lucrările de proiectare și renovare au durat două luni. În această perioadă au făcut performanțe specialiștii companiei responsabilități de serviciu pe teritoriul vechiului birou. Costul renovării a fost aproximativ același cu costul unei renovări tipice. Pretul a fost afectat doar de mobilier si tehnologie de ultima ora.

Rezultat. Câteva luni de ședere în biroul îmbunătățit au arătat că munca a devenit o echipă, iar comunicarea dintre specialiști din diferite departamente s-a îmbunătățit. A reușit să economisească la chirie. În medie, sunt 12-40 m2 de persoană în biroul unei organizații mari. Anterior, aveam 10 m2, iar această cifră s-a redus la 6 m2, repartizând efectiv locurile de muncă. Perioada de rambursare a proiectului a fost de 1,5 ani.

Am dotat toate sălile de întâlnire cu Wi-Fi și apeluri de conferință. Acest lucru a eliminat necesitatea de a închiria săli de conferințe pentru a organiza întâlniri externe. Condițiile confortabile atrag angajații, astfel încât aceștia petrec mai mult timp la serviciu și își îndeplinesc sarcinile mai eficient.

Ce probleme pot apărea la utilizarea metodologiei Agile?

Problema 1.Obișnuirea cu rolul.

Specialisti in echipa de proiect La început, cu puțină reticență, trec la efectuarea unor lucrări neobișnuite pentru ei, realizând chiar că așa va fi mai bine. De exemplu, analiștilor adesea nu le place să testeze un sistem, deși cine, dacă nu ei, știe totul despre caracteristicile funcționării acestuia? Aceste tipuri de probleme sunt ușor de identificat într-o echipă și, de obicei, nu sunt dificil de rezolvat.

Problema 2.Obiceiul documentării.

În primul rând, dezvoltatorii așteaptă cerințe de la client - documentația de proiect care explică toate problemele. Această metodă de transmitere a informațiilor nu este cea mai eficientă și, prin urmare, dezvoltatorii se obișnuiesc mai bine să comunice direct cu clientul. În timp, după comunicarea cu clientul, dezvoltatorilor le va deveni mai ușor să se aprofundeze în complexitatea afacerii și să rezolve probleme evidente. Chiar dacă greșește, clientul o va observa rapid la sfârșitul iterației, iar defectul poate fi corectat la timp.

Problema 3.Echipa noua.

Managerul de proiect riscă să întâmpine dificultăți în lucrul cu o nouă echipă. Participanții nu pot încă comunica corect între ei, nu există contact între ei, le este jenă să ceară ajutor și le este frică să critice pe cineva pentru o decizie greșită. Responsabilitatea revine managerului de proiect. El este obligat să ajute membrii echipei să stabilească relații informale, a căror prezență este implicată de metodologia Agile. Poate fi util să organizați o excursie comună la un restaurant, un eveniment de team building sau o competiție sportivă.

Problema 4.Probleme de comunicare.

Sarcina managerului de proiect este stadiu inițial– organizarea de întâlniri cu membrii echipei pentru realizarea unor activități productive și eficiente.

Problema 5.Presiunea termenului limită.

Adesea, clienții pun presiune asupra dezvoltatorilor și îi grăbesc. Clienții doresc să primească produsul dorit în termen minim. Echipa trebuie să implementeze cu exactitate cerințele, fără a sacrifica calitatea. În caz contrar, pe termen lung, viteza de creare va scădea, deoarece costul modificărilor va crește din cauza calității proaste. În plus, calitatea insuficientă are un impact negativ asupra motivației dezvoltatorilor. Managerul de proiect ar trebui să reamintească în mod regulat echipei de proiect să mențină calitatea înaltă.

Problema 6.Creativitate.

Sarcinile proiectului pot fi atât interesante, cât și nu atât de interesante. Dezvoltatorii au adesea plăcere să ia decizii care dăunează proiectului, dar sunt interesante din punct de vedere tehnic. Aici merită să ne amintim principiile KISS (păstrați-l simplu, stupid) și YAGNI (nu veți avea nevoie). Fie ca principala caracteristică a soluțiilor de proiectare să fie simplitatea. Nu ar trebui să faceți nimic care nu este deosebit de necesar în acest moment.

Ce ar trebui să faci pentru a-ți ajuta echipa să ia decizii simple? Uneori este util să le permiteți specialiștilor să facă o greșeală unică, pentru ca apoi să o analizeze cu atenție și să lase dezvoltatorii să înțeleagă ce ar trebui și ce nu trebuie făcut. Aproape orice proiect este într-un fel sau altul completat de sarcini de cercetare (noi tehnologii și domenii de cunoaștere inginerești). Aici trebuie să încerci și să experimentezi.

Problema 7.Estimarea timpului.

Atunci când determină timpul pentru rezolvarea unei probleme, specialiștii iau în considerare doar scrierea codului. În același timp, sarcina include și, cel puțin, crearea unui design și testare. La începutul proiectului, dezvoltatorii cred că vor finaliza proiectul mai devreme decât este posibil. La sfârșitul procesului, experții notează greșelile și trag concluzii pentru viitor. Timpul trece, iar echipa învață să evalueze corect situația. De obicei, după 3-4 iterații, nivelul de precizie și productivitate se îmbunătățește.

Problema 8.Problema cu managementul.

Conducerea se așteaptă ca anumite funcționalități să fie disponibile până la ora specificată. Dar metodologia Agile nu garantează implementarea 100% a planurilor. Este logic să ne așteptăm ca sarcinile prioritare să fie rezolvate. Este util să fiți de acord cu managementul asupra planurilor la nivel de lansare. Nivelul înalt al planului de lansare permite managerului să varieze domeniul de dezvoltare chiar și a caracteristicilor individuale ale sistemului într-un interval de timp destul de mare. De exemplu, sarcina de a crea un subsistem de căutare poate implica luarea în considerare a morfologiei. În această etapă sunt posibile și economii.

Problema 9.Probleme de comportament necoordonat.

În procesul de implementare a metodologiei Agile nu poate fi exclusă următoarea situație. Are loc un miting și deodată unul dintre participanți se ridică și începe să vorbească despre ideile lui. El nu acceptă obiecții, iar după un timp vorbește despre decizia luată, propunând să se înceapă examinarea celei de-a doua chestiuni. Desigur, echipa nu a luat decizia. De fapt, el a făcut-o acest participant, luându-i acest drept.

Există mai multe opțiuni aici. Este posibil ca persoana să fie pur și simplu într-o stare prea entuziasmată, care ar trebui să treacă în curând. Dar sunt adesea cei care pur și simplu nu pot face parte din echipă din cauza caracterului lor.

Metodologie agilă fără erori

Eroare 1.Managerii de top nu înțeleg ce este metodologia Agile și în ce scop ar trebui implementată.

Avem nevoie de o înțelegere exactă a rezultatului care ne interesează, ce termene limită și buget avem. Obiectivele vagi și formulările frumoase, de exemplu, „Deveniți numărul unu în domeniul dvs.” sau „Începeți să lucrați mai eficient” nu sunt potrivite. Lasă sarcinile să fie exprimate în cifre. De exemplu: „Realizați o cifră de afaceri de 3 miliarde de dolari în 2018”, „Reduceți timpul de creare a unui produs la 3 luni”, etc.

Eroare 2.Diagnostic incorect.

Adesea, atunci când introduce metodologia Agile, o companie dorește să rezolve o serie de probleme specifice, cum ar fi costurile umflate sau calitatea proastă a mărfurilor. Dar trebuie să vă dați seama în detaliu unde sunt golurile. În caz contrar, managerul se va aștepta ca metodologia Agile să schimbe totul. Totuși, aici riscă doar să înrăutățească situația.

Eroare 3.Introducerea Agile doar într-o zonă separată a proceselor de afaceri.

Aceasta este o continuare logică a celei de-a doua erori descrise mai sus. Motivul presupunerii ei este același: lipsa de înțelegere a problemei și a locului în care se ascunde. Toate sectoarele întreprinderii trebuie să se schimbe: producție și marketing, contabilitate și vânzări. Altfel, nimic nu va funcționa. Dacă se introduc modificări doar în marketing și nu se obține efectul dorit, vă veți dezvolta o părere puternică că metodologia Agile este ineficientă.

Eroare 4.Înțelegerea importanței implicării tuturor angajaților companiei.

Trebuie să fii aliați cu colegii tăi. Dacă acest lucru nu se întâmplă, este mai bine să economisiți resurse, timp și să nu începeți nimic. Metodologia agilă presupune inițiativa, mobilizarea și responsabilitatea tuturor celor care participă la proces, cel puțin managerilor de întreprindere. Dacă acești oameni sunt lideri puternici și autoritari care sunt capabili să obțină o bună disciplină atunci când rezolvă probleme și introduc reguli noi în muncă, atunci totul va funcționa. Potrivit statisticilor, 85% dintre întreprinderi nu au manageri puternici, cu pregătire profesională suficientă.

Eroare 5.Iluzia că totul este posibil doar prin eforturi umane.

Desigur, competențele, motivația și nivelul profesional al personalului sunt importante în atingerea obiectivelor. Dar trebuie acordată atenție și dotării tehnice adecvate a companiei, software cu ajutorul căruia managementul și planificarea activităților devin mai eficiente. În acest sens, fie că vă place sau nu, va trebui să investiți în achiziționarea de mașini, echipamente și software.

Eroare 6.Reticența de a schimba personalul.

Aproape 90% din succes depinde de echipa întreprinderii. O atenție continuă trebuie acordată dezvoltării, formării și motivației adecvate a angajaților. Mulți specialiști nu sunt pregătiți să desfășoare activități folosind metodologia Agile, nu sunt interesați de noile cunoștințe și oportunități, sau de stăpânirea proceselor de afaceri; Aproximativ 25-30% din personalul întreprinderii nu vrea să dea tot ce e mai bun și se străduiește câștiguri mari. Este mai bine să le spuneți „la revedere” unor astfel de angajați. Legăturile slabe pot fi destul de dificil de identificat și, prin urmare, managerii de resurse umane nu se ocupă adesea de acest lucru.

Eroare 7.Pierderea interesului și a participării managerilor de top.

De obicei, este nevoie de 8-16 luni pentru a implementa un proiect. În 70% din situații, după trei luni interesul participanților scade. Drept urmare, membrii echipei pur și simplu nu doresc să facă parte din proiect. Dacă acesta este cazul, desigur, nu veți putea rezolva problema.

Metodologie agilă: exemple de aplicare nereușită

Metodologia Agile atrage mulți profesioniști și, până în prezent, o serie de companii de renume mondial au încercat să o implementeze. Dar aproape nimeni nu a reușit să obțină rezultatul dorit.

Exemplu: în 2015, tranzacționarea s-a desfășurat pe Bursa de Valori din New York, care a trebuit să fie oprită până la 4 ore. La început a fost explicat ca un atac cibernetic. Dar, după cum sa dovedit mai târziu, problema a fost o eroare în timpul următoarei actualizări. Desigur, 4 ore de oprire la World Trade Center au adus pierderi de miliarde.

Și acest exemplu nu este singurul. Este mai ușor pentru brokeri: au pierdut și apoi au câștigat de două ori mai mult. Lucrurile sunt mai complicate pentru companiile aeriene. Aproximativ aceeași situație s-a întâmplat cu transportatorul aerian Delta după o simplă actualizare de software. Sistemul de dispecerat a încetat să mai primească date, ceea ce a dus la anularea forțată a zborurilor. Compania nu numai că a suferit pierderi, ci și-a pierdut și reputația.

Cel mai notoriu eșec al utilizării metodologiei Agile este asociat cu lansarea sistemului de asigurări de sănătate Obama Care în Statele Unite. Sensul programului era următorul: anumite categorii de cetățeni americani au fost asigurate cu polițe de asigurare gratuite. Pentru a obține un astfel de drept, o persoană trebuia să completeze un formular de pe site și să aștepte o decizie din partea anumitor servicii. Desigur, milioane de oameni s-au grăbit să completeze formulare. Dar problema a fost că au putut să completeze formularul, dar nu să-l trimită, a existat un fel de defecțiune a serverului. Obama Care s-a încheiat la aproximativ 6 luni după ce a început. Pentru a îmbunătăți munca, părțile interesate au adus un specialist extern care a evaluat situația. Consultantul a parcurs un drum lung, pornind de la final - „producție”, a pus piesele împreună și a reușit să realizeze funcționarea corectă a sistemului.

Opinia expertului

Exemplu de implementare cu succes Omanagement gile

Serghei Bucik,

director general Grupul NPM, Novosibirsk

Compania, inclusiv toate diviziile, a trecut la lucrul conform metodologiei Agile pe parcursul a 1,5 ani. Anterior, departamentul HR era format din: un specialist în resurse umane, un manager de training și un recrutor. Conducerea departamentului, alegerea personal nou sau în timpul desfășurării instruirii, a completat cererile în un număr imens. Acum fiecare departament al întreprinderii are propriul său HR. În echipele de dezvoltare care lucrează conform metodologiei Scrum, acest loc este atribuit Scrum Master-ului. Produsele de aici sunt un serviciu de personal, iar membrii echipei sunt consumatori interni.

Noul stil de management bazat pe metodologia Agile a prins bine rădăcini în domeniul selecției angajaților. Clientul își poate planifica activitățile, ținând cont de ieșirea candidatului la ora exactă specificată. Pe parcursul a 9 sprinturi cu durata de 2 saptamani, am reusit sa reducem de 2 ori numarul posturilor vacante restante. Un post vacant simplu (de exemplu, un muncitor de turnătorie) este acum ocupat în 20 de zile, unul mediu (pentru un inginer de service) - 32 de zile și un specialist rar (un inginer de proces de turnare prin injecție de plastic) - în 51 de zile. După finalizarea primului sprint, a devenit clar pentru recrutori: pentru managementul departamentului, principalul lucru nu este viteza căutării, ci termenele-limită transparente pentru ocuparea posturilor vacante și perioada de timp pe care o pot petrece selectării unui angajat cu pregătire ulterioară. . În acest moment, managerul îi spune clientului despre momentul și stadiul căutării unui solicitant. Responsabilitățile recrutorilor includ, de asemenea, dezvoltarea competențelor tehnice necesare pentru a selecta în mod eficient locurile de muncă în producție, de exemplu, formarea în citirea planurilor.

Să dăm un exemplu: conducerea departamentului nu înțelege ce fel de angajat are nevoie, sau această problemă este rezolvată de specialiști din mai multe departamente deodată. Să presupunem că o companie are nevoie de un depozitar care va lucra într-un depozit de scule. În acest caz, postul vacant este rezervat de către departamentul de producție și serviciul de logistică. Responsabilitățile recrutorului includ luarea în considerare a cerințelor acestor departamente pentru solicitant. Producătorii au nevoie specialist tehnic, care știe modernul unealtă de tăiere a metalelor. Logistienii vor să vadă orice profesionist cu experiență și care știe perfect ce este logistica depozitului. Clienții încă nu s-au hotărât și nu au venit cu un numitor comun, dar recrutorul caută deja un candidat, luând în considerare candidații. După ce a selectat cel mai bun candidat, în opinia sa, poartă un dialog cu toți clienții. Dacă după interviu nu se poate ajunge la un acord, recrutorul aduce modificări textului postului vacant.

În acest moment, departamentele ajung la concluzia că grupul țintă ar trebui să includă experți tehnici care au cunoștințe excelente despre instrument. Recruitorul efectuează din nou căutarea, selectează candidații potriviți și se întâlnește cu aceștia. Aceasta continuă până când postul vacant este ocupat.

Metodologia agilă de management de proiect: 6 reguli de eficiență

Regula 1. Lucrați la planul de proiect și răspundeți la următoarele întrebări: ce sarcini sunt cele mai importante de realizat, ce resurse sunt necesare pentru aceasta, ce interval de timp este alocat pentru a obține rezultatul?

Planurile pe termen lung au o precizie scăzută, așa că faceți un plan în trei dimensiuni:

• un plan pe termen lung care indică toate sarcinile care trebuie îndeplinite și o planificare pe scară largă a termenelor limită pentru punerea în aplicare a reperelor cheie;
• planuri lunare de obiective, bazate pe planul general (implementarea lor nu trebuie să fie mai mică de 90%);
• Definiți cele mai detaliate obiective în cursul lunii, descriind în mod clar rezultatele realizării lor.

Regula 2. Implicați echipa în implementarea proiectului, informați angajații despre acest lucru. Toți specialiștii trebuie să înțeleagă și să împărtășească obiectivele organizației, să știe ce trebuie făcut pentru a rezolva sarcinile atribuite, chiar dacă acești angajați nu le îndeplinesc în cadrul proiectului.

Regula 3.Întâlniți-vă din când în când cu echipa de implementare. Frecvența întâlnirilor este de 1-2 ori lunar. Acest lucru este necesar pentru a determina soluții la sarcini și probleme, ajustarea în timp util a planului dacă apar dificultăți în implementare. În același timp, reglați ascuțitul situatii conflictuale nu trebuie făcut în timpul întâlnirii, care este programată să aibă loc într-o săptămână. Autorizarea trebuie să fie clară și promptă.

Regula 4. Nu ar trebui să opriți un proiect dacă vedeți că nu are un efect pozitiv. Problemele, de regulă, apar din cauza nemulțumirii echipei, ai cărei membri trebuie să părăsească zona de confort și să devină creativi. Amintiți-vă că primele rezultate sunt de obicei măsurate după finalizarea a 80% din întregul traseu.

Regula 5. Spuneți „la revedere” angajaților cu performanțe slabe dacă vedeți că metodologia Agile nu este aproape de ei.

Regula 6. Nu vă așteptați să rezolvați perfect problemele de prima dată. Aproximativ 95% instrumente eficiente iar ideile au fost realizate după multe iterații și ajustări pe mai multe iterații.

1. Andrew Stellman, Jennifer Greene „Înțelegerea Agile”.

Cartea vorbește despre cele patru opțiuni principale în care este prezentată metodologia Agile. Descrierea lor este destul de interesantă și detaliată. Datorită manualului, stăpânirea artei de a aplica tehnici devine ușoară și distractivă.

Cartea dezvăluie esența celor mai populare metodologii Agile: Scrum, XP (programare extremă), Lean (programare lean) și Kanban; vă spune cum să le utilizați pentru a crea programe de calitate și pentru a vă atinge obiectivele. Manualul descrie modul în care metodologia Agile ajută la schimbarea gândirii participanților la proiect, îi unește și luptă împreună pentru îmbunătățiri. Scopul publicației este de a vorbi despre metode, valori și principii Agile, datorită cărora echipele pot schimba complet strategia de lucru la proiecte și o pot aborda diferit. Manualul va fi de interes pentru managerii de proiect, directori și pur și simplu pentru cei care sunt interesați de metodologia de dezvoltare flexibilă Agile.

2. Boris Volfson „Managementul agil de proiect și produs”.

Cartea îmbină teoria și practica. Descrie diferite aspecte ale conceptului de metodologie Agile, dezvoltare de produs, management și analiză. Partea teoretică despre managementul proiectelor și al produselor conține informații despre starea actuală a Scrum și Kanban. Cea practică vorbește despre gestionarea cerințelor, echipelor, riscurilor, modelarea afacerii, analiza cerințelor, estimarea timpului, practici de inginerie pentru dezvoltarea produsului (în principal despre programare extremă), controlul și asigurarea calității, implementarea și scalarea Scrum.

3. Jeff Sutherland Scrum. O metodă revoluționară de management de proiect.”

Jeff Sutherland are propria metodologie, pe care a dezvoltat-o ​​în încercarea de a depăși neajunsurile managementului clasic de proiect. Specialisti in diferite companii Este adesea dificil să se realizeze o muncă eficientă, rapidă și coordonată. Ei nu reușesc să-și ducă la bun sfârșit majoritatea planurilor din cauza lipsei de timp și resurse, iar departamentele și echipele rezolvă adesea sarcini de importanță opusă sau le repetă.

Scrum există de 20 de ani, iar în acest timp metodologia a fost folosită cu succes nu numai de dezvoltatorii de software, ci și de producătorii de mașini, farmaciști, FBI și oameni obișnuiți planificându-și timpul și oportunitățile.

Datorită citirii cărții, vei privi diferit managementul proiectelor și vei înțelege cum să rezolvi problemele care anterior păreau de neatins. Nu contează care sunt planurile tale: deschiderea unui startup, schimbarea sistem educațional, introducerea de noi tehnologii sau managementul echipei mai eficient. Datorită Scrum, îți vei crește productivitatea exponențial. Manualul este perfect pentru managerii de proiect, directori și specialiști IT.

4. Roman Pichler „Managementul produsului în Scrum”.

Manualul va fi de interes pentru toți cei care studiază metodologia Agile, în special pentru cei care dețin tehnologia. Cartea explică ce rol joacă proprietarul produsului, cum să-l gestioneze cel mai bine și ce metode de bază există pentru aceasta. Vorbim despre vizualizarea produselor, crearea și îmbunătățirea unui backlog, planificarea și urmărirea lansărilor și utilizarea eficientă a Scrum.

5. Kenneth S. Rubin „Fundamentele Scrum”.

Din carte veți afla totul despre Scrum, termenii acestei metodologii și veți înțelege cum să beneficiați de aplicarea acesteia. Dacă sunteți interesat de metodologia Agile, ghidul vă va spune de ce este nevoie pentru a obține rezultate excelente. Cartea a fost scrisă de un expert important în formarea Scrum. Autorul vorbește în detaliu despre principiile cheie, valorile și standardele de practică, atingând abordări flexibile, a căror eficacitate a fost dovedită de-a lungul timpului.

Informații despre experți

Andrei Koceșkov, Analist șef al editurii OJSC Prosveshcheniye. „Prosveshchenie” este o editură de specialitate sovietică și mai târziu rusă de literatură educațională și pedagogică.

Maria Onuchina, Director al Departamentului de management al activelor la Becar Asset Management Group, Moscova. Becar-Exploitation LLC (Becar Asset Management Group). Domeniul de activitate: rezolvarea sistematică a problemelor de gestionare a proprietății, management de proiect și investiții (intermediere, evaluare). Număr de personal: 5000. Teritoriu: birouri - la Moscova și Sankt Petersburg; trei reprezentanțe și 55 diviziuni separate– în diferite orașe ale Rusiei.

Serghei Bucik, Director general al Grupului NPM, Novosibirsk. NPM LLC (Grupul NPM). Domeniu de activitate: producție de echipamente pentru industria băuturilor; dezvoltarea de soluții IT pentru integrarea cu echipamente, aplicații mobile. Număr de angajați: peste 300. Cota de piață: 95% din echipamentele pentru îmbutelierea berii și băuturilor carbogazoase din Rusia. Numărul de brevete per produse proprii: peste 80.