Arvutitööstus on tulvil mitmetähenduslikku keelt, karmi kõnepruuki ja keerulisi ideid, millest on raske aru saada ja mis võivad saata teie meeled arvutusliku puhverdamise meeletusse.
kosk? Scrum? Agiilne?
Kui need fraasid on teile täiesti võõrad, ärge muretsege; teie abivalmis HashDorki tehnikahuviliste meeskond on siin, et aidata teil mõista arendusprotsessi nende oluliste etappide erinevusi, et saaksite teadlikuks saada.
Selles ajaveebi postituses käsitletakse kõiki nõtkeid, ründe- ja jugatehnikaid ning seda, kuidas igaüks saab teie meeskonda tervikuna aidata.
Alustame väledatest ja ülejäänu kanname kaasas.
Mis on vilgas?
Agiilne tarkvaraarendus järgib iteratiivset, järkjärgulist lähenemist. Projekti alguses toimuva põhjaliku ettevalmistuse asemel on Agile tehnikad paindlikud aja jooksul muutuvate vajaduste suhtes ja soodustavad pidevat tagasisidet lõppkasutajatelt.
Funktsiooniülesed meeskonnad töötavad toote iteratsioonide kallal aja jooksul ning see töö liigitatakse mahajäämuseks ja prioriseeritakse ettevõtte või kliendi väärtuse alusel. Iga iteratsiooni eesmärk on luua kasutatav toode.
Juhtimine edendab koostööd, vastutustunnet ja näost näkku suhtlemist Agile metoodikates.
Ettevõtluse sidusrühmad ja arendajad peavad tegema koostööd tagamaks, et toode vastab tarbija nõudmistele ja ettevõtte eesmärkidele.
Väljend "agiilne areng" viitab mitmesugustele meetoditele ja raamistikele, mis põhinevad dokumendis kirjeldatud ideaalidel ja põhimõtetel. Agiilne manifest.
Eksperdid soovitavad järgida agiilseid põhimõtteid ja väärtusi ning kasutada neid juhendina, et otsustada, milliseid toiminguid konkreetses keskkonnas tarkvaraarendusele lähenedes teha.
Koostööd tegev ja iseorganiseeruv meeskond on agiilse tarkvaraarenduse kogukonna peamised fookusvaldkonnad.
Meeskondadel on lubatud iseseisvalt otsustada, kuidas nad konkreetse projektiga tegelevad, kuid see ei tähenda, et juhendajaid poleks. Agiilsed meeskonnad on seetõttu ristfunktsionaalsed.
Agiilses paradigmas on juhid endiselt vajalikud. Nad hoolitsevad selle eest, et igal meeskonnaliikmel oleks või omandataks projektiks vajalikud võimed.
Agiilses raamistikus tegutsevad juhid loovad atmosfääri, mis toob esile meeskonna parimad küljed. Kuid selle asemel, et asuda juhtima, jäävad nad sageli tahaplaanile ja lasevad meeskonnal otsustada, kuidas nad asju toimetavad.
Juhid osalevad ainult siis, kui meeskonnad püüavad korduvalt probleeme lahendada, kuid see ei õnnestu.
Agiilne arendustsükkel
Agiilse arendustsükli etapid on loetletud allpool. Oluline on meeles pidada, et need etapid ei tohiks toimuda järjekorras, kuna need on paindlikud ja muutuvad pidevalt. Paljud neist etappidest toimuvad samaaegselt.
- Planeerimine: Kui projektimeeskond on otsustanud, et idee on praktiline ja teostatav, hakkavad nad funktsioone otsima. Selle etapi eesmärk on seada iga omadus tähtsuse järjekorda ja määrata see iteratsioonile pärast idee jagamist väiksemateks toorikuteks (funktsioonid).
- Nõuete analüüs: Ärinõuete kindlaksmääramiseks hõlmab see samm mitmeid arutelusid juhtide, sidusrühmade ja kasutajatega. Kes ja kuidas seda toodet kasutab, on üksikasjad, mida meeskond peab koguma. Need standardid peavad olema konkreetsed, kohaldatavad ja kvantitatiivsed.
- Disain: Süsteemi ja tarkvara disaini koostamisel kasutatakse eelmises etapis leitud nõudeid. Toote või lahenduse välimuse osas peab arvestama meeskond. Testimeeskond töötab välja ka testi strateegia või plaani.
- Rakendamine, kodeerimine või arendus: selles etapis keskendutakse funktsioonide loomisele ja hindamisele ning iteratsioonide juurutamise kavandamisele (järgides iteratiivset ja järkjärgulist arendusmeetodit [IID]). Kuna funktsioone ei pakuta, algab arendusperioodi iteratsioon 0. Viies lõpule selliseid tegevusi nagu lepingute sõlmimine, seadete seadistamine ja rahastamine, loob see iteratsioon aluse tulevaseks kasvuks.
- Testimine: Pärast koodi loomist testitakse seda nõuete suhtes, et tagada toote vastavus kasutajate nõudmistele ja ärieesmärkidele. Selles etapis viiakse läbi üksuse, integratsiooni, süsteemi ja vastuvõetavuse testimine.
- Deployment: Pärast testimist saadetakse toode klientidele, et nad saaksid seda kasutada. Kuid projekt pole pärast kasutuselevõttu lõppenud. Kliendid võivad pärast toote kasutamise alustamist kokku puutuda lisaprobleemidega, millele lahenduse leidmiseks on vaja projektimeeskonda.
Eelised
- Kiirem ja kvaliteetsem kohaletoimetamine: Jaotades projekti iteratsioonideks (juhitavateks üksusteks), saab meeskond keskenduda kvaliteetsemale koostööle, arendusele ja testimisele. Kui testitakse iga iteratsiooniga, leitakse ja parandatakse probleeme kiiremini. Lisaks saab seda kvaliteetset tarkvara kiiremini tarnida pidevate hilisemate muudatustega.
- Muutus on teretulnud: Kuigi planeerimistsüklid on lühemad, on projekti mis tahes punktis muudatustega lihtne nõustuda ja nendega toime tulla. Mahajäämust saab alati parandada ja prioriteete ümber seada, võimaldades meeskondadel paari nädala jooksul projektis muudatusi teha.
- Lõppeesmärk ei pruugi olla teada: Agile sobib suurepäraselt projektidele, mille lõppeesmärk pole selgelt määratletud. Projekti edenedes selguvad eesmärgid ja arendus suudab nende muutuvate vajadustega hõlpsasti kohaneda.
- Pidev täiustamine: Agiilsed programmid soodustavad kasutajate ja meeskonna panust projekti kõikides etappides, võimaldades õpitut järgmise iteratsiooni paremaks muutmiseks rakendada.
- Klientide arvamust hinnatakse: Klientidel on mitmeid võimalusi jälgida töö valmimist, anda tagasisidet ja reaalselt lõpptulemust mõjutada. Projektimeeskonnaga nii tihedalt suheldes võib neil tekkida omanikutunne.
- Tugev meeskonnatöö: Agiilne rõhutab regulaarse suhtluse ja isiklike kohtumiste tähtsust. Meeskondades töötades saavad inimesed võtta vastutuse ja omada teatud projektikomponente.
Puudused
- Meeskonnaliikmetel peavad olema teadmisede: Agiilsed meeskonnad on sageli väikesed. Seega peab meeskonnaliikmetel olema lai valik oskusi. Lisaks peavad nad valitud Agile tehnikat kasutades aru saama ja tundma end vabalt.
- Planeerimine võiks olla vähem täpne: Täpse tarnekuupäeva määramine võib aeg-ajalt olla keeruline. Agile on üles ehitatud ajapõhisele kohaletoimetamisele ja projektijuhid korraldavad sageli ülesannete prioriteete ümber. Seega on tõenäoline, et osa tarneid, mis olid algselt kavandatud tarnimiseks, ei valmi õigeaegselt. Lisaks võib projekti mis tahes punktis lisada rohkem sprinte, mis pikendab kogu ajakava.
- Dokumentatsiooni võib eirata: Mõned meeskonnaliikmed võivad arvata, et dokumentatsioonile keskendumine pole nii oluline, kuna Agile Manifest eelistab töötavat tarkvara põhjalikumale dokumentatsioonile. Agiilsed meeskonnad peaksid leidma ideaalse tasakaalu dokumentatsiooni ja dialoogi vahel, isegi kui põhjalik dokumentatsioon ei taga projekti edukust üksinda.
- Lõplik väljund võib oluliselt erineda: Esialgse Agile projekti jaoks ei pruukinud olla selget strateegiat ja seetõttu võib lõpptulemus oluliselt erineda sellest, mida algselt oodati. Oluliselt erinev lõppväljund võib tuleneda uute iteratsioonide lisamisest kliendi muutuva sisendi põhjal, kuna Agile on nii kohandatav.
- Arendajate ajaline pühendumine: arendusmeeskond peab olema projektile täielikult pühendunud, et agiil oleks tõhus. Agiilne meetod, mis võtab tavapärasest lähenemisest kauem aega, nõuab pidevat aktiivset osalemist ja koostööd. Lisaks tähendab see, et arendajad peavad pühenduma kogu projekti pikkusele.
Mis on kosk?
Kõige populaarsem süsteemi arenduselutsükli (SDLC) iteratsioon tarkvaratehnika ja IT-projektide jaoks on tuntud kui "juga lähenemine", mis järgib järjestikust lineaarset protseduuri.
Selle planeerimiseks kasutatakse aeg-ajalt Gantti diagrammi, tulpdiagrammi vormi, mis kuvab iga töö algus- ja lõppkuupäeva.
Arendusmeeskond liigub järgmisele tasemele, kui üks kaheksast etapist on lõppenud. Meeskond ei saa naasta eelnevasse etappi, ilma et peaks kogu protseduuri uuesti alustama.
Lisaks võib klient nõudeid hinnata ja nendega nõustuda, enne kui meeskond saab järgmisele tasemele minna.
Kose mudel töötati välja tootmis- ja ehitussektori hästi organiseeritud keskkondades, kus kohandamine võib olla ülemäära kulukas või isegi võimatu.
Kosetehnikat nimetatakse nii, kuna see on mõeldud voolama ainult ühes suunas - allapoole - nagu juga. Selle etapid hõlmavad analüüsi, käivitamist, testimist, kavandamist, ehitamist, kasutuselevõttu, hooldust ja testimist.
Juga tehnikal on nagu igal teisel strateegial mitmeid eeliseid. Üks on see, et projekti planeerimise ja kujundamise etapid on paremini välja kujunenud.
Kliendid ja arendusmeeskond on Waterfall tarkvaraarendust kasutades projekti tulemuste osas rohkem kooskõlas. Kuna olete projekti ulatusega algusest peale teadlik, muudab juga arendamine ka edenemise jälgimise lihtsamaks.
Waterfall protsess kasutab spetsialiste, arendajaid, analüütikuid ja testijaid, et keskenduda projektis oma tööle, selle asemel, et kogu meeskond keskenduks ühele sammule.
Kose etapid
Kose kuus sammu peavad kõik toimuma üksteise järel:
- Nõuded kogumiseks ja ladustamiseks: Peaksite koguma põhjalikke teadmisi selle kohta, mida see projekt praegu nõuab. Nende andmete kogumiseks on mitu tehnikat, sealhulgas intervjuud, küsitlused ja koostöö ajurünnakud. Projekti vajadused peaksid selguma selle etapi lõppedes ja teie meeskond peaks olema saanud nõuete dokumendi koopia.
- Süsteemi disain: süsteemi on välja töötanud teie meeskond, kasutades eelnevalt kindlaksmääratud spetsifikatsioone. Selles etapis ei kodeerita, kuid meeskond seab nõuded riistvarale või programmeerimiskeelele.
- Täitmine: see etapp hõlmab kodeerimist. Eelmise etapi andmeid kasutavad programmeerijad kasutatava toote loomiseks. Koodi rakendatakse sageli väikeste tükkidena, mis kombineeritakse ühe faasi lõpus või teise alguses.
- Testimine: Toote testimist saab alustada pärast koodi valmimist. Testijad leiavad kõik probleemid hoolikalt üles ja annavad neist teada. Oluliste probleemide ilmnemisel võib tekkida vajadus minna tagasi esimesse faasi, et uuesti hinnata.
- Kohaletoimetamine/kasutamine: toode on sel hetkel valmis ja teie meeskond esitab tarned juurutamiseks või vabastamiseks.
- hooldus: Klient on toote kätte saanud ja kasutab seda. Kui ilmnevad probleemid, võib teie meeskond nende lahendamiseks välja töötada parandused ja värskendused. Jällegi võivad olulised probleemid nõuda tagasipöördumist esimese sammu juurde.
Eelised
- Lihtne kasutada ja hallata: Waterfalli lähenemisviisi on lihtne kasutada ja arusaadav, kuna iga projekti käsitletakse samal viisil. Enne Waterfalli projekti alustamist ei nõuta meeskonnal eelnevaid teadmisi ega koolitust. Kose lähenemine on väga range; igal etapil on tulemuste komplekt ja ülevaade, mis muudab selle haldamise ja hooldamise lihtsaks.
- Vaja on hästi dokumenteeritud metoodikat: kose metoodikaga nõutav dokumentatsioon aitab selgitada testide ja koodi tagamaid. Lisaks loob see paberjälje juhuks, kui sidusrühmad soovivad teatud etapi või tulevaste algatuste kohta lisateavet.
- Distsipliini jõustamine: koseprojekti igal sammul on algus ja lõpp, mis muudab edusammudest sidusrühmade ja klientide teavitamise lihtsaks. Meeskond saab vähendada tähtajast möödalaskmise võimalust, seades nõuded ja kujunduse enne koodi koostamist esikohale.
Puudused
- Täpsete nõuete kogumine võib olla keeruline: Tarbijate ja sidusrühmadega rääkimine nende vajaduste väljaselgitamiseks on Waterfalli projekti üks algetappidest. Projekti praeguses varases staadiumis võib nende konkreetsete nõuete väljaselgitamine olla keeruline. Kliendid saavad sageli oma nõudmistest teada projekti arenedes, selle asemel, et neid eelnevalt väljendada.
- Muutusi on raske kohaneda: Meeskond ei saa pärast faasi lõppu tööd jätkata. Väga raske ja kulukas on tagasi pöörduda ja seda parandada, kui nad saavad testimise ajal teada, et nõuete täitmise protsessis puudus funktsionaalsus.
- Tarkvara tarnitakse pärast selle tähtaega: Enne tegeliku kodeerimise algust peab projekti kaks kuni neli etappi olema lõpetatud. Selle tulemusel näevad sidusrühmad funktsionaalset tarkvara alles elutsükli lõpus.
Mis on Scrum?
Üks populaarsemaid protsessiraamistikke Agile'i praktikas rakendamiseks on Scrum, mis on Agile'i alamhulk.
See on iteratiivne paradigma keeruka tarkvara ja toodete loomise juhtimiseks. Sprintid, mis on fikseeritud pikkusega iteratsioonid, mis kestavad üks kuni kaks nädalat, võimaldavad meeskonnal tarkvara regulaarselt välja anda.
Sidusrühmad ja meeskonnaliikmed saavad pärast iga sprindi kokku, et arutada järgmisi samme. Rollid, kohustused ja koosolekud Scrumis jäävad muutumatuks.
Näiteks Scrum määrab sprindi planeerimise, igapäevase püstitõusmise, sprindi demo ja sprindi tagasivaate nelja rituaalina, mis pakuvad iga sprindi struktuuri.
Meeskond kasutab edenemise demonstreerimiseks ja järkjärgulise tagasiside saamiseks visuaalseid esemeid, nagu ülesannete tahvlid või põletusgraafikud.
Scrumis teevad meeskond ja tooteomanik tihedat koostööd, et tuvastada ja seada prioriteediks süsteemi funktsionaalsus. Nad saavutavad selle, luues toodete mahajäämuse, mis sisaldab kõiki ülesandeid, mis on vajalikud eesmärgipäraselt toimiva tarkvara tootmiseks.
Veapaigad, mittefunktsionaalsed nõuded ja funktsioonid tuleks kõik järjekorda lisada. Funktsiooniülesed meeskonnad peavad hindama ja registreeruma, et tarnida tarkvara juurdekasvu pidevate Sprintide jooksul, mis kestavad tavaliselt 30 päeva pärast eesmärkide seadmist.
Ainult meeskond saab sprindile funktsioone lisada pärast selle sprindi mahajäämuse tegemist.
Järgmise sprindi tarne puhul hinnatakse ja vajadusel muudetakse prioriteedid toodete mahajäämust ning järgmise sprindi osaks valitakse järgmine tarnekomplekt.
Scrum protsess
- Toote mahajäämus: Toodete tagavaras olevate esemete tellimiseks kohtuvad Tooteomanik ja Scrumi meeskond (töö tootejäägiga tuleb kasutajate lugudest ja nõuetest). Toote mahajäämus on loend kõigist toote jaoks soovitud funktsioonidest, mitte lõpetamist vajavate ülesannete loend. Pärast seda valib arendusmeeskond toote mahajäämust ülesanded, mida iga sprindi jooksul täita.
- Sprindi planeerimine: Enne iga sprinti annab tooteomanik meeskonnale sprindi planeerimise koosolekul mahajäämuse peamised üksused. Seejärel valib rühm toodete mahajäämust üksused, mida nad saavad sprindi jooksul lõpetada, ja teisaldab need sprindi mahajäämusse (see on sprindis täitmist vajavate ülesannete loend).
- Mahajäämuse viimistlemine/hooldus: Tagamaks mahajäämuse ettevalmistamist järgmiseks sprindiks, kohtuvad meeskond ja tooteomanik ühe sprindi lõpus. Meeskond saab loobuda kasutajate lugudest, mis pole enam asjakohased, lisada uusi, vaadata nende käsitlemise järjekorda või jagada kasutajalood väiksemateks ülesanneteks. Sellel "hoolduskoosolekul" veendutakse, et mahajäämus sisaldab ainult asjakohast, põhjalikku ja projekti eesmärkidega kooskõlas olevat.
- Scrum koosolekud iga päev: 15-minutilisel püstijalanõupidamisel nimega Daily Scrum arutab iga meeskonnaliige oma eesmärke ja tekkinud probleeme. Iga päev kogu sprindi jooksul osaleb meeskond Daily Scrum'is, mis hoiab kõiki oma ülesandel.
- Kohtumine sprini hindamisekst: meeskond esitleb oma töid sprindiülevaate koosolekul iga sprindi lõpus. Raporti või PowerPointi esitluse asemel peaks see kohtumine sisaldama tõelist demonstratsiooni.
- Retrospektiivne sprindikohtumine: Meeskond arutab iga sprindi lõpus kõiki muudatusi, mida tuleb teha järgmisel sprindil, ja seda, kui hästi Scrum nende jaoks töötab. Meeskond saab arutada sprindi positiivseid, negatiivseid külgi ja arengukohti.
Eelised
- Rohkem vastutust meeskonnalt: Puudub projektijuht, kes juhendaks scrumi meeskonda, mida ja millal teha. Töö, mis igal sprindil valmis saab, otsustab hoopis meeskond tervikuna. Nad kõik teevad koostööd ja abistavad üksteist, tõhustades meeskonnatööd ja edendades iga meeskonnaliikme individuaalsust.
- Parem projekti nähtavus ja läbipaistvus: Arusaamatusi ja ebakindlust on vähem, kuna kõik meeskonnaliikmed on tänu sagedastele püstitõusmiskoosolekutele teadlikud oma kohustustest. Meeskond saab probleemidega tegeleda enne, kui need kontrolli alt väljuvad, kuna probleeme märgatakse juba ette.
- Täiustatud kulude vähendamine: Pidev suhtlus hoiab meeskonda kursis probleemide või muudatustega kohe, kui need juhtuvad, mis aitab kulusid kokku hoida ja kvaliteeti parandada. Väiksemad funktsioonitükid pakuvad pidevat tagasisidet ja võimaldavad varakult veaparandusi, enne kui suuremate vigade parandamine liiga kulukaks muutub.
- Lihtne kohaneda muutustega: Lihtsam on muutustega toime tulla ja nendega kohaneda, kui on sagedased tagasisideahelad ja lühikesed spurdid. Näitena võib öelda, et kui meeskond puutub ühe sprindi jooksul kokku täiesti uue kasutajalooga, saavad nad selle funktsiooni kiiresti lisada järgmisele sprindile mahajäämuse täpsustamise koosolekul.
Puudused
- Ulatuslik hiilimisoht: Kindlaksmääratud valmimiskuupäeva puudumise tõttu võivad teatud Scrumi projektid ulatuda kokku. Kui valmimise tähtaega pole, võiks sidusrühmi meelitada nõudma rohkem funktsioone.
- Halb Scrum Master võib kõik rööpast välja lüüa: Projektijuht ei ole sama, mis scrum master. Scrum Master peab usaldama meeskonda, mida nad juhendavad, ja mitte kunagi andma neile juhiseid. Scrum Masteril puudub võim meeskonna üle. Projekt ebaõnnestub, kui scrum master proovib meeskonda juhtida.
- Täpsusprobleemid võivad tuleneda halvasti esitatud ülesannetest: kui ülesanded pole selgelt määratletud, ei ole projekti kulud ja ajakavad täpsed. Planeerimine muutub keeruliseks ja sprindid võivad võtta oodatust kauem aega, kui esialgseid eesmärke ei määratleta.
- Kogemused ja pühendumus on meeskonna jaoks vajalikud: Et meeskond oleks edukas, peavad rollid ja kohustused olema selgelt määratletud. Scrum Team nõuab tehniliste oskustega meeskonnaliikmeid, sest puuduvad selgelt määratletud rollid (kõik teevad kõike). Samuti peab meeskond võtma kohustuse osaleda igapäevastel Scrumi seanssidel ja püsida koos kogu projekti vältel.
Agile vs Scrum
Kuigi Agile ja Scrum kasutavad sama metoodikat, on nende kahe vahel mõningaid erinevusi. Agiilne manifest toob välja põhimõtete kogumi tarkvara loomiseks iteratiivse arenduse kaudu.
Scrum seevastu on juhiste kogum, mida tuleb Agile'i tarkvaraarenduse tegemisel järgida. Agile on kontseptsioon, Scrum aga tehnika selle elluviimiseks.
Scrum on Agile'i juurutamise meetod, seetõttu on neil mõlemal palju ühist. Mõlemad lähenemisviisid on iteratiivsed, seavad prioriteediks varajase ja sagedase tarkvara tarnimise ning aktsepteerivad muudatusi. Samuti toetavad need avatust ja pidevat arengut.
Agile vs juga
Jäik vs paindlik kirjeldab kõige paremini erinevusi Waterfall protsessi ja Agile vahel. Kui Agile on sujuv ja pidevalt muutuv, siis Waterfall on palju rangem ja jäigem metoodika.
Need täiendavad erinevused nende vahel on järgmised:
- Agile ei vaja lineaarset lähenemist, samas kui Waterfall on järjestikune.
- Kuigi vajadused on Waterfalli projektides sageli eelnevalt määratletud, eeldatakse, et need muutuvad ja kohanduvad Agile algatustes.
- Erinevalt Agile'ist ei võimalda Waterfall projektid teha muudatusi eelmises etapis lõpetatud töös.
- Kosk on organiseeritud protseduur, mille käigus peate lõpetama iga sammu, enne kui jätkate järgmisega. Agile on aga paindlik metoodika, mis võimaldab projektiga omas tempos edasi minna.
Agile vs Waterfall vs Scrum
- Kosk suurendab usaldust selle vastu, mida hakatakse pakkuma väga kiiresti pärast selle kavandamist. Agile tugineb arenduskeskkonna parimatele tavadele. Siin saab mitmeid projekti riske hästi juhtida, kuna tulemusi hinnatakse pidevalt.
- Waterfall ei eelda, et meeskond ja projekt asuvad samas kohas. Kuigi scrum ja agile vajavad töötajate ühist asukohta.
- Agile keskendub projekti ümbertöötamise vähendamisele ja julgustab muudatusi palju varem sisse viima. Erinevalt kosest, mis reageerib erinevalt, võimaldab scrum ka muutusi varakult avastada.
- Lõpptoote kompaktsema plaani annavad agile ja scrum. See tekitab probleeme ostjale antud lubadustega. Seevastu kosegraafika jätab klientidele ja arendajatele valmis tulemusest parema mulje.
- Kõigil neil tehnikatel on tööriistade komplekt nende loomisega seotud ülesannete korraldamiseks ja simuleerimiseks.
Järeldus
Kui olete seda siiani jälginud ja olete kindel oma teadmistes Waterfall-, Agile- ja Scrumi protsesside erinevuste kohta, peaksite juba teadma, milline strateegia töötab teie ja teie meeskonna jaoks kõige paremini.
Waterfall-tehnika, mis on mõeldud kindla ulatuse, ajakava ja eelarvega projektide jaoks, võib olla teie parim valik, kui teile meeldivad karmid reeglid ja protseduurid ning leiate, et need toovad selgust.
Teisest küljest, kui Agile'i pakutav vabadus ja kohanemisvõime inspireerivad, võiks see olla koht, kus peaksite oma tähelepanu pöörama.
Scrum on siiski õige tee, kui soovite paindlikus raamistikus pisut distsipliini.
Siiski peate neid lähenemisviise kaaluma projekti, mille kallal töötate, ja lõpptulemust silmas pidades.
Jäta vastus