Valitse sivu

Agile sanasto

Agile sanasto – kaikki mitä olet halunnut tietää ketteryydestä, Scrumista, Kanbanista, eri rooleista ja termeistä

Mitä tarkoittaa Definition of Ready? Entä Burnup -kaavio? Tutustu tämän agile-sanaston avulla ketteryyden tärkeimpiin termeihin niin tiedät, mistä puhutaan!

Agile-terminologia kannattaa laittaa kuntoon, kun lähtee parantamaan ketteriä toimintatapoja. Huomaa kuitenkin, että erityisesti agilen rooleihin liittyvät vastuut vaihtelevat paljon organisaatiosta toiseen. Roolien vastuiden selventämiseksi kannattaa aina tehdä organisaatiossa omaa selvitystyötä.

Jos mielestäsi termistöstämme puuttuu oleellisia sanoja, niin niitä voi lähettää info@contribyte.fi osoitteeseen.

 

Termi Lyhenne Suomennos Määritelmä Linkkejä Contribyten koulutus / blogi
Acceptance Test Driven Development ATDD Hyväksyntätestiohjattu kehittäminen Tapa kehittää ohjelmistoja, missä kehittäjät ja asiakkaan edustajat (usein tuoteomistaja) kirjoittavat hyväksyntätestit ennen varsinaista ohjelmistokehittämisen aloittamista. Yhteinen hyväksyntätestien kirjoittaminen auttaa kehittäjiä ymmärtämään kehitettävältä toiminnolta vaaditut ominaisuudet. Wikipedia Scrum perusteet
Acceptance criteria AC Hyväksyntäkriteeri Hyväksyntäkriteerit määrittelevät, mitä kehitettävän asian tulisi tehdä ja millä tavalla sen tulisi toimia. Hyväksyntäkriteerien tulisi olla kirjoitettu ”maallikkokielellä”, niin että myös ei-ohjelmistokehittäjät tai testaajat ymmärtävät ne. Paras on, jos hyväksyntäkriteerit kirjoitetaan yhdessä tuoteomistajan ja kehitystiimin kanssa, tai niistä ainakin keskustellaan ennen työn aloittamista. Kriteerien listaus voidaan tehdä Sprintin suunnittelukokouksessa tai kehitysjonon jalostuskokouksessa. Hyväksyntäkriteerit voivat sisältää myös määrittelyä, miten kehitettävä asia toimii vikatilanteissa. Thinksys Scrum perusteetProduct Owner koulutukset
Acceptance tests   Hyväksyntätestit Hyväksyntätestit ovat seurausta hyväksyntäkriteereistä. Hyväksyntätestit on kirjoitettu testin muotoon, kun hyväksyntäkriteerit ovat enemmän vapaamuotoinen määritelmä tehtävälle asialle. Wikipedia Scrum perusteetProduct Owner koulutukset
Backlog   Kehitysjono Kehitysjonolla on kehitettävät asiat jonossa (duh!) prioriteettijärjestyksessä. Ainoa henkilö, joka saa priorisoida asioita on tuoteomistaja. Kehitystiimi aloittaa jonon kärjessä olevia asioita. Jonon kärjessä olevien asioiden pitäminen ”aloitusvalmiina” eli hyvin määriteltyinä, keskusteltuina ja tarpeeksi pieninä on tuoteomistajan vastuulla. Kehitysjono voidaan määritellä tuotteen (Product Backlog), Releasen (Release Backlog) tai Sprintin (Sprint Backlog) kokoisena. Scrum.org Scrum perusteetProduct Owner koulutukset
Backlog Grooming   Kehitysjonon jalostaminen Kehitysjonon laatua parantava, yleensä säännöllisesti toistuva kokous. Tässä kokouksessa tuoteomistaja ja kehitystiimi käyvät läpi kehitysjonolla olevia asioita, ja keskustelevat ja parantavat asioiden määritystä ja hyväksyntäkriteerejä. Jalostuskokouksessa voidaan myös havaita jonolta puuttuvia asioita ja myös poistaa asioita jotka eivät enää kuulu sinne (liian alhainen prioriteetti), sekä muuttaa asioiden prioriteettijärjestystä. Kutsutaan myös nimellä Backlog Refinement Agile Alliance Scrum perusteetProduct Owner koulutuksetBacklog grooming -blogi
Backlog Item BI Kehitysjonolla oleva asia Yksittäinen asia kehitysjonolla. Tämä voi olla EPIC, Käyttäjätarina (user story), tehtävä (task), korjausta vaativa virhe (bugi) tai muu asia. Scrum.inc Scrum perusteetProduct Owner koulutukset
Burndown -kaavio   Jäljellä oleva työ -kaavio Kaaviossa on aika X-akselilla ja jäljellä oleva työ Y-akselilla. Voidaan käyttää tuotteelle, releaselle tai Sprintille. Wikipedia Product Owner koulutukset
Burnup -kaavio   Valmiiksi saatu työ -kaavio Kaaviossa on aika X-akselilla ja valmiiksi saatu työ ja suunniteltu työ Y-akselilla. Voidaan käyttää tuotteelle, releaselle tai Sprintille. burn up vs burn down -blogi Product Owner koulutukset
Branch   Haara Ohjelmiston haara (kuten puussa oksa). Piste, jossa eri versiot ohjelmistossa lähtevät eroamaan toisistaan. Mitä enemmän haaroja ohjelmistotuotteesta on, sitä hankalammaksi käy tuotteen ylläpito. Testaus, kehitys ja korjaukset ovat moninkertaisesti hankalampia. Yleisesti tiimit pyrkivät minimoimaan ohjelmistohaarojen määrän. Mitä lähempänä pääkehityshaara on todistettua tuotannon laatua, sitä helpommin tiimi pystyy toimittamaan tuotantoon versioita. Täydellisesti automatisoitu testaus voi mahdollistaa myös jatkuvan tuotantoon siirron kehityshaarasta. Wikipedia  
Continuous Delivery   Jatkuva valmius tuotantoon siirtoon Jokainen koodimuutos testataan automaattisesti ja toimitetaan automaattisesti tuotannonkaltaiseen ”staging” ympäristöön, ja on siirrettävissä tuotantoon erikseen päätettäessä ”napinpainalluksella”. Puppet  
Continuous Deployment CD Jatkuva tuotantoon siirto Jokainen koodimuutos testataan automaattisesti ja toimitetaan tuotantoon automaattisesti. Wikipedia  
Continuous Integration CI Jatkuva integraatio Jokainen koodimuutos integroidaan, käännetään ja yksikkötestataan kaikkien muiden koodimuutosten kanssa. Kehittäjät laittavat muutoksia sisään versionhallintaan tiheästi (useita kertoja päivässä). Jatkuva integraatio pakottaa kehitystiimin tekemään asioita pienissä palasissa, ylläpitämään yhteensopivuutta muihin ratkaisun osiin ja ylläpitämään tuotannon kaltaista laatua myös kehityshaarassa. Thoughtworks  
Daily Scrum (tai pelkkä Daily)   Päivittäinen kokous Lyhyt, maksimissaan 15 minuutin päivittäinen kokous, jossa kehitystiimi koordinoi Sprintin aikaista tekemistä Scrum.org Scrum perusteet
Definition of Done DoD Valmiin määritelmä Lista asioita, jotka tiimi tai organisaatio on määritellyt sellaisiksi, mitkä pitää olla tehtynä, jotta asia voidaan katsoa olevan valmis. Samaa tuotetta tekevien ihmisten ja tiimien on syytä käyttää samanlaista valmiin määritelmää. Valmiin määritelmä auttaa arvioimaan työmääriä samalla tavalla. Yhteinen valmiin määritelmä auttaa myös ymmärtämään ilman pitkiä selityksiä mitä joku tarkoittaa kun hän sanoo saaneensa jotain valmiiksi. Tällä tavoin yhteinen DoD auttaa kasvattamaan luottamusta tiimin sisällä ja tiimien välillä. Agile Alliance Scrum perusteet,
Product Owner koulutuksetScrumin perusasiat -blogi
Definition of Ready DoR Työ, mikä on valmis aloitettavaksi Tiimi ei saisi aloittaa ihan millaista tarinaa tahansa. Tarina, joka aloitetaan ilman kunnon määrittelyä, venyy ja vanuu helposti ”kun on ihan kiva lisätä siihen toimintoja” ja ”ehkä se tarvitsee vielä tämän ominaisuuden”. Puutteellisesti määritellyt tarinat on mahdotonta sanoa milloin ne ovat valmiita! Tämä on eräs suurimpia tiimin hukkatyön syitä. Hyvät tiimit määrittelevät DoR:n jossa sanotaan esimerkiksi että asioilla mitä otetaan työn alle, on kunnon määritelmä, asiakastarve, hyväksyntäkriteerit ja tarvittaessa käyttöliittymäluonnos. Agile Alliance Scrum perusteetProduct Owner koulutukset
Development Team   Kehitystiimi Scrumin kehitystiimi sisältää tiimin jäsenet ja Scrum Masterin. Product Owner ei kuulu kehitystiimiin, mutta saa norkoilla lähettyvillä. Scrum.org Scrum perusteet
EPIC   Iso kehitysjonolla oleva asia Suurta kehitysjonolla olevaa asiaa voidaan kutsua EPICiksi. EPICit pitää pilkkoa pienempiin, Sprinteissä toteutettaviin palasiin ennen kuin työtä voidaan aloittaa. Agile Alliance Product Owner koulutukset
Estimate   Arvio Kehitysjonolla olevan asian toteuttamiseen arvioitu kuluva työmäärä. Arvio tehdään yleisimmin tarinapisteinä, mutta voidaan tehdä myös muilla tavoin (esimerkiksi ideaalitunteina tai -päivinä). Agile Alliance Scrum perusteetProduct Owner koulutuksetScrum Master koulutukset
Extreme Programming XP   90-luvun puolivälissä kehittynyt ohjelmistokehityksen metodi, joka koostuu useista eri käytännöistä. Moni XP:n käytännöistä on edelleen validi ja käytössä useissa Scrum-tiimeissä. Scrum ja XP ovat usein toisiaan täydentäviä metodeja. Agile AllianceAmazon Scrum Master koulutukset
Impediment   Este Yleensä liittyen tiimin Sprintille hyväksymään kehitysjonon asiaan. Tiimin jäsenet ovat törmänneet ongelmaan, joka estää tai merkittävästi hidastaa edistymistä, ja ovat yrityksistä huolimatta epäonnistuneet ratkaisemaan ongelmaa. Tällöin on kyseessä este. Scrum Masterin vastuulla on pyrkiä löytämään keinoja ratkaista este. Barry Overeem Scrum Master koulutukset
Information Radiator     Tiimin ”ilmoitustaulu” joka voi olla käsin piirretty, tulostettu, tai näyttö. Ilmoitustaulu sisältää hyödyllistä tietoa kaikille, jotka sen ohi kävelevät. Tieto voi olla esimerkiksi käännöksen tila, automaattitestien kattavuus, määrä ja tulokset, kehitysjonon tila, Sprintin tai releasen edistymiskäyrä… Agile Alliance  
Iteration   Iteraatio Voidaan myös käyttää nimitystä Sprintti. Tarkasti määritellyn mittainen ajanjakso (timebox – aikalaatikko, yleensä 1-3 viikkoa), joka toistuu ilman taukoja kunnes tarvittavat ominaisuudet tuotteeseen on saatu valmiiksi. Agile Alliance Scrum Master koulutuksetScrum perusteet
Kanban     Kanban on alunperin Toyotan tehtailleen kehittämä toiminnanohjausjärjestelmä, jossa työn kulku tiimin prosessin läpi visualisoidaan ”kanban taululle”. Työn visualisointi auttaa tiimiä huomaamaan, mitkä asiat ovat työn nopeamman virtauksen tiellä. Kanban auttaa erityisesti tilanteissa, joissa tiimille tulee eteen hankalasti ennustettavia ongelmia. Tiimit, jotka toimivat asiakastuessa tai lähellä sitä, voivat haluta käyttää Kanbania ennemmin kuin Scrumia. Myös Scrumissa käytetään yleensä kanban-taulua Sprinttiin valitun työn tekemisen visualisointiin. Plainview Scrum perusteet
Minimum Viable Product MVP   Termistä on kahta eri käyttötapaa. Vanhempi määritys MVP:lle tarkoitti pienintä mahdollista kokoelmaa ominaisuuksia, minkä voi viedä markkinoille. Modernimpi, Lean Startupin mukainen määritys MVP:lle tarkoittaa pienintä mahdollista kokoelmaa ominaisuuksia, minkä kehitystiimi voi tehdä tarkoituksenaan oppia lisää asiakkaan tarpeista ja tuotteen vaatimuksista. Jälkimmäinen, modernimpi määritys korostaa sen merkitystä, että tiimi tekee yleensä aina oletuksia, ja yleensä on hyvä idea rakentaa MVP versio tuotteesta validoimaan niitä oletuksia. Kumpaa tahansa määritelmää käytetäänkin, tärkeintä on, että kaikki organisaatiossa ymmärtävät mitä MVP:tä tarkoitetaan ja mitä tämä versio tuotteesta tekee. Lean Startup Product Owner koulutuksetTuotejohtaminen 2.0 -koulutusMitä MVP tarkoittaa -blogi
Pair Programming   Pariohjelmointi Osa Extreme Programmingin käytäntöjä. Pariohjelmoinnissa kaksi kehittäjää tekee työtä saman monitorin ääressä. Toinen kehittäjistä on enemmän havainnoimassa ja toinen enemmän tuottamassa koodia. Pariohjelmointi on nopea tapa tuottaa korkealaatuista koodia. Todellista pariohjelmointia näkee harmillisen harvoin. Wikipedia Scrum Master koulutukset
Persona     Persona on fiktiivinen käyttäjä, jonka motivaatiot, tarpeet ja käyttäjätavat auttavat kehitystiimiä asettumaan todellisen käyttäjän saappaisiin. Jos personat eivät ole käytössä, kehitystiimin on aika helppo alkaa suunnitella ohjelmistoa itselleen, joka yleensä johtaa siihen että lopputuote ei ole kovin helppokäyttöinen muille käyttäjille. Personat pitäisi tehdä yhdessä kehitystiimin ja organisaatiossa mahdollisesti olevien user experience -asiantuntijoiden kanssa, ja niiden olisi hyvä olla tiimihuoneessa kaikkien näkyvillä. Agile modeling Product Owner koulutukset
Planning Poker   Suunnittelupokeri Suunnittelupokerissa käytetään apuna pelikortteja, joissa on eri työmääräarvioita. Jokainen tiimin jäsen saa oman korttipakan. Kun aletaan arvioimaan jonkin asian työmäärää, ensin asian kuvailee tai kertoo tiimille asiakkaan edustaja (usein tuoteomistaja) tai joku muu henkilö. Sitten jokainen tiimin jäsen valitsee sopivan työmääräarviokortin ja näyttää sen yhtäaikaa muille. Jos arvioissa on eroja, tiimi keskustelee erityisesti suurimman ja pienimmän työmääräarvion esittäneiden ihmisten näkemyksistä. Tämä käytäntö auttaa paljastamaan kehitettävässä asiassa mahdollisesti olevia ”piilossa” olevia töitä, ja saa aikaan konsensuksen siitä miten isoksi työmäärä lopulta arvioidaan. Käytäntö auttaa saamaan asiat sprinteissä valmiiksi, ja parantamaan kehitysjonolla olevien asioiden laatua Wikipedia Scrum Master koulutukset
Product Backlog   Tuotteen kehitysjono Katso ”Backlog” yllä. Koko tuotteen kehitysjono, joka yleensä sisältää useamman releasen verran ominaisuuksia. Tuotteen kehitysjono ei kuitenkaan saisi olla liian pitkä. Liian pitkä kehitysjono johtaa tehottomaan kehitysjonon jalostamiseen, ja siihen että prioriteetissa alimpana olevia asioita ei saada koskaan tehdyksi. Tuoteomistajan vastuulla on ylläpitää tuotteen kehitysjonoa. Tärkein asia on sanoa joillekin pyynnöille ”EI”, eli pitää kontrolli siitä mitä tuotteen kehitysjonolle päästetään. International Scrum Institute Product Owner koulutukset
Product Owner PO Tuoteomistaja Tuoteomistaja on yksi Scrumin perusrooleista. Hänen vastuullaan on kehitysjonon ylläpito, sidosryhmien ja asiakkaiden kanssa kommunikointi, ja tuotteita kehittävien tiimien tulosten hyödyn maksimointi valitsemalla oikeat asiat kehitettäväksi. Suuri osa tuoteomistajan työtä on kommunikointia, määrittelyä ja priorisointia, mutta tuoteomistaja ei kuitenkaan saa unohtaa myös tiimin hyvinvointia ja oppimista, koska sillä on suuri vaikutus työtehoon ja tuloksiin. Scrum.org Product Owner koulutuksetTuoteomistaja – täysipäiväinen työ? -blogiTuoteomistaja – vastuut ja tehtävät -blogiTuoteomistaja vs Tuotepäällikkö -blogiTuoteomistaja vs Projektipäällikkö -blogi
Refactoring   Refaktorointi Refaktoroinnilla tarkoitetaan koodin uudelleenkirjoittamista tai rakentamista, ilman että koodin toteuttamat toiminnot muuttuvat. Refaktoroinin tavoitteena on koodin luettavuuden ja laadun parantaminen. Refaktorointia kannattaa tehdä jatkuvasti, aina kun koodiin kosketaan. Jos refaktorointia ei tehdä ja sen tarvetta harkita, johtaa se pitkässä juoksussa kehitysvauhdin hidastumiseen ”sammakko kuumassa kattilassa” tapaan, ja tuote tai organisaatio kuolee pois. Wikipedia Scrum perusteetScrum Master koulutuksetRefaktorointiblogi
Release R Julkaisu

Ketterässä toimintatavassa tiimi(t) pyrkivät vähintään joka sprintin lopussa saamaan valmiiksi julkaisukelpoisen tuotteen. Hyvät tiimit pystyvät ylläpitämään julkaisukelpoista tilannetta myös sprintin aikana. Tuoteomistaja päättää, milloin tehdään varsinainen julkaisu, eli annetaan tuote jonkin sidos- tai käyttäjäryhmän käyttöön. Erilaisia julkaisun ilmenenmismuotoja voi olla vaikkapa early access, sisäinen julkaisu tai alfa tai beta julkaisu. Julkaisut tyypillisesti numeroidaan major ja minor julkaisunumeroin, esimerkiksi 3.1.1.

Jos organisaatiossa on tapana julkistaa tuote jatkuvasti tuotantoon, julkaisun käsite voidaan ymmärtää myös käsittämään tietyllä ajanjaksolla toteutettavat toiminnot. Tällöin esimerkiksi vuoden 2020 ensimmäisen kvartaalin toteutetut toiminnot voisivat kuulua releaseen 20.1, vaikka ne julkaistaisiinkin juoksevasti koko ajan kvartaalin aikana. Tällöin julkaisu toimii enemmän suunnittelun apuna eikä niinkään varsinaisesti viittaa siihen, milloin käyttäjät saavat uudet toiminnot käyttöönsä.

AgileMind Scrum perusteetScrum Master koulutukset
Retrospective Retro Retrospektiivi Säännöllisesti toistuva tiimin kokous, jossa mietitään miten toimintaa voisi parantaa. Retrospektiivi kannattaa fasilitoida, yleensä Scrum masterin toimesta. Retrometodeja on paljon, ja käytettyä tapaa kannattaa vaihdella, jotta kokous ei muodostuisi tylsäksi pakkopullaksi. Scrum.org Retrospektiivi koulutus,
Hyvä retrospektiivi blogi
Scope   Määritelty laajuus Usein puhutaan ”Release scopesta” kun halutaan kuvata sitä osuutta tuotteen kehitysjonosta, joka on tavoitteena releasoida. Tiimin kehitysnopeutta (velocity) voidaan sitten verrata releasen määriteltyyn laajuuteen, ja tästä saadaan varsin tarkka arvio valmistumiseen tarvittavasta ajasta. Jos nopeus ei ole riittävä tavoiteaikatauluun, voidaan määriteltyä laajuutta pienentää. Mitä aikaisemmin tällaiset muutokset tehdään, sitä parempi. Itsadeliverything Product Owner koulutukset
Scrum     Suosituin ketterä kehitystoimintamalli. Scrum ei ole pelkästään ohjelmistokehitykseen soveltuva, vaan sopii kaikkeen toimintaan missä tulevat työtehtävät voidaan kuvata kehitysjonolle, ja missä voidaan antaa tiimille aikalaatikon (time box) mittainen kehitysrauha. Scrum.org Scrum perusteet
Scrum Master SM   Scrumin rooli. Scrum Masterin tehtäviä ovat muun muassa tiimin valmennus parempaan Scrumiin, esteiden poisto, tiimin seremonioiden fasilitointi ja tuoteomistajan apurina toimiminen. Scrum.org Scrum perusteetScrum Master koulutukset
Scrum of Scrums SoS   Usean tiimin yhteinen Scrum, tyypillisesti viikottain. Osa useita erilaisia ”skaalattuja” ketteriä metodeja. Agile Alliance Scrum Master koulutukset
Scrum Team     Scrum tiimiin kuuluu tuoteomistaja, Scrum Master ja kehitystiimi International agile Scrum perusteet
Sprint     Määrämittainen ajanjakso, yleensä 1-3 viikkoa, missä tiimi lupaa toimittaa valitut asiat tuotantolaatuisina, loppuun asti tehtyinä. Sprintin voi nähdä ”miniprojektina” jossa asioita saadaan valmiiksi. Pienissä palasissa tehty toiminnallisuus paljastaa tiimin todellisen nopeuden, ja auttaa suunnittelemaan julkaisun aikataulua ja sisältöä, ja välttämään projektin lopun pitkää kypsyttelyvaihetta. Yodiz Scrum perusteet
Sprint Backlog     Katso yllä ”Backlog”. Sprint backlog tarkoittaa niitä kehitysjonon asioita, jotka kehitystiimi lupasi toimittaa sprintin aikana tuotantolaatuisina. Sprintin kuluessa tiimi seuraa backlogin edistystä ”todo” tilasta ”done” tilaan, esimerkiksi sprint burndown-kaaviolla. Scrum.org Product Owner koulutukset
Sprint Planning     Sprintin suunnittelukokous, tyypillisesti pidetään sprintin ensimmäisenä päivänä. Kokous kestää noin 2-3 tuntia. Tuoteomistaja tuo kokoukseen ehdotuksen tärkeimmistä kehitysjonon asioista, ja tiimi keskustelee niistä ja päättää miten suuri osa niistä voidaan ottaa mukaan sprinttiin. Päätös perustuu historiatietoon (velocity) ja suunniteltuun kapasiteettiin (joka ottaa huomioon koulutukset, lomat yms). Suunnittelukokouksen tuloksena pitäisi syntyä Sprintin toteutussuunnitelma, joka saattaa sisältää yksittäisien kehitysjonon asioiden tekemiseen tarvittavat tehtävät (tasks) ja myös prioriteettijärjestyksen missä työt aloitetaan. Agile Alliance Product Owner koulutuksetScrum Master koulutuksetHyvä sprint planning blogi
Sprint Review     Sprintin katselmus, jossa käydään läpi mitä saatiin valmiiksi, mitä ei, mitä opittiin. Sprint review sisältää yleensä demon, jossa Sprintissä valmiiksi saatuja asioita demotaan tiimin sisällä ja sidosryhmille. Demo saattaa joskus olla myös erillinen kokous. Sprinttikatselmuksessa pitäisi keskustella myös siitä, ollaanko huomattu että backlogilta puuttuu jotain tai prioriteettijärjestys on muuttunut. Periaattessa sprinttikatselmus on myös paikka tehdä suuria suunnanmuutoksia (”pivot”). Scrum.org Scrum Master koulutuksetSuper-seremonia hyvä demo
Sprint Goal   Sprintin tavoite Tuoteomistaja määrittelee sprintin tavoitteen. Tavoite auttaa tiimiä priorisoimaan asioita sprintin sisällä. Scrum.org Product Owner koulutukset
Story Mapping   Käyttäjätarinakartta Keino visualisoida ja järjestää tuotteen ominaisuuksia hierarkisesti. Käyttäjätarinakartta voi myös auttaa release suunnittelussa ja tarinoiden pilkkomisessa ja sen huomaamisessa, onko kaikki tarinat listattu kehitysjonoon. Aha Product Owner koulutukset
Story Point   Tarinapiste Tapa arvioida kehitysjonolla olevien asioiden työmäärää. Yleensä ohjeena on, että tarinapistettä ei sekoiteta kalenteriaikaan, mutta ei se nyt niin vakavaa ole jos niin tehdään. Ideana kuitenkin on että pienet tarinat ovat 0.5 tai 1 pistettä, ja sitten isompia tarinoita verrataan niihin. Tiimin kannattaisi asettaa ”yläraja” sille miten suuren arvion saaneita tarinoita sallitaan aloittaa. Suurempien tarinoiden määrittely on paljon vaikeampaa, ja saattaa johtaa siihen että niitä ei saada valmiiksi ja ne vuotavat seuraavaan Sprinttiin. Story pointin sijaan tiimi saattaa haluta arvioida työmääriä myös ”ideaaliajassa” esim ideaalitunneissa tai ideaalipäivissä. Tämä on aivan sallittua. Eri tiimien arvioita ei voi verrata toisiinsa. Mike Cohn Product Owner koulutukset,
Scrum perusteet
Story Splitting   Tarinoiden jakaminen Tarinoiden jakaminen pienempiin, kunnes ne ovat tarpeeksi pieniä toteutettavaksi. Tarinoita voidaan jakaa milloin vain, mutta yleensä se tehdään Backlog Grooming/refinement kokouksessa, Sprintin suunnittelukokouksessa, tai hankkeen alussa kun tuotteen backlogia rakennetaan esimerkiksi Story mappingin avulla. Tarinoita voidaan jakaa monella eri tavalla, mutta pääasia olisi se, että jakaminen tehdään niin että jokainen tarina tuo pystysuunnassa toimintoja loppukäyttäjälle. Väärin jaettu on, jos tehdään yhdessä tarinassa käyttöliittymä, toisessa backend, ja kolmannessa testataan. Hyvä tarinoiden jakotapoja kuvaava juliste löytyy linkeistä. Agileforall story splitting poster Product Owner koulutukset
Super-seremoniat     Contribyten termi, joka viittaa parhaisiin mahdollisiin käytäntöihin eri agile-seremonioissa   Scrum Master koulutukset
Technical Debt   Tekninen velka Tekninen velka kuvaa tilannetta, missä tiimi ”menee helpoimman kautta” eli tekee toimintoja harkitsematta refaktorointitarvetta, koodin luettavuutta, testattavuutta tai robustisuutta. Jos teknisen velan annetaan jatkuvasti kasvaa, se pitkällä tähtäimellä hidastaa tiimin nopeutta, koska asiat muuttuvat vain koko ajan hankalammiksi. Purkkaviritysten teko yhden kerran voi olla perusteltua, mutta koko talon rakentaminen purukumista on itsemurhaa. Vastuu teknisen velan kasvun välttämisestä on kehitystiimillä, ei kenelläkään muulla. Jos kehitystiimi ei ota tätä vastuuta itselleen, vastuu valmentaa tiimiä ottamaan se on Scrum Masterilla. Tuoteomistajan kannattaa olla varuillaan tiimin kanssa, joka on liian innokas toimittamaan featureita, mutta ei tunnu välittävän pitkän aikavälin koodin terveydestä. Wikipedia Scrum Master koulutukset
Test Driven Development TDD Testiohjattu kehittäminen Läheisesti sidoksissa ”hyväksyntätestiohjattuun kehittämiseen” (ATDD). TDD ja ATDD erot ovat lähinnä siinä että ATDD keskittyy business ja asiakasymmärryksen lisäämiseen ja keskusteluun kehitystiimin ja asiakasta ymmärtävän tiimin välillä, sellaisella kielellä että molemmat ymmärtävät mistä puhutaan. TDD keskittyy tilanteisiin missä ongelma on hyvin ymmärretty, ja kehittäjä lähtee liikkeelle koodaamalla yksikkötestit ensin, ja sitten alkaa lisäämään toteutusta kunnes yksikkötestit menevät kaikki läpi. Sinällään kummatkin ovat tarpeellisia – on hyvä aloittaa ATDD-tyyppisellä keskustelulla ja sitten edetä TDD-tyyppiseen toteutukseen. Reqtest  
Timebox   Aikalaatikko Aikalaatikko kuulostaa Hollywood-elokuvalta, mutta joo, näin se suomennetaan. Tämä tarkoittaa ketterässä kehittämisessä sekä iteraatioiden pitämistä saman mittaisena (ja sitä ettei iteraatioiden välissä pidetä taukoja, vaan seuraava alkaa välittömästi edellisen loputtua), että myös sitä että seremoniat on timeboxattu tietyn mittaisiksi, eli että kokoukset ei veny. Agile Alliance  
Unit Testing UT Yksikkötestaus Yksikkötestauksessa koodi, mikä lopulta toteuttaa halutut loppukäyttäjälle tarjotut toiminnot, testataan pienissä osissa. Tyypillisesti yksikkötestaus tarkoittaa, että koodin jokaiselle funktiolle kirjoitetaan omia testejä. Testit kirjoittaa yleensä ohjelmistokehittäjä. Testit kirjoitetaan vaatimusten ja hyväksyntäkriteerien pohjalta. Yksikkötestit ajetaan automaattisesti jatkuvan integraation käännöksien jälkeen, ja tällöin paljastuu jos muutokset ovat rikkoneet mitään vanhoja toimintoja. stackoverflow Scrum perusteetScrum Master koulutukset
Usability Testing   Käytettävyystestaus Käytettävyystestaus on metodi, missä testaavat henkilöt pyrkivät arvioimaan onko kehitetty toiminnallisuus tarpeeksi helppo käyttää. Tässä auttaa personoiden käyttäminen. Käytettävyystestaukseen on myös olemassa spesialisteja, mutta käytettävyystestausta voi tehdä myös kehitystiimin ja tuoteomistajan voimin.  Käytettävyystestausta voi tehdä joko havainnoimalla oikeita käyttäjiä, tai sitten niin että testausta tekevä henkilö kuvittelee itsensä oikean käyttäjän housuihin. Agile Alliance  
User Story   Käyttäjätarina Käyttäjätarinan perusjuttu on että se kuvaa toteutettavan toiminnon käyttäjän näkökulmasta. Hyvässä käyttäjätarinassa kuvataan käyttäjärooli, asia mitä käyttäjä haluaa, ja sitten se motivaatio MIKSI käyttäjä sen asian haluaa. Tämä ohjaa tiimiä määrittelemään asian oikein ja priorisoimaan asian oikein. Tiimi jatkaa vielä tämän jälkeen tarkentamalla käyttäjätarinan määrittelyä hyväksyntäkriteereillä. Näin kerrottuna tarina on paremmin käsiteltävissä ja arvioitavissa. Mike Cohn Product Owner koulutukset
Velocity   Tiimin nopeus Tiimin nopeus eli velocity on paras tiedonlähde sen ennustamiseen, milloin tietty määritelty laajuus (scope) saataisiin nykytiedon valossa valmiiksi. Velocity mitataan sen perusteella kuinka paljon kehitysjonon asioita ollaan saatu todellisesti valmiiksi tietyssä aikayksikössä. Scrumia käyttävät tiimit mittaavat velocityä per sprintti. Kanbania käyttävät mittaavat esimerkiksi per viikko. Avainasiana on, että on myös määritelty DoD eli valmiin määritelmä. Muuten velocitystä ei ole paljoakaan hyötyä. Agile alliance Scrum perusteet
Version Control   Versiohallinta Järjestelmä, mihin kehittäjät laittavat koodin, ja mikä seuraa jokaisen tiedoston versioita. Nykyään ohjelmistokehitys ilman versiohallintaa on käytännössä mahdotonta (ja turhaa – sen verran helppoja ja halpoja työkalut ovat). Versiohallintaohjelmistoja on paljon, suosituimpia ovat versionone, TFS ja git. Gitistä on myös maksullisia versioita jotka toimivat muiden työkalujen kanssa saumattomasti kuten Atlassianin Bitbucket. Atlassian git tutorial

Contribyte yhteystiedot

Lasse Mikkonen, teknologiajohtaja 040 543 9845
Harri Pendolin, tuotejohtaminen 040 582 0865
Markku Nurmela, valmennuspalvelut 040 501 5094
Timo Leppä, koulutuspalvelut 0400 924 830
Niklas Tikkala, työkalun palvelupäällikkö 040 681 8585
Henri Hämäläinen, toimitusjohtaja 050 487 3291

Sähköposti - info@contribyte.fi tai etunimi.sukunimi@contribyte.fi

Laita viestiä

6 + 6 =

Share This