Spread the love
Reading Time: 2 minutes

Tech spikes: pienet ja suuret testit & oppimiset työelämässä

"Spike" on termi joka tarkoittaa pientä normaalista
rutiinikehittämisestä poikkeavaa teknologista testiä / miniprojektia. Kuulin termin ekaa kertaa 2015 tienoilla softahommissa. Spike on mielenkiintoinen konsepti. Erityisesti viehätti sen nivelyminen "legopalikkamaiseen" ajatteluun, missä tavallaan oppimista voi konkreettisesti paketoida ja itse oppimisprosessin voi myös mahdollisesti jakaa muiden kanssa paremmassa muodossa kuin missä itse sen on vastaanottanut.

Varsinaisissa softaprojekteissa tulee usein vastaan oppimista ja epävarmuutta; uusia tuttavuuksia.

Tällöin kannattaa tehdä pieni erillinen testi jolla voidaan todentaa hypoteesit; tai kumota oletukset. Testi näyttää onko jokin asia mielekäs tehdä, tai ylipäätään tehtävissä.

Onko erillinen 'spike' perusteltua?

Oman kokemukseni perusteella, kyllä! Suosittelen - eli sen sijaan että antaa erilaisten teknologioiden viedä sivuhuomiota tai jatkuvasti "kyykyttää" aikatauluja, on parempi toisinaan selkeästi keskittyä tekemään yksi hallittu testi.

Älä nipistele perusasioiden kanssa: "plan"

Spike kannattaa mitoittaa normaalisti; se käyttäytyy usein lopulta aika lailla kuten muutkin ohjelmistoprojektin palaset: joskus mennään alle suunnitellun toteutusajan, toisinaan yli. Nipistelyllä tarkoitan sitä, että vaikka kyse on erillisestä oppimisesta, sille kannattaa silti varata myös aikansa ja paikkansa, sekä rakenne.

Jos itse tuotteen roadmap ja tarpeet ovat jotakuinkin selvillä, voidaan myös tällöin helposti napata samaan sprinttiin varmuudeksi myös seuraava spike - kunhan näillä on keskenään jokin looginen yhteys.

Eteenpäin "hiihtämällä" ilman tavoitteita voi helposti käydä niin, että puurot ja vellit menevät sekaisin: tuleekin liikaa uutta kerralla, ja voi olla
vaikea ymmärtää tai hahmottaa mistä jumitus kiikastaa.

Spike selkeyttää asioita tiimissä niin team leadille (projektivastaavalle) kuin tekijällekin.

Ihan konkreettisesti näin voi käydä jos esimerkiksi rakentaa CI -putkea (continuous integration) lätkimällä erilaisia komponentteja järjestelmään mutta ei malta tutustua niiden konfigurointiin, tai esimerkiksi komponentin soveltuvuusalueisiin.

Komponentti saattaa olettaa tiettyjä asioita toimintaympäristöstä, joita itse ei ole huomannut dokumentaatiosta (aina dokumentaatiota ei myöskään ole - asiat pengotaan lähdekoodista ja netin keskusteluista).

Spike: pre-flight check list

  • Mihin tarpeeseen opettelet?
  • aseta tekniselle testille selkeä maali ja polku: palasista kokonaiseksi
  • selvitä suurinpiirtein teknologian taustat; milloin ja millaiseen
    käyttöön kyseinen teknologia syntyi?
  • esimerkiksi:
    • "Karma" oli alunperin Googlen sisäinen yksikkötestaustyökalu, nimeltään Testacular
    • keskeisenä voimahahmona kehittäjä nimeltä Vojta Jina
    • Vojta esittelee v. 2012 tekniikan tällä videolla:
      https://www.youtube.com/watch?v=5mHjJ4xf_K0
    • videon katsomalla ymmärtää taustat helposti
  • saatat esimerkiksi tarvita syvempää osaamista aihepiiristä..
  • tai tiedät, että pitää oppia täysin uusi teknologia
  • esimerkkinä: en osaa Djangoa (Python framework)
  • asetetaan maalit:
    1. ymmärrän Djangon perusperiaatteet ja kykenen selittämään ne alle 1 minuutissa
    2. käsitän, miten Django eroaa ja toisaalta on yhtenäinen "kilpailijoiden"
      suhteen
    3. saan Python-serverin (paikallinen) pyörimään
    4. Djangon framework asennettuna omalla läppärilläni
    5. osaan koodata Djangon päälle pienen testiohjelman, jolla näytän sen että osaan myös
      käytännön
  • säilö opetusreissut toisille tiimissä
  • laita "git":llä pakettiin
  • sopiva määrä committeja -> esimerkiksi ainakin
    1. initial commit -> aivan perusasiat, voi olla vaikka pelkkä README tai TODO lista
    2. infra kunnossa -commit
    3. kirjoita myös README.md (dokkariin) miten tarkkaan ottaen tuleva käyttäjä
      voi kävellä askeleesi omalla koneellaan
    4. jne
  • tee koko spike siten kuin "oikeasti tekisit" myös projektia
  • ennen kehittämistä, tee aikamääräarvio: hyödyt myöhemmin, vie vain hetken
  • pilko projekti selkeisiin aliosasiin
    • sub tasks
  • määrittele funktionaalinen selkeästi mitattava maali
  • tutki miten hyvin tai huonosti arviosi osuu maaliin
  • jaa myös tämä kokemus ja mahdolliset opit itse arviointimenetelmän suhteen muille
  • mitä odottamatonta tapahtui matkalla?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.