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 perusteet, Product 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 perusteet, Product 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 perusteet, Product 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 perusteet, Product Owner koulutukset, Backlog 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 perusteet, Product 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 koulutukset, Scrumin 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 perusteet, Product 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 perusteet, Product Owner koulutukset, Scrum 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 Alliance, Amazon | 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 koulutukset, Scrum 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 koulutukset, Tuotejohtaminen 2.0 -koulutus, Mitä 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 koulutukset, Tuoteomistaja – täysipäiväinen työ? -blogi, Tuoteomistaja – vastuut ja tehtävät -blogi, Tuoteomistaja vs Tuotepäällikkö -blogi, Tuoteomistaja 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 perusteet, Scrum Master koulutukset, Refaktorointiblogi | |
| 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 perusteet, Scrum 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 perusteet, Scrum 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 koulutukset, Scrum Master koulutukset, Hyvä 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 koulutukset, Super-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 perusteet, Scrum 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
Email - info@contribyte.fi