Kui tarkvaraarendaja kuuleb uudiseid uue JavaScripti raamistiku või uue IDE kohta, ei pea ta selle kohta selgitamiseks rohkem küsimusi esitama. Kuid kui ta kuuleb „uuest väledast raamistikust”, teeb ta tõenäoliselt Homeruse-Simpsoni noogutades näo, et ta teab, millega tegu, kuid tal on üks ja ainus küsimus: Mida kuradit tähendab „vilgas raamistik“?

Kaasaegses tarkvaraarenduskeskkonnas kuuleme üha enam selliseid sõnu nagu 'vilgas', 'scrum' ja 'kanban' ning neid kasutatakse sageli valesti. Selles artiklis püüan mõnda neist terminitest selgitada ja selgitada.

Vilgas

Kui soovite olla rahvahulga nutikas, peaksite tööprotsessist rääkides kasutama igas teises lauses sõna “vilgas”. Sellel on üsna lai valik, see ei kohusta teid palju rääkima teema kohta, millest te räägite, ja see on tõeliselt kena omadussõna või määrsõna: 'mõtlemine vilgas', 'vilgas lähenemine', 'vastavalt vilgasele põhimõtetele'. Kuid mida tähendab 'vilgas' tegelikult?

'Agile' viitab ' vilgas tarkvaraarendus , ”Lähenemisviis arengule, mis järgib väledat põhimõtet. Aga mis kuradit on 'väledatel põhimõtetel'? Heitke pilk peale vilgas manifest ja juures 12 väleduse põhimõtet , mis pani aluse agarale arengule. Manifestist:

Isikud ja suhtlemine protsesside ja tööriistade üle
Töötav tarkvara üle põhjaliku dokumentatsiooni
Klientide koostöö lepingu läbirääkimiste üle
Muutustele reageerimine plaani järgimise üle

Agile põhimõtted soodustavad toimiva tarkvara pidevat edastamist, tihedat suhtlemist meeskondade vahel ja kõrget kohanemisvõimet muutuvate vajadustega. Kui järgite oma töös neid väärtusi ja põhimõtteid, võite öelda, et töötate väledas keskkonnas. Niisiis, kiire tarkvaraarendus pole metoodika, see on lihtsalt erinevate metoodikate, raamistike ja tehnikate kogum, mis järgib samu põhimõtteid. Võib öelda, et “vilgas” on raamistik mõtlemiseks ja otsuste langetamiseks.

Agile on raamistik mõtlemiseks ja otsuste langetamiseks.

Kuid miks on nende põhimõtete järgimine oma töös nii oluline?

Manifest ja põhimõtted on aastakümnete jooksul arenenud parimate lahenduste otsimise tulemus vastusena tarkvaraarenduse väljakutsetele. 70-ndatel, 80-ndatel ja 90-ndatel aastatel olid erinevad arendajad ja meeskonnad üle kogu maailma katsetanud töömeetodeid ja lähenemisviise probleemide lahendamisele, leiutanud erinevaid raamistikke ja tehnikaid (näiteks scrum ja Extreme Programming) ning jõudnud isegi samadeni ideed paralleelselt. Lõpuks, 2001. aasta veebruaris said seitseteist arendajat kokku ja leidsid kõigi nende mitmekesiste ideede ja kogemuste ühisosa. Nii loodi manifest.

Agile manifest on aastakümnete jooksul tekkinud erinevate kogemuste ja praktiliste lahenduste tulemus.

Scrum

Kui räägite agiilsetest meetoditest, teadmata, mida need tähendavad, võite libiseda ja öelda asju, mis paljastavad teid teemat tundva vestluskaaslase ees: „Scrum ja muud agarad metoodikad”.

Scrum pole metoodika , kuigi me kõik oleme kuulnud, et seda nimetatakse nii sagedamini kui mõrvade arv aastal Troonide mäng . Scrum ei anna vastust igale küsimusele ega anna teile täpset protseduuri, kuidas reageerida igale teie silmitsi seisvale olukorrale. Tõenäoliselt on selle vale tõlgendamise tulemusena vale ka enamik scrum-rakendusi: meeskonnad ei saa väärtust. Selle tulemuseks on ilmselt kõige rumalam väide scrumi kohta: 'Scrum ei tööta.'

Mis on scrum? Scrumi juhend määratleb scrumi kui:

'Raamistik, mille raames saavad inimesed lahendada keerukaid kohanemisprobleeme, pakkudes samal ajal produktiivselt ja loovalt võimalikult kõrge väärtusega tooteid.'

Nii et see on raamistik ja nagu iga muud raamistikku, võib seda ka regulaarselt kasutada valesti. Scrumi efektiivne kasutamine ei nõua mitte ainult scrumi poolt ette nähtud struktuuri omaksvõtmist, vaid kogu meeskonna agarate põhimõtete sügavat mõistmist ja tunnustamist.

Scrum koosneb järgmistest rollidest: tooteomanik, Scrum Master, arendustiim.

Samuti on neli Scrumi tseremooniat: Planning Meeting, Daily Scrum, Sprint Review, Sprint Retrospective

Ja kolm artefakti: toote mahajäämus, Sprindi mahajäämus, toote juurdekasv.

Scrumi projektid on korraldatud tavapärastesse ajaraamidesse, mida me nimetame sprintideks. Need kestavad tavaliselt kaks nädalat.

TO Toote omanik vastutab projekti suuna suunamise eest. Uute ülesannete ja funktsioonide määramisel lisab prokti omanik need toote mahajäämusse. Sprint algab planeerimiskoosolekuga, kus arendusmeeskond valib töö mahajäämusest ülesanded ja kavandab nende rakendamist. Sellele järgneb arendus, mille käigus arendusmeeskond kasutab edusammude jälgimiseks mahajäämust ja kohtub igapäevaseks koosolekuks, et sünkroonida tegevusi ja vajadusel plaani kohandada. Arenduse tulemus peaks olema toote juurdekasv, midagi, mida saab tootele rakendada ja kohe vabastada. Sprindi lõpus esitatakse toote juurdekasv toote omanikule sprindi ülevaatamisel, kus täiendavate muudatuste vajadusel suureneb toote mahajäämus. Pärast seda osaleb kogu meeskond sprindi retrospektiivis, kus räägitakse tööprotsessist ja selle parandamisest.

Seda on lihtne õppida ja aru saada, kuid seda on raske omaks võtta. On palju põhjuseid, miks see raamistik võib projekti jaoks sobida või mitte. Sageli nõuab see palju muudatusi, mitte ainult igapäevases arengus, vaid ka kultuuriliselt. Scrum sobib kõige paremini keerukate toodete väljatöötamiseks, mis kestavad kaua ja sisaldavad erinevaid spetsialiste.

Miks on scrum nii populaarne ja miks on sellel traditsioonilise juga mudeli ees eelis? Lihtsamalt öeldes, sest see annab tootele ja klientidele rohkem väärtust. Selliste raskekaaluliste meetodite nagu juga abil on külluses õuduslugusid, milles keegi ei näe kuude jooksul projektist midagi. Scumiga pole see võimalik.

Scrum on kõike väärtus mis edastatakse lõppkasutajatele. Kui te tõesti kasutate scrumit, peate igal sprindil pakkuma midagi väärtuslikku. Väärtust saab mõõta ning meeskond on sunnitud ka takistusi kontrollima ja kohanema, eesmärgiga pakkuda järgmisel iteratsioonil rohkem väärtust.

Enamikus tarkvaraarenduses ei ehita me pilvelõhkujat; meil pole vaja kogu kava enne alustamist valmis olla ja peame selle kavani lõpuni kinni. Arendame tarkvara ja meil on võime erinevate olukordadega kohaneda ja tootenõudeid arenduse käigus muuta. Pikka aega nägid paljud arendajad seda kaheksanda surmapattuna, kuid toote vaatenurgast on see tohutu eelis prognoositavuse optimeerimiseks ja riski kontrollimiseks. Scrum on selle võime ümber välja töötatud ja selle rakendamine annab usaldusväärse ja tõhusa viisi vajalike muudatustega toimetulekuks.

Koos scrumiga kasutatakse paljusid tehnikaid: pokkeri planeerimine, paaride programmeerimine, testpõhine arendus (TDD), käitumisest lähtuv areng (BDD) ja teised. Need ei ole tegelikult osa scrum'ist, vaid pigem ühilduvad tehnikad. Üks meetod, mida sageli mainitakse samaaegselt scrumiga, on kanban ja on palju segadust selles, mida need kaks asja üksteise suhtes tähendavad.

Kanban

Kui räägite scrumist ja kanbanist, on rahvahulga üks korduma kippuv küsimus: 'Kumb on parem, kas scrum või kanban?' Ja te ei tea, mida vastata, sest see on nagu õunte ja apelsinide võrdlemine või küsimus: 'Mis on parem, pannkoogid või õlu?' Mõlemad on paremad.

Kanban on lihtne meetod, mille eesmärk on õigeaegne kohaletoimetamine, ilma et see koormaks meeskonnaliikmeid. See sarnaneb scrumiga, kuna eesmärk on pakkuda maksimaalset väärtust lõpus, kuid see on palju paindlikum kui scrum.

Kanbani ei leiutanud tarkvaraarenduse kogukond. Tegelikult pärineb see Toyota tootmisprotsessidest ja seda kasutatakse laialdaselt ka teistes valdkondades. Puuduvad ranged protseduurid, mida peaksite järgima, ja ükski range viis, kuidas peaksite kanbani juurutama ja kasutama; see on pigem põhimõtete ja tavade kogum ning saate valida nende tavade seast oma vajadustele vastavaks. Kuid tarkvaraarenduses on üks kanbani kõige sagedamini kasutatav rakendus, mis hõlmab a kasutamist kanbani juhatus , mis koosneb veergudest, mis tähistavad tööetappe ja ülesandeid.

Veerud näitavad ülesande olekut arendusprotsessis. Lihtsaim näide koosneb kolmest veerust: „To Do”, „In Progress” ja „Done”. Niisiis, ülesanded lisatakse jaotisse „Tööülesanded”, teisaldati arenduse alustamisel jaotisesse „Protsessis” ja loetakse viimasesse veergu viimisel „Valmis”. Kuid muidugi võib see olla keerulisem:

Mahajäämus → Spetsifikatsiooni määratlemine → Arendamiseks valmis → Arendus → Koodi ülevaade → Testimine → Kasutusel (→ Keegi seda tegelikult ei kasuta → Täielikult eemaldatud).

Igal veerul võivad olla alamveerud; näiteks võib „Arenduse” jagada „Planeerimiseks” ja „Kodeerimiseks”; “Testimise” võib jagada “Unit Testing” ja “Integration Testing” jne. Vajadusel võidakse veerge pühendada spetsialistidele. Meeskond määratleb veerud ja etapid vastavalt oma vajadustele. „Tõmba” filosoofia kohaselt peaksid ülesanded tööle minema ainult siis, kui nõudlus nende järele on kohene.

Selle juhatuse eesmärk on visualiseerige töövoog , mis on kanbani esimene põhipraktika. Tegelikult saab kanbani üldse ilma tahvlita! See võib olla lihtne ülesannete loend Google'i lehel, millel on erinevad taustavärvid, mis näitavad ülesande olekut, või see võib olla Gantti diagrammid, skeemid, tabelid ... See võib olla isegi teie kontoris olevate ämbrite komplekt, kus igaüks neist tähistab ülesande olek ja kus pallidena kasutatakse ülesandeid. Lihtsalt visualiseerige töövoog ja tagage kogu protsessi läbipaistvus.

Teine oluline põhimõte on vähendage oma jõupingutuste partii suurust . Lihtsustatult tähendab see, et väldiksite mitme ülesande täitmist. See võib tähendada samal ajal vähendatavate tööde mahtu. Kui teil on meeskonnas kolm disainerit, võib meeskond määrata veerus „Kujundus” maksimaalseks ülesannete arvuks kolm.

Sarnaselt scrumile näeb ka Kanban meeskonda protsessi kõige olulisemana. Kuid see ei soovita rolle nagu scrum teeb ja võite olemasolevad rollid säilitada, et vältida oma olemasolevas protsessis muudatuste tegemist. Sama tähistab pidevat täiustamist: Kanban julgustab teid üldjuhul pidevalt õppima ja end täiendama, kuid ei määra just selleks protsessiks konkreetset sündmust, nagu ka scrumi Sprindi retrospektiiv.

Kumba peaksin kasutama?

Scrum ja kanban ei välista üksteist ega ole tegelikult võrreldavad. Vaates on määratletud rollid, samas kui kanban ütleb: 'Mida kuradit, hoidke oma praeguseid rolle ja vastutust.' Scrum sunnib sind oma tööviisi muutma; kanban võimaldab teil alustada oma olemasolevat protsessi. Eeskätt näeb raamistik ette selge sündmuste ajakava; kanbanis pole teil üritusi. Ometi on neil palju sarnasusi: mõlemad on väärtuskesksed, meeskonnaliikmeid austatakse kui süsteemi ülemusi ja sisuliselt on neil sama missioon: jäätmete pidev kõrvaldamine ja takistuste kõrvaldamine.

Kuid küsimus: 'Mida peaksin kasutama oma konkreetses projektis ja oma konkreetse meeskonnaga?' on palju mõttekam. Kanban ei nõua nii palju protsessi ja kultuurilisi muudatusi ning enamasti on seda lihtsam omaks võtta kui nühkida. Scrum seevastu pakub protsessi juhtimiseks oluliselt rohkem struktuuri, mis võib kaotada palju üldkulusid, kui kõik on samal lehel.

Kuid mõlema ilu on see, et kumbki pole range reeglistik. Miski ei takista teid valimast ja valimast teile parimaid elemente, näiteks igapäevane koosolek või ülevaade. Ja pole mingit põhjust, miks te ei saa kanbani tahvlit scrum'i lisada.

Scrum on osutunud ülitõhusaks raamistikuks, kui kogu meeskond sellest hästi aru saab. Minu kogemuse põhjal on mul siiski raske töötada mõne kliendiga. Protsessi ja kultuurimuutused, mida on vaja nõuetekohaseks juurutamiseks, võivad olla liiga suured (eriti kui on tegemist kellegagi, kes usub, et ta teeb uut Google'i!) Teiselt poolt on kanban paindlikum ja ei sunni inimesi muutuma. Mõned autorid ütlevad ka, et kanban on hea tee agility juurde ja pakub scrumi lihtsamat rakendamist. Teised ütlevad, et scrumi kasutamine peaks lõpuks viima kanbanini.

Tõsi on see, et iga projekt on erinev ja kõigile sobivat lahendust pole. Projektijuhina on teie teha kindlaks, mis teie meeskonnale kõige paremini sobib.