Sisältö
- Lyhyt kuvaus ohjelmistokehityksen elinkaaresta
- Miksi ketterä kehitys erilainen?
- Ketterät käytännöt
- Miksi mennä ketterästi?
- Ei vikoja, ei stressiä - vaiheittaiset ohjeet elämää muuttavien ohjelmistojen luomiseen tuhoamatta elämääsi
Ottaa mukaan:
Tämä ohjelmistokehitysmenetelmä kannustaa yhteistyöhön ja joustavuuteen korkealaatuisen tuotteen toimittamisessa.
Agile-ohjelmiston ja sovelluskehityksen maailmassa on ollut paljon hälinää. Ketterä ei ole käsite, vaan ajattelutapa. Kuten nimestä voi päätellä, se keskittyy olemaan joustava ja dynaaminen. Tämä menetelmä poistaa myös eristyksen ohjelmistokehityksen vaiheiden välillä ja kannustaa kehitysryhmää tekemään yhteistyötä laatuanalyytikkojen kanssa. Se korostaa myös asiakkaiden osallistumista korkealaatuisen tuotteen kehittämiseen, rakentamiseen ja toimittamiseen. Täällä voit tarkastella Agilea, miten se toimii ja joitain parhaita käytäntöjä tälle suositulle ohjelmistokehitysmenetelmälle.
Lyhyt kuvaus ohjelmistokehityksen elinkaaresta
Ohjelmistokehityksen elinkaari (SDLC) on prosessi, jolla luodaan ohjelmistoratkaisuja tai muutetaan olemassa olevia rakenteita, joiden tarkoituksena on vastata tiettyyn ongelmaan. Se käsittää useita vaiheita, joita seurataan loogisessa järjestyksessä. Perinteisissä SDLC-malleissa nämä ovat vaiheet, joita noudatetaan peräkkäin, ja ne suoritetaan yleensä erikseen:
- Vaatimukset keräävät asiakkailta
- Järjestelmä- ja toteutettavuusanalyysi
- Suunnittelu ja mallintaminen
- Koodaus tai toteutus
- Testaus
- Käyttöönotto ja toimitus
- Huolto- ja muutospyynnöt
Tyypillisessä ohjelmistokehitysjaksossa todelliset käyttäjät tai asiakkaat osallistuvat vaatimusten keräämisprosessiin ja sitten beetatestaukseen. Tämän perinteisen mallin ongelma on kuitenkin se, että jakson ylläpito-osasta tulee vaikea ja melko kallis tapaus. Monta kertaa järjestelmässä ei ole tilaa parannuksille tai muutoksille. Pahimmassa tapauksessa suunnitellut tai kehitetyt ohjelmistot eivät ole todellisten asiakasmääritysten ja odotusten mukaisia, mikä tarkoittaa, että kehitysryhmän on ehkä aloitettava koko prosessi uudestaan.
Miksi ketterä kehitys erilainen?
SDLC: n tavallisimmissa perinteisissä malleissa - vesiputousmallissa, nopean käytön mallissa, iteratiivisessa mallissa, kierremallissa jne. - on omat edunsa ja miinuksensa. Kesti vuosia, ennen kuin ihmiset pystyivät tosiasiallisesti analysoimaan, kuinka realistiset nämä mallit olivat. Ne sopivat täydellisesti ihanteellisiin skenaarioihin, mutta ne ovat aina käytännöllisiä reaalimaailman sovelluksissa. Tämän seurauksena ohjelmistokehitysryhmät kohtasivat paljon haasteita. Joitakin perinteisten SDLC-mallien rajoituksia ovat:
- Ne eivät salli vaatimusten muuttamista myöhemmissä vaiheissa, koska ne on jäädytetty ohjelmistovaatimusten määrittelyasiakirjaan. Tietyissä tapauksissa käyttäjien odotukset pysyvät ennallaan tai ymmärretään väärin.
- Loppukäyttäjät näkevät järjestelmän vasta, kun se on valmis. Tämä tarjoaa hyvin vähän tilaa ehdotusten ja muutosten tekemiselle.
- Perinteinen SDLC voi luoda valtavan viestintäkuilun kehittäjien ja testaajien välillä, koska ne ovat erillisiä vaiheita, eikä osapuolten välillä ole mitään yhteistyötä.
- Valkoisen ruudun testausta ei voida tehdä tehokkaasti.
Ketterän käyttö ratkaisee monia näistä ongelmista, koska askel askeleelta tapahtuvan prosessin sijaan se toimii enemmän filosofiana ja kehyksenä, jonka tarkoituksena on auttaa joukkueita yhteistyössä, reagoida muutoksiin ja rakentaa valmis tuote, joka sisältää enemmän panosta kaikilta osapuolet, mukaan lukien käyttäjät.
Ketterät käytännöt
Ketterän metodologian syntyminen on vähintäänkin mullistava uudistus ohjelmistokehitysmenetelmissä, koska se tarjoaa tarpeeksi tilaa projektiryhmille olla luovia ja monipuolisia ottaen samalla kollektiivisen omistuksen kaikissa tuotteen vaiheissa. Seuraamalla ketterää polkua, yksittäiset ohjelmistokehitysryhmän osallistujat kykenevät parantamaan mieltään omaksumaan epävarmuuden, selviytymään muutoksista ja rakentamaan paremman tuotteen prosessina eikä erillisinä, kiinnittämättöminä vaiheina.
Vaikka ketterästä periaatteista ei ole kattavaa luetteloa, on joitain käytäntöjä, joita Agile levittää. Nämä sisältävät:
- Testiohjattu kehitys (TDD)
Ihannetapauksessa kehittäjien tulisi ensin kirjoittaa testitapaukset toiminnallisuudelle, jota he aikovat koodata. Tämä varmistaa laadukkaan koodin, joka rikkoutuu vähemmän poikkeuksellisissa olosuhteissa. Tämä prosessi auttaa myös varmistamaan, että käyttäjän vaatimukset on otettu huomioon. - Pariohjelmointi
Ketterässä kehityksessä ohjelmoijat työskentelevät yleensä saman ongelman parissa, jolloin yksi henkilö kirjoittaa koodin (ohjain) ja toinen tarkistaa koodin ja antaa ideoita ja ehdotuksia (navigaattori). Tämä parantaa tuottavuutta ja vähentää koodin tarkistamiseen kuluvaa aikaa. - Koodin reagointi
Koodin refaktorointi sisältää koodin hajottamisen pienemmiksi ja yksinkertaisemmiksi moduuleiksi, jotka voivat (ja pitäisi olla) olemassa itsenäisesti ihanteellisessa tilanteessa. Tämä parantaa koodin luettavuutta, testattavuutta ja ylläpidettävyyttä suuressa määrin. - Todellisten sidosryhmien aktiivinen osallistuminen
Säännöllisin väliajoin tietyn ajanjakson (jäljempänä "ss") avulla asiakkaiden tulisi saada ohjelmiston merkittävä prototyyppi. Tämän avulla kehittäjät voivat saada palautetta siitä, mitä he rakentavat menossa. - Käsittele vaatimuksia priorisoiduna pinona
Ketterässä on välttämätöntä luokitella vaatimukset niiden tärkeyden perusteella. Tämä voi sisältää sekä implisiittisiä että nimenomaisia asiakkaiden odotuksia kehitettävälle ohjelmistotuotteelle. Ohjelmistokehitysryhmän tulisi yhdessä arvioida aika ja resurssit, jotka he aikovat investoida ominaisuuden toteuttamiseen, ja kartoittaa se käyttäjän vaatimusten ja suhteellisen järjestyksen perusteella, jossa he käsittelevät projektin kaikkia osia. - Regressiotestaus
Regressiotestaus sisältää koko sovelluksen toimivuuden testaamisen uuden ominaisuuden lisäämisen tai koodin nykyisen toiminnallisuuden muokkaamisen jälkeen. Tämä auttaa varmistamaan, että muutokset eivät ole rikkoneet olemassa olevaa koodia.
Miksi mennä ketterästi?
Ketterä määrää tietyt käytännöt, mutta se ei pakota niitä ohjelmistokehitysryhmään. Loppujen lopuksi, jos säätöihin ja poikkeamiin ei ole varaa, Ketterän tarkoitus häviää suurelta osin. Joidenkin ketterän kehityksen näkökohtien sisällyttäminen projektiin voi auttaa ohjelmistokehitysryhmiä selviytymään odottamattomista haasteista ja viime kädessä rakentamaan paremman tuotteen tehokkaammalla tavalla.
Ei vikoja, ei stressiä - vaiheittaiset ohjeet elämää muuttavien ohjelmistojen luomiseen tuhoamatta elämääsi
Et voi parantaa ohjelmointitaitojasi, kun kukaan ei välitä ohjelmiston laadusta.