Ketterän ohjelmistokehityksen elinkaarivaiheet selitetty

# aloittelijoille

Ketterä ohjelmistokehitysmenetelmä on yksi yksinkertaisimmista, mutta tehokkaimmista tavoista toimittaa upea tuote marketti. Ja silti jonnekin matkan varrella ihmiset alkoivat todella monimutkaistaa sitä. Oikein toteutettu Agile on nopea, joustava, virheetön ja yksinkertaisesti parempi tapa hallita ohjelmistokehitystiimejä. Tässä artikkelissa selitämme ketterän ohjelmistokehityksen elinkaaren vaiheet ja kuinka ketterät periaatteet sisällytetään.

Ketterän kehityksen pääperiaatteet

Ketterän pääideat kehitystä kuvattiin alkuperäisessä ketterän ohjelmistokehityksen manifestissa. Yhteenvetona ne ovat:

• Muutos on väistämätöntä. Projektin on sopeuduttava siihen sen sijaan, että se jätetään huomiotta;
• Â Tulosten tuottaminen on tärkeämpää kuin vakiintuneet prosessit ja työkalut;
• Asiakkaan todelliset tarpeet ovat etusijalla kehityssuunnitelmien vaatimuksiin nähden.

Nämä ideat hahmotellaan tarkemmin ketterän ohjelmistokehityksen pääperiaatteissa.

Ketterän painopisteenä on loppukäyttäjien tyytyväisyys. Kaikki tehtävät, jotka eivät suoraan toimi sen parantamiseksi, ovat toissijaisia. Ja vaikka ketterät kehitystiimit työskentelevät edelleen prosessien luomisessa, asiakirjojen kirjoittamisessa ja suunnitelmien noudattamisessa, nämä tehtävät voidaan lykätä tai tehdä vähimmäistasolla, jos ne uhkaavat kehityksen tehokkuutta.

Ketterä metodologia Selitetty

Ketterän kehityksen pääväline on iterointi. Iteraatio on prosessi, jossa joukko toimintoja toistetaan peräkkäin, kunnes ehto täyttyy.

Erilaiset ketterät kehitysmenetelmät saavuttavat iteroinnin eri tavoin. Esimerkiksi Scrum toteuttaa Sprintsin. Sprintit ovat kiinteitä ajanjaksoja – yleensä 1-2 viikkoa pitkiä -, joiden aikana kehitystiimi suorittaa tietyn osan toiminnallisuudesta ja saavuttaa ennalta asetetut tavoitteet.

Tässä on esimerkki yhden Scrum Sprintin työnkulusta:

• Tuotteen omistaja – joka vastaa sen valmistumisesta – tarkastaa keskeneräiset tehtävät Tuotelogissa. Vanhentuneet tehtävät poistetaan samalla kun uudet lisätään;
• Tuotteen omistaja määrittää uuden Sprintin laajuuden ja tavoitteen, jonka se haluaa saavuttaa.
• Tuotteen omistajalla on suunnittelu Tapaaminen kehitystiimin kanssa. He luovat käyttäjäkertomuksia, jotka hajotetaan tiettyjen Backlogiin tallennettujen Sprintin tehtäviin.
• Kehitystiimi pitää päivittäin kokouksia, joiden aikana he pitävät itsensä ajan tasalla kunkin tiimin jäsenen edistymisestä;
• Kun sprintin aikataulu on loppunut, sprintti katsotaan täydelliseksi. Keskeneräiset tehtävät siirretään takaisin tuotekirjaan; Poikkeustapauksissa tuotteen omistaja voi muuttaa Sprintin päättymispäivää.
• Tuotteen omistaja järjestää asiakkaalle esittelyn ja näyttää Sprintin aikana tehdyn työn.
• Tuotteen omistaja tapaa kehitystiimin, jossa Sprintin tulokset ovat tarkistettu. Joukkue selvittää, mitä tehtiin hyvin ja mitä prosesseja voidaan parantaa seuraavalla sprintillä. Tätä tarkistusta kutsutaan Sprint-retrospektiiviksi.
• Seuraava Sprint alkaa.

Lokien säännöllinen tarkastelu auttaa ylläpitämään volyymin ominaisuuksien osuvuutta. Sprinttien rajoitettu laajuus ja ennalta asetetut tavoitteet auttavat kehittäjiä suorittamaan mielekästä työtä ajoissa. Uusien ominaisuuksien jatkuva esittely pitää asiakkaan tyytyväisenä ja kykenevänä antamaan palautetta. Kaiken kaikkiaan kehitys tulee tehokkaammaksi.

HUOM. Scrum on vain yksi ketterä menetelmä monien joukossa. Esimerkiksi Kanbanilla ei ole Sprint-vastaavaa, ja sen sijaan se säilyttää merkityksensä jatkuvasti päivitettävän Tehtäväprioriteettijonon kautta.

Ketterän ohjelmiston kehittämisen elinkaaren vaiheet

Kun jaat sen ydinkäsitteisiin, ketterä kehitys ei ole niin vaikeaa. Ja vaikka se saattaa tuntua tuhlaavalta mukana olevien kokousten lukumäärä säästää paljon aikaa optimoimalla kehitystehtävät ja vähentämällä suunnitteluvaiheessa mahdollisesti esiintyviä virheitä.

Vaihe 1: Vaatimukset

Ennen kuin tuotteen omistaja voi edes aloittaa projektin suunnittelua, hänen on luotava alkuperäinen dokumentaatio, jossa luetellaan alkuperäiset vaatimukset. Ne ovat:

• Lopputulos, jonka projekti saavuttaa. Esimerkiksi tekstieditori;
• ominaisuudet, joita se tukee. Esimerkiksi erilaiset kirjasinkoot;
• ominaisuudet, joita se ei aluksi tue. Esimerkiksi animaatioiden lisääminen tekstiin tai kyky upottaa video;

Yleinen suositus on alentaa näitä alkuperäisiä vaatimuksia niin kovasti kuin mahdollista, lisäämällä vain ehdottomasti tarvittavat ominaisuudet ja jättämällä huomiotta ne, jotka ei käytetä usein. Kehittäjät voivat työskennellä niiden kanssa myöhemmin, kun sovellus on otettu käyttöön ja ydinominaisuudet toimivat hyvin.

HUOMAUTUS: Jos kehittäjät päättävät jättää tämän vaiheen huomiotta, heillä on taipumus ominaisuuden hiipimiseen – tilanne, kun uusia tärkeitä ominaisuuksia lisätään jatkuvasti projektiin ja otetaan kehittäjien aika pois tärkeistä tehtävistä.

Jatkossa toistettaessa asiakas ja tuotteen omistaja tarkastelevat vaatimuksia ja tekevät niistä entistä osuvampia.

Vaihe 2: Suunnittelu

Voit lähestyä kahdella tavalla suunnittelu ohjelmistokehityksessä – yksi on visuaalinen suunnittelu ja toinen sovelluksen arkkitehtoninen rakenne.

Ohjelmistosuunnittelu

Ensimmäisen iteraation aikana tuotteen omistaja kokoaa kehitystiimin ja esittelee edellisen vaiheen aikana luodut vaatimukset. Ryhmä keskustelee sitten näiden vaatimusten täyttämisestä ja ehdottaa parhaan tuloksen saavuttamiseksi tarvittavia työkaluja. Esimerkiksi tiimi määrittelee ohjelmointikielen, kehykset ja kirjastot, joita projekti aikoo käyttää.

Jatkoisissa toistoissa kehittäjät keskustelevat ominaisuuksien toteutuksesta ja tulevaisuuden sisäisestä rakenteesta.

UI / UX-suunnittelu

Tässä SDLC-vaiheessa suunnittelijat luovat karkean mallin käyttöliittymästä. Jos tuote on kuluttajalaatuinen, käyttöliittymä ja käyttökokemus ovat tärkeimpiä. Joten on yleensä hyvä tarkistaa mahdolliset kilpailijat nähdäksesi, mitä he tekevät oikein – ja varsinkin mitä he tekevät väärin.

Lisää iteraatioita käytetään alkuperäisen suunnittelun parantamiseen ja / tai muokkaamiseen sen sopivaksi uudet ominaisuudet.

Vaihe 3. Kehitys ja koodaus

Kehitysvaihe on koodin kirjoittamista ja suunnitteludokumentaation muuntamista varsinaiseksi ohjelmistoksi ohjelmistokehitysprosessissa. Tämä SDLC-vaihe on yleensä pisin, koska se on koko prosessin selkäranka.

Tässä ei ole paljon muutoksia iteraatioiden välillä.

Vaihe 4. Integrointi ja testaus

Tämä vaihe käytetään varmistamaan, että ohjelmisto on virheetön ja yhteensopiva kaiken muun kanssa, jonka kehittäjät ovat kirjoittaneet aiemmin. Laadunvarmistusryhmä suorittaa sarjan testejä varmistaakseen, että koodi on puhdas ja että ratkaisun liiketoiminnalliset tavoitteet saavutetaan.

Tämän SDLC-vaiheen jatko-osien aikana testaus osallistuu entistä paremmin ja tilejä ei vain toiminnallisuuden testaukseen, mutta myös järjestelmien integrointiin, yhteentoimivuuteen ja käyttäjien hyväksyntätesteihin jne.

Vaihe 5. Käyttöönotto ja käyttöönotto

Sovellus asennetaan palvelimille ja toimitetaan asiakkaille – joko esittelyyn tai todelliseen käyttöön. Muut iteraatiot päivittävät jo asennetun ohjelmiston tuomalla uusia ominaisuuksia käyttöön ja korjaamalla virheitä.

Vaihe 6. Katsaus

Kun kaikki edelliset kehitysvaiheet on saatu päätökseen, tuotteen omistaja kerää kehitystiimin uudelleen ja tarkastelee vaatimusten täyttämisessä saavutettua edistystä. Tiimi esittelee ideoitaan edellisissä vaiheissa esiin tulleiden ongelmien ratkaisemiseksi, ja tuotteen omistaja ottaa huomioon heidän ehdotuksensa.

Sen jälkeen ketterän ohjelmistokehityksen elinkaarivaiheet alkavat uudestaan – joko uudella iteraatiolla tai siirtymällä kohti seuraavaa vaihetta.

Yleisten Lean-periaatteiden sisällyttäminen ketterään metodologiaan

Lean-periaatteet ovat:

• Poista jätteet;
• Rakenna laatua;
• Luo tietoa;
• Osoita vastuullisuutta;
• Toimita nopeasti;
• Kunnioita ihmisiä;
• optimoi kokonaisuutena.

Kaiken kaikkiaan nämä arvot vastaavat melko hyvin ketterää metodologiaa ja niitä voidaan käyttää täydentämään sitä, jos kysymyksiä ilmenee .

Päätelmä

Ohjelmistokehitys on jäsennelty iteratiivinen prosessi. Ei ole kuitenkaan yhtä ”oikeaa” tapaa tehdä ketterä – on vain sellaisia, jotka sopivat tai eivät sovi tiettyyn joukkueeseen.Jokaisella yrityksellä on oma käsityksensä siitä, mikä on ketterää kehitystä, ja jokaisella on omat etunsa. Päivän päätteeksi tärkeätä on arvokas lopputuote, joka toimitetaan ajoissa.

Näin me Relevant Software -ohjelmassa kehitämme räätälöityjä sovelluksia, jotka vastaavat asiakkaidemme liiketoiminnan tarpeita. Käytämme ketteriä paradigmoja kaikissa projekteissamme ja tarjoamme jatkuvasti erinomaisia tuloksia.