Vaatimusanalyysi: kuinka tätä käynnistysystävällistä lähestymistapaa + tapaustutkimusta käytetään

Edellisissä blogi-viesteissään selitimme miksi päätimme kehittää Badges-sovelluksen ja kuinka arvioimme idean toteutettavuutta OpsGeniellä:

Koska havaitsimme, että ideaamme on kehittämisen arvoinen, seuraava vaihe on vaatimusten analysointi.

Vaatimusanalyysi - erittäin hyvin tutkittu ohjelmistosuunnittelun alue - on prosessi, jolla määritetään käyttäjän odotukset tuotteelle tai määritellään lyhyesti tuotealue. Vaatimusten analysointimenetelmille, hyvien vaatimusten ominaisuuksille ja jäljitysvaatimuksille on saatavana tonnia resursseja. Kirjallisuuden toistamisen sijasta aiomme tehdä kriittiset kohdat tiivistelmän startup-ajattelutavalla.

Tiedämme, että startup-kaverit eivät yleensä pidä termeistä, kuten “prosessi”, “konseptitodistus”, “vaatimukset”, “laajuus”, “aikataulu”, “suunnittelu”, “dokumentointi” tai “ylläpidettävyys”. Yleensä he ovat kärsimättömiä ja haluavat vain koodata ja vapauttaa. Hyväksymme, että ketteryys on elintärkeää maailmassamme, ja meidän on yritettävä, epäonnistua ja palautua nopeasti. Ohjelmistomaailman perinnön hyödyntäminen auttaa meitä kuitenkin kohti menestystä. Tärkeintä on pitää se ketteränä.

Prosessin seuraaminen ei ole tavoite, vaan työkalu, joka auttaa meitä saavuttamaan tavoitteemme. Katsotaan siis, kuinka voimme omaksua klassisen lähestymistavan maailmaan vaatimuksienhallinnan yhteydessä.

Projektinhallinnan kolmio on malli ohjelmistonhallinnan rajoituksista. Huolimatta siitä, että se on vanha 1950-luvun käsite, mielestäni se on edelleen ajankohtainen.

Yhteenvetona voidaan todeta, että projektinhallintakolmion mukaan työn laatua rajoittavat projektin budjetti, määräajat ja ominaisuudet. Näiden kolmen rajoituksen välillä on kompromissi tarvittavan projektin laadun saavuttamiseksi. Joten voimme sanoa, että ohjelmistokehitys on monitavoiteoptimointiongelma.

Projektinhallinnan kolmio (kuva Wikipediasta)

Emme halua rajoittaa itseämme klassisilla lähestymistavoilla, joten mukauttakaamme vanhaa projektinhallintakolmioa uuteen startup-maailmaan. Muista käynnistyksen menestystekijät, jotka mainitsimme toteutettavuusanalyysiviestissä.

Näin yhdistämme nämä menestystekijät klassiseen projektinhallintakolmioon:

Kuten yllä olevasta taulukosta käy ilmi, kaikki käynnistyksen menestystekijät liittyvät erilaisiin projektinhallinnan kolmion rajoituksiin. Koska nämä kolme rajoitusta ovat kompromisseissa, voidaan sanoa, että soveltamisalan pitäminen siistinä on välttämätöntä käynnistyksen onnistumiselle.

Jotta määritellä siisti laajuus, meidän on tehtävä hyvä vaatimusanalyysi ennen kehittämisen aloittamista. Huomaa, että tämä ei tarkoita, että aiomme suorittaa täysin yksityiskohtaisen vaatimusanalyysin, kuten vesiputousprosessissa määriteltiin. Aiomme tehdä sen ketterästi.

Vinkkejä vaatimusten analysointiin

Tässä osassa annamme tärkeitä vinkkejä, jotka sinun tulisi pitää mielessä:

Tarkasta vaihtoehtoiset / vastaavat tuotteet syvyydessä

Kuten aina, älä keksitä pyörää uudelleen. Tarkista, mitä muut tekevät tavoitteesi saavuttamiseksi. Jopa saatat lopultakin ymmärtää, että tuotteellasi ei näytä olevan vaikutuksia liiketoimintaan, jota ajattelit aiemmin.

Tämä on hyvä merkki kääntää ideasi. Se voi tuntua epäonnistumiselta, mutta muista, että meidän on epäonnistuttava niin nopeasti kuin mahdollista.

Dokumentoi vaatimuksesi

Sinun ei tarvitse käyttää vaatimustenhallintatyökalua, kuten IBM Rational DOORS. Lyhyt, luettelomerkillä varustettu asiakirja auttaa neuvottelemaan sidosryhmien kanssa.

Pidä (potentiaaliset) asiakkaasi poissa silmukasta

Mielestäni tämä on yksi tärkeimmistä asioista vaatimusten kehittämisessä. Sillä, että luulet olevan tappaja, ei välttämättä ole merkitystä asiakkaille.

Pitääksesi potentiaaliset asiakkaasi silmukassa, sinun on noudatettava iteratiivista lähestymistapaa. Voit tehdä tämän lähettämällä alkuperäisen version tuotteestasi - Minimum Lifeble Product (MVP) - ja kehittämällä sen asiakaspalautteen perusteella.

Esimerkiksi Amazon Web Services -tiimi käyttää tätä lähestymistapaa usein. He toimittavat palvelun, jolla on vähimmäisominaisuudet ja kehittävät sitä asiakaspalautteen perusteella.

Toinen lähestymistapa on kehittää mallisovelluksia, jotka tarjoavat vain näennäisen käyttöliittymän (UI), jotta potentiaalinen asiakas voi ymmärtää tuotteen ominaisuuksia ja antaa palautetta. Voit käyttää näitä pilkkejä InvisionApp-kaltaisilla tuotteilla.

Vaatimusten hallinta on jatkuva prosessi

Sinun ei tarvitse viettää kuukausia vaatimusten analysointiin projektin alussa, äläkä tee sitä - se ei ole ketterä tapa.

Aluksi tavoitteesi on määritellä järjestelmän rajat, neuvotella ryhmän ja muiden sidosryhmien kanssa ja valmistella vähimmäiskykyisen tuotteen määritelmä. Vaatimusten tulisi olla yksityiskohtaisia ​​tai ne voivat jopa kehittyä kehityskertojen aikana.

Ryhmittele vaatimuksesi

Kun olet luonut luettelon kaikista vaatimuksista, ryhmittele ne (jaa ja valloita) muodostamaan liittyviä ominaisuuksia. Ryhmittelyvaatimukset ominaisuusryhmille helpottavat elämääsi kehitysvaiheessa ja jopa se voi auttaa sinua määrittelemään rajatut tilanteet, mikropalveluarkkitehtuurit ja niin edelleen.

Ajattele UX: ta

Ei tarvitse sanoa, että käyttäjäkokemus (UX) on enää erittäin tärkeä tekijä tuotteen menestyksessä; tänään se on niin ilmeinen. Mutta meidän on silti muistutettava, että käyttäjäkokemus ei koske pelkästään hienoja käyttöliittymiä.

Kuten nimestä voi päätellä, kyse on ”kokemuksesta” ja järjestelmän UX: n parantaminen on vaikeaa sen kehittämisen jälkeen.

Ajattele UX: ää vaatimusanalyysistä lähtien, se voisi olla jopa motivaatiota toteutettavuusanalyysivaiheessa kehittää uutta tuotetta, jos markkinoilla olevista vaihtoehdoista puuttuu hyvä UX.

Käyttäjäkokemus vaikuttaa liiketoiminnan vaatimuksiin. Jos esimerkiksi kehität verkkokauppasovellusta, nopeasti reagoivan asiakastukijärjestelmän suunnittelulla on tarkoitus parantaa käyttökokemusta.

Ole agnostiikka toteutusteknologioille niin paljon kuin mahdollista

Tätä ei tietenkään voida soveltaa, jos kehität infrastruktuuria tai kirjastoa tiettyä tekniikkaa varten :)

Älä kuulu "Jos sinulla on vain vasara, kaikki näyttää kynsiltä" -loukkuun. Löydä uusia työkaluja ja apuohjelmia sen sijaan, että rajoitat tuoteominaisuudet tekniikoihin, jotka tunnet tai joiden kanssa nautit.

Yritysyrityksissä vaatimusten analysoinnin suorittavat yleensä muut kuin ohjelmistosuunnittelijat, joita kutsutaan yleensä liiketoiminta-analyytikoiksi tai järjestelmäinsinööriksi. Tällä erottelulla on joitain haittoja, etenkin kun vaatimuksia siirretään kehitysryhmille, mutta mielestäni sillä on myös joitain etuja.

Mielestäni riippumattomien analyysitiimien suurin etu on, että he ovat agnostisia tekniikoista, joita käytetään kehityksen aikana.

Mutta aloitusmaailmassa, todennäköisesti ryhmän jäsenenä (tai jopa perustajana), sinun on käytettävä useita hattuja: analyytikko, kehittäjä, palkkaava johtaja tai vieläkin mielenkiintoisempia rooleja, joita et kuvitellut päästyäsi tälle polulle. . Joten, jos sinulla on analyytikkohattu tällä hetkellä, yritä olla agnostinen tekniikoista, joita aiot käyttää toteutuksen aikana.

Kuulemme jatkuvasti ilmaisuja kuten "mutta Spring Framework ei tue ..." ja "Tämä aiheuttaa paljon työtä käyttöliittymässä" vaatimusanalyysin aikana.

Tällaisten rajoitusten huomioon ottaminen heikentää lopputuotteen laatua. Määritetään lopullinen kyky ja kehitetään sitä tarvittaessa kehittämisen aikana.

Lopullinen tavoite on lopullinen tavoite, jonka voit toteuttaa yksinkertaisemmassa muodossa, kun aloitat ja kehität sitä tulevissa versioissa. Mutta tietämällä kohta, jonka haluamme saavuttaa, autamme meitä määrittelemään näkemyksemme tuotteen kasvusta.

Ajattele esimerkiksi matkapuhelimien nipistys-zoomaus -ominaisuutta. Se näyttää triviaaliselta kyvyltä, mutta se oli vallankumous, kun Steve Jobs osoitti sen ensimmäisen kerran. Jos iPhonen suunnittelijat eivät ajatteleisi valmista ja tarttuisivat käytettävissä oleviin tekniikoihin ja menetelmiin, meillä ei olisi tätä hienoa toimintoa tänään. Tiedämme, että se on liioiteltu esimerkki, mutta pääasia on, että älä anna haluamasi tekniikan rajoittaa sinua, voit siirtyä muihin tekniikoihin, jos tämä auttaa sinua luomaan niche-tuotteen.

Tunnusmerkkien sovellusvaatimusten analyysi

Suoritimme vaatimusanalyysin edellä tiivistelmän mukaisesti:

  • Määrittelimme ensimmäiset vaatimukset
  • Jaoimme vaatimukset alkuperäisen asiakkaamme - OpsGenie-tiimin - kanssa ja päivitimme vaatimuksia ryhmän kommenttien mukaan.
  • OpsGenie-palvelussa käytämme Atlassianin JIRA: ta seuraamiseen. Vaatimusten seuraamiseksi loimme ongelman ”Uusi ominaisuus” -tyypillä jokaiselle JIRA-vaatimukselle.
  • Ryhmittelimme niihin liittyvät vaatimukset JIRA Epics -sovelluksella. Jotkut eepostamme ovat käyttäjäoperaatiot, ryhmäoperaatiot, merkkitoiminnot, hyväksyntä ja kolmannen osapuolen työkalujen integrointi.
  • Jatkokehitysvaiheissa loimme yksityiskohtaiset asiat päivittäisiin tehtäviin, kuten ketterät käytännöt suosittelevat. Yhdistimme jokaisen tehtävän yhteen tai useampaan vaatimukseen pitääksemme kehitystoimintojen jäljitettävyyden vaatimusten kanssa.
  • Jokainen eepos sisältää joukon vaatimuksia (kuten uuden ominaisuuden), kehittämistehtäviä ja virheitä.
Jäljitysvaatimukset kehitystehtävien kanssa

Haluatko seurata Badges-sovellustamme tai vielä paremmin, suositella uusia ominaisuuksia ja auttaa meitä parantamaan sitä? Liity Badges App -yhteisöön!

Lisätietoja: