Tietokoneteollisuus on täynnä moniselitteistä kieltä, ankaraa ammattikieltä ja monimutkaisia ideoita, joita on vaikea ymmärtää ja jotka voivat saada mielesi laskennallisen puskuroinnin kiihkoon.
Vesiputous? Scrum? Ketterä?
Jos nämä lauseet ovat sinulle täysin vieraita, älä huoli; avulias HashDork tech -nörttitiimisi on täällä auttamaan sinua ymmärtämään erot näiden kehitysprosessin tärkeiden vaiheiden välillä, jotta sinusta tulee asiantunteva.
Ketterät, scrum- ja vesiputoustekniikat käsitellään tässä blogiviestissä sekä kuinka kukin voi auttaa tiimiäsi kokonaisuutena.
Aloitetaan ketteristä ja viedään loput mukana.
Mikä on ketterä?
Ketterä ohjelmistokehitys noudattaa iteratiivista, inkrementaalista lähestymistapaa. Sen sijaan, että projektin alussa valmistauduttaisiin laajasti, ketterät tekniikat ovat joustavia ajan mittaan muuttuviin tarpeisiin ja edistävät jatkuvaa palautetta loppukäyttäjiltä.
Monitoimitiimit työskentelevät tuotteiden iteraatioiden parissa ajan mittaan, ja tämä työ luokitellaan ruuhkaksi ja priorisoidaan liiketoiminnan tai asiakkaan arvon perusteella. Jokaisen iteroinnin tarkoituksena on luoda käyttökelpoinen tuote.
Johtajuus edistää yhteistyötä, vastuullisuutta ja kasvokkain tapahtuvaa viestintää ketterissä menetelmissä.
Liiketoiminnan sidosryhmien ja kehittäjien on tehtävä yhteistyötä varmistaakseen, että tuote vastaa kuluttajan vaatimuksia ja yrityksen tavoitteita.
Ilmaus "ketteri kehitys" viittaa erilaisiin menetelmiin ja kehyksiin, jotka perustuvat julkaisussa hahmoteltuihin ihanteisiin ja periaatteisiin. Ketterä manifesti.
Asiantuntijat neuvovat noudattamaan ketteriä periaatteita ja arvoja ja käyttämään niitä oppaana päättämään oikeanlaisista toimista tietyssä ympäristössä ohjelmistokehitystä lähestyttäessä.
Yhteistyökykyinen ja itseorganisoituva tiimi ovat ketterän ohjelmistokehitysyhteisön pääpainopistealueita.
Ryhmät voivat itsenäisesti päättää, miten he käsittelevät tiettyä projektia, mutta se ei tarkoita, etteikö esimiehiä olisi olemassa. Ketterät tiimit ovat siksi ristikkäisiä.
Ketterässä paradigmassa johtajia tarvitaan edelleen. He varmistavat, että jokaisella tiimin jäsenellä on tai hankkii projektiin tarvittavat kyvyt.
Johtajat ketterissä puitteissa toimivat edistämällä ilmapiiriä, joka tuo esiin tiimin parhaat puolet. Mutta johtajuuden sijaan he jäävät usein taka-alalle ja antavat tiimin päättää, kuinka he toimittavat asiat.
Esimiehet tulevat mukaan vain, kun tiimit yrittävät toistuvasti ratkaista ongelmia ilman menestystä.
Ketterä kehityssykli
Ketterän kehityssyklin vaiheet on lueteltu alla. On tärkeää muistaa, että nämä vaiheet eivät saa tapahtua järjestyksessä, koska ne ovat joustavia ja jatkuvasti muuttuvia. Monet näistä vaiheista tapahtuvat samanaikaisesti.
- Suunnittelu: Kun projektitiimi on päättänyt, että idea on käytännöllinen ja toimiva, he alkavat etsiä ominaisuuksia. Tämän vaiheen tavoitteena on priorisoida jokainen piirre ja määrittää se iteraatioon sen jälkeen, kun idea on jaettu pienempiin työkappaleisiin (ominaisuuksiin).
- Vaatimusanalyysi: Liiketoiminnan vaatimusten määrittämiseksi tämä vaihe edellyttää useita keskusteluja johtajien, sidosryhmien ja käyttäjien kanssa. Kuka käyttää tuotetta ja miten he käyttävät sitä, ovat yksi niistä yksityiskohdista, jotka tiimin on kerättävä. Näiden standardien on oltava erityisiä, sovellettavia ja määrällisiä.
- Malli: Järjestelmä- ja ohjelmistosuunnittelun valmistelussa käytetään edellisessä vaiheessa löydettyjä vaatimuksia. Tuotteen tai ratkaisun ulkonäkö on otettava tiimin toimesta. Testiryhmä laatii myös testin strategian tai suunnitelman.
- Käyttöönotto, koodaus tai kehitys: Tämän vaiheen painopiste on ominaisuuksien rakentamisessa ja arvioinnissa sekä iteraatioiden käyttöönoton suunnittelussa (iteratiivisen ja inkrementaalisen kehityksen lähestymistavan [IID] mukaisesti). Koska ominaisuuksia ei ole tarjolla, kehitysjakson iteraatio 0 alkaa. Suorittamalla toimintoja, kuten sopimusten tekemisen, asetusten määrittämistä ja rahoitusta, tämä iteraatio tarjoaa pohjan tulevalle kasvulle.
- Testaus: Kun koodi on luotu, se testataan vaatimusten mukaisesti sen varmistamiseksi, että tuote todella täyttää käyttäjien vaatimukset ja täyttää liiketoimintatavoitteet. Tässä vaiheessa suoritetaan yksikkö-, integrointi-, järjestelmä- ja hyväksyttävyystestaus.
- käyttöönoton: Testauksen jälkeen tuote lähetetään asiakkaille, jotta he voivat hyödyntää sitä. Projekti ei kuitenkaan ole valmis käyttöönoton jälkeen. Asiakkaat voivat kohdata lisäongelmia tuotteen käytön aloittamisen jälkeen, joihin projektitiimin on löydettävä ratkaisu.
edut
- Nopeampi ja laadukkaampi toimitus: Jakamalla projektin iteraatioihin (hallittaviin yksiköihin), tiimi pystyy keskittymään laadukkaampaan yhteistyöhön, kehittämiseen ja testaukseen. Kun testaus suoritetaan jokaisella iteraatiolla, ongelmat löydetään ja korjataan nopeammin. Lisäksi jatkuvalla myöhemmällä versiolla tämä korkealaatuinen ohjelmisto voidaan toimittaa nopeammin.
- Muutos on tervetullut: Vaikka suunnittelusyklit ovat lyhyempiä, on helppoa hyväksyä ja mukauttaa muutokset missä tahansa projektin vaiheessa. Ruuhkaa voidaan aina parantaa ja priorisoida, jolloin tiimit voivat tehdä muutoksia projektiin parissa viikossa.
- Lopputavoitetta ei ehkä tiedetä: Ketterä sopii erinomaisesti projekteihin, joissa lopputavoitetta ei ole määritelty selkeästi. Hankkeen edetessä tavoitteet selkiytyvät ja kehitys pystyy helposti mukautumaan näihin muuttuviin tarpeisiin.
- Jatkuva parantaminen: Ketterät ohjelmat edistävät käyttäjien ja tiimien panosta projektin kaikissa vaiheissa, mikä mahdollistaa opitun soveltamisen paremmaksi seuraavassa iteraatiossa.
- Asiakkaiden mielipiteitä arvostetaan: Asiakkailla on useita mahdollisuuksia seurata työn valmistumista, antaa palautetta ja todella vaikuttaa lopputulokseen. Kun he ovat niin läheisessä vuorovaikutuksessa projektiryhmän kanssa, he voivat kehittää omistajuuden tunteen.
- Vahvaa tiimityötä: Ketterä korostaa säännöllisen viestinnän ja henkilökohtaisen kohtaamisen merkitystä. Ihmiset voivat ottaa vastuuta ja omistaa tiettyjä projektikomponentteja työskennellessään ryhmässä.
Haitat
- Joukkueen jäsenillä tulee olla tietoae: Ketterät tiimit ovat usein pieniä. Näin ollen tiimin jäsenillä tulee olla monenlaisia taitoja. Lisäksi heidän tulee ymmärtää ja tuntea olonsa kotoisaksi valitun ketterän tekniikan avulla.
- Suunnittelu voisi olla vähemmän tarkka: Tarkan toimituspäivämäärän määrittäminen voi toisinaan olla haastavaa. Agile perustuu aikarajalliseen toimitukseen, ja projektipäälliköt järjestävät usein tehtävien prioriteetteja uudelleen. Näin ollen on todennäköistä, että osa toimituksista, jotka alun perin oli suunniteltu toimitettavaksi, ei valmistu ajoissa. Lisäksi sprinttejä voidaan lisätä missä vaiheessa tahansa projektin aikana, mikä pidentää koko aikataulua.
- Dokumentaatio voidaan jättää huomiotta: Jotkut tiimin jäsenet saattavat uskoa, että dokumentointiin keskittyminen ei ole niin tärkeää, koska ketterä manifesti suosii toimivia ohjelmistoja perusteellisen dokumentaation edelle. Kettereiden tiimien tulee löytää ihanteellinen tasapaino dokumentoinnin ja dialogin välillä, vaikka perusteellinen dokumentointi ei yksinään takaa projektin onnistumista.
- Lopullinen tulos voi vaihdella suuresti: Alkuperäiselle ketterälle projektille ei ehkä ollut selkeää strategiaa, ja siksi lopputulos voi poiketa suuresti siitä, mitä alun perin odotettiin. Oleellisesti erilainen lopputulos voi johtua uusien iteraatioiden lisäämisestä asiakkaan muuttuvan syötteen perusteella, koska ketterä on niin mukautuva.
- Kehittäjien aikasitoumus: Kehitystiimin on oltava täysin sitoutunut projektiin, jotta ketterä olisi tehokas. Ketterä menetelmä, joka kestää kauemmin kuin perinteinen lähestymistapa, vaatii jatkuvaa aktiivista osallistumista ja yhteistyötä. Lisäksi se tarkoittaa, että kehittäjien on sitouduttava koko projektin pituuteen.
Mikä on vesiputous?
Ohjelmistosuunnittelun ja IT-projektien suosituin järjestelmän kehityselinkaari (SDLC) on "vesiputouslähestymistapa", joka noudattaa peräkkäistä, lineaarista menettelyä.
Gantt-kaaviota, pylväskaaviota, joka näyttää kunkin työn alkamis- ja päättymispäivät, käytetään toisinaan sen suunnitteluun.
Kehitystiimi etenee seuraavalle tasolle, kun yksi kahdeksasta vaiheesta on päättynyt. Tiimi ei voi palata edelliseen vaiheeseen ilman, että koko prosessia on aloitettava uudelleen.
Lisäksi asiakkaan on ehkä arvioitava ja hyväksyttävä vaatimukset ennen kuin tiimi voi siirtyä seuraavalle tasolle.
Vesiputousmalli kehitettiin teollisuus- ja rakennussektorin hyvin organisoiduissa ympäristöissä, joissa sopeuttaminen saattaa olla kohtuuttoman kallista tai jopa mahdotonta.
Vesiputoustekniikka on saanut nimensä, koska se on tarkoitettu virtaamaan vain yhteen suuntaan - alaspäin - aivan kuten vesiputous. Sen vaiheita ovat analysointi, aloitus, testaus, suunnittelu, rakentaminen, käyttöönotto, ylläpito ja testaus.
Vesiputoustekniikalla on useita etuja, kuten kaikilla muillakin strategioilla. Yksi on se, että projektin suunnittelun ja suunnittelun vaiheet ovat vakiintuneet.
Asiakkaat ja kehitystiimi ovat enemmän linjassa projektien suorituksissa käytettäessä waterfall-ohjelmistokehitystä. Koska olet alusta asti tietoinen projektin laajuudesta, vesiputouskehitys helpottaa myös edistymisen seurantaa.
Waterfall-prosessi käyttää asiantuntijoita, kehittäjiä, analyytikoita ja testaajia keskittymään työhönsä projektissa sen sijaan, että koko tiimi painottaisi yhtä askelta.
Vesiputouksen vaiheet
Kaikkien vesiputouksen kuuden vaiheen on tapahduttava peräkkäin:
- Keräys- ja varastointivaatimukset: Sinun tulisi kerätä perusteellista tietoa siitä, mitä tämä projekti tällä hetkellä vaatii. On olemassa useita tekniikoita näiden tietojen keräämiseen, mukaan lukien haastattelut, kyselyt ja yhteistyön aivoriihi. Projektin tarpeiden pitäisi olla selvillä tämän vaiheen päättyessä, ja tiimisi olisi pitänyt saada kopio vaatimusasiakirjasta.
- Järjestelmän suunnittelu: Järjestelmän on suunnitellut tiimisi käyttämällä ennalta määritettyjä eritelmiä. Tässä vaiheessa koodausta ei tehdä, mutta tiimi asettaa vaatimuksia laitteistolle tai ohjelmointikielelle.
- Täytäntöönpano: Tämä vaihe sisältää koodauksen. Ohjelmoijat käyttävät edellisen vaiheen tietoja käyttökelpoisen tuotteen rakentamiseen. Koodi toteutetaan usein pieninä paloina, jotka yhdistetään yhden vaiheen lopussa tai toisen alussa.
- Testaus: Tuotetta voidaan testata, kun koodi on valmis. Testaajat löytävät kaikki ongelmat huolellisesti ja raportoivat niistä. Projektisi on ehkä palattava ensimmäiseen vaiheeseen uudelleenarviointia varten, jos huomattavia ongelmia ilmenee.
- Toimitus/käyttöönotto: Tuote on valmis tässä vaiheessa, ja tiimisi lähettää toimitukset käyttöönotettaviksi tai julkaisua varten.
- kunnossapito: Asiakas on vastaanottanut tuotteen ja käyttää sitä. Tiimisi saattaa joutua kehittämään korjauksia ja päivityksiä, kun ongelmia ilmenee. Jälleen merkittävät ongelmat voivat vaatia paluuta vaiheeseen yksi.
edut
- Helppo käyttää ja hallita: Waterfall-lähestymistapa on helppokäyttöinen ja ymmärrettävä, koska jokainen projekti käsitellään samalla peräkkäisellä tavalla. Ennen Waterfall-projektin aloittamista tiimillä ei vaadita aiempaa asiantuntemusta tai koulutusta. Vesiputouksen lähestymistapa on erittäin tiukka; jokaisessa vaiheessa on joukko suoritteita ja katsaus, mikä tekee sen hallinnasta ja ylläpidosta helppoa.
- Tarvitaan hyvin dokumentoitu metodologia: Vesiputousmetodologian vaatima dokumentaatio auttaa selventämään testien ja koodin taustalla olevia perusteluja. Lisäksi se luo paperipolun siltä varalta, että sidosryhmät haluavat lisätietoja tietystä vaiheesta tai tulevista aloitteista.
- Kurin noudattaminen: Vesiputousprojektin jokaisella askeleella on alku ja loppu, joten edistymisestä on helppoa viestiä sidosryhmille ja asiakkaille. Tiimi voi vähentää mahdollisuutta jättää määräaikaa asettamalla vaatimukset ja suunnittelu etusijalle ennen koodin tuottamista.
Haitat
- Tarkkojen vaatimusten kerääminen voi olla vaikeaa: Keskusteleminen kuluttajien ja sidosryhmien kanssa heidän tarpeidensa määrittämiseksi on yksi Waterfall-projektin alkuvaiheista. Projektin tässä varhaisessa vaiheessa voi olla haastavaa selvittää heidän erityistarpeensa. Asiakkaat oppivat usein tarpeistaan projektin edetessä sen sijaan, että ilmaisivat ne etukäteen.
- Muutoksia on vaikea hyväksyä: Miehistö ei voi jatkaa työtä vaiheen päätyttyä. On erittäin vaikeaa ja kallista palata takaisin korjaamaan sitä, jos he saavat testausvaiheessa tietää, että toiminnallisuus puuttui vaatimusprosessin aikana.
- Ohjelmisto toimitetaan eräpäivän jälkeen: Projektin kahdesta neljään vaihetta on saatava valmiiksi ennen kuin varsinainen koodaus voi alkaa. Sidosryhmät näkevät toimivan ohjelmiston vasta elinkaaren loppupuolella.
Mikä on Scrum?
Yksi suosituimmista prosessikehyksistä Agilen toteuttamiseksi käytännössä on Scrum, joka on Agilen osajoukko.
Se on iteratiivinen paradigma monimutkaisten ohjelmistojen ja tuotteiden luomisen hallintaan. Sprintit, jotka ovat kiinteän pituisia iteraatioita, jotka kestävät yhdestä kahteen viikkoa, antavat tiimille mahdollisuuden julkaista ohjelmistoja säännöllisesti.
Sidosryhmät ja tiimin jäsenet kokoontuvat keskustelemaan seuraavista vaiheista jokaisen sprintin jälkeen. Roolit, vastuut ja kokoukset Scrumissa pysyvät vakiona.
Esimerkiksi Scrum määrittelee sprintin suunnittelun, päivittäisen stand-upin, sprintin demon ja sprintin retrospektiivin neljäksi rituaaliksi, jotka tarjoavat kunkin sprintin rakenteen.
Tiimi käyttää jokaisen sprintin aikana visuaalisia esineitä, kuten tehtävätauluja tai polttokaavioita, osoittaakseen edistymistä ja saadakseen lisäpalautetta.
Scrumissa tiimi ja tuotteen omistaja tekevät tiivistä yhteistyötä tunnistaakseen ja priorisoidakseen järjestelmän toimivuutta. He saavuttavat tämän luomalla tuoteruuhkan, joka sisältää kaikki tehtävät, jotka ovat tarpeellisia toimivien ohjelmistojen tuottamiseksi.
Virhekorjaukset, ei-toiminnalliset vaatimukset ja ominaisuudet tulisi sisällyttää jonoon. Monitoimitiimien on arvioitava ja kirjauduttava toimittaakseen ohjelmiston lisäyksiä jatkuvien Sprinttien aikana, jotka kestävät yleensä 30 päivää, kun tavoitteet on asetettu.
Vain joukkue voi lisätä toimintoja Sprintiin sen jälkeen, kun se on sitoutunut siihen sprinttiin.
Seuraavassa Sprint-toimituksessa tuotekanta arvioidaan ja tarvittaessa priorisoidaan, ja seuraava toimitussarja valitaan osaksi seuraavaa sprinttiä.
Scrum-prosessi
- Tuotteen kulutus: Tuotevaraston kohteiden tilaamiseksi Product Owner ja Scrum Team tapaavat (tuotevaraston työ tulee käyttäjien tarinoista ja vaatimuksista). Tuotevaraus on luettelo kaikista tuotteelle halutuista ominaisuuksista, ei luettelo tehtävistä, jotka on suoritettava. Sen jälkeen kehitystiimi valitsee tuoteruuhkasta tehtävät, jotka suoritetaan jokaisen sprintin aikana.
- Sprintisuunnittelu: Ennen jokaista sprinttiä tuotteen omistaja toimittaa joukkueelle ruuhkan tärkeimmät kohteet sprintin suunnittelukokouksessa. Tämän jälkeen ryhmä valitsee tuoteselvityksestä tuotteet, jotka he voivat viimeistellä sprintin aikana, ja siirtää ne sprintin ruuhkaan (joka on luettelo sprintissä suoritettavista tehtävistä).
- Tilauskannan hienosäätö/hoito: Varmistaakseen, että ruuhka on valmis seuraavaan sprinttiin, joukkue ja tuotteen omistaja tapaavat yhden sprintin lopussa. Tiimi voi hylätä tarpeettomia käyttäjätarinoita, lisätä uusia, muuttaa niiden käsittelyjärjestystä tai jakaa käyttäjätarinat pienempiin tehtäviin. Tässä "harjoitus"-kokouksessa varmistetaan, että ruuhkassa on vain asiaankuuluvia, syvällisiä ja hankkeen tavoitteiden mukaisia asioita.
- Scrum-kokoukset joka päivä: 15 minuutin stand-up-kokouksessa, nimeltään Daily Scrum, jokainen tiimin jäsen keskustelee tavoitteistaan ja mahdollisista ongelmista. Joka päivä koko sprintin ajan joukkue osallistuu Daily Scrum -tapahtumaan, joka pitää kaikki tehtävässä.
- Tapaamisen arvioimiseksit: Ryhmä esittelee työnsä sprintin tarkistuskokouksessa jokaisen sprintin lopussa. Raportin tai PowerPoint-esityksen sijaan tämän kokouksen tulisi sisältää todellinen esittely.
- Retrospektiivinen sprinttikokous: Tiimi keskustelee mahdollisista muutoksista, jotka on tehtävä seuraavassa sprintissä, sekä siitä, kuinka hyvin Scrum toimii heidän kanssaan kunkin sprintin lopussa. Ryhmä voi keskustella sprintin positiivisista, negatiivisista puolista ja kehittämiskohteista.
edut
- Lisää vastuuta joukkueelta: Ei ole projektipäällikkö, joka ohjeistaisi scrum-tiimiä mitä tehdä ja milloin. Kussakin sprintissä suoritettava työ on sen sijaan koko joukkueen päätettävissä. He kaikki tekevät yhteistyötä ja auttavat toisiaan tehostaen tiimityötä ja vaalimaan jokaisen tiimin jäsenen yksilöllisyyttä.
- Parempi hankkeen näkyvyys ja läpinäkyvyys: Väärinkäsityksiä ja epävarmuutta on vähemmän, koska kaikki tiimin jäsenet ovat tietoisia vastuistaan toistuvien stand-up-kokousten ansiosta. Tiimi voi käsitellä ongelmia ennen kuin ne karkaavat käsistä, koska ongelmat havaitaan etukäteen.
- Tehostetut kustannussäästöt: Jatkuva viestintä pitää tiimin ajan tasalla kaikista ongelmista tai muutoksista heti niiden tapahtuessa, mikä auttaa säästämään kustannuksia ja parantamaan laatua. Pienemmät ominaisuuspalat tarjoavat jatkuvaa palautetta ja mahdollistavat virheiden varhaisen korjaamisen, ennen kuin suurempien virheiden korjaaminen tulee liian kalliiksi.
- Helppo sopeutua muutoksiin: Muutoksia on helpompi käsitellä ja niihin sopeutua, kun palautesilmukoita ja lyhyitä sprinttejä on usein. Esimerkkinä voidaan mainita, että jos tiimi törmää täysin uuteen käyttäjätarinaan yhden sprintin aikana, he voivat nopeasti lisätä tämän ominaisuuden seuraavaan sprinttiin ruuhkan tarkennuskokouksessa.
Haitat
- Scope creep vaara: Asetetun valmistumispäivämäärän puuttumisen vuoksi tietyt Scrum-projektit voivat kohdata laajuuden hiipimistä. Sidosryhmät voitaisiin houkutella vaatimaan lisää ominaisuuksia, jos valmistumiselle ei ole määräaikaa.
- Huono Scrum Master voi suistaa kaiken: Projektipäällikkö ei ole sama asia kuin scrum master. Scrum Masterin tulee luottaa valvomaansa tiimiin eikä koskaan antaa heille ohjeita. Scrum Masterilla ei ole valtaa joukkueeseen. Projekti epäonnistuu, jos scrum-mestari yrittää hallita tiimiä.
- Tarkkuusongelmia voi johtua huonosti ilmoitetuista tehtävistä: Jos tehtäviä ei ole määritelty selkeästi, projektin kulut ja aikataulut eivät ole tarkkoja. Suunnittelusta tulee haastavaa ja sprintit voivat kestää odotettua kauemmin, jos alkuperäisiä tavoitteita ei ole määritelty.
- Kokemusta ja omistautumista tarvitaan tiimissä: Jotta tiimi menestyisi, roolit ja tehtävät on määriteltävä selkeästi. Scrum-tiimiin tarvitaan teknisiä taitoja omaavia tiimiläisiä, koska rooleja ei ole selkeästi määritelty (kaikki tekevät kaiken). Tiimin tulee myös sitoutua osallistumaan päivittäisiin Scrum-istuntoihin ja pysymään yhdessä koko projektin ajan.
Ketterä vs Scrum
Vaikka Agile ja Scrum käyttävät samaa menetelmää, näiden kahden välillä on joitain eroja. Ketterä manifesti hahmottelee periaatteet ohjelmistojen luomiselle iteratiivisen kehityksen kautta.
Scrum puolestaan on joukko ohjeita, joita on noudatettava ketterässä ohjelmistokehityksessä. Ketterä on konsepti, kun taas Scrum on tekniikka sen toteuttamiseksi käytännössä.
Scrum on Agilen toteutustapa, joten molemmilla on monia yhteisiä piirteitä. Molemmat lähestymistavat ovat iteratiivisia, priorisoivat varhaista ja toistuvaa ohjelmistotoimitusta ja hyväksyvät muutokset. Ne tukevat myös avoimuutta ja jatkuvaa kehitystä.
Ketterä vs vesiputous
Rigid vs. joustava kuvaa parhaiten Waterfall-prosessin ja ketterän eron. Vaikka ketterä on juoksevaa ja jatkuvasti muuttuvaa, Waterfall on paljon tiukempi, jäykempi menetelmä.
Nämä lisäerot niiden välillä ovat seuraavat:
- Ketterä ei vaadi lineaarista lähestymistapaa, kun taas Waterfall on peräkkäinen.
- Vaikka tarpeet on usein ennalta määritelty Waterfall-projekteissa, niiden odotetaan muuttuvan ja mukautuvan ketterissä aloitteissa.
- Toisin kuin Agile, Waterfall-projektit eivät salli muutosten tekemistä aiemmassa vaiheessa valmistuneisiin töihin.
- Vesiputous on organisoitu toimenpide, jossa sinun on suoritettava jokainen vaihe ennen kuin siirryt seuraavaan. Agile on kuitenkin joustava menetelmä, jonka avulla voit jatkaa projektia omaan tahtiisi.
Ketterä Vs Waterfall Vs Scrum
- Vesiputous lisää luottamusta siihen, mitä tarjotaan hyvin pian sen suunnittelun jälkeen. Ketterä luottaa kehitysympäristön parhaisiin käytäntöihin. Tässä useita projektiriskejä voidaan hallita hyvin, koska tuloksia arvioidaan jatkuvasti.
- Waterfall ei ennakoi tiimin ja projektin olevan samassa paikassa. Vaikka scrum ja ketterä tarvitsevat työntekijöiden yhteispaikkaa.
- Agile keskittyy vähentämään projektien uudelleentyöskentelyä ja rohkaisee ottamaan muutokset käyttöön paljon aikaisemmin. Toisin kuin vesiputous, joka reagoi eri tavalla, scrum mahdollistaa myös muutosten varhaisen havaitsemisen.
- Agile and scrum tarjoaa kompaktimman suunnitelman lopputuotteelle. Tämä aiheuttaa ongelmia ostajalle annettujen lupausten kanssa. Sitä vastoin vesiputousgrafiikka antaa asiakkaille ja kehittäjille paremman kuvan lopputuloksesta.
- Jokaisella näistä tekniikoista on joukko työkaluja niiden luomiseen liittyvien tehtävien järjestämiseen ja simulointiin.
Yhteenveto
Jos olet seurannut tätä tähän mennessä ja olet varma tiedoistasi Waterfall-, Agile- ja Scrum-prosessien eroista, sinun pitäisi jo tietää, mikä strategia toimii parhaiten sinulle ja tiimillesi.
Waterfall-tekniikka, joka on tarkoitettu projekteille, joilla on määrätty laajuus, aikataulu ja budjetti, voi olla paras vaihtoehto, jos pidät kovista säännöistä ja menettelyistä ja huomaat niiden tuovan selkeyttä.
Toisaalta, jos Agilen tarjoama vapaus ja sopeutumiskyky inspiroivat sinua, se voi olla paikka, johon sinun pitäisi kiinnittää huomiosi.
Scrum on kuitenkin oikea tapa edetä, jos haluat hieman kurinalaisuutta joustavan kehyksen sisällä.
Sinun on kuitenkin harkittava näitä lähestymistapoja työskentelemäsi projektin ja lopullisen tuloksesi valossa.
Jätä vastaus