Agile esimerkki, sykli
Last updated
Last updated
Esimerkissä on kuvattu yksittäisen syklin (sprintti, vaihe, sykli, iteraatio jne.) kierto ja mitä se sisältää. Syklin sisältö on kerätty omien kokemusten perusteella ja se saattaa yhdistellä useita eri menetelmiä. Tarkoituksena on kuitenkin antaa esimerkki ja sen kautta harjoitusprojektin yhteydessä noudattaa ohjeistettua tapaa.
Käyttäjätarina -kuvaus
Käytämme käyttäjätarinoihin Role-Feature-Reason tapaista kuvausta. Syvempi kuvaus ei ole tässä kohdin tärkeä vaan yritetään ensin muodostaa ymmärrettävä lause, joka muodostuu mallin mukaisesti.
Usein tarkempi määrittely ja kuvaus voidaan kirjoittaa ennen tarinan toteuttamista tai jopa ennen sitä suunnitteluvaiheessa, jossa mukana on henkilö, joka tuntee tämän tarinan sisällön. Liian tarkkaan ei tarvitse määritellä vaan pystyä tekemään kuvaus, jolla priorisoidaan tarve. Käyttötapauksia voidaan hyödyntää toteuttamisvaiheen alussa ja tehdä tarkempi suunnitelma miten ominaisuudet toimivat.
Käyttötapaus -kuvaus
Kts. User Stories linkki
Käyttötapaus on dokumentti mikä voidaan kirjoittaa esimerkiksi käyttäjätarinan perusteella. Huomaa lähteissäkin, että ne pyrkivät kertomaan mikä ero on käyttäjätarinalla ja käyttötapauksella. Lyhyesti, käyttötapaus voidaan nähdä tarkempana määritelmänä miten ohjelma kommunikoi eri osapuolten kanssa ja toteuttaa halutun tavoitteen.
Tuotteen -backlog
Tuotteen tehtävälista on dokumentti, joka ohjaa kehitystä. Se muuttuu aika ajoin ja pääasiassa tuotteen omistaja huolehtii siitä. Kehitystiimi kuitenkin osallistuu tähän myös tarvittaessa ja varsinkin kun tehtäviä otetaan seuraavaan sykliin.
Syklin (sprintin) -backlog
Syklin tehtävälista on dokumentti, johon on valittu ne tehtävät mitkä kehitystiimi "lupaa" tehdä. Tarkoitus on, ettei valita liikaa vaan voidaan melko tarkasti sanoa, että ne toteutuvat. Tehtäviä katsotaan läpi aina syklien lopussa ja siivotaan sekä korjataan olettamuksia.
Versionhallinta
Kts. Versionhallinan perusteet
Yksikkötestaus ja TDD
Kts. yksikkötestauksen perusteet
Kts. yksikkötestauksen perusteet
SOLID -sääntö/ohje
SOLID säännöstä ei ole muuta kirjoitettua materiaalia tässä kirjassa. Lähteet auttavat sinua tutustumaan aiheeseen ja varsinkin Robert Martinin video on valaiseva. Kyseinen henkilö on säännön luonut eri kokemuksien pohjalta. Säännön tarkoitus on koostaa hyviä tapoja olio-ohjelmoinnin luokkien ohjelmointiin ja parantaa koodin laatua. Käytännössä on kyse ohjelmoinnista ja vain vinkata mitä huomioida kun ohjelman koodia tuotetaan ja kuinka se auttaa myöhemmin muutosten tekemisessä.
Tuoteversio (Increment)
Kts. Scrum guide ja etsi sana increment.
Lyhyesti tarkoitetaan sitä, että kehitystiimi on lisännyt tuotteeseen ominaisuuksia, jotka tarvittaessa tuotteen omistajan hyväksymisen jälkeen voidaan julkaista. Julkaisu ei ole pakollinen vaan isompi julkaisu voidaan tehdä useammassa syklissä. Tärkeintä on, että tuote on aina julkaisuvalmis tarvittaessa, koska välttämättä kaikkien ominaisuuksien ei tarvitse olla valmiita. Tämä on ketterän ohjelmistokehityksen tavoite. Tehdä vähän, julkaista ja oppia tuotteesta. Tällöin riskit voidaan rajat esimerkiksi 2 viikon jaksoihin kuukausien sijasta.
[1]
[2]
