Mikä on App MVP Sprint?

Mikä se on?

Toimeksianto alkaa selkeyttämällä, mitä ongelmaa tuotteen on tarkoitus ratkaista, keitä ensisijaiset käyttäjät ovat ja mitä heidän on saatava tehtyä ensin. Siitä eteenpäin työ keskittyy ensisijaisiin käyttäjäpolkuihin: siihen pieneen joukkoon polkuja, jotka tekevät tuotteesta hyödyllisen ensimmäisestä päivästä alkaen. Tyypilliseen laajuuteen voi kuulua tuotemäärittely, keskeiset näkymät, sovittu sovellustoiminnallisuus, data- ja integraatio-oletukset, laadunvarmistus sekä käytännön julkaisuvalmistelu. Tarkka tekninen lähestymistapa riippuu tuotteesta, sen olemassa olevista resursseista ja sovitusta alustasta. Sprintti keskittyy yhtenäiseen ensimmäiseen julkaisuun, joka rakennetaan sovittujen ydinpolkujen ympärille. Se on jäsennelty tapa tehdä varhaiset valinnat näkyviksi, testattaviksi ja toimitettaviksi. Ominaisuudet, jotka eivät tue ensimmäisen julkaisun keskeistä tavoitetta, dokumentoidaan tulevina harkittavina asioina sen sijaan, että ne lisättäisiin hiljaa kiinteään laajuuteen.

Kenelle se on tarkoitettu

App MVP Sprint sopii tiimeille, jotka:

• Omaavat määritellyn tuoteidean tai liiketoimintaongelman mutta tarvitsevat apua sen muuttamiseen realistiseksi ensimmäiseksi julkaisuksi
• Haluavat validoida kohdennetun asiakaspolun ennen kuin investoivat laajempaan tuotetiekarttaan
• Tarvitsevat yhden vastuullisen toimitusprosessin tuotelaajuudelle, käyttöliittymäpäätöksille, kehitykselle ja julkaisun valmistelulle
• Korvaavat epävirallisia prototyyppejä, taulukoita tai manuaalisia vaiheita ensimmäisellä käyttökelpoisella sovelluskokemuksella

Mitä se auttaa selkiyttämään

MVP-sprintti auttaa selvittämään:

• Mihin käyttäjäongelmaan ja ensisijaiseen polkuun ensimmäisen julkaisun tulisi vastata ja minkä ideoiden tulisi odottaa
• Mitkä oletukset, riippuvuudet, sisällöt, integraatiot tai asiakkaan hyväksynnät on ratkaistava ennen kuin rakentaminen voi edetä
• Mitkä ominaisuudet ovat välttämättömiä testattavaa julkaisua varten ja mitkä ovat toivottavia parannuksia myöhempään tiekarttaan
• Mikä testaus, omistajuus ja julkaisuvalmistelu on käytännössä mahdollista sovitussa laajuudessa ja aikataulussa

Mitä sisältyy

• Kirjallinen laajuuden vahvistus, jossa kuvataan ensimmäisen julkaisun tavoite, alusta, sovitut käyttäjäpolut ja toimituksen rajaus
• Kohdennettu tuote- ja käyttöliittymämäärittely laajuuteen kuuluville keskeisille näkymille ja vuorovaikutuksille
• Sovittujen MVP-ominaisuuksien rakennustyö, jossa oletukset ja riippuvuudet dokumentoidaan niiden ilmetessä
• Sovittujen käyttäjäpolkujen käytännön testaus ennen luovutusta tai julkaisun valmistelua
• Julkaisuvalmiuden tuki, joka vastaa sovittua alustaa, tilien käyttöoikeuksia ja julkaisuvastuita
• Lähdekoodi, dokumentaatio ja luovutusyhteenveto, josta käy ilmi, mitä toimitettiin, mikä vaatii omistajan panosta ja mikä kuuluu tulevaan vaiheeseen

Se, mitä ei ole mukana

• Rajaton ominaisuusjono, rajoittamattomat muutoskierrokset tai jokaisen sprintin aikana käsitellyn idean automaattinen sisällyttäminen
• Monimutkaiset taustajärjestelmäalustat, markkinapaikkatoiminnot, reaaliaikainen video, edistyneet dataohjelmat tai laaja vaatimustenmukaisuustyö, ellei niitä ole rajattu erikseen
• Lupaus julkaisuajankohdasta, App Store- tai Google Play -hyväksynnästä, käyttäjien omaksumisesta, kaupallisista tuloksista tai kolmannen osapuolen palvelun keskeytyksettömyydestä
• Jatkuva tuotehallinta, ylläpito tai tulevien ominaisuuksien kehitys toimeksiannon päätyttyä, lukuun ottamatta rajattua julkaisun jälkeistä tukea toimitetuille laajuuteen kuuluville kohdille
• Työ, joka riippuu puuttuvasta sisällöstä, tileistä, oikeudellisista päätöksistä, ulkoisista toimittajista tai integraatioista, joita ei ole vahvistettu laajuuteen

Milloin valita se

Valitkaa App MVP Sprint, kun keskeinen haaste on päättää, mikä ensimmäisen hyödyllisen version tulisi olla, ja sitten toimittaa tämä versio kurinalaisesti. Se voi sopia alkuvaiheen tiimille, vakiintuneelle yritykselle, joka testaa uutta palvelumallia, tai tiimille, jonka on korvattava manuaalinen asiakasprosessi kohdennetulla sovelluspolulla. Se on tehokkain, kun on nimetty päätöksentekijä, pääsy käyttäjäongelman ymmärtäviin ihmisiin ja valmius pitää ensimmäinen versio tietoisesti suppeana. Se sopii huonommin, kun tuotteen suunta on vielä hyvin epävarma, keskeistä käyttäjäpolkua ei vielä voida kuvata tai tarvittavat integraatiot ja toiminnalliset riippuvuudet ovat tuntemattomia. Tällöin discovery- tai tuotesuunnitelmavaihe voi olla hyödyllisempi lähtökohta ennen rakentamiseen sitoutumista.

Lähestymistapamme

Aloitamme vahvistamalla tavoitellun lopputuloksen, ensisijaiset käyttäjät, alustan ja toimituksen rajauksen kirjallisesti. Alkuvaiheen keskustelut keskittyvät keskeiseen polkuun pitkän ominaisuuslistan sijaan: mitä käyttäjän on pystyttävä tekemään, mitä tietoja tarvitaan ja mikä tekisi ensimmäisestä julkaisusta johdonmukaisen. Kirjaamme oletukset sisällöstä, integraatioista, tileistä, hyväksyntävastuista ja ulkoisista riippuvuuksista, jotta niistä ei myöhemmin tule piileviä toimitusriskejä. Rakentamisen aikana pidämme sovitun laajuuden näkyvillä ja selitämme jokaisen uuden pyynnön vaikutuksen ennen kuin sitä käsitellään laajuuteen kuuluvana. Testaus perustuu sovittuihin käyttäjäpolkuihin ja käytännön julkaisuolosuhteisiin. Luovutuksessa tiimi saa selkeän kuvan ensimmäisen julkaisun rajauksesta, tehdystä työstä ja kohdista, jotka tulisi siirtää myöhempään tiekarttaan tai erilliseen laajuuteen.

Usein kysyttyjä kysymyksiä

Aiheeseen liittyvät artikkelit