SANASTO | SAFe® 4.0 Sujuvaan ja ketterään ohjelmistojen ja

®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
SANASTO | SAFe® 4.0 Sujuvaan ja ketterään ohjelmistojen ja
järjestelmien kehittämiseen
Arkkitehtuurin kiitorata (Architectural Runway)
Arkkitehtuurin kiitorata toimii yhtenä SAFen keinoista toteuttaa ketterän arkkitehtuurin periaatteita.
Tämä kiitorata on juuri oikeaan aikaan tuotettu välttämätön tekninen perusta liiketoiminnan
kehitysaihioiden (Epic) kehittämiselle sekä uusien toiminnallisuuksien (Features) ja kyvykkyyksien
(Cababilities) toteuttamiselle. Arkkitehtuurin kiitorata toteutuu, kun yrityksen alustoilla on riittävästi
olemassa olevaa infrastruktuuria, joka ilman ylenmääräistä, hidastavaa uudelleensuunnittelua tukee
korkeimman prioriteetin lyhyen aikavälin toiminnallisuuksia.
Arvovirran inkrementin tavoitteet (Value Stream PI Objectives)
Inkrementin suunnittelun jälkeisen suunnittelutapaamisen aikana toimitusjunan tavoitteet vedetään
yhteen arvovirtatasolla, jolloin niistä tulee arvovirran tavoitteita. Nämä ovat SAFen inkrementin
korkeimman tasoiset tavoitteet, jotka viestivät sidosryhmille, mitä arvovirta kokonaisuutena tulee
julkaisemaan seuraavassa inkrementissä.
Arvovirran kehitysaihiot (Value Stream Epics)
Arvovirran kehitysaihiot ovat aloitteita, jotka ovat laajuudeltaan riittävän suuria analyysin ja kevyen
liiketoimintamallin perusteeksi (ks. Kehitysaihio), mutta rajoittuvat kuitenkin vain yhteen arvovirtaan.
Arvovirran kehitysaihiot poikkeavat pienistä, inkrementteihin mahtuvista kyvykkyyksistä (Capability)
siten, että niiden kehittäminen saattaa kestää useamman inkrementin (PI) ajan. Ne voivat ilmetä
salkun kehitysaihioiden seurauksena tai paikallisesti, kun arvovirrat suunnittelevat laajempia aloitteita
Arvovirran kehitysjono (Value Stream Backlog)
Arvovirran kehitysjono on määritelty tallennuspaikka kaikelle tulevalle työlle, joka oletetaan tarvittavan
ratkaisun kehittämiseksi. Kehitysjono koostuu tulevista kyvykkyyksistä, jotka voivat vaikuttaa
useampaan toimitusjunaan (ART), sekä mahdollistajista, jotka edistävät oppimista sekä arkkitehtuurin
kiitoradan riittävyyttä.
Arvovirran kehityspäällikkö (Value Stream Engineer)
Arvovirran kehityspäällikkö johtaa arvovirran prosesseja ja toteutusta. Hän eskaloi esteitä, hallitsee
riskejä sekä osaltaan auttaa arvon toimittamisen ja jatkuvan prosessien parantamisen
varmistamisessa.
Arvovirran koordinointi (Value Stream Coordination)
Arovirran koordinointi tarjoaa ohjeet salkun sisältämien arvovirtojen välisten riippuvuuksien
hallitsemiseksi.
Arvovirran valmisteluseinä (Value Stream Kanban)
Arvovirran valmisteluseinä auttaa varmistamaan, että arvovirran kehitysaihiot ja kyvykkyydet
perustellaan ja analysoidaan ennen inkrementin aloittamista, ja varmistaa että nämä on
asianmukaisesti priorisoitu, ja niille on luotu täsmällisen toteuttamisen määrittelevät
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
2
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
hyväksymiskriteerit.
Arvovirrat (Value Streams)
Arvovirrat ovat SAFen ensisijainen rakenne arvon ymmärtämiseen, organisoimiseen ja
julkaisemiseen.. Jokainen arvovirta on pysyvähkö kokoelma työvaiheita, joita yritys tekee
toteuttaakseen jatkuvan arvon julkaisemisen asiakkaalle. Arvovirta toteutetaan toimitusjunissa (ART).
Arvovirtataso (Value Stream Level)
Arvovirtataso auttaa laajojen ja monimutkaisten, tyypillisesti useita toteutusjunia ja useiden
toimittajien työpanosta vaativien ratkaisujen toteuttamisessa. Tätä tasoa käytetään yleensä
yrityksissä, jotka kohtaavat suurimmat järjestelmiin liittyvät haasteet, rakentaen suuria, monialaisia
ohjelmistoja ja kyber-neettisiä järjestelmiä (cyber-physical systems).
Asiakas (Customer)
Asiakas hyödyntää arvovirran lopputulosta. Asiakkaat korjaavat lopullisen hyödyn toimitetuista
ratkaisuista. Niin sisäiset kuin ulkoiset asiakkaat kuuluvat oleellisena osana kehittämisen arvovirtaan.
Budjetit (Budgets)
SAFe tarjoaa strategioita Lean-ajattelun mukaiseen ja ketterään budjetointiin, jossa projektien sijaan
rahoitetaan arvovirtoja. Tämä lähestymistapa mahdollistaa nopean päätöksenteon sekä joustavan
arvon toimittamisen arvovirralle osoitetun budjetin sisällä, mutta säilyttää toteutustason
salkunhallinnan (PPM) kontrollin kokonaiskuluista, joita säädetään ajan myötä.
CapEx ja OpEx (CapEx and OpEx)
Arvovirran budjetti voi sisältää sekä CapExia että OpExia. CapExiksi lasketaan tyypillisesti kuluja, jotka
käytetään ratkaisun rakentamiseen vaadittavan konkreettisen omaisuuden hankkimiseen,
päivittämiseen tai korjaamiseen. Joissain tapauksissa CapEx saattaa myös sisältää osan aineettoman
omaisuuden kehittämistyöstä aiheutuneista kuluista. OpEx-kulut sisältävät tyypillisesti palkat ja
yleiskustannukset, sopimustyöt, materiaalit, tarvikkeet ja muut ratkaisun kehittämiseen suoraan
liittyvät asiat.
DevOps-malli (DevOps)
DevOps-malli on ohjelmistokehityksen lähestymistapa, kulttuuri ja kokoelma teknisiä käytäntöjä jotka
painottavat kommunikaatiota, yhteistyötä sekä tiivistä yhteistoimintaa ketterien kehitystiimien ja
muiden teknisten ammattilaisten kanssa, jotka ovat tarpeen ohjelmistojen ja järjestelmien
kehittämiseksi, testaamiseksi, tuotantoon viemiseksi ja ylläpidon kannalta.
Ei-toiminnalliset vaatimukset (Nonfunctional Requirements)
Ei-toiminnalliset vaatimukset (ETV) kuvaavat järjestelmämääritteitä kuten turvallisuutta, luotettavuutta,
suorituskykyä, huollettavuutta, skaalattavuutta ja käytettävyyttä. Nämä voivat olla järjestelmän
suunnittelua tai rakennetta rajoittavia tekijöitä.
Hanketaso (Program Level)
Hanketasolla ihmiset ja muut resurssit toteuttavat jotain tärkeitä, pitkäikäiseen yrityksen missioita.
SAFen hankkeet tuteutetaan pitkäikäisissä toteutusjunissa (ART), jotka toimittavat osan arvovirrasta
(joissain tapauksessa koko arvovirran).
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
3
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Hankkeen inkrementin tavoitteet (Program PI Objectives)
Jokaisen tiimin inkrementtien tavoitteiden kokoelma muodostaa hankkeen inkrementin tavoitteet,
jotka liiketoiminnan omistajat hyväksyvät ja joille he määritelevät bisnesarvon. Jos tarvitaan
arvovirtatason inkrementin suunnittelua, voidaan hankkeiden inkrementtien tavoitteet yhdistää ja
koota arvovirran inkrementin (PI) tavoitteiksi.
Hankkeen inkrementti (Program Increment)
Hankkeen inkrementti (HI) on pidempi kehityksen ajanjakso, joka hyödyntää syklistä kehitystä ja
synkronointia suunnittelun fasilitoimiseen, käynnissä oleva työn rajoittamiseen (WIP), arvokkaan ja
koostetun palautteen tarjoamiseen sekä johdonmukaisten toteutustason retrospektiivien
varmistamiseen. Se koostuu useista kehitysiteraatioista sekä IS (innovaatio ja suunnittelu) iteraatiosta. Rajoitetun keston takia inkrementit tarjoavat syklistä palautetta myös salkkutason
etenemissuunnitelmiin ja tiekarttoihin.
Hankkeen kehitysaihiot (Program Epics)
Hankkeen kehitysaihiot ovat aloitteita, jotka ovat laajuudeltaan tarpeeksi suuria ansaitakseen
analyysin ja kevyen liiketoimintakuvauksen, mutta rajoittuvat kuitenkin vain yhteen toimitusjunaan
(ART). Toisin kuin toiminnallisuudet (Features), jotka ovat tarpeeksi pieniä mahtuakseen yhteen
inkrementtiin (PI), hankkeen kehitysaihioiden tekeminen saattaa kestää useita inkrementtejä. Ne
voivat syntyä arvovirran tai salkun kehitysaihioista, tai paikallisesti toimitusjunan muun
toiminnallisuuden tai arvon toteuttamisen edistämisestä.
Hankkeen kehitysjono (Program Backlog)
Hankkeen kehitysjono on yksi määrätty tallennuspaikka kaikelle tulevalle työlle, joka ajatellaan
tarvittavan toimitusjunan (ART) ratkaisun tekemiseen. Kehitysjono koostuu pääosin tulevista käyttäjän
tarpeita vastaavista ja bisneshyötyä tuottavista toiminnallisuuksia; näiden lisäksi se sisältää virtaavaan
arkkitehtuuriin tarvittavat mahdollistavat toiminnallisuudet.
Hankkeen valmisteluseinä (Program Kanban)
Hankkeen valmisteluseinä auttaa varmistamaan, että toiminnallisuuksia ennätetään analysoimaan
ennen kuin ne otetaan toteutukseen. Ne arvioidaan ja priorisoidaan asianmukaisesti, ja niille
määritellään hyväksymiskriteerit.
Inkrementin suunnittelu (PI Planning)
Inkrementin (PI) suunnittelu on perustavanlaatuinen, säännöllisessä rytmissä tapahtuva ja kasvokkain
suoritettava tapahtuma, joka antaa ketterälle toimitusjunalle sykkeen. Se on oleellinen ja tärkeä osa
SAFea.
Innovaatio- ja suunnitteluiteraatio (Innovation and Planning Iteration)
SAFe sisältää säännöllisesti toistuvan innovaatio- ja suunnitteluiteraation, joka palvelee monia
tarpeita. Nämä tarjoavat lisäaikaa estimoitujen tavoitteiden saavuttamiseksi, erikseen varatun ajan
Tutki & Sopeuta -tilaisuus junan toimintaa koskien, seuraavan inkrementin suunnitteluun (PIsuunittelu) sekä mahdollisuuden säännölliseen innovointiin, aikaa kouluttautumiseen, teknisen
ympäristön parantamiseen tai muiden etenemisen esteiden poistamiseen sekä aikaa kehitysjonon
työstöön.
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
4
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Integrointitiimi (System Team)
Integrointitiimi on erityinen, toimitusjunalle tai arvovirralle (joskus molempien), tukea tarjoava ketterä
tiimi, joka auttaa ketterän kehityksen infrastruktuurin rakentamisessa ja käyttämisessä, sisältäen
jatkuvan integraation ja testauksen automatisoinnin, ketterien tiimien tekemien julkaisujen
integroimisen sekä järjestelmän kokonaisvaltaisen testaamisen. He demonstroivat usein ratkaisuja
inkrementtien järjestelmädemossa.
Iteraation retrospektiivi (Iteration Retrospective)
Iteraation retrospektiivi on iteraation lopussa järjestettävä lyhyt palaveri, jossa tiimin jäsenet
kokoontuvat yksityiseen ja turvalliseen ympäristöön keskustelemaan käytänteidensä toimivuudesta ja
määrittelemään parannuksia tulevalle jaksolle.
Iteraation suunnittelu (Iteration Planning)
Iteraation suunnittelun aikana koko tiimi hahmottelee tulevan iteraation. Tapaamisen tuloksena
syntyy iteraation kehitysjono, joka sisältää toteutettavat tarinat ja niiden hyväksyntäkriteerit jotka
iteraatiossa sitoudutaan toteuttamaan, sekä luettelo iteraation tavoitteista, ja tiimin sitoutuminen
siihen työhön, mikä vaaditaan tavoitteiden saavuttamiseksi.
Iteraation tavoitteet (Iteration Goals)
Iteraation tavoitteet ovat korkean tason yhteenveto tuoteomistajan (product owner) ja tiimin yhdessä
sopimista yhden iteraation liiketoiminnallisista ja teknisistä tavoitteista. SAFe:ssa iteraation tavoitteet
ovat oleellinen osa tehokkaan, itseorganisoituvien ja -ohjautuvien tiimien joukosta koostuvan
toimitusjunan koordinoimisessa.
Iteraation toteutus (Iteration Execution)
SAFessa iteraatioiden pituus on kaksi viikkoa. Ketterät tiimit ottavat tiimin kehitysjonosta tehtäviä ja
määrittelevät, tekevät ja testaavat nämä järjestelmän versionhallinnnan päähaarassa tämän kahden
viikon ajanjakson aikana.
Iteraatiot (Iterations)
Iteraatiot ovat tarkasti rajattuja ajanjaksoja , joiden sisällä tiimit toimittavat inkrementaalisesti (joka
iteraatiossa lisäten) arvoa toimivina ja testattuina ohjelmistoina ja järjestelminä. Jokainen iteraatio
noudattaa samaa saavaa: iteraatio suunnittelu; tavoitteisiin sitoutuminen; toteutus; työn
demoaminen sidosryhmille; ja lopulta retrospektiivi, jossa tiimi analysoi ja päättää miten parantaa
tuottavuuttaan.
Jaetut palvelut (Shared Services)
Jaetut palvelut edustavat erikoisosaamista, joka on oleellista toimitusjunan tai arvovirran
menestymisen kannalta, mutta, jota ei voida antaa vain yhdelle toimitusjunalle. Tällaisia rooleja voivat
olla turvallisuusspesialistit, informaatioarkkitehdit, tietokanta-arkkitehdit, tekniset kirjoittajat, laadun
valvojat, IT-operaatiohenkilöstä sekä muut vastaavat roolit.
Jatkuva integraatio (Continuous Integration)
Jatkuva integraatio on käytäntö, jossa tiimin jäsenet integroivat ja validoivat työtään säännöllisesti.
Ohjelmiston tapauksessa tämä saattaa tapahtua ainakin päivittäin, tai jopa useita kertoja päivässä. Jos
mahdollista, integraatio verifioidaan automaattisilla rakennus- ja testausympäristöillä, jotka nopeasti
paljastavat integraation ongelmat ja puutteet.
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
5
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Joukkopohjainen suunnittelu (Set-Based Design)
Joukkopohjainen suunnittelu on käytäntö, joka ylläpitää useita vaatimuksia ja muotoiluvaihtoehtoja
pidemmän kehityssyklin aikana. Empiiristä dataa käytetään kohdentamaan tekemistä uuden hankitun
tiedon perusteella.
Julkaisu (Release)
Sujuvan ja ketterän kehittämisen tavoitteena on usein toistuva arvoa tuottavien, toimivien ja täysin
testattujen ratkaisun inkrementin toimittaminen. Tämä saavutetaan peräkkäisten julkaisujen virrralla,
jossa jokainen toimitus on validoitu ja hyväksytty lopulliseen käyttöön, sisältäen myös onnistuneen
käytön varmistavan dokumentaation.
Julkaisu asiakastarpeen mukaan (Release Any Time)
SAFe erottelee kehitystiimien tarpeet synkronoida ja rytmittää kehityssyklit kompleksisuuden ja
ympäristön muutosten hallitsemiseksi ja silti samaan aikaan mahdollistaa joko säännöllinen (joka
hanketason inkrementin jälkeen) tai epäsäännöllinen (milloin vain) tuotantoon vienti.
Julkaisujen hallinta (Release Management)
Julkaisujen hallinta on toiminto, joka tukee julkaisujen suunnittelussa ja hallinnoinnissa. Sillä on valta
ja vastuu auttaa arvovirtoja ohjautumaan liiketoiminnan tavoitteita kohti. Se saattaa sisältää tähän
toimintaan erikoistuneita henkilöitä tai olla vain rooli, jota joku ketterä salkun johtaja hoitaa.
Järjestelmäarkkitehti (System Architect/Engineering)
Järjestelmäarkkitehti linjaa toimitusjunat yhteiseen teknologiseen ja arkkitehtoniseen visioon
kehitteillä olevan ratkaisun suhteen. He osallistuvat järjestelmän ja alajärjestelmien määrittelyyn,
validoivat teknologisia valintoja sekä arvioivat vaihtoehtoja. Lisäksi he tukevat järjestelmän
kehittämistä tarjoamalla, kommunikoimalla ja kehittämällä ratkaisun laajempaa teknologista ja
arkkitehtonista sisältöä.
Järjestelmädemo (System Demo)
Järjestelmädemo on kokonaisen toimitusjunan ensisijainen mekanismi tehdyn järjestelmän
arvioimiseen ja palautteen keräämiseen sidosryhmiltä. Järjestelmädemo pidetään jokaisen iteraation
lopussa, ja se tarjoaa integroidun ja koostetun näkemyksen uusista toiminnallisuuksista, jotka kaikki
toimitusjunan tiimit ovat toimittaneet viimeisimmässä iteraatiossa. Se tarjoaa myös toimitusjunalle
(ART) faktapohjaisen arvion siitä miten järjestelmän tekeminen on edistynyt viimeisimmässä
inkrementissä (PI).
Kanban (Team Kanban)
Kanban on menetelmä, joka tähtää jatkuvaan arvonmuodostukseen työn kulun visualisoimisella,
meneillään olevan työn määrän (WIP) rajoittamisella, läpivirtauksen mittaamisella ja jatkuvalla
prosessien parantamisella. Kanban on erityisen hyödyllinen systeemitiimeille, DevOps:ille ja
ylläpitotiimeille, sekä sellaisissa tapauksissa joissa nopea reagointi, lyhyen tähtäimen muuttuvat
prioriteetit tai etukäteissuunnittelun vähäisempi merkitys ohjaa valitsemaan tämän vaihtoehdon.
Kehitysaihio (Epic)
Kehitysaihiot ovat merkittäviä aloitteita, jotka ohjaavat arvovirroissa tapahtuvaa kehittämistä
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
6
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
täyttämään salkun (portfolio) tavoitteita. Ne vaativat isoja investointeja ja vaikuttavat pitkälle
tulevaisuuteen. Kehitysaihiot vaativat määrittelyn sekä kustannuksen, vaikutuksen ja
mahdollisuuksien analysoimista, joka tehdään kevyellä liiketoimintakuvauksella (Lightweight Business
Case). Lisäksi tarvitaan taloudellinen hyväksyntä ennen kehitysaihioiden toteuttamista. Kehitysaihioita
on kahdenlaisia: liiketoiminta-aihioita sekä näiden mahdollistajia, ja ne voivat esiintyä salkku-,
arvovirta- tai hanketasolla.
Kehitysaihioiden omistajat (Epic Owners)
Kehitysaihioiden omistajat ovat vastuussa kehitysaihioista (Epic) niiden elinkaaren ajan, eli vastaavat
kehitysaihiosta kun se liikkuu salkun valmisteluseinän (Portfolio Kanban) läpi. Kehitysaihioiden
omistajat määrittelevät kehitysaihion liiketoimintakuvauksen ja hyväksynnän saatuaan työskentelevät
suoraan tarvittavien toteutusjunien keskeisten sidosryhmien kanssa ja auttavat kehitysaihion (Epic)
toteutuksessa.
Ketterä arkkitehtuuri (Agile Architecture)
Ketterä arkkitehtuuri on kokoelma sääntöjä ja käytäntöjä, joka tukevat järjestelmän ja designin
aktiivista kehittämistä liiketoiminnan toteutuksen rinnalla Tämän lähestymistavan myötä laajankin
järjestelmän arkkitehtuuri saadaan kehittymään samanaikaisesti muun tekemisen kanssa,
samanaikaisesti tukien myös senhetkisten käyttäjien tarpeita. Lisäksi vältytään täydelliseltä toteutusta
edeltävältä määrittelyltä (Big Design Up Front, BDUF) sekä vesiputous –mallille ominaiselta työn
katkonaisuudelta.
Ketterä johtaminen (Lean-Agile Leaders)
Ketterä johtaminen on niiden elinikäisisten oppijoiden, managereiden, opettajien ja valmentajien
joukko, jotka auttavat tiimejä luomaan parempia ohjelmistoja ja järjestelmiä tuntemalla ja
noudattamalla Lean-ajattelun ja ketterän kehittämisen sekä systeemiajattelun mukaisia arvoja,
periaatteita sekä käytänteitä. Ketterä johtaminen tarkoittaa sitoutumista Leanin ja ketterän
kehittämisen periaatteisiin.
Ketterät tiimit (Agile Teams)
Ketterä tiimi on eri osa-alueet kattava viiden - yhdeksän henkilön ydinyksikkö, jolla on kyvykkyys ja
vastuu määritellä, rakentaa ja testata ratkaisun arvoa yritykselle lyhyissä, kahden viikon jaksoissa.
Tiimiin kuuluvat kyseisen arvon toimittamisen onnistumisen kannalta tarvittavat henkilöt, joita
spesialistit tukevat tarvittaessa.
Koordinointi (Coordination)
Ks. arvovirtojen koordinointi.
Kyvykkyys (Capability)
Kyvykkyydet muistuttavat toiminnallisuuksia (Features), mutta ne kuvaavat korkeammalla tasolla
ratkaisun (Solution) kyvykkyyksiä, jotka toteutetaan useammassa toimitusjunassa (ART). Kyvykkyyksiä
ylläpidetään arvovirran kehitysjonossa, ja ne pilkotaan mahtumaan hankkeen inkrementteihin (PI),
joista jokainen lisää ratkaisun arvoa.
Käytettävyys (User Experience)
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
7
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Vaikka varsinaisen ratkaisun toteuttaminen kuuluukin ketterien tiimien vastuulle, mukaan lukien
käyttöliittymä, käytettävyyden (UX) suunnittelijat vastaavat siitä, että käyttökokemus on
yhdenmukainen eri komponenttien eli sekä isompien ratkaisujen sisältämien eri järjestelmien välillä.
Lean ja ketterä ajattelutapa (Lean-Agile Mindset)
Ketterä- ja Lean ajattelutapa lähtee ketterän ohjelmistonkehityksen ja Leanin periaatteiden
ymmärtämisestä ja soveltamisesta kokonaisvaltaisesti siten, että luodaan jatkuvan arvonkehityksen
virta konseptista toteutukseen. SAFen Lean-talo perustuu arvon toimittamiselle nopeimmalla
mahdollisella, jatkuvasti ylläpidettävällä läpimenoajalla kunnioittaen ihmisiä, kulttuuria, tekemisen
virtaa, innovaatiota sekä periksiantamatonta toiminnan parantamista – jossa perustuksena toimii
ketterä johtaminen.
Liiketoiminnan kehitysaihio (Business Epic)
Ks. Kehitysaihio (Epic)
Liiketoiminta, Liiketoiminnan omistajat (Business Owners)
Liiketoiminnan omistajat ovat pieni sidosryhmien joukko (tyypillisesti 3-5), jolla on lopullinen vastuu
liiketoiminnan sisäpiirin tiedosta, hallinnasta, tehokkuudesta sekä investoinnin tuotosta (ROI) tietyn
toimitusjunan arvon toimittamisessa. Heillä on tyypillisesti hallinnollinen vastuu asiakassuhteista,
kehityksestä, ratkaisun laadusta, käyttöönotosta, operaatioista, tuotehallinnasta sekä arkkitehtuurista.
Mahdollistajat (Enablers)
Mahdollistajat kiteyttävät ratkaisujen tutkinnan (exploration) sekä tulevien ratkaisun kyvykkyyksien
tukemiseen tarvittavat selvitykset sekä arkkitehtoniset ja infrastruktuuriset kehitystoimet. Niitä
esiintyy kaikilla SAFen tasoilla, ja tasosta riippuen niitä kutsutaan joko kehitysaihioiden, kyvykkyyksien,
toiminnallisuuksien tai tarinoiden mahdollistajiksi.
Mahdollistava kehitysaihio (Enabler Epic)
Mahdollistavat kehitysaihiot ovat tietyn tyyppisiä Kehitysiaihioita (Epic), jotka märitellään samalla
tavalla kuin Kehitysaihiot, eli Arvomäärittelyn (Value Statement) mukaisesti. Kehitysaihiot ulottuvat
tyypillisesti useaan arvovirtaan ja junaan, ja ne toteutetaan useammassa palasessa (inkrementissä,
PI). Mahdollistavat kehity aihiot vaativat kevyen liiketoimintakuvauksen (Lightweight Business Case)
toteutuksensa tueksi. Niiden tunnistus ja toteutuksen seuraaminen tapahtuvat salkkutason
valmisteluseinällä (Portfolio Kanban).
Mahdollistava kyvykkyys (Enabler Capability)
Mahdollistavat kyvykkyydet ovat olemassa arvovirtatasolla, jossa ne sisältävät arvovirtaan liittyvää
työtä. Nämä mahdollistajat ovat eräs kyvykkyyden alalaji, joten ne määritellään kyvykkyyksien tavoin
hyötyjen ja hyväksymiskriteerien kautta siten, että ne ovat toteutettavissa yhdessä inkrementissä.
Mahdollistava tarina (Enabler Story)
Mahdollistavat tarinat ovat tietyn tyyppisiä (käyttäjä) tarinoita, eli niiden täytyy mahtua iteraatioon.
Vaikka ne eivät vaadi saman muotoista määrittelyä kuin varsinaiset (käyttäjä) tarinat, niillä täytyy olla
hyväksymiskriteerit jotka selventävät vaatimusta ja tukevat sekä demoa että testaamista.
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
8
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Mahdollistavat toiminnallisuus (Enabler Feature)
Mahdollistavat toiminnallisuudet ovat olemassa hanketasolla (Program level), jossa ne sisältävät
siihen liittyvää työtä. Koska nämä mahdollistajat ovat eräs toiminnallisuuksien (Feature) alalaji, ne
määritellään toiminnallisuuksien mukaisesti hyötyjen ja hyväksymiskriteerien kautta siten, että ne ovat
toteutettavissa yhdessä inkrementissä.
Mallipohjainen (systeemi)suunnittelu (Model-Based Systems Engineering)
Mallipohjainen suunnittelu (MBSE) on mallinnuksen ja mallinnustyökalujen käyttämistä ratkaisun
kehittämisen vaatimusten, suunnittelun, analyysin ja verifioinnin tekemiseen. Mallipohjainen
suunnittelu tarjoaa kustannustehokkaan tavan oppia järjestelmän toiminnallisuuksista niin ennen sen
rakentamista kuin sen aikanakin, mikä auttaa hallitsemaan laaja-alaisen järjestelmän dokumentaation
monimutkaisuutta ja kustannuksia.
Metriikka (Metrics)
SAFen ensisijainen mittari on objektiivinet ratkaisujen toimivuuden arvioiminen. Nämä määritetään
kokeellisesti demoilla jokaisen iteraation ja inkrementin aikana sekä lopussa. Lisäksi on olemassa
joitakin keskipitkän ja pitkän aikavälin mittareita, joilla tiimit, hankkeet ja salkut voivat mitata
edistymistään.
Toiminnallisuus (Feature)
Toiminnallisuus on järjestelmän sidosryhmilleen tarjoama palvelu. Jokainen toiminnallisuus
kehitetään yhdessä ketterässä toimitusjunassa (ART). Niitä ylläpidetään hankkeen kehitysjonossa ja
ne pilkotaan mahtumaan hankkeen inkrementteihin (PI) siten, että jokainen inkrementti tuottaa
kokonaisen tuotoksen. Jokainen toiminnallisuus määritellään hyötyjen ja hyväksymiskriteerien kautta.
Painotettu pienin työmäärä (Weighted Shortest Job First (WSJF))
Painotettu pienin työmäärä (PPT) on menetelmä priorisoida “työtä” tuotteen kehitysvirtaan
taloudellisesta näkökulmasta. PPT lasketaan jakamalla viiveen aiheuttama kustannus työn kestolla.
SAFessa “työtä” ovat kehitysaihiot (Epic), toiminnallisuudet (Feature) sekä kyvykkyydet (Capability), joita
toimitusjunat (ART) kehittävät. Viiveen aiheuttamiin kustannuksiin kuuluu kolme peruselementtiä: 1)
liiketoiminnallinen arvo käyttäjälle, 2) aikakriittisyys sekä 3) riskin vähentämisen ja mahdollisuuksien
luomisen arvo.
Ratkaisu (Solution)
Ratkaisu on joko lopullinen, ostajalle toimitettava tuote tai vastaavasti joukko järjestelmiä, jotka
mahdollistavat toiminnallisen arvovirran organisaation sisällä.
Ratkaisuarkkitehti/ (Solution Architect/Engineering)
SAFen ratkaisuarkkitehti edustaa yksilöitä ja tiimejä, joiden tekninen vastuu liittyy kokonaisvaltaiseen
ratkaisun arkkitehtuurin ja toteutuksen suunnitteluun. He auttavat arvovirtaa ja toimitusjunaa
sopeutumaan yleiseen tekniseen ja arkkitehtuurin visioon.
Ratkaisun demo (Solution Demo)
Ratkaisun demo on arvovirran inkrementin huipentuma; useiden toteutusjunien (ART) kaikkien
kehitystöiden tulokset ja toimittajien työpanos integroidaan, arvioidaan ja tehdään näkyväksi
asiakkaille ja muille sidosryhmille. Tämä demo tarjoaa säännöllisen syklin ratkaisun tavoitteiden
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
9
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
evaluoinnille sekä palautteen keräämiselle sidosryhmiltä ja asiakkailta.
Ratkaisun hallinta (Solution Management)
Ratkaisun hallinta päättää arvovirran sisällöstä. Heillä on ensisijainen vastuu arvovirran kehitysjonon
hallinnasta ja priorisoinnista. He työskentelevät yhdessä asiakkaiden kanssa ymmärtääkseen näiden
tarpeita, luovat vision ja tiekartan, määrittelevät vaatimuksia sekä ohjaavat työtä arvovirran
valmisteluseinällä (Value Stream Kanban).
Ratkaisun konteksti (Solution Context)
Ratkaisun konteksti tunnistaa tavoiteltavan ratkaisun toimintaympäristön kannalta kriittisiä tekijöitä
sekä niiden vaikutuksia itse ratkaisun käyttöön, käyttöönottoon, operointiin ja käytön tukeen. Nämä
tekijät vaikuttavat kehityksen prioriteetteihin ja infrastruktuuriin, testiympäristöihin, ratkaisun
kyvykkyyksiin (Capabilities), toiminnallisuuksiin ja ei-toiminnallisiin vaatimuksiin (NFR). Lisäksi nämä
tekijät luovat DevOpsiin fokusta ja tarkentavat vastaavia muita käyttöönoton reunaehtoja.
Ratkaisun tarkoitus (Solution Intent)
Ratkaisun tarkoitus merkitsee järjestelmän rakentajille kehittyvän ja järjestelmään liittyvän tiedon
tallentamista, hallintaa ja kommunikointia, sekä sitä teknistä tietämystä miten järjestelmä aiotaan
rakentaa. Tämä sisältää määrittelyjä, muotoilusuunnitelmia, testejä senhetkiselle ratkaisun vaiheelle
sekä aiottuja muutoksia. Ratkaisun tarkoitus voidaan esittää monessa eri muodossa aina
dokumenteista, laskentataulukoista, valkotaulun ääressä pidetyistä työpajoista formaaleihin
vaatimuksiin ja mallinnustyökaluihin asti.
SAFen räätälöintiosa (Spanning Palette)
SAFen räätälöintiosa ei ole itsenäinen osio; vaan tämä osa sisältää erilaisia rooleja ja artefakteja, jotka
voivat olla tarpeen millä tahansa SAFen tasolla. Tätä osaa käytetään, kun SAFe sovitetaan kunkin
yrityksen omaan kontekstiin. Tarkempi tämän aihepiirin kuvaus löytyy kohdasta Hanketaso (Program
level).
SAFen periaatteet (SAFe Principles)
SAFe perustuu yhdeksään muuttumattomaan, vakaaseen Leaniin ja ketterään periaatteeseen. Nämä
ovat hyvin perustavanlaatuisia oppinkappaleita, yleisiä totuuksia sekä taloudellisia tukipilareita, jotka
tekevät SAFen rooleista ja käytänteitä tehokkaita.
Salkkutaso (Portfolio Level)
SAFen salkkutaso on tasoista ylin. Se tarjoaa keskeiset rakenteet, joilla voidaan organisoida Leanajattelun mukainen ja ketterä yritys arvon virtauksen ympärille yhden tai useamman arvovirran avulla,
joista jokainen kehittää järjestelmiä ja ratkaisuja yrityksen strategisten aikeiden saavuttamiseksi.
Salkunhallinta (Program Portfolio Management)
Salkunhallinta (PPM) edustaa tahoa, joka omistaa yrityksen yrityksen (tuote- tai palvelu)
salkun korkeimman tason strategisen ja lainvoimaisen päätäntävallan . PPM:llä toimintona on
vastuu strategiasta ja investointien rahoittamisesta, hankkeiden hallinnasta sekä
johtamisesta.
Salkun kehitysjono (Portfolio Backlog)
Salkun kehitysjono on SAFen korkeimman tason kehitysjono. Siihen voidaan tallettaa suunnitteilla
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
10
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
olevat liiketoiminnan kehitysaihiot (Epics) sekä mahdollistavat kehitysaihiot (Epic Enablers), joita
tarvitaan salkun sisältämien ratkaisujen toimittamiseen, ja jotka mahdollistavat erottautumisen
kilpailijoista, tarvittavan operatiivisen tehokkuuden strategisten teemojen toteuttamiseksi ja
bisnesmenestyksen saavuttamiseksi.
Salkun liiketoiminnan kehitysaihio (Portfolio Business Epic)
Salkun liiketoiminnan kehitysaihiot kuvaavat portfoliossa esiintyvät laajimmat, monialaiset
liiketoiminnan aloitteet.
Salkun valmisteluseinä (Portfolio Kanban)
SAFen salkun valmisteluseinää (Kanban) käytetään ensisijaisesti tunnistamaan ja hallitsemaan
kehitysaihioiden virtaa, joita käytetään määräämään arvovirtojen sisältö, sekä nämä uudet
toiminnallisuudet toteuttavien ketterien toteutusjunien sisältö.
Scrummaster (Scrum Master)
SAFen scrummaster on ketterän tiimin palveleva johtaja ja valmentaja. Hän on ensisijaisesti
vastuussa siitä, että prosessia noudatetaan; tiimin ohjaamisesta Scrumin, XP:n ja SAFe:n
käyttöön, esteiden poistamisesta, huipputiimin dynamiikan suojelemisesta ympäristöä
vaalimalla, tekemisen jatkuvasta virrasta sekä periksiantamattomasta jatkuvasta toiminnan
kehittämisestä.
ScrumXP (ScrumXP)
ScrumXP on kevyt, mutta kurinalainen ja tuottelias prosessi moniosaaville, itseorganisoituville SAFen
kontekstissa toimiville tiimeille. ScrumXP-tiimi koostuu 5-9 henkilöstä, jotka sijoitetaan samaan
fyysiseen toimipisteeseen silloin kun se vain on mahdollista. ScrumXP-tiimit seuraavat scrumin
projektinhallintakäytänteitä ja XP-lähtöisiä teknisiä käytänteitä sekä visualisoivat ja mittaavat arvon
virtaa.
Sisäänrakennettu laatu (Built-in Quality)
Sisäänrakennettu laatu on yksi SAFen neljästä ydinarvosta. Yrityksen kyky toimittaa uutta
toiminnallisuutta nopeimmalla kestävällä läpimenoajalla sekä reagoida nopeasti muuttuviin
liiketoiminnan edellytyksiin on riippuvaista sisäänrakennetusta laadusta.
Strategiset teemat (Strategic Themes)
Strategiset teemat ovat erityisiä, yksityiskohtaisia liiketoiminnan tavoitteita, jotka yhdistävät salkun
vision yrityksen liiketoimintastrategiaan. Strategiset teemat tarjoavat liiketoiminnallisen kontekstin
salkkutason päätösten tueksi, vaikuttaen taloudellisen päätöksenteon kehykseen sekä arvovirtojen ja
toteutusjunien investointipäätöksiin ja budjettiin. Ne toimivat myös salkun -, ratkaisun - ja hankkeen
kehitysjonon päätöksenteon perustana.
Suunnittelu inkrementtiä ennen ja jälkeen (Pre- and Post-PI Planning)
Ennen inkrementin (PI) suunnittelua ja sen jälkeen pidettävät tapaamiset antavat suurten arvovirtojen
toteutusjunille (ART) ja toimittajille mahdollisuuden linjata suunnitelmansa seuraavaa inkrementtiä
(PI) varten. Nämä ennen ja jälkeen inkrementin suunnittelua tapahtuvat tapaamiset toimivat myös
suojana inkrementtien suunnittelulle toteutustasolla, jossa todellinen ja yksityiskohtainen suunnittelu
tapahtuu.
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
11
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Syklinen kehittäminen (Develop on Cadence)
Kehitysaktiviteettien nopea ja synkronoitu tai - säännöllinen ja ennustettava tärkeiden tapahtumien
syklisyys – auttaa hallitsemaan järjestelmien kehittämiselle luontaista vaihtelevuutta. Tämä on SAFen
keskeinen perusta. Sen vaikutukset voidaan nähdä suoraan Big Picturesta, jossa nopearytmisiä lyhyitä
samaan aikaan tapahtuvia iteraatioita seuraavat näiden iteraatioiden integraatiot suuremmiksi
hanketason inkrementeiksi (Program Increments).
Taloudellisen päätöksenteon kehys (Economic Framework)
Taloudellisen päätöksenteon kehys tarkoittaa kokoelmaa sääntöjä, jonka pohjalta voidaan hyväksyä
kuluja ja pysyä portfolion määräämässä budjetissa. SAFen ensimmäinen kokonaisketterä periaate on
päätöksenteon taloudellinen näkökulma; taloudellisen päätöksenteon kehys sisältää talouden
kannalta oleellisimmat asiat jotta ratkaisuja voidaan kehittää menestyksekkäästi.
Tarinat (Stories)
Tarinat ovat ketterän kehityksen kulmakivi, jolla määritellään järjestelmän toimintaa. Tarinat eivät ole
vaatimuksia vaan lyhyitä, yksinkertaisia kuvauksia pienestä osasta haluttua toiminnallisuutta, jotka
yleensä kerrotaan käyttäjän näkökulmasta ja käyttäjän kielellä. Jokaisen tarinan tulisi mahdollistaa
pienen vertikaalisen järjestelmän toiminnallisuuden osan kehittämistä, mahdollistaen samalla
inkrementaalisen (pala kerrallaan tapahtuvan) kehittämisen.
Tarkistuspisteet (Milestones)
Tarkistuspisteet osoittavat erityisiä edistysaskeleita kehitysaikajanalla, ja voivat olla korvaamattomia
edistymisen ja ohjelman riskien mittaamisessa sekä seuraamisessa. Toisin kuin vesiputousmallin
työvaiheisiin sidotut tarkistuspisteet, SAFessa tarkistuspisteet perustuvat hanketason inkrementteihin
(PI), suunniteltuihin oppimispisteisiin ja kiinteisiin päivämääriin.
Testaus edellä –käytäntö (Test-First)
Testaus edellä –käytäntö tarkoittaa järjestelmän kehittämistä ja testaamista pienissä inkrementeissä
siten, että testitapaukset tehdään tyypillisesti ennen koodin tai komponentin kehittämistä. Tällä
tavalla testaaminen palvelee yksityiskohtaista ja parempaa aiotun järjestelmän toiminnan määrittelyä
ennen kuin järjestelmä on rakennettu, mikä parantaa laatua.
Tiekartta (Roadmap)
Tiekartta kommunikoi suunniteltuja toteutusjunia ja arvovirran julkaisuja ja tarkistuspisteitä
aikajanalla. Tiekartta sisältää julkaisuja, joihin on jo sitouduttu, ja lisää näkyvyyttä vielä ennusteteissa
olevien julkaisujen osalta muutaman seuraavan inkrementin (PI) ajalle. Tiekarttaa kehitetään ja
päivitetään ratkaisu- ja tuotehallinnan toimesta vision ja toimitusstrategian kehittyessä.
Tiimin demo (Team Demo)
Tiimin demon tarkoituksena on mitata tiimin edistymistä esittelemällä toteutettuja tarinoita
tuoteomistajalle, muille tiimin jäsenille sekä sidosryhmille, ja kerätä siten palautetta jokaisen
iteraation lopussa. Tiimit esittelevät tässä demossa jokaisen tehdyn tarinan, minitutkimuksen (spike),
refaktoroinnin eli uudelleen muotoilun sekä uudet toteutetut ei-toiminnalliset vaatimukset (NFR).
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
12
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Tiimin inkrementin tavoitteet (Team PI Objectives)
Tiimin inkrementin (PI) tavoitteet sisältävät tiivistetyn kuvauksen tarkoin määritellyistä
liiketoiminnallisista ja teknisistä tavoitteista, jotka ketterä tiimi aikoo saavuttaa tulevassa
inkrementissä. Niiden merkitys on varmistaa samanlainen ymmärrys liiketoiminnallista ja teknisestä
tarkoituksesta, ohjata keskustelu lopputuotoksiin prosessi- tai taktisten murheiden sijaan sekä
kiteyttää tiedot siten, että kommunikaatio, yhtenäisyys ja näkyvyys lisääntyy.
Tiimin kehitysjono (Team Backlog)
Tiimin kehitysjono pitää sisällään kaiken sen tekemisen, joka tiimin täytyy tehdä saadakseen valmiiksi
heidän vastuullaan olevan osan järjestelmästä. Se sisältää (käyttäjä)tarinat ja mahdollistavat tarinat,
jotka ovat lähtöisin hankkeen kehitysjonosta, sekä tarinat, jotka syntyvät paikallisesti tiimin omasta
erityisistä tarpeista.
Tiimitaso (Team Level)
Tiimitaso kuvaa ketterien tiimien organisaation, työt, roolit, aktiviteetit sekä prosessimallin, ja toimii
ketterän toimitusjunan (ART) keskeisenä voimana.
Toimittaja (Supplier)
Toimittajat kehittävät ja julkaisevat komponentteja ja alijärjestelmiä, jotka auttavat Lean-ajattelua
käytäviä ja ketteriä organisaatioita toimittamaan arvoa asiakkailleen. Toimittajat omaavat erityistä ja
poikkeuksellista osaamista sekä ratkaisuja ja ovat eritysasiantuntijoita omissa teknologioissaan; he
voivat tarjota eritysedun pyrittäessä nopeisiin ja taloudellisiin julkaisuihin.
Toimitusjuna (Agile Release Train)
Toimitusjuna on pysyväisluontoinen ketterien tiimien muodostama tiimien tiimi, jossa työskentelee
tyypillisesti 50-125 henkilöä. Se hitsaa tiimit yhteen yhteiseen tehtävään sekä tarjoaa säännöllisen
rytmin suunnittelulle, kehitykselle ja retrospektiiville. Junat toteuttavat jatkuvan tuotekehitysvirran.
Jokaisella junalla on omat kohdistetut resurssinsa, jotka tarvitaan asiakasarvon määrittelemiseksi,
rakentamiseksi ja testaamiseksi kahden viikon jaksoissa.
Toimitusjunan päällikkö (Release Train Engineer)
Toimitusjunan päällikkö (RTE) fasilitoi toimitusjunan prosesseja ja toteutusta. Hän eskaloi etenemisen
esteitä, auttaa riskinhallinnassa ja varmistaa arvon toimittamisen sekä ohjaa toiminnan jatkuvaa
kehittämistä.
Tuotehallinta (Product Management)
Tuotehallinta on vastuussa asiakkaan tarpeiden tunnistamisesta. He omistavat toimitusjunan (ART)
vision, etenemissuunnitelman, hinnoittelun, lisensoinnin, investoinnin tuoton (ROI) sekä hanketason
kehitysjonon. He huolehtivat inkrementtien tavoitteista sekä julkaisevat sisältöä priorisoitujen
toiminnallisuuksien ja hyväksymiskriteerien muodossa, ja hyväksyvät toiminnallisuudet järjestelmän
pääkehityshaaraan.
Tuoteomistaja (Product Owner)
Tuoteomistaja on tiimin jäsenenä vastuussa (käyttäjä) tarinoiden määrittelystä sekä tiimin
kehitysjonon priorisoinnista. Tuoteomistaja työskentelee myös osana laajempaa
tuotehallinta/tuoteomistaja –tiimiä, ymmärtäen ja antaen oman panoksensa hanketason
kehitysjonoon, visioon ja tiekarttaan.
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
13
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Tutki ja Sopeuta (Inspect and Adapt)
Tutki ja Sopeuta (T&S) on säännöllisesti toistuva tilaisuus, joka pidetään jokaisen inkrementin (PI)
lopussa. Se antaa tiimeille ja ryhmille mahdollisuuden demota ratkaisua; saada palautetta; ja sitten
reflektoida, ratkaista ongelmia ja määritellä tehtävät parannustoimenpiteet. Parannustoimet voidaan
tämän jälkeen välittömästi sisällyttää seuraavan inkrementin (PI) suunnitteluun.
Visio (Vision)
Visio kuvaa sitä, millainen kehitettävä ratkaisu on tulevaisuudessa, kuvastaen asiakkaiden ja
sidosryhmien tarpeita, toiminnallisuuksia sekä niiden toiminnallisuuksien luomiseksi tarvittavia
kyvykkyyksiä. Visio tarjoaa laajemman kontekstiin sidotun yleiskuvan ja merkityksen kehitettävänä
olevalle ratkaisulle. Visio on osa SAFen räätälöintiosaa, ja sitä voidaan käyttää millä tahansa SAFen
tasolla.
Ydinarvot (Core Values)
SAFe kunnioittaa ja kuvastaa neljää ydinarvoa: yhtenäistä suuntaa, sisäänrakennettua laatua,
läpinäkyvyyttä ja hanketason toteutusta.
Osaamisyhteisö (Communities of Practice)
Osaamisyhteisö (CoP) on epämuodollinen, hankkeen tai yrityksen kontekstissa toimiva, tiimin
jäsenistä ja muista ammattilaisista koostuva ryhmä, jonka tehtävänä on jakaa tietämystä yhdestä tai
useammasta käytännöstä.
Yritys (Enterprise)
Yritys on liiketoimintataho, joka omistaa SAFen portfoliot ja arvovirrat, ja jolla on lopullinen
määräysvalta niiden strategiasta,ja johtamisesta sekä yrityksen hallituksen luottamus. Jokainen SAFe
salkku (SAFe portfolio) on osa laajempaa yrityksen viitekehystä, josta salkun strategia on peräisin ja
johon salkun toiminnan tulee vastata. Yritys myös huolehtii siitä tavasta, jolla kaikkia salkkuja
hallinnoidaan (Governance model).
Yritysarkkitehti (Enterprise Architect)
Yritysarkkitehti työskentelee liiketoiminnan sidosryhmien sekä ratkaisu- ja järjestelmäarkkitehtien
kanssa ohjatakseen kokonaisvaltaista teknologian toteutusta eri arvovirtojen välillä. Yritysarkkitehdin
työ pohjautuu jatkuvaan palautteeseen. Hänen tehtävänään on edistää sopeutuvaa suunnittelua ja
teknisiä käytänteitä sekä ohjata toteutus- ja tiimitason välistä yhteistyötä yhteisen teknisen vision
avulla.
1-2-3 -toteutusmalli (Implementing 1-2-3)
SAFen 1-2-3 -toteutusmalli on todistetusti menestyksekäs kaava SAFen käyttöönottoon. Se kuvaa
kolmea perusvaihetta: (1) toteuttajien sekä SAFe muutosagenttien kouluttaminen, (2) koko johdon,
keskijohdon ja hallinnon kouluttaminen, (3) tiimien kouluttaminen ja toteutusjunien käynnistäminen.
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
14
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
SANASTO | SAFe® 4.0 Sujuvaan ja ketterään ohjelmistojen ja
järjestelmien kehittämiseen
Agile Architecture
Ketterä arkkitehtuuri
Agile Release Train
Toimitusjuna
Agile Teams
Ketterät tiimit
Architectural Runway
Arkkitehtuurin kiitorata
Budgets
Budjetit
Built-in Quality
Sisäänrakennettu laatu
Business Epic
Liiketoiminnan kehitysaihio
Business Owners
Liiketoiminta, Liiketoiminnan omistajat
Capability
Kyvykkyys
CapEx ja OpEx
CapEx and OpEx
Communities of Practice
Osaamisyhteisöt
Continuous Integration)
Jatkuva integraatio
Coordination
Koordinointi
Core Values
Ydinarvot
Customer
Asiakas
Develop on Cadence
Syklinen kehittäminen
DevOps
DevOps-malli
Economic Framework
Taloudellisen päätöksenteon kehys
Enabler Capability
Mahdollistava kyvykkyys
Enabler Epic
Mahdollistava kehitysaihio
Enabler Feature
Mahdollistava toiminnallisuus
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
15
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Enabler Story
Mahdollistava tarina
Enablers
Mahdollistajat
Enterprise Architect
Yritysarkkitehti
Enterprise
Yritys
Epic Owners
Kehitysaihioiden omistajat
Epic
Kehitysaihio
Feature
Toiminnallisuus
Implementing 1-2-3
1-2-3 -toteutusmalli
Innovation and Planning Iteration
Innovaatio- ja suunnitteluiteraatio
Inspect and Adapt
Tutki ja Sopeuta
Iteration Execution
Iteraation toteutus
Iteration Goals
Iteraation tavoitteet
Iteration Planning
Iteraation suunnittelu
Iteration Retrospective
Iteraation retrospektiivi
Iterations
Iteraatiot
Lean-Agile Leaders
Ketterä johtaminen
Lean-Agile Mindset
Lean ja ketterä ajattelutapa
Metrics
Metriikka
Milestones
Tarkistuspisteet
Model-Based Systems Engineering
Mallipohjainen (systeemi) suunnittelu
Nonfunctional Requirements
Ei-toiminnalliset vaatimukset
PI Planning
Inkrementin suunnittelu
Portfolio Backlog
Salkun kehitysjono
Portfolio Business Epic
Salkun liiketoiminnan kehitysaihio
Portfolio Kanban
Salkun valmisteluseinä
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
16
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Portfolio Level
Salkkutaso
Pre- and Post-PI Planning
Suunnittelu inkrementtiä ennen ja jälkeen
Product Management
Tuotehallinta
Product Owner
Tuoteomistaja
Program Backlog
Hankkeen kehitysjono
Program Epics
Hankkeen kehitysaihiot
Program Increment
Hankkeen inkrementti
Program Kanban
Hankkeen valmisteluseinä
Program Level
Hanketaso
Program PI Objectives
Hankkeen inkrementin (HI) tavoitteet
Program Portfolio Management
Salkunhallinta
Release Any Time
Julkaisu asiakastarpeen mukaan
Release Management
Julkaisujen hallinta
Release Train Engineer
Toimitusjunan päällikkö
Release
Julkaisu
Roadmap
Tiekartta
SAFe Principles
SAFen periaatteet
Scrum Master
Scrummaster
ScrumXP
ScrumXP
Set-Based Design
Joukkopohjainen suunnittelu
Shared Services
Jaetut palvelut
Solution Architect/Engineering
Ratkaisuarkkitehti
Solution Context
Ratkaisun konteksti
Solution Demo
Ratkaisun demo
Solution Intent
Ratkaisun tarkoitus
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
17
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Solution Management
Ratkaisun hallinta
Solution
Ratkaisu
Spanning Palette
SAFen räätälöintiosa
Stories
Tarinat
Strategic Themes
Strategiset teemat
Supplier
Toimittaja
System Architect/Engineering
Järjestelmäarkkitehti
System Demo
Järjestelmädemo
System Team
Integrointitiimi
Team Backlog
Tiimin kehitysjono
Team Demo
Tiimin demo
Team Kanban
Kanban
Team Level
Tiimitaso
Team PI Objectives
Tiimin inkrementin tavoitteet
Test-First
Testaus edellä –käytäntö
User Experience
Käytettävyys
Value Stream Backlog
Arvovirran kehitysjono
Value Stream Coordination
Arvovirran koordinointi
Value Stream Engineer
Arvovirran kehityspäällikkö
Value Stream Epics
Arvovirran kehitysaihiot
Value Stream Kanban
Arvovirran valmisteluseinä
Value Stream Level
Arvovirtataso
Value Stream PI Objectives
Arvovirran inkrementin tavoitteet
Value Streams
Arvovirrat
Vision
Visio
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
18
®
Sanasto | SAFe 4.0 Sujuvaan ja ketterään ohjelmistojen ja järjestelmien kehittämiseen
Weighted Shortest Job First (WSJF)
Leffingwell, et al. © 2008–2016 Scaled Agile, Inc.
Painotettu pienin työmäärä
19