© 2021 Scaled Agile, Inc. All rights reserved.

Evolving the Scaled Agile Framework:

Update to SAFe 5

Guidance for organizing around value, DevSecOps, and agility for business teams

Learn more

Clear explanations and actionable guidance

SAFe Distilled 5.0

SAVE 35% WITH CODE SCALEDAGILE

ORDER NOW

Remote-Enabled SAFe: Tools & Resources

Learn More

SAFe Glossary

Authors

A

  • Agile Product Delivery (Ketterä tuotteen toimitus)

    Ketterä tuotteen toimitus on asiakaslähtöinen lähestymistapa määritellä ja kehittää arvoa tuottavia tuotteita ja palveluita asiakkaille ja käyttäjille, sekä julkaista niitä jatkuvana virtana.

  • Agile Release Train, ART (Julkaisujuna)

    Julkaisujuna muodostuu useista ketteristä tiimeistä, joka yhdessä muiden sidosryhmien kanssa kehittää pala kerrallaan, julkaisee ja joissakin tapauksissa myös ylläpitää yhden tai useampia arvovirran ratkaisuja.

  • Agile Team (Ketterä tiimi)

    SAFessa ketterä tiimi on 5–11 henkilöstä koostuva, moniosaava tiimi, joka määrittää, kehittää, testaa ja julkaisee pieniä paloja arvoa lyhyessä aikaikkunassa.

  • Architectural Runway (Arkkitehtuurin kiitorata)

    Arkkitehtuurin kiitorata koostuu olemassa olevasta koodista, komponenteista ja teknisestä infrastruktuurista, joita tarvitaan toteuttamaan lyhyen tähtäimen ominaisuuksia ilman mittavaa uudelleen suunnittelua ja viiveitä.

B

  • Built-In Quality (Sisäänrakennettu laatu)

    Sisäänrakennettu laatu varmistaa, että kaikki ratkaisun osat täyttävät asianmukaiset laatuvaatimukset kaikissa vaiheissa koko kehitystyön ajan.

  • Business Agility (Liiketoiminnan ketteryys)

    Liiketoiminnan ketteryys on kyky kilpailla ja menestyä digiajassa vastaamalla nopeasti markkinoiden muutoksiin ja esiin nouseviin uusiin mahdollisuuksiin innovatiivisilla liiketoimintaratkaisuilla.

  • Business Owners (Liiketoiminnan edustajat)

    Liiketoiminnan edustajat ovat pieni joukko sidosryhmien jäseniä, joilla on ensisijainen liiketoiminnallinen ja tekninen vastuu julkaisujunan (ART) kehittämän ratkaisun hallinnasta, sääntelystä (Compliance) ja sijoitetun pääoman tuotosta (ROI). He ovat julkaisujunan tärkeitä sidosryhmiä, jotka arvioivat toteutettavan ratkaisun käyttökelpoisuutta ja osallistuvat aktiivisesti tiettyihin julkaisujunan tapahtumiin.

C

  • Capabilities (Kyvykkyydet)

    Useampi julkaisujuna toteuttaa ratkaisujunan ominaisuuksia, joita kutsutaan kyvykkyyksiksi. Kyvykkyydet mitoitetaan ja jaetaan useisiin ominaisuuksiin (Feature) helpottamaan niiden toteuttamista yhden PI:n aikana.

  • Communities of Practice, CoPs (Osaamisyhteisö)

    Osaamisyhteisöt ovat ryhmiä, joilla on yhteinen mielenkiinto johonkin tiettyyn tekniikan tai liiketoiminnan alueeseen. He tekevät säännöllisesti yhteistyötä jakaakseen keskenään tietoa, parantaakseen taitojaan ja lisätäkseen yleistä alueen tietämystä.

  • Compliance (Sääntelynmukaisuus)

    Sääntelynmukaisuus tarkoittaa lean-ketterää kehitysstrategiaa ja toimintoja, joilla tiimit voivat luoda järjestelmiä, jotka ovat mahdollisimman korkealaatuisia ja täyttävät kaikki asiaankuuluvat lait ja säädökset sekä toimialakohtaiset standardit.

  • Continuous Delivery Pipeline, CDP (Jatkuva toimitusputki)

    Jatkuva toimitusputki edustaa työnkulkuja, toimintoja sekä automatisointia, joita tarvitaan uuden ominaisuuden viemiseksi ideasta julkaisuun.

  • Continuous Deployment, CD (Jatkuva tuotantoympäristöön vienti)

    Jatkuva tuotantoympäristöön vienti on prosessi, joka siirtää esituotantoympäristössä (staging environment) validoituja ominaisuuksia tuotantoympäristöön, jossa ne ovat valmiina julkaisuun.

  • Continuous Exploration, CE (Jatkuva tutkimus)

    Jatkuva tutkimus on prosessi, joka analysoi jatkuvasti asiakkaiden ja markkinoiden tarpeita, edistää innovaatiota ja auttaa löytämään yhteisen näkemyksen ratkaisun visiosta, tiekartasta ja toteutettavista ominaisuuksista (Features).

  • Continuous Integration, CI (Jatkuva integrointi)

    Jatkuva integrointi on prosessi, jolla julkaisujunan kehitysjonon ominaisuuksia kehitetään, testataan ja integroidaan. Ominaisuudet validoidaan esituotantoympäristössä (staging environment), jossa ne ovat valmiina tuotantoympäristöön vientiä ja julkaisua varten.

  • Continuous Learning Culture (Jatkuvan oppimisen kulttuuri)

    Jatkuvan oppimisen kulttuuri kuvaa arvoja ja käytäntöjä, jotka rohkaisevat yksilöitä ja koko organisaatiota lisäämään tietoa, osaamista, tehokkuutta ja innovaatiota jatkuvalla tahdilla.

  • Core Values (Ydinarvot)

    SAFen neljä ydinarvoa ovat yhtenäinen suunta, sisäänrakennettu laatu, läpinäkyvyys ja hanketason toteutus. Nämä arvot kuvastavat yleisiä käsityksiä, joihin SAFen tehokkuus perustuu. Nämä periaatteet ohjaavat kaikkien SAFe-organisaatiossa työskentelevien käyttäytymistä ja toimintaa.

  • Customer (Asiakas)

    Asiakas on portfolion arvovirroissa toteutetuista ja ylläpidetyistä ratkaisuista hyötyvä taho.

  • Customer Centricity (Asiakaslähtöisyys)

    Asiakaslähtöisyys on ajattelumalli ja tapa tehdä liiketoimintaa, joka keskittyy positiivisten kokemusten luomiseen asiakkaalle yrityksen tarjoamilla tuotteilla ja palveluilla.

D

  • Design Thinking (Suunnitteluajattelu)

    Suunnitteluajattelu on asiakaslähtöinen kehitysprosessi, jolla luodaan tuotteita, jotka ovat haluttuja, kannattavia ja kestäviä koko elinkaarensa ajan.

  • DevOps (DevOps)

    DevOps on ajattelumalli, toimintakulttuuri ja kokoelma teknisiä käytäntöjä. Se painottaa kommunikaatiota, integrointia, automaatiota sekä tiivistä yhteistyötä kaikkien niiden ihmisten välillä, joita tarvitaan kehittämään, testaamaan, viemään tuotantoon sekä ylläpitämään ohjelmistoja ja järjestelmiä.

E

  • Enablers (Mahdollistajat)

    Mahdollistajien avulla rakennetaan ja laajennetaan arkkitehtuurin kiitorataa (Architectural Runway). Niitä ovat tutkinta (Exploration), arkkitehtuuri, infrastruktuuri sekä sääntelynmukaisuus (Compliance). Mahdollistajia tarvitaan SAFe-raamin (SAFe Frameworkin) kaikilla tasoilla tulevaisuuden ominaisuuksien kehittämiseksi ja niitä säilytetään ominaisuuksien tavoin kehitysjonoissa.

  • Enterprise (Yritys)

    Yritys tarkoittaa liiketoimintakokonaisuutta, johon jokainen SAFe-portfolio kuuluu.

  • Enterprise Architect (Yritysarkkitehti)

    Yritysarkkitehti laatii teknologiastrategian ja tiekartan, jolla portfolio voi tukea nykyisiä ja tulevia liiketoimintamahdollisuuksia.

  • Enterprise Solution Delivery (Yrityksen ratkaisun toimitus)

    Yrityksen ratkaisun toimitus kuvaa sitä kyvykkyyttä, miten leanejä ja ketteriä periaatteita ja käytäntöjä sovelletaan maailman laajimpien ja kehittyneimpien ohjelmistosovellusten, verkkojen ja kyberfyysisten järjestelmien määrittämiseen, kehittämiseen, tuotantoympäristöön vientiin, ylläpitoon ja jatkokehitykseen.

  • Epic Owners (Aihioiden omistajat)

    Aihioiden omistajat ovat vastuussa portfolion aihioiden koordinoinnista hyödyntäen portfolio-kanbania. He määrittelevät aihion MVP:n (pienimmän toteutuskelpoisen tuotteen) ja ketterän liiketoimintakuvauksen. Hyväksynnän jälkeen he fasilitoivat aihion toteutusta.

  • Epics (aihiot)

    Aihio kuvaa investoinniltaan merkittävän portfoliotason kehitysaloitteen. Johtuen niiden huomattavasta laajuudesta ja vaikuttavuudesta aihiot vaativat pienimmän toteutuskelpoisen tuotteen (MVP) määrittämisen ja portfolion johdon (Lean Portfolio Management) hyväksynnän ennen toteuttamista.

  • Essential SAFe (SAFen ydin)

    SAFe ydin sisältää sisältää pienimmän mahdollisen joukon rooleja, tapahtumia ja tuotoksia, jotka vaaditaan liiketoimintaratkaisujen jatkuvaan kehittämiseen julkaisujunassa (ART) ketterien tiimien tiiminä.

F

  • Features (Ominaisuudet)

    Ominaisuus on palvelu, joka täyttää sidosryhmien tarpeita. Jokainen ominaisuus (Feature) määritellään kuvaamalla hyötyhypoteesi ja hyväksymiskriteerit. Jokainen ominaisuus kehitetään yhdessä julkaisujunassa (ART) yhden inkrementin (PI) aikana.

  • Foundation (Perusta)

    Perusta sisältää SAFen arvot, periaatteet, ajattelumallin, käyttöönoton suuntaviivat ja ketterän johtajuuden roolit, joita tarvitaan menestyksekkääseen arvon tuottoon skaalautuvasti.

  • Full SAFe (Koko SAFe)

    Koko SAFe on kaikkein kattavin konfiguraatio, joka sisältää kaikki ketterän liiketoiminnan vaatimat seitsemän osaamisaluetta, joilla aikaansaadaan liiketoiminnan ketteryys.

I

  • Innovation and Planning Iteration (Innovaatio- ja suunnitteluiteraatio)

    Innovaatio- ja suunnitteluiteraatio sisältyy jokaiseen julkaisujunan inkrementtiin (PI) palvellen useaa eri tarkoitusta. Se tuo väljyyttä PI:n tavoitteiden saavuttamiselle ja tarjoaa aikaa innovoinnille, toistuville koulutuksille, julkaisujunan inkrementin suunnittelutapahtumille (PI Planning) sekä tutki ja sopeuta (I&A) -tapahtumille.

  • Inspect & Adapt, I&A (Tutki ja sopeuta)

    Tutki ja sopeuta on merkittävä, jokaisen julkaisujunan inkrementin lopussa tapahtuva tilaisuus, jossa esitellään ja arvioidaan julkaisujunan toteuttaman ratkaisun sen hetkinen tila. Tämän jälkeen tiimit miettivät ja tunnistavat jatkokehitystoimenpiteitä vakiosisältöisessä ongelmanratkaisutyöpajassa.

  • Iteration (Iteraatio)

    Iteraatio on ketterän kehittämisen peruspalikka. Jokainen iteraatio on vakiomittainen ajanjakso, jossa ketterät tiimit toimittavat inkrementaalisesti arvoa toimivan ja testatun ohjelmiston ja järjestelmän muodossa. Ajanjakson suositeltu kesto on kaksi viikkoa. Iteraation pituus voi olla liiketoiminnan kontekstista riippuen yhdestä neljään viikkoa.

  • Iteration Execution (Iteraation toteutus)

    Iteraation toteutus tarkoittaa sitä, miten ketterät tiimit hallitsevat työtään iteraation aikana. Sen tuloksena syntyy laadukas, toimiva ja testattu järjestelmän osa.

  • Iteration Goals (Iteraation tavoitteet)

    Iteraation tavoitteet ovat korkean tason yhteenveto liiketoiminnallisista ja teknisistä tavoitteista, joiden saavuttamiseen ketterä tiimi sitoutuu iteraation aikana. Tavoitteet ovat välttämättömiä julkaisujunan (ART) koordinoimiseksi itseorganisoituvana ja -ohjautuvana tiimien tiiminä.

  • Iteration Planning (Iteraation suunnittelu)

    Iteraation suunnittelu on tapahtuma, jossa tiimin jäsenet määrittelevät yhdessä, kuinka paljon tiimin kehitysjonosta he sitoutuvat toimittamaan seuraavan iteraation aikana. Lopuksi tiimi tekee yhteenvedon, listan iteraation tavoitteista, joihin tiimi on sitoutunut.

  • Iteration Retrospective (Iteraation retrospektiivi)

    Iteraation retrospektiivi on säännöllinen tapahtuma, jossa ketterän tiimin jäsenet keskustelevat iteraation tuloksista, käytäntöjen toimivuudesta ja tunnistavat tapoja parantaa toimintaa.

  • Iteration Review (Iteraation katselmus)

    Iteraation katselmus on säännöllinen tapahtuma jokaisen iteraation lopussa, jossa jokainen tiimi tarkastelee toteutettua inkrementtiä, arvioi edistymistä ja valmistelee kehitysjonon seuraavaa iteraatiota varten.

L

  • Large Solution SAFe (Suuri-SAFe)

    Suuri-SAFe on SAfen konfiguraatio, jossa lisätään rooleja, käytäntöjä ja suuntaviivoja ja kuvataan miten rakennetaan ja kehitetään maailman suurimpia sovelluksia, verkkoja ja kyber-fyysisiä järjestelmiä.

  • Lean Budget Guardrails (Leanin budjetin liikkumavara)

    Leanin budjetin liikkumavarat (guardrails) kuvaavat tietyn portfolion periaatteet ja käytännöt budjetointiin, investointiin ja niiden hallintaan.

  • Lean Budgets (Ketterä budjetointi)

    Ketterä budjetointi on lean-ketterä lähestymistapa rahoituksen hallintaan. Se lisää kehityksen läpimenoa ja tuottavuutta vähentämällä rahoituksen hallinnollisia kuluja ja projektien kustannuslaskelmien aiheuttamia hidasteita.

  • Lean Portfolio Management, LPM (Lean-portfolion hallinta)

    Lean-portfolion hallinta on kyvykkyys yhdenmukaistaa strategiaa ja toteutusta soveltamalla Lean- ja systeemiajattelua strategiaan ja investointien rahoitukseen, ketterän portfolion operointiin ja hallintoon.

  • Lean User Experience, Lean UX (Lean käyttökokemus)

    Lean-käyttäjäkokemuksen suunnittelu on leanien ja ketterien periaatteiden mukainen ajattelutapa, kulttuuri ja prosessi. Siinä toiminnallisuudet toteutetaan inkrementaalisesti minimitoimituksina (minimum viable), joiden onnistumista arvioidaan mittaamalla hyötyhypoteesien tuloksia.

  • Lean-Agile Leadership (Lean-ketterä-johtaminen)

    Lean-ketterä-johtaminen kuvaa kuinka sitä miten leaniin ja ketterään pohjautuva johtajuus ylläpitää organisaation muutosta ja operatiivista onnistumista voimautetaan yksilöt ja tiimit hyödyntämään kattavasti omia voimavarojaan.

  • Lean-Agile Mindset (Lean-ketterä-ajattelutapa)

    Lean-ketterä ajattelutapa on yhdistelmä SAFen käyttäjien ja kehittäjien uskomuksia, oletuksia, asenteita ja toimintaa, jotka pohjautuvat ketterän ohjelmistokehityksen julistukseen (Manifesto for Agile Software Development) ja lean-ajatteluun. Se toimii SAFe-periaatteiden ja käytäntöjen omaksumisen ja soveltamisen henkilökohtaisena, henkisenä ja johtajuuden perustana.

  • Lean-Agile Principles (Leanit ja ketterät periaatteet)

    SAFe perustuu kymmeneen pysyvään kaiken takana olevaan leaniin ja ketterään periaatteeseen. Nämä pääperiaatteet ja taloudelliset käsitteet toimivat innostuksena ja opasteena SAFen rooleille ja käytännöille.

M

  • Measure And Grow (Mittaus ja kasvu)

    Mittaus ja kasvu on tapa, jolla portfoliot arvioivat edistymistään kohti liiketoiminnan ketteryyttä ja määrittelevät seuraavat parantamisen vaiheet.

  • Metrics (Metriikka)

    Metriikka tarkoittaa sovittuja mittareita, joiden avulla seurataan, miten organisaatio etenee kohti portfolion, ratkaisun, järjestelmän ja tiimin teknisiä ja liiketoiminnallisia tavoitteita.

  • Milestones (Tarkistuspisteet)

    Tarkistuspisteillä seurataan etenemistä kohti määrättyä tavoitetta tai tapahtumaa. SAFessa on kolmenlaisia tarkistuspisteitä: julkaisujunan inkrementin (PI) aloitus- ja loppumispäivät, erityisesti sovitut tärkeät päivämäärät sekä päivät, jolloin saadaan palautetta oppimista varten.

  • Model-Based Systems Engineering, MBSE (Mallipohjainen systeemisuunnittelu)

    Mallipohjainen systeemisuunnittelu on käytäntö, jossa kehitetään joukko toisistaan riippuvia systeemimalleja, jotka auttavat määrittelemään, suunnittelemaan ja dokumentoimaan kehitteillä olevan järjestelmän. Mallit tarjoavat tehokkaan tavan järjestelmän osien tutkimiseen, päivittämiseen ja viestimiseen sidosryhmille vähentäen samalla merkittävästi tai poistamalla kokonaan perinteisten dokumenttien tarpeen.

N

  • Nonfunctional Requirements, NFR (Ei-toiminnalliset vaatimukset)

    Ei-toiminnalliset vaatimukset määrittelevät järjestelmän ominaisuuksia, kuten turvallisuutta, luotettavuutta, suorituskykyä, ylläpidettävyyttä, skaalattavuutta ja käytettävyyttä. Ne toimivat järjestelmän suunnittelun ehtoina ja rajoitteina eri kehitysjonoissa.

O

  • Organizational Agility (Organisaation ketteryys)

    Organisaation ketteryys kuvaa, kuinka lean-ajattelumallia noudattavat ihmiset ja ketterät tiimit optimoivat liiketoimintaprosessejaan ja kehittävät strategiaansa päättäväisesti ja mukauttavat organisaatiotaan nopeasti hyödyntääkseen uusia mahdollisuuksia.

P

  • PI Objectives (Inkrementin tavoitteet)

    Inkrementin tavoitteet on koottu lista niistä liiketoiminnallisista ja teknisistä tavoitteista, jotka ketterät tiimit ja julkaisujunat pyrkivät toteuttamaan seuraavassa inkrementissä (Program Increment, PI).

  • Portfolio Backlog (portfolion kehitysjono)

    Portfolion kehitysjono on SAFe:n ylimmällä tasolla oleva kehitysjono. Siellä pidetään tulevia liiketoiminnan aihioita ja mahdollistajia, joiden perusteella luodaan ja kehitetään kokonaisvaltaisia ratkaisuja (Solutions).

  • Portfolio Kanban (Portfolion kanban)

    Portfolion kanban on menetelmä, jota käytetään hallitsemaan ja visualisoimaan liiketoiminnan aihioiden virtaa ideoinnista analyysiin, toteutukseen ja valmistumiseen.

  • Portfolio SAFe (Portfolion SAFe)

    Portfolion SAFe yhdensuuntaistaa strategian ja toteutuksen. Se organisoi ratkaisujen jatkuvan arvon tuottamisen yhden tai useamman arvovirran kautta.

  • Portfolio Vision (Portfolion visio)

    Portfolion visio on kuvaus portfolion arvovirtojen ja ratkaisujen tulevasta tilasta. Se kuvaa, kuinka ne tekevät yhteistyötä saavuttaakseen portfolion tavoitteet ja organisaation laajemman päämäärän.

  • Pre- and Post-PI Planning (Esi- ja jälkisuunnittelu)

    Esi-ja jälkisuunnittelulla valmistaudutaan ratkaisujunaan sisältyvien julkaisujunien ja toimittajien inkrementin suunnitteluihin ja seurataan niiden toteutumista.

  • Product Management (Tuotehallinta)

    Tuotehallinta on vastuussa houkuttelevien, toteuttamiskelpoisten, elinkelpoisten ja kestävien tuotteiden määrittämisestä ja toteutusaikaisesta tukemisesta, jotka vastaavat asiakkaan tarpeita tuotteen elinkaaren aikana.

  • Product Owner, PO (Tuoteomistaja)

    Tuoteomistaja (PO) on ketterän tiimin jäsen, jonka vastuulla on tarinoiden (Stories) määrittely ja priorisointi tiimin kehitysjonoon (Team Backlog) sekä tiimin toiminnan linjaaminen julkaisujunan prioriteettien mukaan. Tuoteomistaja vastaa tiimin tekemien ominaisuuksien (Features) käsitteellisestä ja teknisestä eheydestä.

  • Program Backlog (Julkaisujunan kehitysjono)

    Julkaisujunan kehitysjono on tallennuspaikka niille suunnitelluille ominaisuuksille (Features), jotka vastaavat käyttäjien tarpeisiin ja tuovat liiketoiminnallisia etuja ketterälle julkaisujunalle (ART). Se sisältää myös ominaisuuksien mahdollistajat arkkitehtonisen kiitotien rakentamiseksi.

  • Program Increment, PI (Inkrementti)

    Inkrementti on ajanjakso, jonka aikana julkaisujuna (Agile Release Train, ART) tuottaa asteittain arvoa toimivien ja testattujen ohjelmistojen ja järjestelmien muodossa. Inkrementit ovat tyypillisesti 8–12 viikkoa pitkiä. Inkrementin tyypillisin toteutustapa on neljä peräkkäistä kehitysiteraatiota, joita seuraa yksi innovaatio- ja suunnitteluiteraatio (Innovation and Planning, IP).

  • Program Increment (PI) Planning (Inkrementin Suunnittelu)

    Inkrementin suunnittelu on säännölllinen kasvokkain järjestettävä julkaisujunan tapaaminen, jolla saavutetaan yhteinen rytmi. Siinä julkaisujunan tiimit sitoutuvat yhteiseen jaettuun tavoitteeseen ja visioon.

  • Program Kanban (Julkaisujunan kanban)

    Julkaisujunan ja ratkaisujunan kanbanit ovat menetelmiä, joilla visualisoidaan ja hallitaan ominaisuuksien (Feature) ja kyvykkyyksien (Capabilities) virtausta ideoinnista analyysiin, toteutukseen ja julkaisuun jatkuvan jatkuvan toimitusputken (Continuous Delivery Pipeline) kautta.

R

  • Release on Demand (Kysynnän mukainen julkaisu)

    Kysynnän mukainen julkaisu on prosessi, joka vie uusia toimintoja tuotantoon ja julkaisee ne välittömästi tai paloittain asiakkaille kysynnän perusteella.

  • Release Train Engineer, RTE (Julkaisujunan päällikkö)

    Julkaisujunan päällikkö on ketterän julkaisujunan (Agile Release Train, ART) palveleva johtaja ja valmentaja. Julkaisujunan päällikkö (RTE) on vastuussa etenkin julkaisujunan tapahtumien fasilitoinnista, prosesseista ja niiden noudattamisesta. Lisäksi hän auttaa tiimejä arvon tuottamisessa. RTE:t kommunikoivat sidosryhmien kanssa, nostavat esteitä johdon tietoisuuteen, auttavat hallitsemaan riskejä ja ajavat periksiantamatonta parantamista.

  • Roadmap (tiekartta)

    Tiekartta on tapahtumia ja tarkistuspisteitä (Milestones) sisältävä aikataulu, mikä esittää tulevaisuudessa suunnitellut ratkaisujen (Solution) julkaisut suunnittelun aikaväleillä.

S

  • SAFe for Government (Julkishallinnon SAFe)

    Julkishallinnon SAFe on joukko menestyksekkäitä tapoja, joiden avulla julkisen sektorin organisaatiot voivat ottaa käyttöön lean-ketterä-käytäntöjä.

  • SAFe for Lean Enterprises (SAFe for Lean Enterprises)

    SAFe for Lean Enterprises on todistetuista, integroiduista periaatteista, käytännöistä ja kompetensseista koottu tietämyskanta (knowledge base), jolla lean-yritys voi saavuttaa liiketoiminnan ketteryyden (Business Agility) hyödyntäen leaniä, ketteriä menetelmiä ja DevOpsia skaalautuvasti.

  • SAFe Implementation Roadmap (SAFen käyttöönoton tiekartta)

    SAFen käyttöönoton tiekartta koostuu yleiskuvasta ja 12 artikkelin sarjasta, joissa kuvataan strategia ja onnistuneeseen SAFen käyttöönottoon käytännössä toimiviksi todistetut tehtävät.

  • SAFe Program Consultants, SPCs (SAFe-konsultit)

    Sertifioidut SAFe-konsultit ovat muutosagentteja, jotka yhdistävät oman sisäisen motivaationsa SAFe-osaamiseen parantaakseen yrityksen ohjelmisto- ja järjestelmäkehitysprosesseja. Heillä on on erittäin tärkeä rooli SAFe:n onnistuneessa käyttöönotossa. SPC:t voivat olla taustaltaan esimerkiksi liiketoiminta- tai teknologiajohtajia, ohjelma- tai projektipäälliköitä, prosessipäälliköitä, arkkitehtejä, analyytikkoja tai konsultteja.

  • Scrum Master (Scrummaster)

    Scrummasterit ovat ketterien tiimien palvelevia johtajia ja valmentajia. He auttavat scrumin, XP:n (Extreme Programming), Kanbanin ja SAFen käytössä varmistaen, että sovittua ketterää prosessia noudatetaan. He auttavat myös poistamaan esteitä ja luovat ympäristön suorituskykyiselle tiimidynamiikalle, jatkuvalle virtaukselle ja periksiantamattomalle parannukselle.

  • ScrumXP

    ScrumXP on kevyt prosessi, jota SAFen itseohjautuvat moniosaajatiimit käyttävät tuottaakseen arvoa. Se yhdistää scrumin projektinhallintakäytännöt Extreme Programming (XP) -käytäntöihin.

  • Set-Based Design (Joukkopohjainen suunnittelu)

    Joukkopohjaisessa suunnittelussa kehityksen aikaisia vaatimuksia ja suunnitelmia pidetään mahdollisimman pitkään avoinna. Yhden ennakkoon kiinnitetyn suunnitteluratkaisun sijaan tunnistetaan ja tutkitaan useita vaihtoehtoja samanaikaisesti ja eliminoidaan huonommat vaihtoehdot ajan myötä. Tämä lisää joustavuutta suunnitteluprosessiin, koska teknisiin ratkaisuihin sitoudutaan vasta oletusten validoinnin jälkeen. Tällainen suunnitteluprosessi johtaa parempiin taloudellisiin tuloksiin.

  • Shared Services (Yhteiset palvelut)

    Yhteiset palvelut ovat erityisosaamisen rooleja, ihmisiä ja palveluita, joita tarvitaan julkaisujunan (Agile Release Train, ART) tai ratkaisujunan (Solution Train) onnistumiseksi, mutta joita ei voida kiinnittää tiimeihin päätoimisesti.

  • Solution (Ratkaisu)

    Ratkaisu on yhden tai useamman arvovirran tuotos, jotka voivat olla tuotteita, palveluita tai järjestelmiä, joita toimitetaan sisäisille tai ulkoisille asiakkaille.

  • Solution Architect/Engineer (Ratkaisuarkkitehti)

    Ratkaisuarkkitehti on vastuussa kaikille yhteisen teknisen ja arkkitehtuurivision määrittämisestä ja viestimisestä ratkaisujunalle varmistaakseen, että kehitettävä järjestelmä tai ratkaisu sopii haluttuun tarkoitukseen.

  • Solution Backlog (Ratkaisun kehitysjono)

    Ratkaisun kehitysjono on säilytyspaikka tuleville kyvykkyyksille (Capabilities) ja mahdollistajille (Enablers), joista ratkaisu (Solution) ja arkkitehtuurin kiitorata (Architectural Runway) rakentuvat ja jotka voidaan toteuttaa useammassa julkaisujunassa (ART).

  • Solution Context (Ratkaisun ympäristö)

    Ratkaisun ympäristö määrittelee ratkaisun toimintaympäristön kriittiset ominaisuudet. Se tarjoaa oleellisen tiedon ratkaisun asentamisen, käytön, ylläpidon ja tuen kannalta. Ratkaisun ympäristö vaikuttaa merkittävästi ratkaisun kysynnän mukaisen julkaisun (Release on Demand) mahdollisuuksiin ja rajoitteisiin.

  • Solution Demo (Ratkaisun demo)

    Ratkaisun demo on tapahtuma, jossa ratkaisujunassa integroitu työ esitellään ja annetaan arvioitavaksi asiakkaille ja muille sidosryhmille.

  • Solution Intent (Ratkaisun tarkoitus)

    Ratkaisun tarkoitus on säilytyspaikka, jonne tallennetaan, jossa hallitaan ja jolla viestitään ratkaisun nykyistä sekä aiottua käyttäytymistä. Tarvittaessa tämä sisältää sekä sovitun että muuttuvat määrittelyt ja muotoilun (design), viittaukset sovellettaviin standardeihin, järjestelmämalleihin, toiminnallisiin ja ei-toiminnallisiin testeihin sekä jäljitettävyyteen.

  • Solution Management (Ratkaisunhallinta)

    Ratkaisunhallinta on vastuussa asiakkaiden haluamien, kannattavien, kestävien sekä ylläpidettävien ja toteuttamiskelpoisten suurten liiketoimintaratkaisujen toteutuksen määrittelystä ja tukemisesta kattaen ratkaisujen koko elinkaaren.

  • Solution Train (Ratkaisujuna)

    Ratkaisujuna on organisaatiorakenne, joka koordinoi useampaa julkaisujunaa (ART) ja sekä toimittajien tuotoksia suurten ja monimutkaisten ratkaisujen kehityksessä. Ratkaisujunan visio, kehitysjono ja tiekartta linjaa siihen kuuluvien julkaisujunien inkrementtien (PI) sisältöä siten, että yhteinen liiketoiminta- ja teknologiamissio toteutuu.

  • Solution Train Engineer, STE (Ratkaisujunan päällikkö)

    Ratkaisujunan päällikkö on palveleva johtaja ja valmentaja, joka fasilitoi ja ohjaa kaikkien arvovirran junien ja toimittajien (Supplier) työtä.

  • Spanning Palette (Räätälöintipaletti)

    Räätälöintipaletti sisältää erilaisia rooleja ja tuotoksia, joita voidaan käyttää tiimeissä, julkaisujunissa, suurissa ratkaisuissa tai portfoliossa.

  • Stories (Tarinat)

    Tarinat ovat käyttäjän omalla kielellä kirjoitettuja lyhyitä kuvauksia jostain halutun toiminnallisuuden pienestä osasta. Ketterät tiimit toteuttavat pienen, vertikaalisen järjestelmän osan, jotka on mitoitettu niin, että ne voidaan toteuttaa yhdessä iteraatiossa.

  • Strategic Themes (Strategiset teemat)

    Strategiset teemat ovat liiketoimintatavoitteita, joilla yritys pyrkii erottautumaan ja jotka kytkevät yrityksen strategian portfolioon. Ne vaikuttavat portfolion strategiaan ja toimivat portfolion päätöksenteon tukena.

  • Supplier (Toimittaja)

    Toimittaja on sisäinen tai ulkoinen organisaatio, joka kehittää ja toimittaa sellaisia komponentteja, alijärjestelmiä tai palveluja, jotka auttavat sekä ratkaisujunia (Solution Train) että julkaisujunia (Agile Release Train) toimittamaan ratkaisuja (Solution) asiakkailleen.

  • System Architect/Engineer (Järjestelmäarkkitehti/suunnittelija)

    Järjestelmäarkkitehti/suunnittelija on vastuussa yhteisen teknisen ja arkkitehtuurivision määrittämisestä ja viestimisestä koko ketterälle julkaisujunalle (Agile Release Train, ART) sen varmistamiseksi, että kehitettävä järjestelmä tai ratkaisu soveltuu haluttuun tarkoitukseen.

  • System Demo (Järjestelmädemo)

    Järjestelmädemo on julkaisujunan (ART) merkittävä tapahtuma, jossa esitellään tiimien viimeisimmistä iteraatioista tulleet ominaisuudet (Feature) integroituna. Järjestelmädemo tarjoaa sidosryhmilleen objektiivisen arvion siitä, miten järjestelmän tekeminen on edistynyt viimeisimmässä inkrementissä.

  • System Team (Systeemitiimi)

    Systeemitiimi on erikoistunut ketterä tiimi (Agile Team), joka auttaa ketterän kehitysympäristön luonnissa ja tukemisessa, sisältäen jatkuvaa toimitusputkea (Continuous Delivery Pipeline) tukevan työkalukokoelman kehityksen ja ylläpidon. Systeemitiimi voi myös tukea ketterien tiimien tuotosten integrointia, tekee tarvittaessa ratkaisun (Solution) päästä-päähän-testausta ja avustaa käyttöönotossa sekä kysynnän mukaisessa julkaisussa (Release on Demand).

T

  • Team and Technical Agility (Tiimin ketteryys ja ketteryyden tekniikka)

    Tiimin ketteryys ja ketteryyden tekniikka -kompetenssi kuvaa kuvaa niitä kriittisiä taitoja, leaneja ja ketteriä periaatteita sekä käytäntöjä, mitä ketterät tiimit ja ketteristä tiimeistä koostuvat tiimit hyödyntävät rakentaessaan korkealaatuisia ratkaisuja asiakkailleen.

  • Team Backlog (Tiimin kehitysjono)

    Tiimin kehitysjono sisältää julkaisujunan kehitysjonosta (Program Backlog) lähtöisin olevat tarinat ja mahdollistavat tarinat (Enabler Story) sekä tarinat, jotka syntyvät paikallisesti tiimin omista tarpeista. Se saattaa sisältää myös kaikkia muita töitä, joita tiimin on tehtävä edistääkseen omaa osuuttaan järjestelmäkehityksessä.

  • Team Kanban (Tiimin kanban)

    Tiimin kanbanin avulla visualisoidaan työn kulku sekä hallitaan tiimin tuottaman arvon virtausta. Kanban toimii työkaluna kun rajoitetaan keskeneräisen työn määrää (WIP) mitataan läpivirtausta ja tehdään jatkuvaa parantamista.

V

  • Value Stream Coordination (Arvovirran koordinointi)

    Arvovirran koordinointi tarjoaa ohjausta portfolion sisältämien arvovirtojen välisten riippuvuuksien hallitsemiseksi ja niiden yhtymäkohtien tarjoamien mahdollisuuksien hyödyntämiseen.

  • Value Stream KPIs (Arvovirran suorituskykymittarit, KPIt)

    Arvovirran suorituskykymittarit ovat määrällisiä mittareita joiden avulla arvioidaan, kuinka hyvin arvovirta on saavuttamassa sille ennustettuja liiketoimintahyötyjä.

  • Value Streams (Arvovirrat)

    Arvovirta kuvaa kaikki ne vaiheet, joita organisaatio tekee tuottaakseen ratkaisua asteittain asiakkaalle.

  • Vision (Visio)

    Visio kuvaa millainen kehitettävä ratkaisu (Solution) tulee olemaan tulevaisuudessa. Se kuvastaa asiakkaiden ja sidosryhmien tarpeita sekä alustavia ominaisuuksia ja kyvykkyyksiä, jotka vastaavat näihin tarpeisiin.

W

  • Weighted Shortest Job First, WSJF (Painotettu nopein arvo)

    Painotettu nopein arvo on priorisointimalli, jota käytetään priorisoimaan ominaisuuksia (Feature), kyvykkyyksiä (Capabilities) ja aihioita (Epic), jotta voidaan saavuttaa suurin mahdollinen taloudellinen hyöty. SAFessa WSJF arvioidaan viiveen aiheuttamana kustannuksena (CoD) jaettuna työn koolla.

© 2021 Scaled Agile, Inc. All rights reserved.