Agile, Scrum și Kanban: Ce naiba înseamnă cu adevărat aceste cuvinte?

Când un dezvoltator de software aude știri despre un „nou cadru JavaScript” sau un „nou IDE”, nu trebuie să pună mai multe întrebări pentru a clarifica despre ce este vorba. Dar dacă aude despre un „nou cadru agil”, probabil că va da din cap Homer-Simpsonian, pretinzând că știe despre ce este vorba, dar va avea una și o singură întrebare: Ce naiba face „cadru agil” Rău?

În mediul modern de dezvoltare software, auzim din ce în ce mai mult cuvinte precum „agil”, „scrum” și „kanban” și sunt adesea folosite incorect. În acest articol, voi încerca să explic și să clarific unii dintre acești termeni.

Agil

Dacă vrei să fii istețul mulțimii, ar trebui să folosești cuvântul „agil” în fiecare altă propoziție atunci când vorbești despre procesul de lucru. Are o gamă destul de largă, nu te obligă să știi prea multe despre subiectul despre care vorbești și este un adjectiv sau adverb foarte drăguț: „thinking agile”, „agile abordare”, „după principii agile”. Dar ce înseamnă cu adevărat „agil”?

„Agile” se referă la „dezvoltare agilă de software”, abordarea dezvoltării care urmează principiile agile. Dar ce naiba sunt „principiile agile?” Aruncă o privire la Manifestul Agile și la cele 12 principii ale agilității, care pun bazele dezvoltării agile. Din Manifest:

Principiile agile încurajează livrarea continuă a software-ului funcțional, comunicarea strânsă între echipe și adaptabilitatea ridicată la nevoile în schimbare. Dacă urmați aceste valori și principii în munca dvs., puteți spune că lucrați într-un mediu agil. Deci, dezvoltarea agilă de software nu este o metodologie, este doar un set de metodologii, cadre și tehnici diferite care urmează aceleași principii. Se poate spune că „agil” este un cadru de gândire și de luare a deciziilor.

Dar de ce este atât de important să respectăm aceste principii în munca noastră?

Manifestul și principiile sunt rezultatul căutării celor mai bune soluții care au evoluat de-a lungul deceniilor ca răspuns la provocările dezvoltării software. De-a lungul anilor 70, 80 și 90, diferiți dezvoltatori și echipe din întreaga lume au experimentat cu metode de lucru și abordări ale rezolvării problemelor, au inventat cadre și tehnici diferite (cum ar fi scrum și programare extremă) și chiar au ajuns la același lucru. idei în paralel. În cele din urmă, în februarie 2001, șaptesprezece dezvoltatori s-au reunit și au găsit numitorii comuni pentru toate aceste idei și experiențe diverse. Așa a fost creat manifestul.

Scrum

Dacă vorbești despre metode „agile” fără să știi ce înseamnă ele, poți să scapi și să spui lucruri care te vor descoperi în fața interlocutorului care cunoaște subiectul: „Scrum și alte metodologii agile”.

Scrum nu este o metodologie, deși cu toții am auzit că se numește așa mai des decât numărul de crime din Game of Thrones . Scrum nu va oferi un răspuns la fiecare întrebare și nu vă va oferi procedura precisă pentru a răspunde la fiecare situație cu care vă confruntați. Și probabil ca urmare a acestei interpretări incorecte, majoritatea implementărilor de scrum sunt, de asemenea, greșite: echipele nu primesc valoare. Acest lucru are ca rezultat probabil cea mai stupidă afirmație despre scrum: „Scrum nu funcționează”.

Ce este scrum? Ghidul Scrum definește scrum ca:

Deci este un cadru și, ca orice alt cadru, poate fi, și este în mod regulat, folosit în mod greșit. Utilizarea eficientă a scrum necesită nu doar adoptarea structurii stabilite de scrum, ci și o înțelegere profundă și apreciere a principiilor agile în întreaga echipă.

Scrum este format din următoarele roluri: Product Owner, Scrum Master, Development Team.

Există, de asemenea, patru ceremonii Scrum: Întâlnire de planificare, Scrum zilnic, Sprint Review, Sprint Retrospective

Și cele trei artefacte: Product Backlog, Sprint Backlog, Product Increment.

Proiectele Scrum sunt organizate în intervale de timp regulate, pe care le numim sprinturi. Acestea durează de obicei două săptămâni.

Un Product Owner este responsabil pentru ghidarea direcției proiectului. Pe măsură ce noi sarcini și caracteristici sunt determinate, proprietarul procuct le adaugă la un backlog de produse. Un sprint începe cu o întâlnire de planificare în care echipa de dezvoltare selectează sarcinile din restanță pentru a lucra și planifică modul în care acestea vor fi implementate. Aceasta este urmată de dezvoltare, timp în care echipa de dezvoltare folosește restanța pentru a urmări progresul și se întâlnește pentru întâlnirea zilnică pentru a sincroniza activitățile și a ajusta planul, dacă este necesar. Rezultatul dezvoltării ar trebui să fie o creștere a produsului, ceva care poate fi aplicat produsului și eliberat imediat. La sfârșitul sprintului, creșterea de produs este prezentată proprietarului de produs la revizuirea sprintului, unde acumularea de produse este crescută dacă sunt necesare modificări suplimentare. Ulterior, întreaga echipă participă la retrospectiva de sprint unde vorbesc despre procesul de lucru și despre cum poate fi îmbunătățit.

Este ușor de învățat și de înțeles scrum, dar este greu de adoptat. Există multe motive pentru care acest cadru poate fi sau nu potrivit pentru un proiect. Adesea necesită multe schimbări, nu numai în dezvoltarea de zi cu zi, ci și cultural. Scrum se potrivește cel mai bine cu dezvoltarea de produse complexe, care durează mult timp și care includ diferite tipuri de specialiști.

De ce este scrum atât de popular și de ce are un avantaj față de modelul tradițional în cascadă? Pur și simplu, pentru că oferă mai multă valoare unui produs și clienților. Cu metode „grele”, precum cascada, abundă poveștile de groază în care nimeni nu vede nimic din proiect timp de luni de zile. Cu scrum, asta nu se poate.

Scrum se referă la valoarea care este oferită utilizatorilor finali. Dacă folosești cu adevărat scrum, trebuie să oferi ceva de valoare la fiecare sprint. Valoarea poate fi măsurată, iar echipa este, de asemenea, forțată să inspecteze impedimentele și să se adapteze, cu scopul de a oferi mai multă valoare în următoarea iterație.

În majoritatea dezvoltării de software nu construim un zgârie-nori; nu trebuie să avem întregul plan pregătit înainte de a începe și să rămânem la acel plan până la sfârșit. Dezvoltăm software și avem capacitatea de a ne adapta la diferite situații și de a schimba cerințele produsului în timpul dezvoltării. Multă vreme, mulți dezvoltatori au văzut acesta ca fiind al optulea păcat mortal, dar din perspectiva produsului este un beneficiu imens pentru optimizarea predictibilității și controlul riscului. Scrum este dezvoltat în jurul acestei abilități, iar implementarea sa oferă o modalitate fiabilă și eficientă de a face față schimbărilor necesare.

Multe tehnici sunt folosite împreună cu scrum: planificarea pokerului, programarea perechilor, dezvoltarea bazată pe teste (TDD), dezvoltarea condusă pe comportament (BDD) și altele. Nu fac cu adevărat parte din scrum, ci mai degrabă tehnici compatibile. O metodă adesea menționată în același timp cu scrum este kanban și există multă confuzie cu privire la ceea ce înseamnă aceste două lucruri în relație unul cu celălalt.

Kanban

Când vorbești despre scrum și kanban, o întrebare frecventă din partea mulțimii va fi: „Care este mai bine, scrum sau kanban?” Și nu vei ști ce să răspunzi pentru că este ca și cum ai compara mere și portocale sau ai întreba: „Care este mai bun, clătite sau bere?” Ambele sunt mai bune.

Kanban este o metodă simplă care urmărește livrarea la timp, fără a supraîncărca membrii echipei. Este similar cu scrum prin faptul că scopul este de a oferi valoare maximă la sfârșit, dar este mult mai flexibil decât scrum.

Kanban nu a fost inventat de comunitatea de dezvoltare software. De fapt, își are originile în procesele de producție la Toyota și are o utilizare largă în alte sfere. Nu există proceduri stricte pe care să le urmați și nici un mod strict în care ar trebui să implementați și să utilizați kanban; este, mai degrabă, un set de principii și practici și puteți alege dintre aceste practici pentru a se potrivi nevoilor dvs. Dar există o implementare a kanban cel mai des folosită în dezvoltarea de software, care include utilizarea unui panou kanban , constând din coloane care reprezintă etapele de lucru și sarcini.

Coloanele reprezintă starea unei sarcini în procesul de dezvoltare. Cel mai simplu exemplu este format din trei coloane: „De făcut”, „În curs” și „Terminat”. Deci, sarcinile sunt adăugate la „De făcut”, mutate în „În desfășurare” când începe dezvoltarea și considerate „Terminat” când sunt mutate în ultima coloană. Dar, desigur, ar putea fi mai complex:

Backlog → Definirea specificației → Gata pentru dezvoltare → Dezvoltare → Revizuire cod → Testare → Implementat (→ Nimeni nu îl folosește cu adevărat → Eliminat complet).

Fiecare coloană poate avea subcoloane; de exemplu, „Dezvoltare” poate fi împărțită în „Planificare” și „Codificare”; „Testarea” poate fi împărțită în „Testarea unitară” și „Testarea de integrare” și așa mai departe. Coloanele ar putea fi dedicate specialiștilor, dacă este cazul. Echipa definește coloanele și etapele în funcție de nevoile sale. Conform filozofiei „pull”, sarcinile ar trebui să intre în fluxul de lucru numai atunci când cererea pentru ele este imediată.

Scopul acestei plăci este de a vizualiza fluxul de lucru , care este prima practică cheie în kanban. De fapt, kanban se poate face deloc fără tablă! Ar putea fi o simplă listă de sarcini într-o foaie Google cu diferite culori de fundal care indică starea sarcinii, sau poate fi diagrame Gantt, diagrame, tabele... Ar putea fi chiar un set de găleți în biroul dvs., unde fiecare reprezintă starea sarcinii și unde bilele sunt folosite ca sarcini. Doar vizualizați fluxul de lucru și oferiți transparență întregului proces.

Un alt principiu important este reducerea volumului lotului de eforturi . Simplificat, aceasta înseamnă evitarea multitasking-ului. Asta poate însemna reducerea volumului sarcinilor la care lucrați în același timp. Dacă aveți trei designeri într-o echipă, echipa poate seta la trei numărul maxim de sarcini din coloana „Proiectare”.

La fel ca scrum, kanban vede echipa ca fiind cea mai importantă figură a procesului. Dar nu sugerează roluri, așa cum face Scrum, și puteți păstra rolurile existente pentru a evita modificarea procesului dvs. existent. Același lucru înseamnă îmbunătățirea continuă: Kanban vă încurajează, în general, să învățați și să vă îmbunătățiți continuu, dar nu prescrie un eveniment anume doar pentru acel proces, la fel ca Sprint Retrospective a Scrum.

Pe care ar trebui să folosesc?

Scrum și kanban nu se exclud reciproc și nu se pot compara cu adevărat. În scrum, există roluri definite, în timp ce kanban spune: „Ce naiba, păstrează-ți rolurile și responsabilitățile actuale.” Scrum te va forța să-ți schimbi modul de lucru; kanban vă permite să începeți cu procesul dvs. existent. În scrum, un program clar pentru evenimente este prescris de cadru; in kanban nu ai evenimente. Cu toate acestea, au multe asemănări: ambele sunt centrate pe valoare, membrii echipei sunt respectați ca „șefi” ai sistemului și, în esență, au aceeași misiune: să elimine continuu risipa și să înlăture obstacolele.

Dar întrebarea: „Ce ar trebui să folosesc în proiectul meu special și cu echipa mea anume?” are mult mai mult sens. Kanban nu necesită atât de mult proces și schimbări culturale și, în majoritatea cazurilor, va fi mai ușor de adoptat decât scrum. Scrum, pe de altă parte, oferă mult mai multă structură pentru a ghida procesul, ceea ce poate elimina o mare parte a cheltuielilor generale, atâta timp cât toată lumea este pe aceeași pagină.

Dar frumusețea ambelor este că niciunul nu este un set strict de reguli. Nimic nu te împiedică să alegi și să alegi cele mai bune elemente scrum pentru tine, cum ar fi o întâlnire zilnică sau o recenzie. Și nu există niciun motiv pentru care să nu încorporați o placă kanban în scrum.

Scrum s-a dovedit a fi un cadru extrem de eficient atunci când întreaga echipă îl înțelege bine. Cu toate acestea, din experiența mea, îmi este greu să lucrez în scrum cu unii clienți. Procesul și schimbările culturale necesare pentru implementarea corectă a scrumului pot fi prea mari (mai ales când ai de-a face cu cineva care crede că face un nou Google!). Pe de altă parte, kanban este mai flexibil și nu obligă oamenii să se schimbe. Unii autori spun, de asemenea, că kanban este o cale bună către agilitate și oferă o implementare mai ușoară a scrumului. Alții spun că utilizarea scrum ar trebui să ducă la kanban la sfârșit.

Adevărul este că fiecare proiect este diferit și nu există o soluție unică. În calitate de manager de proiect, depinde de dvs. să determinați ce funcționează cel mai bine pentru echipa dvs.