Käytänteet ja menetelmät
Luvussa on listattu ne käytänteet, joita tulisi hyödyntää toimeksiannon tekemisen aikana.
Last updated
Luvussa on listattu ne käytänteet, joita tulisi hyödyntää toimeksiannon tekemisen aikana.
Last updated
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.
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.
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ä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ö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ä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.
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 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.
Kts. Versionhallinan perusteet
Kts. yksikkötestauksen perusteet
Kts. yksikkötestauksen perusteet
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ä.
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.
Kts. Scrum guide ja etsi sana increment.
Tuoteversio (Increment)
Kts. Scrum guide ja etsi sana increment.
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ä.
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.
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 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.
