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
Requirements 1010: User Stories vs. Use Cases
User Stories Versus Use Cases
Basic Use Case template, Alistair Cockburn

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.

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.

Sprint Backlog

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

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

Sprint Review

Tuoteversio (Increment)

Kts. Scrum guide ja etsi sana increment.

Sprintin retrospektiivi

Sprint Retrospective

Tuoteversio (Increment)

Kts. Scrum guide ja etsi sana increment.
Sprint Review
Sprint Retrospective

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.

PreviousToimeksianto 2019/01 NextKonsoliohjelman refaktorointia

Last updated 7 years ago