seisokit. Vika. Vihaisia käyttäjiä.
Kuulostaako tutulta? Jos näin on, sinun on ehkä tarkasteltava huolellisesti release management-prosessiasi.
alati muuttuvassa it-bisnesmaailmassa ei ole varaa puskea puolivillaisia julkaisuja. Silti ylivoimainen 75 prosenttia asioista johtuu ohjelmiston tai sen ympäristön muutoksista.
välttääksesi kalliit viivästykset ja pitääksesi organisaatiosi toiminnan käynnissä, sinun on investoitava vahvaan julkaisujen hallintaprosessiin.
mitä on release management?
Jos yrityksesi on joskus joutunut tekemään merkittäviä ohjelmistomuutoksia, on todennäköistä, että ymmärrät jo luotettavan julkaisuhallinnan tarpeen.
Release management valvoo kaikkia ohjelmistojulkaisun vaiheita kehityksestä ja testauksesta käyttöönottoon. Release management on tarpeen aina, kun uutta tuotetta tai jopa muutoksia olemassa olevaan tuotteeseen pyydetään.
vaikka julkaisujen hallintaprosessit voivat vaihdella ja ne tulisi räätälöidä kullekin organisaatiolle, julkaisujen hallintaan on viisi ensisijaista vaihetta.
Plan release
suunnitteluvaihe saattaa olla aikapainotteisin, sillä tässä vaiheessa koko julkaisusi jäsentyy alusta loppuun. Vankka julkaisusuunnitelma auttaa tiimiäsi pysymään raiteillaan ja varmistamaan, että standardit ja vaatimukset täyttyvät asianmukaisesti.
on useita tapoja lähestyä julkaisusuunnitelmaa. Yksi suosituimmista julkaisujen hallintamenetelmistä on systems development life cycle (SDLC).
SDLC auttaa ohjelmistokehittäjiä suunnittelemaan, kehittämään, ylläpitämään ja korvaamaan ohjelmistojärjestelmiä, joilla on korkea hyötysuhde ja laatu. SDLC: tä voidaan käyttää muiden projektinhallintaprosessien yhteydessä tai niiden sijasta.
luo tämän vaiheen aikana työnkulku, johon sekä tiimisi että Keskeiset sidosryhmäsi voivat viitata koko Julkaisun ajan.
työnkulun tulisi selittää yhdellä silmäyksellä, miten koko julkaisu on järjestetty ja miten kullakin tiimin jäsenellä on oma osansa. Julkaisusuunnitelmasi tulee sisältää:
- aikajanat
- toimituspäivät
- vaatimukset
- projektin yleinen laajuus
on useita tapoja kartoittaa suunnitelmasi ja selventää prosessia. Yksi vaihtoehto on julkaisuhallinnan tarkistuslista. Tarkistusluettelossa on esitettävä prosessin toiminnot ja vastuut suurin piirtein aikajärjestyksessä.
kun tiimisi katsoo tarkistuslistaa, heidän pitäisi pystyä nopeasti selvittämään, missä vaiheessa he ovat ja mikä heidän roolinsa tai vastuunsa on.
toinen vaihtoehto on luoda julkaisun työnkulku. Lucidchart on visuaalinen tuottavuusalusta, joka auttaa kehittäjiä kartoittamaan prosessinsa selkeästi.
luo julkaisuprosessistasi intuitiivinen vuokaavio käyttäen värikoodausta, muotoja ja swimlaneja aikajanojen, roolien ja tehtävien määrittämiseen. Lucidchart toimii pilvessä, joten sinä ja tiimisi voitte käyttää julkaisusuunnitelmaa tai tarkistuslistaa milloin ja missä tahansa reaaliaikaisten päivitysten avulla.
kun suunnitelmasi on hahmoteltu, esitä se kaikille asiaankuuluville sidosryhmille (tiimisi, tuotepäällikkösi ja korkean tason johtajat) tarkistettavaksi. Saa palautetta mahdollisista puutteista tai ongelmista, joita he näkevät vaatimuksissa tai laajuudessa.
kun suunnitelma on hyväksytty ja viimeistelty, sen voi panna toimeen.
Rakenna julkaisu
kun julkaisusuunnitelma on valmis, voit aloittaa tuotteen suunnittelun ja rakentamisen julkaisua varten. Tämä on tuotteen varsinainen ”kehittäminen”, joka perustuu julkaisusuunnitelmassa esitettyihin vaatimuksiin.
kun kaikki mahdolliset ongelmat on käsitelty, on aika altistaa rakennus reaalimaailman skenaariotestaukseen.
Tämä voi vaatia useita iteraatioita. Kun tiimi rakentaa tuotteen, se lähetetään (yleensä automaattisesti) testausympäristöön käyttäjän hyväksyttäväksi. Näin tiimi voi tunnistaa mahdolliset viat tai ongelmat, joita voi syntyä reaalimaailman ympäristössä.
kun ongelmat on tunnistettu, rakennus lähetetään takaisin kehitettäväksi toisessa vaiheessa. Toisin sanoen iteratiivisessa release management-prosessissa työ voi virrata vaiheesta kaksi vaiheeseen kolme ja takaisin, kunnes julkaisu on hyväksytty.
User acceptance testing
User acceptance testing, tunnetaan myös nimellä UAT, on kun loppukäyttäjät tuote on rakennettu saada todella käyttää sitä ja antaa palautetta. Tämä tehdään usein ilmaisena beta-kokeiluna verkossa tai jaettuna suuremmalle työntekijäryhmälle yrityksen sisällä.
käyttäjän hyväksymistestaus on ratkaisevin vaihe vapauttamisen hallinnoinnissa, koska kerättyjen tietojen ja korjausten määrä on tarpeen, jotta build saadaan sinne, missä sen pitää olla virallista julkaisua varten.
kuten aiemmin todettiin, tämä on osa iteratiivista prosessia. Kun vikoja tunnistetaan, tiimi palaa piirustuspöydälle korjaamaan ongelmat ja suunnittelemaan rakennuksen eheämmäksi. Rakennuksen on läpäistävä UAT-vaihe, jotta se voidaan ottaa lopulliseen käyttöön ja vapauttaa.
Prepare release
Tämä vaihe on viimeistellä tuote ottaen huomioon kaikki mitä UAT: ssa opittiin. Julkaisuvalmistelu sisältää myös LAADUNVARMISTUSTIIMIN lopullisen laadunarvioinnin.
katselmuksen aikana LAADUNVARMISTUSRYHMÄ tekee lopulliset tarkastukset varmistaakseen, että rakennus täyttää julkistamissuunnitelmassa esitetyt hyväksyttävät vähimmäisstandardit ja liiketoimintavaatimukset.
vaikka UAT ja laadunvarmistus eivät aina voi toistaa jokaista skenaariota, joka saattaa tapahtua, kun tuote on käynnistetty, nämä vaiheet toivottavasti täsmentävät yleisimmät virheet, jotta tiimisi voi paremmin ennakoida ja estää ongelmat lanseerauksessa.
kun katselmus on valmis, toiminnallinen tiimi validoi löydökset ja viimeistelee julkaisun käyttöönottoa varten. Ennen kuin rakentaa voi ottaa käyttöön elävään ympäristöön, se on hyväksyttävä tuotteen omistaja.
Deploy release
suuri päivä on vihdoin koittanut ja tässä kohtaa joukkueen kova työ kannattaa. On aika vapauttaa tuotteesi elävän tuotantoympäristön erämaihin.
sen lisäksi, että tuote lähetetään suoraan tuotantoon, käyttöönottovaihe sisältää myös tuotteen viestittelyä ja koulutusta sekä loppukäyttäjälle että yrityksellesi yleensä.
käyttäjille tulee esimerkiksi ilmoittaa julkaisun myötä tapahtuneista muutoksista ja siitä, miten uusien ominaisuuksien sisällä toimitaan. Riippuen siitä, kuinka merkittäviä muutokset olivat, saatat joutua tarjoamaan vankkaa ja jatkuvaa koulutusta saada kaikki vauhtiin.
Tämä on erityisen tärkeää sisäisissä julkaisuissa, joissa ohjelmistoa käyttävien työntekijöiden on ymmärrettävä se tehdäkseen työnsä tehokkaasti ja tuottavasti.
lopuksi käyttöönottovaiheessa kehitystiimin tulisi kokoontua arvioimaan julkaisun toimivuutta ja keskustelemaan siitä, miten käyttöönotto sujui. Jos on olemassa viipyviä kysymyksiä, ne olisi tunnistettava ja dokumentoitava, jotta joukkue voi käsitellä seuraavassa iteraatiossa.
Release management valvoo jatkuvasti muuttuvaa prosessia. Jokainen julkaisu on mahdollisuus hioa kaikkea työnkulusta tarkistuslistaasi, kun tiimisi löytää, mikä roadmap toimii parhaiten millaiseen julkaisuun-ja mihin ei.
ja Lucidchartin avulla jopa kaikkein monimutkaisin julkaisujen hallintaprosessi voidaan suunnitella varmistamaan onnistunut julkaisu, josta tiimisi voi olla ylpeä.
yhteistyöalustan avulla tiimin jäsenten—kehittäjistä ja tuotteiden omistajista johtaviin sidosryhmiin—on helppo nähdä korkean tason suunnitelma ja saada yhdellä silmäyksellä tietoa sen edistymisestä, joten kaikki ovat samalla sivulla.
Plus, Lucidchart integroituu suosittuihin hallintatyökaluihin, kuten Confluence, Gsuite ja Slack, joten voit tuoda tietoja ja säilyttää kaikki projektisi yksityiskohdat ja ääriviivat yhdessä kätevässä paikassa.
Kirjaudu ilmaiselle tilillesi ja aloita jo tänään.