Agile Architecture Ketterä arkkitehtuuri. Agile Release Train Toimitusjuna. Agile Team Ketterä tiimi. Architectural Runway Arkkitehtuurin kiitorata

Transkriptio

1 SAFE 4.5 SANASTO

2 A Agile Architecture Ketterä arkkitehtuuri 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. Agile Release Train Toimitusjuna Toimitusjuna on pysyväisluontoinen ketterien tiimien muodostama tiimien tiimi, jossa työskentelee tyypillisesti 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 iteraatioissa. Agile Team Ketterä tiimi Ketterä tiimi on eri osa-alueet kattava viidestä yhdeksään henkilön ryhmä, jolla on kyvykkyys ja vastuu määritellä, rakentaa ja testata ratkaisun arvoa lyhyissä, kahden viikon jaksoissa. Tiimiin kuuluvat kyseisen arvon toimittamisen onnistumisen kannalta tarvittavat henkilöt, erityisesti kehitystiimi, scrum master ja tuoteomistaja, joita spesialistit tukevat tarvittaessa. Architectural Runway Arkkitehtuurin kiitorata 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 toiminnallisuuksien (Feature) toteuttamiselle. Arkkitehtuurin kiitorata toteutuu, kun rakennetaan riittävästi olemassa olevaa infrastruktuuria, joka ilman hidastavaa uudelleensuunnittelua tukee korkeimman prioriteetin lyhyen aikavälin toiminnallisuuksia. B Built-in Quality Sisäänrakennettu laatu 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. Business Epic Liiketoiminnan kehitysaihio Ks. Epic (Kehitysaihio) Business Owners Liiketoiminta, Liiketoiminnan omistajat 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. He ovat avainasemassa arvon määrittämisessä, ja heidän tulee aktiivisesti osallistua toimitusjunan tapahtumiin. 2

3 C Capability Kyvykkyys Kyvykkyydet muistuttavat toiminnallisuuksia (Features), mutta ne kuvaavat korkeammalla tasolla ratkaisun (Solution) kyvykkyyksiä, jotka toteutetaan useammassa toimitusjunassa (ART). Kyvykkyyksiä ylläpidetään ratkaisun kehitysjonossa, ja ne pilkotaan toiminnallisuuksiksi mahtumaan hankkeen inkrementteihin (PI), joista jokainen lisää ratkaisun arvoa. CapEx and OpEx CapEx ja 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. Communities of Practice Osaamisyhteisö 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ä. Compliance Vaatimustenmukaisuus Vaatimustenmukaisuus tarkoittaa strategiaa, toimenpiteitä ja dokumentaatiota, jotka ketterien tiimien tulee huomioida täyttääkseen korkeimmat laatuvaatimukset, regulaatiot ja standardit. Continuous Delivery Pipeline Jatkuva toimitusputki Jatkuva toimitusputki (tai toimitusputki) sisältää kaikki tarvittavat työnkulut, aktiviteetit ja automaation jatkuvan arvon toimittamiseksi loppukäyttäjälle. Continuous Deployment, CD Jatkuva toimittaminen Jatkuva toimittaminen on prosessi, jolla jatkuvan integraation tuloksena syntyvät testatut toiminnallisuudet toimitetaan tuotantoympäristöön julkaisua varten. Jatkuva toimittaminen on neliosaisen jatkuvan toimitusputken kolmas elementti (jatkuva tutkinta jatkuva integrointi jatkuva toimittaminen tarpeenmukainen julkaisu). Continuous Exploration, CE Jatkuva tutkinta Jatkuva tutkinta on prosessi, jossa jatkuvasti tutkitaan markkinoita ja käyttäjätarpeita. Siihen kuuluu vision, tiekartan ja toiminnallisuuksien määrittely käyttäjätarpeiden tyydyttämiseksi. Jatkuva tutkinta on neliosaisen jatkuvan toimitusputken ensimmäinen elementti (jatkuva tutkinta jatkuva integrointi jatkuva toimittaminen tarpeenmukainen julkaisu). Continuous Integration, CI Jatkuva integrointi Jatkuva integrointi on käytäntö, jossa tiimin jäsenet toteuttavat, integroivat ja validoivat toiminnallisuuksia säännöllisesti. Integrointi verifioidaan automaattisilla rakennus- ja testausympäristöillä, jotka nopeasti paljastavat integroinnin. Jatkuvan integroinnin tuloksena toteutetut toiminnallisuudet ovat testattuna tuotannonkaltaisessa ympäristössä ja valmiina tuotantoympäristöön toimittamista ja julkaisua varten. Ohjelmiston tapauksessa tämä saattaa tapahtua ainakin päivittäin, tai jopa useita kertoja päivässä. Coordination Koordinointi Ks. Value Stream Coordination (Arvovirtojen koordinointi). 3

4 Core Values Ydinarvot SAFe kunnioittaa neljää ydinarvoa: yhtenäistä suuntaa, sisäänrakennettua laatua, läpinäkyvyyttä ja hanketason toteutusta. Nämä arvot kuvastavat jaettuja uskomuksia, joihin kaikki SAFen toiminta ja tehokkuus perustuvat, ja siten ohjaavat kaikkien osapuolien käyttäytymistä ja toimintaa. Customer Asiakas Asiakas hyödyntää ja ostaa arvovirran lopputulosta. Asiakkaat korjaavat lopullisen hyödyn toimitetuista ratkaisuista. Niin sisäiset kuin ulkoiset asiakkaat kuuluvat oleellisena osana kehittämisen arvovirtaan. D Dev Team Kehitystiimi Kehitystiimi on osa ketterää tiimiä. Kehitystiimi yhdessä kykenee kehittämään ja testaamaan tarinan tai toiminnallisuuden vaatiman toteutuksen. Kehitystiimi koostuu tyypillisesti kehittäjistä, testaajista ja muista tarvittavista ammattilaisista, joita tarvitaan vertikaalisen toiminnallisuuden toteuttamiseen kokonaisuudessaan. Develop on Cadence Syklinen kehittäminen Syklinen kehittäminen tarkoittaa säännöllistä ja ennustettavaa tärkeiden tapahtumien aikataulutusta. SAFen keskeiset tapahtumat noudattavat tiimitasolla iteraatiosykliä ja hanketasolla inkrementtisykliä. Syklinen kehittäminen auttaa hallitsemaan järjestelmien kehittämiselle luontaista vaihtelevuutta ja varmistamaan arvon virtauksen. DevOps DevOps-malli DevOps-malli on ohjelmistokehityksen lähestymistapa, kulttuuri ja kokoelma teknisiä käytäntöjä jotka painottavat kommunikaatiota, integrointia, automaatiota 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. E Economic Framework Taloudellisen päätöksenteon kehys Taloudellisen päätöksenteon kehys tarkoittaa kokoelmaa sääntöjä, joka ohjaa taloudellista päätöksentekoprosessia ja jolla pyritään yhdenmukaisiin ratkaisun taloudellisiin tavoitteisiin. Se koostuu neljästä osa-alueesta: Ketterä budjetointi, kehitysaihioiden rahoitus ja hallinta, hajautettu päätöksenteko ja työjonojen priorisointi perustuen viiveen kustannukseen. Enablers Mahdollistajat Mahdollistajat kuvaavat kehitystyötä, jota tarvitaan arkkitehtuurin kiitoradan kehittämiseen, joka mahdollistaa tulevien liiketoiminnan toiminnallisuuksien kehittämisen. Mahdollistajat kiteyttävät tutkinnan (exploration) sekä tulevien toiminnallisuuksien tukemiseen ja vaatimustenmukaisuuteen tarvittavat selvitykset sekä arkkitehtuurin ja infrastruktuurin kehitystoimet. Mahdollistajia esiintyy kaikilla SAFen tasoilla ja niitä hallitaan kunkin tason valmisteluseinällä ja kehitysjonoissa. Tasosta riippuen niitä kutsutaan mahdollistaviksi kehitysaihioiksi, kyvykkyyksiksi, toiminnallisuuksiksi tai tarinoiksi. Enabler Capability Mahdollistava kyvykkyys Mahdollistavat kyvykkyydet esiintyvät laajojen ratkaisujen tasolla, jossa ne sisältävät ratkaisun 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ä. Ks. Enablers (Mahdollistajat) 4

5 Enabler Epic Mahdollistava kehitysaihio Mahdollistavat kehitysaihiot ovat tietyn tyyppisiä Kehitysiaihioita (Epic), jotka määritellään samalla tavalla kuin Kehitysaihiot, eli arvohypoteesin (Value Hypothesis) mukaisesti, ja toteutetaan useammassa inkrementissä, tyypillisesti usean ratkaisu ja/ tai toimitusjunan toimesta. Ks. Enablers (Mahdollistajat) Enabler Feature Mahdollistava toiminnallisuus Mahdollistavat toiminnallisuudet ovat 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ä. Ks. Enablers (Mahdollistajat) Enabler Story Mahdollistava tarina Mahdollistavat tarinat ovat tietyn tyyppisiä tarinoita, eli niiden täytyy mahtua iteraatioon. Vaikka ne eivät vaadi saman muotoista määrittelyä kuin käyttäjätarinat, niillä täytyy olla hyväksymiskriteerit jotka selventävät vaatimusta ja tukevat sekä demoa että testaamista. Ks. Enablers (Mahdollistajat) Enterprise Yritys Yritys on liiketoimintataho, joka omistaa SAFen portfoliot ja arvovirrat, ja jolla on lopullinen määräysvalta niiden strategiasta, ja johtamisesta. Enterprise Architect Yritysarkkitehti Yritysarkkitehti työskentelee liiketoiminnan sidosryhmien sekä ratkaisu- ja järjestelmäarkkitehtien kanssa ohjatakseen kokonaisvaltaista teknologian toteutusta eri ratkaisujen 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. Yritysarkkitehti myös edistää ideoiden, komponenttien ja toimivien mallien uudelleenkäyttöä ratkaisujen välillä. Epic Kehitysaihio Kehitysaihiot ovat merkittäviä aloitteita, jotka ohjaavat ratkaisujen kehittämistä 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 (Lean Business Case). Lisäksi tarvitaan taloudellinen hyväksyntä ennen kehitysaihioiden toteuttamista. Kehitysaihiot toteutetaan usean inkrementin aikana noudattaen Lean startup tyylistä kehitä-mittaa-opi sykliä. Kehitysaihioita on kahdenlaisia: liiketoiminta-aihioita sekä näiden mahdollistajia, ja ne voivat esiintyä portfolio-, ratkaisu- tai hanketasolla. Epic Owners Kehitysaihioiden omistajat Kehitysaihioiden omistajat ovat vastuussa kehitysaihioiden koordinoinnista niiden elinkaaren ajan, eli vastaavat kehitysaihiosta, kun se liikkuu salkun valmisteluseinän (Portfolio Kanban) läpi. Kehitysaihion omistaja määrittelee kehitysaihion liiketoimintakuvauksen ja MVP:n Hyväksynnän saatuaan kehitysaihion omistaja työskentelee suoraan tarvittavien toteutusjunien keskeisten sidosryhmien kanssa ja fasilitoi kehitysaihion toteutusta. Essential SAFe Configuration SAFe peruskonfiguraatio SAFen peruskonfiguraatio sisältää viitekehyksen ydinkäytännöt ja on yksinkertaisin aloituspiste SAFen käyttöönotossa. SAFen peruskonfiguraatiossa on viitekehyksen kriittisimmät elementit, joilla SAFen hyötyjä toteutetaan. Se toimii myös pohjana kaikille muille SAFen konfiguraatioille. 5

6 F Feature Toiminnallisuus Toiminnallisuus on järjestelmän tarjoama palvelu jota täyttää sidosryhmien tarpeen. Toiminnallisuudet määritellään kuvaamalla hypoteesi hyödyistä ja hyväksymiskriteerit. Jokainen toiminnallisuus kehitetään yhdessä ketterässä toimitusjunassa (ART) yhden hankkeen inkrementin (PI) aikana ja niitä ylläpidetään hankkeen kehitysjonossa. Foundation Perusta Perusta sisältää SAFen arvot, periaatteet, ajattelutavan, käyttöönoton suuntaviivat ja ketterän johtajuuden roolit, joita tarvitaan menestyksekkääseen arvontuottoon skaalatussa ketterässä kehittämisessä. Full SAFe configuration SAFe täyskonfiguraatio SAFen täyskonfiguraatio on täydellinen versio skaalatun ketteryyden kehyksestä, jossa on kaikki neljä tasoa käytössä: tiimitaso, hanketaso, laajojen ratkaisujen taso sekä portfoliotaso. Se tukee yrityksiä jotka rakentavat ja ylläpitävät laajoja integroituja ratkaisuja satojen kehittäjien voimin. Kaikkein suurimmissa yrityksissä saatetaan tarvita useampia rinnakkaisia SAFen konfiguraatioita. G H I Innovation and Planning Iteration Innovaatio- ja suunnitteluiteraatio SAFe sisältää jokaisessa hankkeen inkrementissä säännöllisesti toistuvan innovaatio- ja suunnitteluiteraation, joka palvelee monia tarpeita. Tämä inkrementin viimeinen iteraatio tarjoaa puskuria inkrementin tavoitteiden saavuttamiseksi, erikseen varattua aikaa innovaatiotoiminnalle ja koulutukselle. Se sisältää myös Tutki & Sopeuta -tilaisuuden junan toiminnan jatkuvan parantamisen tukemiseen, seuraavan inkrementin suunnittelun (PI-suunittelu) sekä mahdollisuuden teknisen ympäristön parantamiseen tai muiden etenemisen esteiden poistamiseen sekä aikaa kehitysjonon työstöön. Inspect and Adapt, I&A Tutki ja sopeuta Tutki ja Sopeuta on säännöllisesti toistuva keskeinen tilaisuus junan toiminnan parantamiseksi, 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 ongelmanratkaisutyöpajassa. Parannustoimet voidaan tämän jälkeen välittömästi sisällyttää seuraavan inkrementin (PI) suunnitteluun. Iteration Iteraatio Iteraatio asettaa ketterän kehityksen perusrytmin. Jokainen iteraatio on vakiomittainen, tarkasti rajattu jakso, jonka aikana ketterä tiimi toimittaa asiakasarvoa inkrementaalisesti (joka iteraatiossa lisäten) toimivan, testatun ja toimitetun ohjelmiston ja järjestelmien muodossa. Suositeltu iteraation pituus on kaksi viikkoa, ja se voi liiketoimintaympäristöstä riippuen vaihdella kahdesta neljään viikkoon. Iteration Execution Iteraation toteutus Iteraation toteutus tarkoittaa sitä, miten ketterät tiimit hallitsevat työtään iteraation aikana, eli ottavat tiimin kehitysjonosta tehtäviä ja määrittelevät, toteuttavat ja testaavat nämä järjestelmän versionhallinnan päähaarassa. Iteraation toteutuksen tuloksena syntyy laadukas, toimiva, testattu ja toimitettu kokonaisuus tämän kahden viikon ajanjakson aikana. Jokainen iteraatio noudattaa samoja aktiviteetteja: iteraation suunnittelu; tavoitteisiin sitoutuminen; toteutus; työn demoaminen sidosryhmille; ja lopulta retrospektiivi tiimin toimintatapojen parantamiseksi. 6

7 Iteration Goals Iteraation tavoitteet Iteraation tavoitteet ovat korkean tason yhteenveto tuoteomistajan (product owner) ja tiimin yhdessä sopimista yhden iteraation liiketoiminnallisista ja teknisistä tavoitteista. Iteraation tavoitteet ovat oleellinen osa tehokkaan, itseorganisoituvista ja ohjautuvista tiimeistä koostuvan toimitusjunan koordinoimisessa. Iteration Planning Iteraation suunnittelu Iteraation suunnittelun aikana koko tiimi hahmottelee tulevan iteraation. Tapaamisen tuloksena syntyy iteraation kehitysjono, joka sisältää toteutettavat tarinat ja niiden hyväksyntäkriteerit sekä iteraation tavoitteet jotka tiimi sitoutuu iteraatiossa toteuttamaan. Iteration Retrospective Iteraation retrospektiivi Iteraation retrospektiivi on jokaisen iteraation lopussa järjestettävä lyhyt palaveri, jossa tiimin jäsenet kokoontuvat yksityiseen ja turvalliseen ympäristöön keskustelemaan käytänteidensä toimivuudesta ja tunnistaa sekä sopii parannustoimenpiteet tulevalle jaksolle. Iteration Review Iteraation katselmus Iteraation katselmus on jokaisen iteraation lopussa pidettävä tapahtuma, jossa ketterä tiimi katselmoi iteraation tulokset ja tavoitteiden saavuttamisen. Tämän katselmoinnin perusteella tuloksia tiimi käyttää palautteena tulevan iteraation kehitysjonon ja tavoitteiden suunniteluun. J K Kanban 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. Kanbanin keskeinen työkalu on visuaalinen valmisteluseinä, jonka avulla työ ja sen virtaus tehdään näkyväksi. L Large Solution Level Laajojen ratkaisujen taso Laajojen ratkaisujen taso 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 kyberneettisiä järjestelmiä (cyber-physical systems). Laajojen ratkaisujen taso tuo vahvemman otteen ratkaisun vaatimusten dokumentointiin (ratkaisun tarkoitus), sekä useiden toimitusjunien ja toimittajien koordinointiin. Large Solution SAFe configuration SAFe laaja konfiguraatio SAFen laajojen ratkaisujen konfiguraatio sopii kaikkein laajimpien ja monimutkaisimpien ratkaisujen kehittämiseen useiden toimitusjunien avulla, mutta jotka eivät kuitenkaan vaadi portfoliopäätöksentekoa. Tällaiset järjestelmät ovat tyypillisiä lentokone- ja avaruus-, puolustus- ja autoteollisuudessa sekä suurissa julkisissa järjestelmähankkeissa. Näissä yhden suuren integroidun ratkaisun hallinta on keskeinen haaste portfolionhallinan sijaan. Lean Budgets Ketterä budjetointi Ketterä budjetointi sisältää joukon Lean-ajattelun mukaisia, ketteriä käytäntöjä joilla minimoidaan taloushallintoon liittyvää hukkaa rahoittamalla ja vastuuttamalla arvovirtoja projektibudjetoinnin ja seurannan sijasta. Tämä lähestymistapa mahdol- 7

8 listaa nopean päätöksenteon sekä joustavan arvon toimittamisen arvovirralle osoitetun budjetin sisällä, mutta säilyttää Lean salkunhallinnan (LPM) kontrollin kokonaiskuluista, joita säädetään ajan myötä. Tämä saavutetaan objektiivisen toimitusten seurannan, kehitysaihiotason investointien hallinnan ja dynaamisen budjettien säätämisen avulla. Lean Portfolio Management Lean salkunhallinta Lean salkunhallinta (LPM) edustaa tahoa, joka omistaa yrityksen (tuote- tai palvelu) salkun korkeimman tason strategisen ja taloudellisen päätäntävallan. LPM:llä toimintona on vastuu strategiasta ja investointien rahoittamisesta, hankkeiden hallinnasta sekä johtamisesta. Lean User Experience, Lean UX Lean käyttökokemus Lean käyttäjäkokemus on ketterien periaatteiden mukainen suunnittelun ajattelutapa, kulttuuri ja prosessi. Siinä toiminnallisuuksia toteutetaan pieninä inkrementaalisina toimintoina, joiden toimivuutta arvioidaan mittaamalla hyödystä asetettuja hypoteeseja vasten. Lean and Agile Principles Lean- ja ketterät periaatteet SAFe perustuu yhdeksään vakaaseen Lean- ja ketterään periaatteeseen. Nämä periaatteet ovat perustavanlaatuisia uskomuksia, yleisiä totuuksia, sääntöjä sekä taloudellisia tukipilareita, jotka antavat pohjan kaikille SAFen rooleille ja käytännöille sekä perustelevat niiden tehokkuuden. Lean-Agile Leaders Ketterät johtajat Ketterät johtajat ovat joukko elinikäisiä oppijoita johtajia, opettajia ja valmentajia. He auttavat tiimejä luomaan parempia ohjelmistoja ja järjestelmiä tuntemalla ja noudattamalla Lean-ajattelun ja ketterän kehittämisen sekä systeemiajattelun mukaisia arvoja, periaatteita ja käytänteitä. Ketterä johtaminen tarkoittaa sitoutumista Leanin ja ketterän kehittämisen periaatteisiin. Lean-Agile Mindset Lean ja ketterä ajattelutapa Lean- ja ketterä ajattelutapa kuvaa ketterien johtajien ja tekijöiden yhteisiä uskomuksia, oletuksia sekä toimintaa ketterässä organisaatiossa. Se lähtee ketterän ohjelmistonkehityksen ja Leanin periaatteiden ymmärtämisestä ja soveltamisesta kokonaisvaltaisesti siten, että luodaan jatkuvan arvonkehityksen virta konseptista toteutukseen. M Metrics Metriikka Metriikka tarkoittaa sovittuja mittareita, joiden avulla seurataan, miten organisaatio etenee kohti asetettuja liiketoimintasekä teknisiä tavoitteitaan. SAFen ensisijainen mittari on objektiivinen ratkaisujen toimivuuden arvioiminen, mikä tapahtuu 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, ratkaisut ja salkut voivat mitata edistymistään. Milestones Tarkistuspisteet Tarkistuspisteitä käytetään osoittamaan edistysaskeleita kehitysaikajanalla ja edistymisen seurantaan erityisten tavoitteiden tai tapahtumien suhteen. SAFessa tarkistuspisteet perustuvat hanketason inkrementteihin (PI), suunniteltuihin oppimispisteisiin tai kiinteisiin päivämääriin. Model-Based Systems Engineering Mallipohjainen systeemisuunnittelu 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 8

9 järjestelmän toiminnallisuuksista etukäteen sekä rakentamisen aikana, mikä auttaa hallitsemaan laaja-alaisen järjestelmän dokumentaation monimutkaisuutta ja kustannuksia. N Nonfunctional Requirements Ei-toiminnalliset vaatimukset Ei-toiminnalliset vaatimukset kuvaavat järjestelmän laadullisia ominaisuuksia kuten turvallisuutta, luotettavuutta, suorituskykyä, huollettavuutta, skaalattavuutta ja käytettävyyttä. Nämä voivat olla järjestelmän suunnittelua tai rakennetta rajoittavia tekijöitä ja esiintyvät kaikkien kehitysjonojen yhteydessä. O P PI Objectives Inkrementin tavoitteet Jokaisen tiimin inkrementin suunnittelun tuloksena on tiimin inkrementin tavoitteet, jotka liiketoiminnan omistajat hyväksyvät ja joille he määritelevät bisnesarvon. Toimitusjunan tiimien tavoitteiden kokoelma muodostaa hankkeen inkrementin tavoitteet. Ks. myös Team PI Objectives (Tiimin inkrementin tavoitteet) Portfolio Backlog Salkun kehitysjono Salkun kehitysjono on SAFen korkeimman tason kehitysjono. Kehitysjonossa talletetaan ja priorisoidaan toteutusta odottavat liiketoiminnan kehitysaihiot (Epics) sekä mahdollistavat kehitysaihiot, joita tarvitaan salkun sisältämien ratkaisujen toimittamiseen, ja jotka mahdollistavat erottautumisen kilpailijoista, tarvittavan operatiivisen tehokkuuden strategisten teemojen toteuttamiseksi ja bisnesmenestyksen saavuttamiseksi. Portfolio Epic Salkun kehitysaihio Ks. Epic (Kehitysaihio) Portfolio Kanban Salkun valmisteluseinä Salkun valmisteluseinää (Kanban) käytetään visualisoimaan, hallitsemaan ja priorisoimaan kehitysaihioiden virtaa sekä rajoittamaan keskeneräisen työn määrää (WIP). Kehitysaihioiden avulla määritellään arvovirtojen sisältö ja valmisteluseinän avulla hallitaan niiden virtaa ideoinnista toimitukseen asti. Portfolio Level Portfoliotaso SAFen portfoliotaso on tasoista ylin. Se tarjoaa keskeiset rakenteet, joilla voidaan organisoida Lean-ajattelun mukainen ja ketterä yritys arvon virtauksen ympärille yhden tai useamman arvovirran avulla, joista jokainen kehittää järjestelmiä ja ratkaisuja yrityksen strategisten aikeiden saavuttamiseksi. Portfoliotaso määrittelee tarvittavat roolit, periaatteet ja käytännöt arvovirtojen ja portfoliotason kehitysaihioiden määrittelyyn, budjetointiin ja hallintaan. Portfolio SAFe configuration SAFe portfoliokonfiguraatio Portfoliokonfiguraatio auttaa kehitystyön linjausta organisaation strategisten tavoitteiden mukaiseksi organisoimalla ketterän kehityksen arvovirtojen mukaan. Portfoliotaso mahdollistaa liiketoiminnan ketteryyden portfoliotason strategian ja budjetointiperiaatteiden ja käytäntöjen kautta. Pre- and Post-PI Planning Inkrementin esi- ja jälkisuunnittelu Ennen inkrementin suunnittelua ja sen jälkeen pidettävät suunnittelutapaamiset antavat suurten arvovirtojen toimitusjunille ja toimittajille mahdollisuuden linjata suunnitelmansa seuraavaa inkrementtiä varten. 9

10 Product Management Tuotehallinta Tuotehallinta on vastuussa asiakkaan tarpeiden tunnistamisesta. He omistavat toimitusjunan vision, tiekartan, hinnoittelun, lisensoinnin, investoinnin tuoton (ROI) sekä hankkeen kehitysjonon. He huolehtivat inkrementtien tavoitteista sekä priorisoivat sisältöä toiminnallisuuksien ja hyväksymiskriteerien muodossa. He myös edistävät toiminnallisuuksien toteutusta hankeen valmisteluseinän avulla sekä hyväksyvät toimitetut toiminnallisuudet. Product Owner Tuoteomistaja Tuoteomistaja on ketterän tiimin jäsenenä vastuussa (käyttäjä) tarinoiden määrittelystä sekä tiimin kehitysjonon priorisoinnista. Tuoteomistaja varmistaa hankkeen prioriteettien sujuvan toimituksen tiimissä huolehtien myös toiminnallisuuksien ja teknisestä eheydestä tiimitasolla. Tuoteomistaja työskentelee myös osana laajempaa tuotehallinta/tuoteomistaja tiimiä, ymmärtäen ja antaen oman panoksensa hanketason kehitysjonoon, visioon ja tiekarttaan. Program Backlog Hankkeen kehitysjono Hankkeen kehitysjono on yksi määrätty priorisoitu tallennuspaikka kaikelle tulevalle työlle, joka on valmisteltu toimitusjunan 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ää arkkitehtuurin kehittämiseen tarvittavat mahdollistavat toiminnallisuudet. Program Epic Hankkeen kehitysaihio Ks. Epic (Kehitysaihio) Program Increment Hankkeen inkrementti Hankkeen inkrementti ajallisesti rajattu kehityksen ajanjakso, jonka aikana toimitusjuna toimittaa asiakasarvoa inkrementaalisesti, testattuina ja toimitettuina ohjelmistona ja järjestelminä. Inkrementti 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. Tyypillinen hankkeen inkrementti kestää viikkoa ja se koostuu useista kehitysiteraatioista sekä innovaatio ja suunnittelu -iteraatiosta. Rajoitetun keston takia inkrementit tarjoavat syklistä palautetta myös portfoliotason etenemissuunnitelmiin ja tiekarttoihin. Program Increment Planning Inkrementin suunnittelu Inkrementin (PI) suunnittelu on perustavanlaatuinen, säännöllisessä rytmissä tapahtuva ja kasvokkain suoritettava tapahtuma, joka antaa ketterälle toimitusjunalle sykkeen. Inkrementin suunnittelu on SAFen keskeinen skaalauskaytäntö, jossa kaikki toimitusjunan tiimit linjaavat yhteisen vision ja inkrementtisuunnielman. Program Kanban Hankkeen valmisteluseinä Hankkeen valmisteluseinää (Kanban) käytetään visualisoimaan, hallitsemaan ja priorisoimaan toiminnallisuuksien virtaa sekä rajoittamaan keskeneräisen työn määrää (WIP). Valmisteluseinän avulla visualisoidaan ja hallitaan määrittelyä, priorisointia ja virtausta ideoinnista analyysin ja toteutuksen kautta toimitukseen ja julkaisuun. Program Level Hanketaso Hanketaso määrittelee roolit ja käytännöt, joita tarvitaan jatkuvaan asiakasarvon ja ratkaisujen toimittamiseen ketterässä toimitusjunassa. Hanketta toteuttaa pitkäikäinen toteutusjuna. 10

11 Q R Refactoring Refaktorointi Refaktoroinnilla tarkoitetaan koodin sisäisen rakenteen tai toiminnan parantamista siten, että sen ulkoinen toiminta ei muutu. Release Management Julkaisujen hallinta 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. Release on Demand Tarpeenmukainen julkaisu Tarpeenmukainen julkaisu on prosessi, jolla toiminnallisuudet siirretään tuotantoon ja julkaistaan asiakkaille inkrementaalisesti tai välittömästi, perustuen markkinoiden ja asiakkaiden tarpeisiin. 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 inkrementissä tai useammin) tai epäsäännöllinen (liiketoimintatarpeen mukaan) tuotantoon vienti. Release Train Engineer, RTE Toimitusjunan päällikkö Toimitusjunan päällikkö (RTE) on toimitusjunan palveleva johtaja, fasilitaattori ja ketterä valmentaja. Hän fasilitoi toimitusjunan prosesseja ja toteutusta ja auttaa tiimejä tuottamaan arvoa tehokkaasti. Hän eskaloi etenemisen esteitä, auttaa riskinhallinnassa sekä ohjaa toiminnan ja junan arvontuoton jatkuvaa kehittämistä. Roadmap Tiekartta Tiekartan avulla kommunikoidaan suunniteltuja toimitusjunien ja arvovirran julkaisuja ja tarkistuspisteitä aikajanalla. Tiekartta sisältää tulevan inkrementin toimitukset, joihin on jo sitouduttu, ja lisää näkyvyyttä vielä ennusteissa olevien toimitusten osalta muutaman seuraavan inkrementin ajalle. Tiekarttaa kehitetään ja päivitetään ratkaisu- ja tuotehallinnan toimesta vision ja toimitusstrategian kehittyessä. S SAFe Impementation Roadmap SAFen käyttöönoton tiekartta SAFen käyttöönoton tiekartta koostuu graafisesta yleiskuvasta ja 12-osaisesta artikkelisarjasta, joka kuvaa strategian ja toimenpiteet, jotka on käytännössä todettu toimivaksi poluksi onnistuneeseen SAFe käyttöönottoon. SAFe Principles SAFen periaatteet Ks. Lean and Agile Principles (Lean- ja ketterät periaatteet) SAFe Program Consultants, SPCs SPC konsultit SPC konsultit ovat muutosagentteja, joilla yhdistyy tekninen SAFe-tietämys ja sisäinen motivaatio yrityksen kehitysprosessien parantamiseen. Heillä on kriittinen rooli onnistuneen SAFen käyttöönoton läpiviennissä. SAFe-konsultit voivat tulla monista yrityksen sisäisistä ja ulkoisista rooleista, kuten liiketoiminta- ja teknologiajohto, salkunhallinta, hanke- ja projektipäälliköt, prosessinomistajat, arkkitehdit, suunnittelijat ja konsultit. 11

12 Scrum Master Scrum master Scrum master on ketterän tiimin palveleva johtaja ja valmentaja. Hän on ensisijaisesti vastuussa siitä, että prosessia noudatetaan ja kehitetään; tiimin ohjaamisesta Scrumin, XP:n, Kanbanin ja SAFen käyttöön, esteiden poistamisesta, huipputiimin dynamiikan suojelemisesta ympäristöä vaalimalla, tekemisen jatkuvasta virrasta sekä periksiantamattomasta ja jatkuvasta toiminnan kehittämisestä. ScrumXP ScrumXP ScrumXP on kevyt, mutta kurinalainen prosessi itseorganisoituville ketterille moniosaajatiimeille. ScrumXP-tiimi koostuu 5-9 henkilöstä, jotka työkentelevät yhdessä samoissa tiloissa, silloin kun se vain on mahdollista. ScrumXP-tiimit seuraavat Scrumin projektinhallintakäytäntöjä ja XP-lähtöisiä teknisiä käytäntöjä sekä visualisoivat ja mittaavat arvon virtaa. Set-Based Design Joukkopohjainen suunnittelu Joukkopohjainen suunnittelu on käytäntö, joka ylläpitää useita vaatimus- ja muotoiluvaihtoehtoja avoinna mahdollisimman pitkään pidemmän kehityssyklin aikana. Yhden valitun suunnitteluratkaisun sijaan identifioidaan ja tutkitaan useita vaihtoehtoja samanaikaisesti ja empiiristä dataa käytetään huonoimpien vaihtoehtojen eliminointiin ajan myötä. Joukkopohjainen suunnittelu tekee suunnitteluprosessista joustavamman, kun lopullinen tekninen ratkaisu valitaan vasta kun olettamukset on kokeilla validoitu. Tämä johtaa parempiin taloudellisiin tuloksiin. Shared Services Jaetut palvelut Jaetut palvelut edustavat erikoisosaamista, joka on oleellista toimitusjunan tai ratkaisujunan menestymisen kannalta, mutta jota ei voida omistaa vain yhden toimitusjunan käyttöön. Solution Ratkaisu Kukin arvovirta toimittaa yhtä tai useampaa Ratkaisua asiakkaalle, joka on joko lopullinen, ostajalle toimitettava tuote tai joukko järjestelmiä, jotka tuottavat asiakkaalle toimitettavan palvelun ja tukevat operationaalista arvovirtaa organisaation sisällä. Solution Architect/Engineer Ratkaisuarkkitehti SAFen ratkaisuarkkitehti edustaa yksilöä ja tiimiä, joka vastaa jaetun kokonaisvaltaisen arkkitehtuurin vision määrittelystä ja toteutuksen suunnittelusta. He auttavat läheisessä yhteistyössä ratkaisu- ja toimitusjunaa määrittelemään järjestelmän ja alijärjestelmien rakenteen, rajapinnat, arvioimaan teknisiä oletuksia ja vaihtoehtoja. Solution Backlog Ratkaisun kehitysjono Ratkaisun kehitysjono on määritelty ja priorisoitu tallennuspaikka kaikelle tulevalle työlle, joka oletetaan tarvittavan ratkaisun kehittämiseksi. Kehitysjono koostuu valmistelluista tulevista kyvykkyyksistä, jotka voivat vaikuttaa useampaan toimitusjunaan (ART), sekä mahdollistajista, jotka edistävät oppimista sekä arkkitehtuurin kiitoradan riittävyyttä. Solution Context Ratkaisun konteksti 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, toiminnallisuuksiin ja ei-toiminnallisiin vaatimuksiin. Ratkaisun konteksti myös määrittää DevOps toimintatapojen ja tarpeenmukaisen julkaisun mahdollisuuksia ja rajoitteita. Solution Demo Ratkaisun demo Ratkaisun demo on ratkaisun inkrementin huipentuma; useiden toimitusjunien (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 arvioinnille sekä palautteen keräämiselle sidosryhmiltä ja asiakkailta. 12

13 Solution Epics Ratkaisun kehitysaihiot Ratkaisun kehitysaihiot ovat aloitteita, jotka ovat laajuudeltaan riittävän suuria analyysin ja kevyen liiketoimintamallin perusteeksi, mutta rajoittuvat kuitenkin yhteen ratkaisuun. Ne voivat ilmetä salkun kehitysaihioiden seurauksena tai paikallisesti, ratkaisun hallinnassa. Ks. Epic (Kehitysaihio) Solution Intent Ratkaisun tarkoitus Ratkaisun tarkoitus merkitsee järjestelmään liittyvän, ylläpidettävä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. Solution Kanban Ratkaisun valmisteluseinä Ratkaisun valmisteluseinää (Kanban) käytetään visualisoimaan, hallitsemaan ja priorisoimaan kyvykkyyksien virtaa sekä rajoittamaan keskeneräisen työn määrää (WIP). Valmisteluseinä visualisoi kyvykkyyksien virtausta ideoinnista analyysin ja toteutuksen kautta toimitukseen ja julkaisuun asiakkaalle. Valmisteluseinä auttaa varmistamaan, että ratkaisun kehitysaihiot ja kyvykkyydet perustellaan ja analysoidaan ennen inkrementin aloittamista, ja varmistaa että nämä on asianmukaisesti priorisoitu. Solution Management Ratkaisun hallinta Ratkaisun hallinta päättää ratkaisun sisällöstä. Heillä on ensisijainen vastuu ratkaisun 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ä ratkaisun valmisteluseinällä. Solution PI Objectives Ratkaisun inkrementin tavoitteet Inkrementin jälkisuunnittelun aikana toimitusjunan tavoitteet vedetään yhteen ratkaisutasolla, jolloin niistä tulee ratkaisun tavoitteita. Nämä ovat SAFen inkrementin korkeimman tasoiset tavoitteet, jotka viestivät sidosryhmille, mitä ratkaisujuna kokonaisuutena tulee julkaisemaan seuraavassa inkrementissä. Solution Train Ratkaisujuna Ratkaisujuna on organisointirakenne, jota tarvitaan koordinoimaan suurien ja monimutkaisten ratkaisujen kehitystä silloin, kun niihin tarvitaan useamman toimitusjunan tai toimittajan panosta. Ratkaisujunan tarkoituksena on linjata toimitusjunien jaettu ratkaisun visio, kehitysjono ja tiekartta. Ratkaisujunassa koordinoidaan erillisten toimitusjunien hankkeen inkrementit muodostamaan yhdenmukainen suunnitelma ratkaisun inkrementille. Solution Train Engineer Ratkaisujunan päällikkö Ratkaisujunan päällikkö on ratkaisujunan palveleva johtaja, fasilitaattori ja valmentaja. Hän fasilitoi sekä parantaa prosesseja ja toteutusta. Hän eskaloi esteitä, hallitsee riskejä sekä osaltaan auttaa arvon toimittamisen ja jatkuvan prosessien parantamisen varmistamisessa. Spanning Palette Räätälöintipaletti Räätälöintipaketti 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. Spikes Spike on yhdentyyppinen mahdollistajatarina SAFe:ssa. Alun perin Extreme Programming menetelmässä määritellyt spiket edustavat aktiviteetteja joissa tutkitaan, selvitetään, suunnitellaan, kokeillaan ja rakennetaan prototyyppejä. Tarkoitus on 13

14 siis luoda parempaa ymmärrystä ja uutta tietoa toteutettavasta teknisestä toteutuksesta riskin pienentämiseksi, vaatimusten paremmin ymmärtämiseksi tai työmääräarvioiden tarkentamiseksi. Stories Tarinat Tarinat ovat ketterän kehityksen kulmakivi, jolla kuvataan järjestelmän toimintaa pieninä toteutettavina paloina. 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äminen, mahdollistaen samalla inkrementaalisen (pala kerrallaan tapahtuvan) toimittamisen. Strategic Themes Strategiset teemat Strategiset teemat ovat erityisiä, yksityiskohtaisia liiketoiminnan tavoitteita, jotka yhdistävät salkun vision yrityksen liiketoimintastrategiaan. Strategiset teemat tarjoavat liiketoiminnallisen kontekstin portfoliotason 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. Supplier Toimittaja Toimittajat ovat ulkoisia tai sisäisiä organisaatioita, jotka kehittävät ja julkaisevat komponentteja ja alijärjestelmiä ja siten auttavat ketterän organisaation ratkaisujunia toimittamaan arvoa asiakkailleen. System Architect/Engineering Järjestelmäarkkitehti Järjestelmäarkkitehti linjaa toimitusjunan yhteiseen teknologiseen ja arkkitehtoniseen visioon kehitteillä olevan ratkaisun suhteen. Hän osallistuu 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öä. System Demo Järjestelmä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 objektiivisen arvion siitä, miten järjestelmän tekeminen on edistynyt viimeisimmässä inkrementissä (PI). System Team Integrointitiimi Integrointitiimi on erityinen, toimitusjunalle tai ratkaisulle (joskus molemmille), tukea tarjoava ketterä tiimi, joka auttaa ketterän kehityksen infrastruktuurin rakentamisessa ja käyttämisessä, sisältäen jatkuvan integroinnin, testauksen automatisoinnin, ketterien tiimien tekemien julkaisujen integroimisen, jatkuvan toimittamisen sekä järjestelmän kokonaisvaltaisen testaamisen. He osallistuvat järjestelmä- ja ratkaisudemojen teknisen ympäristön pystyttämiseen ja demojen valmisteluun. T Team Backlog Tiimin kehitysjono Tiimin kehitysjono pitää sisällään kaiken sen tekemisen, joka tiimin täytyy tehdä saadakseen valmiiksi heidän vastuullaan olevan osan järjestelmästä sekä muut, esim. ylläpitotehtävät, jotka vaativat tiimiltä työtä iteraatioiden aikana. 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. Kehitysjono on aina priorisoitu. 14

15 Team Demo Tiimin demo Tiimin demon tarkoituksena on mitata tiimin edistymistä esittelemällä toteutettuja tarinoita tuoteomistajalle, muille tiimin jäsenille sekä sidosryhmille, ja kerätä siten nopeaa palautetta jokaisen iteraation lopussa. Tiimit esittelevät tässä demossa jokaisen tehdyn tarinan, spiken, refaktoroinnin sekä uudet toteutetut ei-toiminnalliset vaatimukset (NFR). Team Kanban Tiimin valmisteluseinä Tiimin valmisteluseinän avulla visualisoidaan ja hallitaan tiimin tarinoiden määrittelyä, priorisointia ja virtausta määrittelyn, toteutuksen ja testauksen kautta toimitukseen. Kanbanin tomii myös työkaluna meneillään olevan työn määrän (WIP) rajoittamiseen, läpivirtauksen mittaamiseen ja jatkuvaan parantamiseen. Tiimitasolla 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. Team Level Tiimitaso Tiimitaso kuvaa ketterien tiimien organisaation, työt, roolit, aktiviteetit sekä prosessimallin, joilla tiimit toimittava arvoa ketterän toimitusjunan (ART) keskeisenä voimana. Team PI Objectives Tiimin inkrementin tavoitteet 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. Ks. myös PI Objectives (Inkrementin tavoitteet) Test-First Testaus edellä käytäntö Testaus edellä käytäntö tarkoittaa järjestelmän kehittämistä ja testaamista pienissä inkrementeissä siten, että testitapaukset tehdään 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. U User Experience, UX Käyttökokemus Ks. Lean UX V Value Stream Coordination Arvovirran koordinointi Arovirran koordinointi tarjoaa ohjausta salkun sisältämien arvovirtojen välisten riippuvuuksien hallitsemiseksi ja mahdollisuuksien tunnistamiseen. Value Streams Arvovirrat Arvovirrat ovat SAFen ensisijainen rakenne arvon ymmärtämiseen, organisoimiseen ja julkaisemiseen. Arvovirtojen avulla organisoidaan toimitusjunat siten että ne pystyvät toimittamaan portfoliotason tavoitteisiin liiketoiminta-arvoa mahdollisimman lyhyellä läpimenoajalla. Jokainen arvovirta on pysyvähkö kokoelma työvaiheita, joita yritys tekee toteuttaakseen jatkuvan arvon julkaisemisen asiakkaalle. Arvovirta toteutetaan ratakaisu- ja toimitusjunissa. 15

16 Vision Visio 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 räätälöintipalettia, ja sitä voidaan käyttää millä tahansa SAFen tasolla. W Weighted Shortest Job First, WSJF Painotettu nopein arvo Painotettu nopein arvo on menetelmä priorisoida työtä tuotteen kehitysvirtaan taloudellisesta näkökulmasta. Painotettu nopein arvo 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. Kestoa arvioidaan työn koon avulla. 16