Uusi sovellusprojekti - Näin se toimii

Moi! Minä olen Aija, olen Simplifiedilla päädevaajana. Sain tehtäväksi tehdä sovelluksen, joka toimii lisäpalveluna nykyisille asiakkaillemme. Tämä oli myös loistava tilaisuus kertoa käytännössä, miten me tehdään sovelluksia. Tämä on osa 6, uudet osat julkaistaan täällä blogissa, sekä uutiskirjeessä (johon voit liittyä tekstin lopussa).

Tervetuloa seuraamaan sovellusprojektia!

Kertaus edellisistä osista

Viimeksi käytiin läpi sovelluksen logiikkaa, eli toiminnallisuuksia. Toisin sanottuna, miten staattiset ruudut muuttuvat sovellukseksi toiminnallisuus kerrallaan.

Miten sovelluksen kehittäminen aloitetaan käytännössä

Nyt meillä on sovelluksessa olemassa 1) tietokanta 2) käyttöliittymä, mutta meillä ei vielä ole auki piirrettyjä polkuja siitä, mitä käyttäjän täytyy pystyä tekemään sovelluksessa. Aiemmin olemme keränneet ylös sovelluksen tärkeimpiä tehtäviä, kuten katsoa video ja vastata kyselyyn. Tämä ei kuitenkaan ole ihan vielä riittävän selkeä kuvaus käyttäjän tehtävästä.

Tarkoituksena on, että sovelluskehittäjä pystyy rakentamaan kokonaisen toiminnallisuuden dokumentaatiota seuraamalla. Oli kyseessä sitten käyttäjätilin luominen, salasanan vaihto, sisäänkirjautuminen tai uusien kyselyiden tekeminen.

Miten tälläistä sitten kannattaa rakentaa? Käydään seuraavaksi läpi sovelluskehitystä "työtehtävinä". Suunnitelman ja kehitystyön kuvaamiseen ja visualisointiin on käytössä monia tapoja, samoin kuin mahdollisia työkaluja on paljon. Tässä tekstissä käydään läpi, miten nämä konseptit toimivat - meidän tapaan - yksinkertaistettuna.

1. Eri näkymien tehtävät

Otetaan tähän esimerkki sovelluksen "pääsivusta", eli kyselysivusta. Tämä näkymä on tehty Mirossa, kuvat ovat esimerkkikuvia. Kyselysivulla tapahtuu näitä asioita, aloita vasemmalta yläkulmasta:

2. Tehtävien purkaminen käyttäjätarinoiksi

Käyttäjätarinat (user stories) ovat sovelluskehityksen menetelmä, jossa kuvataan yksittäisen käyttäjän näkökulmasta, mitä toiminnallisuuksia sovelluksen tulisi sisältää. Käyttäjätarinat ovat keskeinen osa ketteriä kehitysmenetelmiä, kuten Scrum ja Kanban. Nämä ovat tapoja tehdä sovelluskehitystä, joista ei tässä tekstissä puhuta enempää.

Tyypillisesti, käyttäjätarinat ovat lyhyitä, yksinkertaisia kuvauksia siitä, mitä käyttäjä haluaa saavuttaa tietyllä sovelluksen ominaisuudella.

Tyypillinen käyttäjätarina koostuu kolmesta osasta:
‍Rooli: Kuka käyttäjä on? (Esim. "Käyttäjänä")
‍Tavoite: Mitä käyttäjä haluaa tehdä? (Esim. "haluan pystyä kirjautumaan sisään tililleni")
‍Hyöty: Miksi käyttäjä haluaa tehdä tämän? (Esim. "jotta voin käyttää tilini tietoja")

Esimerkki käyttäjätarinasta edelliseen näkymään:

Monivaiheiseen kyselyyn vastaaminen

‍Käyttäjänä haluan aloittaa monivaiheisen kyselyn, jotta voin vastata kysymyksiin ja edetä kohti lopullista tulosta. Kun olen aloittanut kyselyn, haluan vastata esitettyyn kysymykseen valitsemalla yhden vastausvaihtoehdon. Sovelluksen tulee tallentaa vastaukseni tietokantaan ja tallentaa myös tieto, oliko vastaus oikein vai väärin. Sitten sovellus siirtää minut seuraavaan kysymykseen. Viimeisen kysymyksen jälkeen haluan nähdä kokonaispisteeni kyselystä, jotta voin arvioida suoritukseni.

Sovelluksen kehitys

Sitten aloitetaan kehittäminen! Low-codessa on aika tyypillistä, että näkymät (tai screenit) tehdään ensin, eli pelkkä staattinen sivu tehdyn designin mukaisesti ja vasta sen jälkeen aloitetaan sovelluksen tietokannan rakentaminen ja toiminnallisuuksien lisääminen.

Low-coden hyvä puoli on se, että asiakas saa jotain konkreettista katsottavaa sovelluksestaan hyvin nopeasti, koska työ aloitetaan näkyvistä osista.

Tässä esimerkki tilinluomisprosessista: Ensin näkymä, sitten tietokanta ja kolmanneksi logiikka.

Miten pysyä kartalla työtehtävistä?

Sovelluskehityksessä on tavallista (ja aika pakollistakin) tehdä erilaisia todo-listoja, kanban-tauluja tai muita projektitiedostoja, joissa on selkeästi listattu kaikki työvaiheet, missä ne ovat menossa ja jos kehittäjiä on enemmän kuin yksi, kuka tekee.

Tämän lisäksi on hyvä olla säännöllisiä välideadlineja eri taskeille ja mikäli kyseessä on asiakasprojekti, tietyt ajankohdat, joissa asiakasta tavataan, esitellään siihen mennessä tehtyä työtä ja kerätään kommentteja, sekä yleisesti ottaen katsotaan, että sovitut asiat ja aikataulut pitävät.

Low-code yksinkertaistaa kehitystä

Low-code eroaa perinteisestä kehityksestä sillä, että kehittäjien määrä on huomattavasti pienempi. Perinteisesti, kehitystiimi koostuu sekä front-end (käyttäjälle näkyvät osiot) sekä back-end (osiot, jotka eivät näy käyttäjälle) kehittäjistä tai kehitystiimeistä, mutta Low-codessa on tyypillistä, että yksi henkilö tekee molemmat puolet.

Onhan perinteisessäkin kehityksessä full-stack-kehittäjiä, jotka hallitsevat sekä "frontin", että "bäkkärin", mutta Low-codessa tämä on enemmän sääntö kuin poikkeus.