Käytänteet ja menetelmät
Luvussa on listattu ne käytänteet, joita tulisi hyödyntää toimeksiannon tekemisen aikana.
Tuotteen kehityksen aikana kehitystiimin tulee näyttää osaavansa soveltaa opetettuja käytänteitä ja menetelmiä. Luvussa on kuvattu ne käsitteet, käytänteet, menetelmät ja periaatteet, joita kehitystiimin tulisi noudattaa. Kyseisiä osa-alueita arvioidaan tuotteen kehityksen etenemisen aikana sekä myös lopputulosta arvioidessa.
Menetelmät on pyritty kuvaamaan siinä järjestyksessä kuin ne toistuisi ajallisesti. Tämä on vain tehty sisällön hahmottamista varten mutta todellisuudessa eri menetelmät ja vaiheet voivat tapahtua limittäin. Osa asioista on myös kuvattu vain vinkkeinä ja ohjeistuksina, joita kehitystiimi voi hyödyntää tuotteen kehityksen aikana. Tällaisia asioita voivat olla mm. ajankäyttöön liittyvät tavat.
Sprintin aikana tapahtuvat tehtävät
Sprintti on termi, joka tulee Agile sanastosta. Alla on lueteltu niitä tehtävänosia, joita tuotteen kehittämisen aikana tulisi noudattaa. Lista on tehty vain tämän tuotteen kehittämistä varten ja on hyvä muistaa, että se ei ole kiveen lyöty ratkaisu.
Tarvittaessa kehitystiimi saa muuttaa työskentelytapojaan mutta ne tulee perustella hyvin miksi jokin vaihe jää pois tai mitä uutta on tullut tilalle. Pääsääntönä on, että vähintään seuraavat vaiheet tulisi käydä läpi tuotteen kehittämisen aikana.
Sprintin kestoksi on ennalta määritetty 1 viikko ellei toisin mainita.
Määrittely
Tapahtuu aina joka sprintin alussa.
Määrittelyssä tarkoitus on määrittää alkavalle sprintille tulevat tehtävät. Määrittelyä tehdään aina sen kautta tulisi ymmärtää syvemmin ratkaistavaa ongelmaa. Tähän osallistuu aina tuotteen omistaja, kehitystiimi sekä tarvittaessa muut asiaakn kuuluvat henkilöt. Tarkoitus ei ole suunnitella kaikkea etukäteen vaan pyritään tekemään suunnitelma 1-2 viikon päähän.
Käyttäjätarinat
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.
Muun käytetyn materiaalin lisäksi katso seuraavat linkit.
Käyttötapauskuvaukset
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.
Muun käytetyn materiaalin lisäksi katso seuraavat linkit.
Kts. User Stories linkki
Tuotteen tehtävälistan määritys
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.
Muun käytetyn materiaalin lisäksi katso seuraavat linkit.
Backlog
Sprintin tehtävälistan määritys
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.
Muun käytetyn materiaalin lisäksi katso seuraavat linkit.
Ohjelmointi
Ohjelmointi on osa työtehtäviä. Joskus sen määrä on suurempi kuin muiden työtehtävien määrä mutta on hetkiä, jolloin sprintti voi sisältää vähän ohjelmointia. Tällöin kyseessä voi olla esimerkiksi enemmänkin tutkiva sprintti, jossa haetaan pohjaa seuraavan sprintin aloittamiseen.
Alla on lueteltu niitä kohtia, joita olisi hyvä ottaa huomioon ohjelmoinnin aikana.
Versionhallinta
Kts. Versionhallinan perusteet
TDD (testivetoinen kehitys)
Kts. yksikkötestauksen perusteet
Kts. yksikkötestauksen perusteet
Dokumentointi
Ohjelmiston tulisi sisältää myös siihen liittyvä dokumentaatio. Välttämättä kaikki dokumentaatio ei kulje lähdekoodin mukana mutta on hyvä kirjoittaa vähintään ylös miten uusi kehittäjä voi päästä alkuun tuotteen kehittämisessä.
Sprintin lopetus
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.
Sprintin katselmointi
Tuoteversio (Increment)
Kts. Scrum guide ja etsi sana increment.
Sprintin retrospektiivi
Tuoteversio (Increment)
Kts. Scrum guide ja etsi sana increment.
Sprint 0
Sprint 0 ei ole oikeasti olemassa vaan se voi tapahtua jo ennen tuotekehityksen alkua, jolloin varsinaisia kehityskohteita ei ole vielä oikein määritetty. Toisinaan kyseinen vaihe voi olla myös otettu osaksi tuotteen kehitystä. Sprint 0 tarkoittaa usein seuraavia toimenpiteitä, jotta kehitystyö voidaan aloittaa.
Valmistellaan työasemat
Valmistellaan yhteisiä työtapoja
Valmistellaan versionhallintaan liittyvät asiat kuten esimerkiksi palvelujen käyttöönotto
Valmistellaan tarvittavat ohjelmistot ja muut tekniset asiat
Tavoite on vain tehdä ne toimenpiteet, että voidaan aloittaa tuotteen kehitys. Ylläoleville kohdilla pääsee alkuun mutta se voi sisältää myös paljon muita asioita riippuen kehitettävästä tuotteesta ja kehitystiimistä.
Muut käsitteet
Muita hyödyllisiä tapoja, menetelmiä tai käsitteitä, jotka auttavat työskentelyssä sekä keskittymisessä. Mainitut asiat on hyvä tuntea, koska niillä on aina oma paikkansa ja kun opit esimerkiksi hallitsemaan omaa ajankäyttöäsi, sillä on suuri vaikutus työskentelyn laatuun.
Pomodoro
Ajankäyttöä parantava tekniikka. Suosittelen kokeilemaan ja ottamaan käyttöön omaan tekemiseen. Lyhyen opettelun ja tutustumisen jälkeen huomaat paljon paremmin keskittyväsi työskentelyyn ja et häiriinny keskeytyksistä.
SOLID -periaatteet
SOLID on akronyymi viidelle tekniikalle, joiden avulla voit kirjoittaa laadullisempaa lähdekoodia. Kyseinen aihe ei liity projektin suorittamiseen mutta on isossa osassa aidoissa asiakasprojekteissa. Hyvä lähtökohta ohjelmoijille, jotka haluavat kehittyä kirjoittamaan laadukkaampaa lähdekoodia. Kyseiset tekniikat ovat vain yksi monista taidoista, joiden kautta taidot kehittyvät.
Last updated
