© 2024 Scaled Agile, Inc. All rights reserved.

We are back in Europe and hope you join us!

Prague, Czech Republic, 15 – 17, May 2023

Learn More

Evolving the Scaled Agile Framework:

Update to SAFe 5

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

Learn more

SAFe Glossary

The SAFe glossary is a set of definitions for all SAFe Big Picture elements.  The extended glossary provides definitions for additional terms used in the Framework. Some are unique to SAFe (e.g., PO Sync), while others are common in Lean-Agile development (e.g., MVP). They are provided here for clarity in their meaning in the context of SAFe. All extended glossary terms appear in the English configuration and will appear in other language configurations once translated.

5

  • 5 Whys (5 miksi -kysymystä)

    5 miksi -kysymystä on Tutki ja Sopeuta-tapahtumassa käytetty todennettu ongelmanratkaisumenetelmä, jota käytetään tutkimaan havaitun ongelman syy-seuraussuhteita.

A

  • Acceptance Criteria (Hyväksymiskriteerit)

    Hyväksymiskriteerit sisältävät tarvittavat tiedot sen varmistamiseen, että käyttäjätarina, toiminnallisuus tai ominaisuus on toteutettu oikein ja sisältää sekä oikean toiminnallisuuden että ei-toiminnalliset vaatimukset.

  • Acceptance Test Driven Development (Hyväksymistestiohjattu kehitys)

    Hyväksymistestiohjattu kehitys tarkoittaa, että hyväksymistestit tehdään ennen toteutusta. Se on ketterä testauskäytäntö, joka tarkoittaa samaa kuin käyttäytymisperusteinen kehittäminen (Behavioral-driven development, BDD).

  • Agile (Ketterä kehittäminen)

    Ketterä kehittäminen on joukko arvoja, periaatteita ja käytäntöjä iteratiiviseen kehittämisen toteuttamiseen. Sen kaikkein tunnetuin määritelmä on ketterän ohjelmistokehityksen julistus.

  • Agile Manifesto (Ketterän ohjelmistokehityksen julistus)

    Ketterän ohjelmistokehityksen julistus on uraauurtava yhteinen ketteryyden määritelmä, joka sisältää ketterän ohjelmistokehityksen neljä arvoa ja kaksitoista periaatetta.

  • 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 Program Management Office (Ketterä hankejohto)

    Ketterä hankejohto (The Agile Program Management Office, APMO) on organisaation funktio, joka vastaa ketterän portfolionhallinnan prosessien fasilitoinnista. APMO parantaa osana ketterää transformaatiota myös operatiivisen toiminnan laatua ja hallintotapaa.

  • 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.

  • Architect Sync (Arkkitehtien synkka)

    Arkkitehtien synkka on ratkaisujunan tapahtuma, joka varmistaa ratkaisujunaan kehitettävien arkkitehtuurisuunnitelmien johdonmukaisuuden Se ohjaa säännöllisesti kehittämisen lähtökohtia ja toiminnallisuuden suhteen tehtäviä kompromisseja koko ratkaisujunan tasolla ilman että ohjauksesta koituu merkittäviä viiveitä.

  • 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ä.

  • ART Sync (Junan synkka)

    Junan synkka (The ART Sync) on julkaisujunan tapahtuma, joka yhdistää tuoteomistajien (PO) synkan ja scrummien scrummin (Scrum of Scrums, SoS).

B

  • Backlog Refinement (Kehitysjonon jalostus)

    Kehitysjonon jalostus on kerran tai kaksi kertaa iteraatiossa tai inkrementissä oleva tapahtuma, jossa keskustellaan ja estimoidaan tiimin kehitysjonoon tulevat käyttäjätarinat sekä luodaan alustava ymmärrys niiden hyväksymiskriteereille.

  • Baseline Solution Investments, BSIs (Ratkaisun perustoiminnallisuuden investoinnit)

    Ratkaisun perustoiminnallisuuden investoinnit (Baseline Solution Investments, BSIs) sisältävät kunkin arvovirran kustannukset, jotka kohdistuvat tämän arvovirran jo olemassa olevien liiketoiminnan ratkaisujen kehittämiseen, tukemiseen ja operointiin.

  • Batch Size (Eräkoko)

    Eräkoko mittaa, kuinka paljon työtä (vaatimukset, muotoilu, toteutus, testaus ja muut tehtävät työt) on otettu tehtäväksi valitussa aikaikkunassa.

  • Behavior-Driven Development (Käyttäytymisperusteinen kehittäminen)

    Käyttäytymisperusteinen kehittäminen (Behavior-Driven Development, BDD) on ketterä testaus -edellä testauskäytäntö, joka johtaa sisäänrakennettuun laatuun määrittelemällä (ja mahdollisesti automatisoimalla) testitapaukset ennen tai osana järjestelmän käyttäytymisen määrittelyä.

  • Benefit Hypothesis (Hyötyolettama)

    Hyötyolettama on ehdotettu mitattava etu, jonka toiminnallisuus tai ominaisuus tuottaa loppukäyttäjälle tai liiketoiminalle.

  • Big Visible Information Radiator, BVIR ( Visuaalinen tiedon esittäjä (Big Visible Information Radiator, BVIR))

    Visuaalisen tiedon esittäjä (Big Visible Information Radiator, BVIR) on graafinen seinä tai näyttö, jossa kriittinen tieto on näkyvillä ja seurattavissa yhdellä silmäyksellä (esim. edistymiskäyrä, riippuvuuskartta, ohjelmiston käännöksien tilannekuvat).

  • 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.

  • Burn-Down (Burn-Up) Chart (Edistymiskäyrä)

    Vähenevät ja kasvavat edistymiskäyrät (Burn-Down and Burn-Up Charts) ovat graafisia kuvaajia, jotka näyttävät edistymisen ajan suhteessa.

  • Business Agility (Liiketoiminnan ketteryys)

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

  • Business and Technology (Liiketoiminta ja teknologia)

    Liiketoiminta- ja teknologia osio SAFessa kuvaa sitä, miten yrityksen eri toiminnot mahdollistavat liiketoiminnan ketteryyden. Eri toiminnot kokeilevat jatkuvasti uusia tapoja soveltaa Lean-ketteriä periaatteita ja käytäntöjä omalla alueellaan.

  • Business Context (Liiketoiminnan konteksti)

    Liiketoiminnan konteksti on PI-suunnittelun aikataulun kohta, jossa liiketoiminnan omistaja kuvaa liiketoiminnan nykytilan, esittelee portfolion vision sekä ajatuksensa siitä, miten nykyiset ratkaisut täyttävät asiakkaiden senhetkiset tarpeet.

  • 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

  • CALMR

    SAFen CALMR lähestymistapa on ajattelumalli, joka ohjaa julkaisujunia saavuttamaan jatkuvan arvon toimittamisen. Se saavutetaan hallitsemalla yhtä aikaa kulttuurin, automaation, lean-virtauksen, mittaamisen ja palvelun toipumisen kehittymistä.

  • Capabilities (Kyvykkyydet)

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

  • Capacity Allocation (Kapasiteetin allokointi)

    Kapasiteetin allokointi on ketterän budjetoinnin liikkumavara, joka auttaa tasapainottamaan kehitysjonon uusia toiminnallisuuksia, mahdollistajia sekä teknistä velkaa suunniteltaessa seuraavaa junan inkrementtiä (Program Increment, PI).

  • Committed PI Objectives (Sitovat PI:n tavoitteet)

    Sitovat PI:n tavoitteet ovat kokoelma SMART-mallin mukaisia tavoitteita, jotka jokainen tiimi tuottaa ja jolle liiketoiminnan edustajat määrittelevät bisnesarvon.

  • 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.

  • Confidence Vote (Luottamusäänestys)

    Luottamusäänestys pidetään PI-suunnittelun lopussa. Luottamusäänestyksessä tiimit äänestävät siitä, kuinka varmoja ovat PI:n tavoitteiden saavuttamisesta.

  • 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.

  • Cost of Delay (Viiveen kustannus)

    Viiveen kustannus (Cost of Delay, CoD) edustaa sitä rahallista arvoa, joka menetetään siksi, että työ viivästyy tai sitä ei tehdä. Viiveen kustannusta käytetään WSJF-priorisoinnissa.

  • 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.

  • Customer Journey Map (Asiakaspolku)

    Asiakaspolku kuvaa käyttäjä kokemusta hänen käyttäessään yrityksen operatiivista arvovirtaa eli tuotetta tai palvelua.

D

  • Daily Stand-Up (Päivittäispalaveri)

    Päivittäispalaveri (Daily Stand Up, DSU) on tiimin jokapäiväinen tapahtuma, jossa kukin tiimin jäsen kertoo mitä eilen teki edistääkseen iteraation tavoitteita; mitä he aikovat tänään tehdä edistääkseen iteraation tavoitteita sekä mitä esteitä he kohtaavat iteraation tavoitteita toteuttaessaan.

  • Decentralized Decision-Making (Päätöksenteon hajauttaminen)

    Päätöksenteon hajauttaminen antaa vastuun päätöksenteosta sinne, missä lähin tietämys ja informaatio asioista on. Näin vähennetään viiveitä, kasvatetaan tuotteen kehittämisen virtausta sekä parannetaan päätösten laatua.

  • Definition of Done (Valmiin määritelmä)

    Valmiin määritelmä kuvaa sitä, kuinka täydellinen kokonaisuus inkrementissä tuotettu arvo on ja on yhdessä sovittu määritelmä siitä, mitkä työt tulee suorittaa inkrementin aikana.

  • Design Thinking (Suunnitteluajattelu)

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

  • Develop on Cadence (Rytmin mukainen kehittäminen)

    Rytmin mukainen kehittäminen ketteriä tiimejä tukeva yhteensovitettu joukko käytäntöjä, jotka muodostavat luotettavan joukon säännöllisellä ja ennustettavalla aikataululla ilmeneviä tapahtumia ja toimenpiteitä.

  • Development Value Streams (Kehittämisen arvovirrat)

    Kehittämisen arvovirrat (Development Value Stream, DVS) sisältävät tarvittavat työvaiheet liiketoimintahypoteesin toteuttamiseksi digitaalisina ratkaisuina.

  • 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

  • Empathy Map (Empatiakartta)

    Empatiakartta on palvelumuotoilun työväline, joka auttaa tiimejä kehittämään asiakkaistaan syvän ja jaetun ymmärryksen.

  • 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 Hypothesis Statement (Aihion hyötyhypoteesi)

    Aihion työhypoteesi sisältää, jäsentää ja kommunikoi aihiota koskevan kriittisen tiedon.

  • 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ä.

  • Estimating Poker (Suunnittelupokeri)

    Suunnittelupokeri on SAFe:ssa käytetty yhteistyömenetelmä, jolla voi luotettavasti arvioida tarinoiden, ominaisuuksien ja WSJF:n koon.

  • Extreme Programming

    Extreme Programming on kokoelma pääosin Kent Beckin kehittämiä ketterän ohjelmistokehityksen käytäntöjä, jotka parantavat ohjelmiston laatua ja kykyä vastata muuttuviin asiakasvaatimuksiin.

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.

  • Final Plan Review (Valmiin suunnitelman katselmointi)

    PI-suunnittelussa valmiin suunnitelman katselmoinnissa tiimit esittävät junalle (ART) ja liiketoiminnan edustajille hyväksyttäväksi lopulliset suunnitelmansa (PI:n tavoitteet, suunnitellut työkuorman ja riskit).

  • 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.

G

  • Gemba

    Gemba on paikka, jossa työ tehdään ja missä osana jatkuvaa parantamista tiimit voivat tarkkailla, miten sidosryhmät suorittavat operatiivisen arvovirran vaiheet ja siinä määrätyt tehtävät.

H

  • Hackathon

    Hackaton on innovaatiotapahtuma, jossa tiimin jäsenet voivat työstää mitä haluavat, kenen kanssa haluavat sillä edellytyksellä, että työ edistää yrityksen missiota ja he näyttävät työnsä tulokset toisille Hackatonin pääteeksi.

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.

  • Integration Point (Integrointipiste)

    Integraatiopiste on sovittu ajankohta, jossa ratkaisun eri osat ‘vedetään yhteen’ integroiduksi kokonaisuudeksi tarkastelua varten. Tämä auttaa sidosryhmiä varmistamaan, että kehittyvä ratkaisu vastaa liiketoiminnan tarpeisiin nyt ja tulevaisuudessa.

  • Investment Horizons (Investointihorisontti)

    Investointihorisontit tuovat näkyväksi kullekin arvovirroissa toteuttavalle ratkaisulle varatun investoinnin suuruuden suhteessa toisiinsa. Tämä auttaa arvovirran omistajia sekä muita asianomaisia tekemään tietoon perustuvia investointipäätöksiä. Samalla varmistetaan, että päätökset ovat linjassa strategisten teemojen kanssa ja että investoinnit tukevat portfolion yleistä terveyttä ja kasvua.

  • 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.

K

  • Knowledge Worker (Tietotyön tekijä)

    Tietotyöntekijät ovat ihmisiä, joilla on tarvittavat taidot, asiantuntemus ja koulutus oman toimialueensa ongelmien ratkaisemiseen.

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ä.

  • Lead Time (Läpimenoaika)

    Läpimenoaika on aika, joka kuluu työn valmistumisesta edellisessä vaiheessa siihen asti, kun se on suoritettu nykyisessä vaiheessa.

  • Lean

    Lean on joukko tietoa ja käytäntöjä, joilla parannetaan tehokkuutta ja vaikuttavuutta vähentämällä viiveitä sekä poistamalla arvoa tuottamattomia aktiviteetteja.

  • 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 Business Case (Lean liiketoimintasuunnitelma)

    Lean liiketoimintasuunnitelma (LBC) on kevyt lähestymistapa aihion (Epic) kuvaamiseen, mukaan lukien aihion pienin julkaisukelpoinen tuote (MVP) sekä aihion ennustettu liikearvo.

  • Lean Governance (Lean hallintomalli)

    Lean hallintomalli on yksi Lean-portfolion hallinnan ulottuvuuksista, joka tukee kulujen valvontaa ja päätöksentekoa, tarkastusta ja sääntelynmukaisuutta, kulujen ennustamista, ja mittaamista.

  • 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 Quality Management System, QMS (Lean laatujärjestelmä)

    Lean laatujärjestelmä (QMN) sanelee ne käytännöt, menettelytavat ja menetelmät, joita tarvitaan turvallisuuden ja tehokkuuden saavuttamiseksi. Organisaatiot, joissa SAFe on käytössä, siirtyvät perinteisestä Lean laatujärjestelmän (QMS) käyttöön.

  • 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 Center of Excellence (Lean-ketterä osaamiskeskus)

    Lean-ketterä osaamiskeskus on pieni joukko ihmisiä, jotka ovat sitoutuneet toteuttamaan SAFen mukaisen ketterän työskentelytavan.

  • 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.

  • Little's Law (Littlen laki)

    Littlen laki on jonoteoria, jonka mukaan keskimääräinen odotusaika palvelulle systeemissä on yhtä kuin keskimääräinen jonon pituus jaettuna keskimääräisellä prosessiin kuluvalla ajalla.

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.

  • Minimum Marketable Feature (Markkinoitava minimitoiminnallisuus)

    Markkinoitava minimitoiminnallisuus (Minimum Marketable Feature, MMF) on pienin toteutettavissa oleva toiminnallisuus, jonka tiimi voi toteuttaa arvioidakseen, onko ominaisuuden hyötyhypoteesi totta vai ei.

  • Minimum Viable Product (Pienin julkaisukelpoinen tuote, MVP)

    SAFe:ssa pienin julkaisukelpoinen tuote (MVP) on uuden tuotteen tai liiketoimintaratkaisun varhainen ja minimiversio, jota käytetään todentamaan tai hylkäämään aihion hyötyhypoteesi. Päin vastoin kuin kuvakäsikirjoitukset (storyboards), prototyypit, mockupit, rautalankamallit ja muut kokeilevat tekniikat, MVP on oikeiden asiakkaiden käyttämä todellinen tuote joka tuottaa validoitua oppimista.

  • 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.

  • Modified Fibonacci Sequence (Muokattu Fibonaccin sarja)

    Muokattua Fibonaccin sarjaa (1, 2, 3, 5, 8, 13, 20, 40, 100) käytetään suhteelliseen kokoon perustuvassa arvioinnissa, koska se kuvastaa luontaista tarkkuuden menetystä työn koon kasvaessa suuremmaksi.

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

  • Objectives and Key Results (Tavoitteet ja avaintulokset)

    SAFe:ssa tavoitteita ja avaintuloksia (Objectives and Key Results, OKR) voidaan käyttää määrittelemään, jäsentämään ja kommunikoimaan strategisiin teemoihin liittyvää kriittistä informaatiota sekä seurata strategisen teeman toteutumista konkreettisina, määriteltyinä ja mitattavina toimenpiteinä.

  • Operational Value Streams (Operatiiviset arvovirat)

    Operatiiviset arvovirrat (Operative Value Streams, OVS) ovat sarja toimenpiteitä, jotka tarvitaan tuotteen tai palvelun toimittamiseen asiakkaalle. Esimerkkejä operatiivisista arvovirroista: tuotteen valmistaminen tehtaalla, tilauksen toimittaminen, potilaan potilaaksi kirjaaminen ja hoitaminen, lainan myöntäminen tai ammatillisen palvelun tuottaminen.

  • 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.

  • Organizational Change Management (Organisaation muutosjohtaminen)

    Organisaation muutosjohtaminen on kollektiivinen termi kaikille niille lähestymistavoille, joilla organisaation muutosta voidaan valmistella ja tukea sekä auttaa yksilöitä, tiimejä ja koko organisaatiota muuttumaan.

P

  • Pareto Analysis (Pareto-analyysi)

    Pareto-analyysi on tutki ja sopeuta - tapahtumassa käytetty tekniikka, jolla voidaan rajata toimenpiteiden määrää niihin, joista saadaan mahdollisimman merkittävä kokkonaisvaikutus.

  • Participatory Budgeting (Osallistava budjetointi)

    Osallistava budjetointi (Partipatory Budgeting, PB) on Lean-portfolionhallinnan (LPM) käyttämä prosessi, jossa portfolion budjetti jaetaan arvovirroille.

  • Personas (Persoonat)

    Persoonat ovat kuvitteellisia kuluttajia ja/tai käyttäjiä, jotka saadaan asiakastutkimuksen tuloksena ja jotka ohjaavat tuotekehitystä asiakaslähtöiseen kehittämiseen.

  • Phase Gate (Vaihe)

    Vaiheet (Phase Gates) ovat perinteiseen tapaan kuuluvia tarkistuspisteitä (milestones), jotka SAFe:ssa korvataan puolueettomilla toimivien järjestelmien arviointiin perustuvilla tarkistuspisteillä.

  • 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).

  • Plan-Do-Check-Adjust (Suunnittele-toteuta-tarkista-sopeuta)

    Suunnittele-toteuta-tarkista-sopeuta (PDCA-sykli) on iteratiivinen neliportainen menetelmä, jota käytetään kontrolloimaan vaihtelevuutta ja hienosäätämään tuotekehitystä palautteen mukaan.

  • Portfolio

    SAFe portfolio yhdistää strategian toteutukseen kehittämisen arvovirroissa. Yhteisen hallintomallin puitteissa toimivat arvovirrat toteuttavat yhden tai useamman ratkaisun, joita yritys tarvitsee toteuttaakseen liiketoiminnan tavoitteet.

  • 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 Canvas (Portfoliokanvas)

    Portfoliokanvas määrittelee SAFe-portfolioon kuuluvat arvovirrat, arvolupaukset ja niiden sisältämät ratkaisut, palveltavat asiakkaat, kullekin arvovirralle annetun budjetin sekä muut avainaktiviteetit portfolion vision saavuttamiseksi.

  • 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.

  • Problem-Solving Workshop (Ongelmanratkaisutyöpaja)

    Ongelmanratkaisutyöpaja on osa Tutki ja Sopeuta (Inspect and Adapt, I&A) tapahtumaa. Se on järjestelmällinen lähestymistapa systeemisten ongelmien juurisyiden löytämiseen.

  • 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ä.

  • Product Owner (PO) Sync (Tuoteomistajien (PO) synkka)

    Tuoteomistajien (PO) synkka on junan (ART) tapahtuma, jolla saadaan näkyvyys siihen, miten juna etenee kohti PI:n tavoitteita. Synkassa voidaan keskustella ominaisuuksia kehitettäessä havaituista ongelmista ja mahdollisuuksista sekä arvioidaan sisällön muutostarvetta.

  • 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 Board (Riippuvuustaulu)

    Riippuvuustaulu näyttää PI:n ominaisuuksien (Features) toimituspäivämäärät, tiimien väliset riippuvuudet ominaisuuksia kehitettäessä sekä asiaankuuluvat tarkistuspisteet (milestones).

  • 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.

  • Program Predictability Measure (Hankkeen ennustettavuusmittari)

    Hankkeen ennustettavuusmittarissa lasketaan yhteen kaikkien junan (ART) tiimien suunniteltu ja toteutunut liiketoiminta-arvo. Se on pääindikaattori junan suoritustehosta ja luotettavuudesta.

  • Program Risks (Hankkeen riskit)

    Tiimit tunnistavat sellaiset hankkeen riskit ja etenemisen esteet osana PI-suunnittelua, jotka voivat vaikuttaa tiimien kykyyn saavuttaa tavoitteensa.

R

  • Refactoring (Refaktorointi)

    Refaktorointi on työtä, jossa koodin tai komponentin sisäistä rakennetta parannetaan muuttamatta sen ulkoista toimintaa.

  • Relative Estimation (Suhteellinen estimointi)

    Suhteellinen estimointi vertaa tehtävää työtä toiseen, jotta sen koko ja arvo voidaan arvioida nopeasti.

  • 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.

  • Relentless Improvement (Jatkuva parantaminen)

    Jatkuva parantaminen on neljäs pylväs SAFe:n Lean-huoneessa, ja rohkaisee jatkuvaan reflektioon ja prosessinparannuksiin perustuvaa oppimista ja kasvua.

  • Roadmap (tiekartta)

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

  • ROAMing Risks (Riskien hallinta, ROAM)

    Riskien hallinta (ROAM) on PI-suunnitteluun sisältyvä toiminta, jossa tiimien esiin nostamat junatason riskit käsitellään yleisemällä johtamisen tasolla.

  • Root Cause Analysis (Juurisyyanalyysi)

    Juurisyyanalyysi käyttää joukkoa ongelmanratkaisumenetelmiä tunnistaakseen ongelman todelliset syyt. Se on osa tutki ja sopeuta (I&A) tapahtumaa.

S

  • SAFe Big Picture, BP (SAFe:n iso kuva)

    SAFe:n iso kuva (SAFe Big Picture, BP) on kuva SAFe-raamin tärkeimmistä rooleista, toiminnoista ja tuotoksista. Se löytyy verkko-osoitteesta scaledagileframework.com, ja kuvan elementit toimivat porttina SAFe:n artikkeleihin.

  • 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 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 leania, 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 Lean Startup Cycle (SAFe Lean start-up -sykli)

    SAFe Lean start-up -sykli on iteratiivinen rakenna-mittaa-opi -sykli tuoteinnovaatioille sekä strategisille investoinneille. Lean start-up tuo strategisia ja taloudellisia etuja aihioiden toteutukseen. Se tarjoaa asteittaisen tavan hallita investointeja ja riskejä käyttäen apuna SAFen tarjoamaa näkyvyyttä sekä virtausta.

  • 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.

  • Scrum of Scrums (Scrummien scrummi)

    Scrummien scrummi (Scrum of scrums, SoS) on junan (ART) tapahtuma, joka autaa koordinoimaan junan sisäisiä riippuvuuksia, sekä tarjoaa näkyvyyden niin etenemiseen kuin etenemisen esteisiinkin.

  • 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.

  • Silos (Siilo)

    Siilot ovat toiminnon mukaan muodostettuja organisaatiorakenteita, joiden sisällä tapahtuu optimointia niin asiantuntijoiden menettelytapojen kuin käytänteiden osalta. Niiden avulla varmistetaan toistettava ja tehokas toiminta toiminnallisen yksikön sisällä, mutta isompi arvovirta yksiköiden välillä jää ymmärtämättä.

  • 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.

  • Spike (Kokeilu)

    Kokeilu on eräänlainen tutkimuksen mahdollistava tarina, jolla saadaan lisää tietoa, jotta voidaan vähentää teknisen lähestymistavan riskiä, ymmärtää vaatimukset sekä arvioida tarinan luottavuutta paremmin.

  • Sprint (Sprintti)

    Sprintti on termi, joka tulee Scrum-viitekehyksestä ja on synonyymi SAFen iteraatiolle.

  • 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.

  • Story Map (Tarinakartta)

    Tarinankartta on suunnitteluajattelun tekniikka, joka järjestää tarinat jonoon niiden tehtävien mukaan, joita käyttäjä tarvitsee tavoitteensa saavuttamiseksi.

  • Story Point (Tarinapiste)

    Tarinapiste on kokonaisluku, jota käytetään suhteellisessa arvioinnissa ja joka edustaa omaisuuksien yhdistelmää: määrä, monimutkaisuus, tietämys ja epävarmuus.

  • 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.

  • Sunk Costs (Menetetyt kustannukset )

    Menetetyt kustannukset tarkoittavat rahaa, joka on jo käytetty. Sitä ei pitäisi huomioida, jotta voidaan tehdä tehokkaita suunnanmuutoksia tulevaisuuden sijoituspäätöksissä.

  • 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.

  • SWOT Analysis (SWOT-analyysi)

    SWOT-analyysi on strateginen suunnittelutekniikka, jota käytetään tunnistamaan nykyiseen liiketoimintatilanteeseen liittyvät vahvuudet, heikkoudet, mahdollisuudet ja uhat osana SAFe portfolion visiota.

  • 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).

  • Systems Thinking (Systeemiajattelu)

    Systeemiajattelu ottaa kokonaisvaltaisen lähestymistavan ratkaisujen kehittämiseen sisällyttämällä kaikki järjestelmän ja sen ympäristön näkökohdat itse järjestelmän suunnitteluun, kehittämiseen, käyttöönottoon ja ylläpitoon.

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.

  • Team Topologies (Tiimitopologiat)

    Tiimitopologiat määrittelevät neljä organisaatiotyyppiä, jotka tarjoavat selkeän mallin ketterien tiimien ja julkaisujunien organisointiin.

  • Technical Debt (Tekninen velka)

    Tekninen velka heijastaa tulevan työn oletettuja kustannuksia ja kasvavaa kiinnostusta, joka johtuu yleensä siitä, että on valittu epäoptimaalinen tai epätäydellinen ratkaisu tietoisesti tai epätietoisesti.

  • Test-Driven Development (Testiohjattu kehitys)

    Testiohjattu kehitys on ajatustapa ja käytäntö, johon kuuluu testitapausten tekeminen ja läpivienti ennen koodin tai komponenttien toteutusta.

  • TOWs Analysis (TOWS-analyysi)

    TOWS-analyysiä käytetään SWOT-analyysin rinnalla tunnistamaan strategisia vaihtoehtoja luomaan parempaa tulevaisuutta osana SAFe portfoliovisiota.

U

  • U-curve Optimization (U-käyrän optimointi)

    U-käyrän optimointi eräkoolle määrittää optimaalisen eräkoon tasapainottamalla vaihtuvia ja kiinteitä kuluja.

  • Uncommitted Objectives (Joustavat tavoitteet)

    Joustavat tavoitteet auttavat parantamaan liiketoiminta-arvon ennustettavuutta, koska niitä ei sisällytetä tiimin sitoumukseen eikä niitä lasketa mukaan tiimin hankkeen ennustettavuusmittariin. Tiimit voivat ehdottaa joustavia tavoitteita, kun heillä epävarmuutta niiden saavuttamiseen.

V

  • Value (Arvo)

    Arvo kuvaa niitä hyötyjä, joita yritys toimittaa asiakkailleen ja osakkeenomistajilleen. Arvo näkyy SAFe-viitekehyksessä eri asiayhteyksissä.

  • 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 Identification (Arvovirran tunnistaminen)

    Arvovirran tunnistaminen on toiminto, jota portfoliot käyttävät tunnistamaan tukemiaan kehitysarvovirtoja ja operatiivisia arvovirtoja.

  • 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 Stream Mapping (Arvovirtakuvaus)

    Arvovirtakuvaus on keskeinen työkalu parantaa arvon virtausta läpi jatkuvan kehittämisen putken. Se tuo näkyvyyttä tunnistaa pullonkauloja ja ongelmallisia alueita virrassa, mitkä aiheuttavat viiveitä.

  • Value Streams (Arvovirrat)

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

  • Velocity (Toteutusnopeus)

    Toteutusnopeus on kaikkien niiden käyttäjätarinoiden pisteiden summa, jotka täyttävät valmiin määritelmän.

  • 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.

  • Work in Process (Keskeneräinen työ)

    Keskeneräinen työ kuvastaa osittain tehtyä työtä. Liian suuri keskeneräisen työn määrä hämärtää prioriteetteja, aiheuttaa jatkuvaa ajatuksen keskeytymistä ja näin kasvattaa yleiskustannuksia.

© 2024 Scaled Agile, Inc. All rights reserved.