Nõuete analüüs: kuidas seda käivitamissõbralikku lähenemisviisi + juhtumianalüüsi kasutada

Eelmistes blogipostitustes selgitasime, miks otsustasime välja töötada märkide rakenduse ja kuidas hindasime meie idee teostatavust OpsGenie-s:

Kuna leidsime, et meie idee on väärt arendamist, on järgmine samm nõuete analüüsimine.

Nõuete analüüs - väga hästi uuritud tarkvaratehnika valdkond - on protsess, mille abil määratakse kindlaks toote kasutajate ootused või määratletakse lühidalt toote ulatus. Nõuete analüüsimise metoodika, heade nõuete tunnuste ja jälgimisnõuete kohta on saadaval palju ressursse. Kirjanduse kordamise asemel võtame kriitilised punktid kokku startup-mõtteviisil.

Teame, et alustavatele meestele üldiselt ei meeldi sellised mõisted nagu “protsess”, “kontseptsiooni tõend”, “nõuded”, “ulatus”, “ajakava”, “disain”, “dokumenteerimine” või “hooldatavus”. Üldiselt on nad kannatamatud ja tahavad lihtsalt kodeerida ja vabastada. Oleme nõus, et paindlikkus on meie maailmas ülitähtis ning peame proovima, läbi kukkuma ja kiiresti taastuma. Tarkvaramaailma pärandist kasu saamine aitab meid aga teel eduni. Võtmepunkt on selle paindlikkuse hoidmine.

Protsessi järgimine ei ole eesmärk, see on tööriist, mis aitab meil oma eesmärke saavutada. Vaatame siis, kuidas saaksime oma vajaduste haldamise kontekstis oma maailmas klassikalisi lähenemisviise rakendada.

Projektijuhtimise kolmnurk on tarkvarahalduse piirangute mudel. Hoolimata asjaolust, et see on vana 1950ndatest pärit kontseptsioon, on see minu arvates endiselt asjakohane.

Projektijuhtimise kolmnurk ütleb kokkuvõtvalt, et töö kvaliteeti piiravad projekti eelarve, tähtajad ja funktsioonid. Projekti vajaliku kvaliteedi saavutamiseks on nende kolme piirangu vahel kompromiss. Nii võime öelda, et tarkvara arendamine on mitme eesmärgi saavutamiseks optimeerimise probleem.

Projektijuhtimise kolmnurk (pilt Vikipeediast)

Meile ei meeldi klassikaliste lähenemisviiside piiramine, seetõttu kohandage vana projektijuhtimise kolmnurk uue startupmaailmaga. Tuletage meelde käivitamise edutegureid, mida me mainisime teostatavusanalüüsi postituses.

Kaardistame need edutegurid klassikalise projektijuhtimise kolmnurga külge järgmiselt:

Nagu ülaltoodud tabelist nähtub, on kõik käivitamise edutegurid seotud projektijuhtimise kolmnurga piirangutega. Kuna need kolm piirangut on kompromissis, võime öelda, et ulatuse korrektseks hoidmine on käivitamise õnnestumiseks ülioluline.

Korrektse ulatuse määratlemiseks peame enne arenduse alustamist läbi viima hea nõuete analüüsi. Pange tähele, et see ei tähenda, et hakkame läbi viima täielikult üksikasjaliku nõuete analüüsi, nagu on määratletud jugaprotsessis. Me teeme seda kavalalt.

Nõuandeanalüüsi näpunäited

Selles jaotises pakume olulisi näpunäiteid, mida peaksite meeles pidama:

Vaadake sügavuti alternatiivseid / sarnaseid tooteid

Nagu ikka, ärge leiutage ratast uuesti. Kontrollige, mida teised teie eesmärkide saavutamiseks teevad. Isegi võite lõpuks aru saada, et teie tootel ei näi olevat sellist ärimõju, nagu te varem arvasite.

See on hea märk teie idee pööramiseks. See võib tunduda ebaõnnestumisena, kuid pidage meeles, et peame ebaõnnestuma nii kiiresti kui võimalik.

Dokumenteerige oma nõuded

Te ei pea kasutama nõudehaldusriista, näiteks IBM Rational DOORS. Kuid lühike, täppidega nõuete dokument aitab sidusrühmadega läbi rääkida.

Hoidke oma (potentsiaalseid) kliente silm peal

Ma arvan, et see on üks olulisemaid asju nõuete väljatöötamisel. Võime, mis teie arvates on tapja, ei pruugi klientidele mõtet olla.

Potentsiaalsete klientide hoidmiseks peate järgima korduvat lähenemisviisi. Saate seda teha, tarnides oma toote algse versiooni - Minimaalne elujõuline toode (MVP) - ja arendades seda vastavalt klientide tagasisidele.

Näiteks kasutab Amazon Web Services meeskond seda lähenemist sageli. Nad tarnivad minimaalsete võimalustega teenuse ja arendavad seda välja kliendi tagasiside põhjal.

Teine lähenemisviis on välja töötada mallirakendusi, mis pakuvad lihtsalt näivat kasutajaliidest (UI), mis aitab potentsiaalsel kliendil toote omadustest aru saada ja tagasisidet anda. Nende piltide tootmiseks võite kasutada selliseid tooteid nagu InvisionApp.

Nõuete haldamine on pidev protsess

Te ei pea projekti alguses kulutama kuude kulutamist nõuete analüüsile ja palun ärge seda tehke - see pole eriti tundlik viis.

Alguses on teie eesmärk määratleda süsteemi piirid, pidada meeskonna ja teiste sidusrühmadega läbirääkimisi ning valmistada ette minimaalse elujõulise toote määratlus. Nõuded peaksid olema üksikasjalikud või arendustegevuse kordamise ajal isegi muutuma.

Rühmitage oma nõuded

Kui olete loonud kõigi oma nõuete loendi, rühmitage need (jagage ja valutage), et moodustada seotud funktsioonide komplektid. Nõudmised rühmitamiseks funktsioonigruppidele hõlbustavad teie elu arendusetapis ja isegi see aitab teil määratleda piiritletud kontekste, mikroteenuste arhitektuure jne.

Mõelge UX-ile

Pole vaja öelda, et kasutajakogemus (UX) on toote õnnestumise väga oluline tegur; täna on see nii ilmne. Kuid me peame ikkagi meelde tuletama, et kasutajakogemus ei tähenda ainult väljamõeldud kasutajaliideseid.

Nagu nimest järeldada võib, puudutab see kõike “kogemust” ja süsteemi UX-i on pärast selle väljatöötamist raske parandada.

Mõelge UX-ile alates nõudeanalüüsist, see võib isegi teostatavusanalüüsi etapis olla motivatsioon uue toote väljatöötamiseks, kui turul saadaval olevatel alternatiividel puudub hea UX.

Kasutajakogemus mõjutab ärinõudeid. Näiteks kui arendate e-kaubanduse rakendust, on kiire reageerimisega klienditoesüsteemi kavandamine kasutajakogemuse parandamine.

Olge rakendustehnoloogiate agnostik nii palju kui võimalik

Muidugi ei ole see kohaldatav, kui arendate konkreetse tehnoloogia jaoks taristut või raamatukogu :)

Ärge kuuluge lõksu “Kui teil on ainult haamer, näeb kõik välja nagu nael”. Uute tööriistade ja utiliitide otsimine selle asemel, et piirduda toote võimalustega tehnoloogiatega, millega olete tuttav või millega mängite.

Ettevõtteettevõtetes teostavad nõuete analüüsi üldjuhul tarkvaravälised insenerid, kes on üldiselt tuntud kui ärianalüütikud või süsteemiinsenerid. Sellel eraldamisel on mõned puudused, eriti seoses nõuete edastamisega arendusmeeskondadele, kuid arvan, et sellel on ka teatud eeliseid.

Minu arvates on sõltumatute analüüsimeeskondade suurim eelis see, et nad on arendustes kasutatavate tehnoloogiate agnostikad.

Kuid startup-maailmas peate tõenäoliselt meeskonna liikmena (või isegi asutajana) kandma mitut mütsi: analüütikut, arendajat, palkavat haldurit või veelgi huvitavamaid rolle, mida te sellele teele astudes ei kujutanud ette. . Niisiis, kui teil on praegu analüütikumüts, proovige olla agnostik nende tehnoloogiate suhtes, mida plaanite rakenduse ajal kasutada.

Nõuete analüüsimisel kuuleme pidevalt väljendeid, nagu „aga kevadine raamistik ei toeta…” ja „See põhjustab palju tööd esiotsa”.

Sellise piirangu arvestamine alguses halvendab lõpptoote kvaliteeti. Määratleme lõpliku võime ja arendame seda vajadusel välja arendamise käigus.

Ülim võimekus on lõppeesmärk, milleni jõuate, saate selle tulevastes versioonides käivitamisel ja arendamisel selle lihtsama vormi rakendada. Kuid teadmine punktist, milleni tahame jõuda, aitab meil määratleda oma visiooni toote kasvu kohta.

Mõelge näiteks mobiiltelefonide võimalusele "näppida suumiga". See näib olevat triviaalne võime, kuid see oli revolutsioon, kui Steve Jobs seda esimest korda demonstreeris. Kui iPhone'i disainerid ei mõtleks endast välja ja jääksid olemasolevate tehnoloogiate ja meetodite juurde, siis poleks meil täna seda suurepärast funktsionaalsust. Me teame, et see on liialdatud näide, kuid peamine on see, et ärge laske kasutataval tehnoloogial teid piirata, võite minna teiste tehnoloogiate juurde, kui see aitab teil nišitoodet luua.

Nõuete analüüs märkide rakendusele

Nõuete analüüsi viisime läbi vastavalt ülaltoodud tavadele:

  • Me määratlesime esialgse nõuete komplekti
  • Jagasime nõuded oma algkliendiga - OpsGenie meeskonnaga - ja värskendasime nõudeid vastavalt meeskonna kommentaaridele.
  • OpsGenie-s kasutame numbrite jälgimiseks Atlassiani JIRA-d. Nõuete jälgimiseks lõime JIRA-s iga nõude jaoks välja tüübi “Uus funktsioon”.
  • Me grupeerisime seotud nõuded JIRA Epicsiga. Mõned meie eepostest on kasutajaoperatsioonid, grupioperatsioonid, märkimistegevused, kinnitamine ja kolmanda osapoole tööriistade integreerimine.
  • Edasistes arenguetappides lõime igapäevaste ülesannete jaoks üksikasjalikud küsimused, nagu Agiilsed tavad soovitavad. Sidusime iga ülesande ühe või mitme nõudega, et hoida arendustegevuse jälgitavust nõuetega.
  • Iga eepos sisaldab komplekti nõudeid (näiteks uus funktsioon), arendusülesandeid ja vigu.
Jälgimisnõuded koos arendusülesannetega

Kas soovite jälgida meie märkide rakendust või veelgi parem, soovitada uusi funktsioone ja aidata meil seda täpsustada? Liituge rakenduse Badges App kogukonnaga!

Lisalugemist: