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