ohjelmistokehityksen elinkaari (SDLC). Scrum Model step by Step
Scrum framework mahdollistaa ketterän kehitysmenetelmän toteuttamisen. Toisin kuin ohjelmistokehityksen vesiputousmalli Scrum mahdollistaa iteratiivisen ja inkrementaalisen kehitysprosessin. Hanke jakautuu useisiin vaiheisiin, joista jokainen johtaa käyttövalmiiseen tuotteeseen. Jokaisen vaiheen lopussa (Scrum-terminologiassa sprint) asiakkaalle toimitetaan käyttökelpoinen tuote., Asiakaspalaute auttaa paljastamaan mahdolliset ongelmat tai muuttamaan alkuperäistä kehittämissuunnitelmaa tarvittaessa. Jos haluat, että projekti noudattaa tarkasti keskeiset periaatteet Agile manifesto, voit käyttää Scrum-malli ja olla varma, että olet oikealla tiellä.
Tässä ovat tärkeimmät roolit mukana kehitysprosessissa, mukaan Scrum-malli:
- tuotteen omistaja huolehtii loppukäyttäjän etuja;
- Scrum master koordinoi koko kehitysprosessia., Toinen tehtävä on varmistaa, että Scrumia käytetään oikein ja pitää säännöllisiä Scrum-kokouksia;
- Scrum-tiimi kehittää tuotetta. Sen päätehtävät ovat ohjelmointi, analysointi, testaus jne.
nyt katsotaan Scrumin muodostaman kehitysprosessin päävaiheita.
Scrum-mallin vaiheet
Vaihe 1. Tuotteen Kehitysjonon Luominen
tuotteen kehitysjono on lista, joka sisältää ominaisuuksia, toteutetaan aikana kehitysprosessissa. Se on tilattu priority ja jokainen kohde kutsutaan Käyttäjän tarina. Jokainen käyttäjätarina saa yksilöllisen tunnisteen., Pääsääntöisesti käyttäjätarinoilla on seuraava muoto: a , haluan niin, että . Alla olevasta listasta näet, miltä nämä tarinat voivat näyttää.,ange kesto ja alkamispäivä nykyisen niitä käyttäen vedä-ja-pudota niin, että voin arvioida koko hankkeen ajan
näiden Lisäksi pakolliset kentät, valinnainen niitä voidaan lisätä jos tarve:
- kappale valitaan kaikki käyttäjän tarinoita tietynlainen muuttaa niiden prioriteetti., Voit käyttää sitä lisätä prioriteetti käyttäjän tarinoita, jotka liittyvät Control panel, esimerkiksi;
- Komponentit muodostavat luettelon osat, jotka on muuttunut työn aikana. Sovelluksen moduulit, kuten todennus tai etsiä, esimerkiksi;
- pyytäjä on asiakas, joka on kiinnostunut täytäntöön joitakin erityisiä toimintoja;
- Bug tracking ID sisältää luettelon havaittu vikoja, jotka liittyvät asianmukaisen käyttäjän tarina.
Vaihe 2. Sprinttisuunnittelu ja Sprinttiblogin luominen
ensinnäkin kannattaa selvittää, mikä on sprintin kesto., Lyhyen sprintin avulla voit julkaista tuotteen työversion useammin. Tämän seurauksena asiakkaan palaute tulee useammin, ja kaikki mahdolliset viat ja virheet paljastuvat ajoissa.
vaihtoehtona voi suosia pidempää sprinttikestoa. Sen avulla kehittäjät voivat työskennellä perusteellisemmin. Optimaalinen sprintin kesto määritellään näiden kahden vaihtoehdon keskiarvoksi. Pääsääntöisesti Scrum-mallissa sprintti kestää noin 2-4 viikkoa. Tässä vaiheessa tärkeämpää on Sprinttitavoite. Tavoite määräytyy jokaisen sprintin osalta., Ja sen mukaisesti sprintti on täynnä käyttäjien tarinoita. Toinen tärkeä asia on sidosryhmien ja tiimin jäsenten välinen yhteistyö. Tuotteen omistaja määrittää asianmukaisen käyttäjätarinan tärkeyden, kun taas Scrum-tiimi määrittelee asianmukaiset työvoimakustannukset.
sen jälkeen Scrum-tiimi voi valita tuotteen taustajoukoista tärkeimmät käyttäjätarinat. Sitten tiimin jäsenten pitäisi päättää, miten he ratkaisevat tämän tai tuon tehtävän. Tiimi voi myös jakaa tietyt käyttäjätarinat pienimpiin ja muuttaa ne sitten tehtäväsarjaksi., Sprinttiruuhkan pitäisi syntyä seuraavaksi. Se koostuu käyttäjätarinoista, jotka valmistuvat nykyisen sprintin aikana. Määrä näitä tarinoita riippuu niiden kapasiteetti tarina pistettä kullekin tarinan aikana arviointi vaiheessa. Scrum-tiimin pitäisi pystyä viimeistelemään kaikki tarinat ajoissa.
Vaihe 3. Hiihdän sprinttiä. Päivittäiset Scrum-kokoukset
sen jälkeen kun varsinaiset käyttäjätarinat nykyvaiheeseen on valittu, alkaa kehitysprosessi.
nykyisen työprosessin seuraamiseksi käytetään yleisesti tehtävälautakuntaa., On yleensä isoja kortteja, joissa on tiettyjen käyttäjätarinoiden nimet ja nippu pieniä tahmeita muistiinpanoja, joissa on kuvaus yksittäisistä tehtävistä, joita tarvitaan tämän tai tuon tarinan toteuttamiseen. Jokainen tietty lautakunta on kehitetty hankkeen erityispiirteiden mukaan. Katsotaanpa pieni esimerkki.
kortit voidaan järjestää niiden tärkeyden mukaan. Kun työtehtävä on aloitettu, vastaava tarra siirretään ”to do” – kentästä ”in progress” – kenttään., Kun työ on valmis, tarra voidaan siirtää ”Testaus” – kenttään, ja kun tehtävä on onnistuneesti testattu, tarra menee ”Valmis” – kenttään. Esimerkki siitä, miten Scrum tehtävä hallitus voi katsoa, kuten on esitetty alla:
Siellä on myös mahdollisuus käyttää erikoistunut ohjelmisto tähän tehtävään.
esimerkiksi Atlassian JIRA.
toinen tärkeä Scrum-ominaisuus on päivittäiset Scrum-kokoukset., Näiden tapaamisten tärkein tavoite on saada täysi ja totuudenmukainen tietoa nykyisen projektin tila ja varmista, että kaikki tiimin jäsenet ovat samalla sivulla. Aikana Scrum-kokouksia, jokaisen tiimin jäsenen pitäisi kertoa, mitä hän tai hän on tehnyt Sprintin Tavoitteen, jonka tehtävänä on seuraavaksi ja mitä ongelmia tiimin jäsenet kohtaavat työn aikana.
lisäksi burndown chart on toinen laajalti käytetty työkalu, jonka avulla seuranta päivittäin prosesseja tehokkaasti. Se osoittaa, kuinka monta tehtävää on vielä kesken., Tämä kaavio antaa kyky hallita kehitysprosessia ja voidaan päivittää jokaisen kokouksen jälkeen.
päivä päivältä Scrum-kokoukset auttavat lisäämään kehitysprosessin joustavuutta. Ne mahdollistavat myös ymmärryksen siitä, mitä muutoksia pitäisi tehdä.
X-akseli edustaa jäljellä päivän työtä, kun taas Y-akseli näyttää kokonaismäärä tarina pisteitä vaiheessa. Sen jälkeen, kun tehtävä, joka vaatii tietyn määrän tarina pistettä loppuun on ohi, voit lisätä pisteen kaavion osoittamaan nykyisen edistystä.,
JIRA avulla voit luoda nämä kartat sekä:
Tämä kaavio auttaa johtopäätöksiä nykyinen nopeus työtä. Johtopäätöksistä riippuen seuraavan sprintin käyttäjäkertomusten määrää voidaan muuttaa.
on tärkeää huomata, että koska ihanteellinen tulos jokaisen sprintin Scrum-malli on toimiva tuote, koko elinkaaren testaus prosessi on erittäin tärkeää. On olemassa erilaisia tapoja minimoida testijakson kustannukset. Voit esimerkiksi vähentää käyttäjien kertomusten kokonaismäärää., Tämän seurauksena mahdollisten vikojen määrä minimoidaan. Toinen tapa on ottaa QA-insinöörit mukaan Scrum-tiimiin.
Lue Myös Miksi QA on Keskeinen Rooli Laadukkaan Ohjelmiston tuotekehitys
Vaihe 4. Tuotteen Lisäys ja Sprint Review
tuloksena jokaisen sprintin Scrum on mahdollisesti shippable product increment, että voidaan osoittaa asiakkaalle. Jokaisen iteraation, kehitystiimi luo uuden version ohjelmisto, lisääntynyt arvo., Sprinttikatsauksen aikana, joka on jokaisen sprintin loppuosa, kokonaistulokset voidaan osoittaa ja analysoida. Kaikkien näiden tietojen perusteella sidosryhmät voivat tehdä päätöksen hankkeen uusista muutoksista ja suunnitella seuraavan pikajuoksun.
Vaihe 5. Retrospektiivinen ja seuraava Sprinttisuunnittelu
retrospektiivinen päätavoitteena on keskustella tuloksista ja selvittää, miten kehitysprosessia voidaan parantaa seuraavassa vaiheessa., Tärkeä piirre on, että tässä vaiheessa keskustellaan työn ja vuorovaikutuksen prosesseista Scrum-tiimin työn parantamiseksi kokonaisuutena. Joukkueen pitäisi päätellä, mikä meni hyvin työprosessin aikana ja mitä voidaan tehdä paremmin tulevissa iterointia. Kun parannustavat on määritelty, joukkue voi keskittyä seuraavaan sprinttisuunnitteluun.
Johtopäätös
tärkeimmät erityispiirteet Scrum ovat ketteryys ja jatkuva edistyminen. Sitä tarjotaan useimmiten pysyvällä viestinnällä ja tiiviillä yhteistyöllä sidosryhmien välillä jokaisessa vaiheessa., Scrum-lähestymistapa edellyttää jatkuvaa iteratiivista ja inkrementaalista kehitysprosessia. Tavoitteena on varmistaa, mahdollisuus jatkuvasti lisätä tuotteen arvoa ja ylläpitää joustavuutta valita painopisteitä edelleen toistojen.
Kun sprintti on päättynyt, asiakas voi arvioida työ-tuotteen toimivuus nykyisellä iterointia ja tehdä tietoisen päätöksen siitä, miten hanketta tulisi kehittää seuraavassa sprintissä.,
vaikka mukaan Agile manifesto, sinun pitäisi mieluummin toimivaa ohjelmistoa yli kattavan dokumentaation, mikään ei estä kehittäjien käyttöön Ohjelmiston vaatimusmäärittelyn. SRS on hyvä sanomaan, mitä järjestelmän tai tuotteen pitäisi tehdä. Huolimatta siitä, että SRS voi olla huomaamatta joitakin ketteriä näkökohtia projektin kehittämiseen, kuten yhteistyötä, se voi silti olla hyvä työkalu suunnitteluun ja aikataulutus.