5.3 Toimeksianto
Johdanto toimeksiantoon
CodeCerub Oy on saanut asiakkaakseen JAMK IT:n WIMMA Capstone-koulutusympäristön, joka on juuri nyt kehityksen alla. WIMMA Capstonen toimintaa pyritään avaamaan eri sidosryhmille ja siihen tarvitaan erilaisia palveluja. Toimeksianto CodeCerub Oy:lle on kehittää WIMMA Capstonen käyttöön soveltuva Foorumi-palvelu, joka liitetään myöhemmin osaksi kotisivuja. Foorumin toteutuksen pohjana hyödynnetään (Open Source) avoimen lähdekoodin perustuvaa Conduit-ohjelmistoa, joka on asiakkaan esittämä toive. Syynä tähän on tiukka aikataulu. Asiakkaalla on vahva oletus, että tämä säästää aikaa kehitykseltä ja voidaan keskittyä nopeampaan käyttöönottoon.
Demo-palvelin avuksi
CodeCerub Oy:n tiimi on tutustunut ennakolta Conduit -palveluun käyttäen apuna vapaasti tarjolla olevia demo-palveluita. Näitä voi käyttää projektin määrittelyn tukena. Demo-palvelu löytyy syksyllä 2023 oletuksena seuraavalta palvelimelta osoitteesta: https://demo.realworld.io/#/. Samasta Conduit-palvelusta on tarjolla myös erilaisia toteutuksia (eri kielillä ja kehikoilla) ja näihin voi myös tutustua https://codebase.show/projects/realworld
Muista, että Demo-palvelin saattaa yllättäen kaatua ja tiedot katoavat aina tässä yhteydessä!
Tärkeät henkilöt ja tarpeet
Asiakkaan edustajana toimii aiemmin WIMMA Capstonen kehityksessä työskennellyt arkkitehti Maarit Pitkäniemi, joka toivoo Forum-palvelun käyttöön saamista ~4 kk jälkeen projektin alkamisesta. Tämä tarkoittaa sitä, että ohjelmistopalvelu tarvittavine muutoksineen on asiakkaan täysimääräisessä käytössä projektin loppuessa. CodeCerub Oy vastaa tämän jälkeen palvelun tukemisesta ja siihen liittyvästä ylläpidosta. Ylläpito ja tukipalvelu ei kuulu alkuperäisen projektin tavoitteisiin.
Projektin tavoite on muokata ja kehittää nykyisestä Conduit-ohjelmistosta paremmin asiakkaan tarpeeseen sopiva versio. Tärkeimpinä toimintoina asiakas edellyttää käyttöliittymän sulavaa integrointia WIMMA Lab-kotisivun kanssa ja saumatonta liittämistä osaksi kotisivuja. Lisäksi tietosuojan vaikutukset on otettava huomioon palvelun tuotannossa.
Projektin kesto ja kokonaisuus
- Projektin kesto on max 3.5 kk
- Projektissa käytetään yhden viikon mittaisia sprinttejä (1 sprint = 1 viikko)
- Projektin aloituspäivä on Keskiviikko 28.8.2024
- Projektin alkuvaiheen suunnittelu voidaan laskuttaa taannehtivasti, eli projektin valmistelu voidaan aloitaa heti
- Tarkka aloitus päivä projektille määrittyy opintojakson suoritushetken perusteella (Tarkasta mikä on aloitusluennon/infon päivämäärä = projektin aloituspäivä)
- Projektin työaika maanantaista-perjantaihin 8:00-16:00
Toimeksiantoon liittyvät henkilöt
- Asiakkaan edustajana toimii WIMMA Capstonen tiimistä Maarit Pitkäniemi
- Johtoryhmään oletetusti kuuluvat seuraavat henkilöt:
- Sinä (tunnuksesi gitlabissa)
- WIMMA Capstonen Senior Coach Mauri Karvalahti
- Tuoteomistajana toimii Marko "Narsuman" Rintamäki, jolle ei ole erillistä tunnusta gitlabissa (Älä liitä assign)
Projektin jakaminen vaiheisiin:
CodeCerubilla työskentelevä vanhempi projektipäällikkö Arnold Suksi on antanut sinulle listan tärkeimmistä etapeista, joita hän on käyttänyt aiemmissa projekteissa. Arnold kehotti käyttämään näitä, koska ne ovat toimineet aika hyvin, mutta voit soveltaa niitä tarpeen mukaan
Muista, että etappi tarkoittaa joitan valittua päivämäärää, jolloin ennalta sovitut tavoitteet on tarkoitus saavuttaa. Älä sekoita etappia käynnissä olevaan sprinttin.
Projektin etapit ja arvioidut kestot
- E0 - Esivalmistelut ~1 vk
- E1 - Tarkempi suunnittelu ~2 vk
- E2 - Toteutus (implementointi) käynnissä (???)
- E3 - Tarkistukset ja korjaukset ~2 vk
- E4 - Luovutus ja projektin lopetus 1 vk
- E5 - Palvelutuotannossa ~2 pv
Asiakkaan antamaa taustatietoa (vaatimuksia palvelulle)
Asiakkaan kanssa on käytä alustavasti keskustelua palvelun toteuttamisesta ja samalla on tullut ilmi muutamia tärkeitä kohtia:
- Palvelun kannalta saavutettavuus on tärkeässä osassa ja pyritään noudattamaan EU:n asettamia saavutettavuuden vaatimuksia.
- Kannattaa tutustua saavutettavuudelle asetettuihin yleisiin vaatimuksiin 5-10 kpl. Nämä kirjataan vaatimusmäärittelyyn
- Palvelun suorituskyvylle (performance) on asetettu tavoitteeksi palvella alkuvaiheessa suomen tasolla muutamia satoja käyttäjiä. Tulevaisuudessa on varauduttava kansainvälisen kanssakäynnin aktivoitumiseen ja oletetaan, että käyttäjä kunta on 5 vuoden aikajänteellä noin 10000 henkilöä.
- Yhtäaikaisisia käyttäjiä oletetaan olevan ~10 normaalitilanteessa, mutta aktiivisemmassa tilanteessa ~100 henkilöä.
- Palvelun on oltava saatavilla 24/7 ja SLA:ssa vaatimuksena 99% käyttöaste, eli 1 % on varttu huoltokatkoihin.
- Tietoturvan osalta edellytetään Kyberturvallisuus keskuksen jakamia tunnettuja hyviä käytänteitä. Nämä lähteet toimivat myös lähteinä vaatimusmäärittelylle.
- Kannattaa tutustua esitettyihin tietoturvavaatimuksiin ja kirjata niistä mielestäsi tärkeät (5-10kpl) mukaan omaan vaatimusmäärittelyyn
Asiakkaan antamaa lisätietoa
Asiakkaalta tuli materiaalia, josta selviää millaisia sidosryhmiä (stakeholders) liittyy tulevaisuudessa käynnistyvään WIMMA Capstonen toimintaan. Niitä voi käyttää määrittelytyön tukena. JAMK IT:llä aiemmin toimineen WIMMA Labin sidosryhmät ovat yhä voimassa, joten niitä voidaan käyttää samassa yhteydessä.
Kannattaa ehdottomasti tutustua WIMMA Lab Black Book
Työtehtävien tuntihinnoittelu asiakkaalle toimeksiannossa
Arnolod kaivoi kainalokotelostaan esille myös listan työtehtävien hinnoittelusta. Nämä ovat siis tuntihintoja jotka laskutetaan suoraan asiakkaalta. Älä hämmästy hintoja! (Kannattaa miettiä miten työtehtävän tuntihinta rakentuu: henkilön palkka ja sosiaalikulut, KATE (Kiinteät kulut) Tilat, laitteet, vuokrat etc.)
Hinnat eivät sisällä ALV 25,5 %
Kilpailu on koventunut, ja viimeisimmät tarkistetu hinnat eri tehtäville ovat seuraavat:.
- Arkkitehti/johtava ohjelmoija 85 €/h
- Ohjelmoija 80 €/h
- Testaaja 75 €/h
- Palvelumuotoilu 85 €/h
- Projektihallinta 90 €/h
- Graafinen suunnittelu 70 €/h
- Palvelin ja tuotanto (DevOps) 90 €/h
- Muut tehtävät 65 €/h
Miten paljon meillä on käytössä työaikaa?
Arnold selvitti ystävällisesti ennakkoon, miten paljon on käytettävissä eri henkilöill aikaa mahdolliseen projektiin. Tulokset perustuvat siihen miten paljon eri henkilöillä on kuormitusta. On normaalia, että eri henkilöt työskentelevät eri projekteille samaan aikaan ja on tärkeää selvitää miten paljon heillä on aikaa käytettävissä. Löydät jokaisen käytettävissä olevat tunnit tiimin kuvauksesta:
Projektin eteneminen vaiheittain
Milloin eri osaajia tarvitaan projektissa? Alla hieman hahmottelua, eli karkea resurssien käyttö projektin aikana etapeittain. (Perustuu aiempien projektien oppeihin). Tätä voi soveltaa kustannuslaskennan apuna.
- (E0) Käynnistysvaihe: Projektipäällikkö (on käytännössä mukana kaikissa vaiheissa)
- (E1) Määrittelyvaihe: CodeCerub-asiakaspalvelun edustaja, arkkitehti/pääohjelmoija, palvelumuotoilija, ja projektipäällikkö
- (E2) Suunnittelu + Toteutus: mukaan liittyy tulevat graafinen suunnittelija ja yksi testaaja
- (E3) Toteutus+korjaus: ohelmoijat + testaajat + tarvittaessa muita henkilöitä
- (E4) Toteutus/hyväksyntätestaus Mukana ovat testaajat ja ohjelmoijat ja asiakaspalvelu ja projektinhallinta
- (E5) Palvelun käynnistys vaiheessa Projektipäälliikö + tuotantotiimi
Alustava Työlista/Backlog
Arnold ehti palaveerata asiakkaan kanssa pari viikko sitten ja kartoitti ennakkoon tärkeitä tehtäviä, joita projektissa on saatava aikaiseksi tulevien kuukausien aikana. Tutustu alla olevaan listaan tehtävistä ja siirrä ne oletuksena Gitlab-projektiisi (issueiksi) työlistan eli (Backlog) muotoon.
Huomaa useat tehtävät on kirjauttu suoraan User Story muotoon! Listaan voi vielä tulla täydennystä, jos jotain ilmenee! Huomio, että eri tyyppiset tehtävät kirjataan Issue-tyyppien mukaan!
Arnoldin keräämä lista:
HUOMIO Ennalta on sovittu seuraavat tapahtumat ja ne kirjataan projektin työlistaan (Backlog) käyttäen "Yleinen" -Issue Templatea. Sijoita issuet aikataulun mukaan!
Tehtävä | Ajankohta | Vastuu | Muuta |
---|---|---|---|
Organisoi johtoryhmän kokoukset | E4 | Johtoryhmä | Tutustu materiaaliin 2.7 Johtoryhmä ja palverikäytännöt |
Projektisuunnittelun työkokous | E2 | Johtoryhmä | Tutustu materiaaliin 2.7 Johtoryhmä ja palverikäytännöt |
Järjestä saunailta | E5 | Johtoryhmä + koko tiimi | |
Pidä tilannekatsaus | Joka toinen viikko | koko tiimi | |
Järjestä esittelytilaisuus sidosryhmille | E3 | Johtoryhmä + sidosryhmät | |
Seuraava lista sisältää itse tuotteeseen käyttötarinoita (User Story), vikaraportteja (Bug report) ja parannusehdotuksia (Enhancement), jotka tulivat esiin asiakkaan keskusteluissa. Nämä pitää ehdottomasti kirjata projektin Backlogiin! Ne syötetään käyttäen apuna sopivaa Issue Templatea, koska samalla ne saavat oikean Label-merkinnän.
ID | Kuvaus | Tyyppi |
---|---|---|
US39 | Palvelutuottajana haluan ajaa palvelua Amazon AWS:n varassa, koska se selkeyttää tuotantoa | User Story |
US30 | Kehittäjänä haluan, että voin käynnistää testiympäristön docker-compose up komennolla | User Story |
US31 | Palvelutuottajana haluan saada palautetta loppukäyttäjilä, jonka perusteella palvelua voidaan parantaa asiakaslähtöisesti | User Story |
US32 | Palvelutuottajana haluan tukea loppukäyttäjää käyttäen siihen DOORBELL.io palvelua, koska en halua kuormittaa kehitystiimiä ylimääräisillä kysmyksillä | User Story |
US33 | Palvelutuottajan on palvelustamme löydyttävä GDPR kuvaukset, koska tietosuojalaki edellyttää sitä | User Story |
US34 | Palvelutuottajan haluan vaihtaa palvelun värit WIMMA Capstonen-sivuston mukaisiksi | User Story |
US35 | Testaajana haluan pystyttää testiympäristön kontti (docker) tekniikalla, koska se on tehokkaampaa | User Story |
US36 | Kehittäjänä haluan päivittää kehitysympäristön tietokannan nopeasti käyttäen kontteja | User Story |
US37 | Toimeksiantajana toivon, että sivusto näyttää visuaalisesti yhtenäiseltä sopien WIMMA Capstonen brandiin | User Story |
US38 | Palvelun käyttäjän toivon, että tunnukseni ovat turvassa ja voin käyttää HTTPS-yhteyttä, koska en uskalla käyttää HTTP-palveluja nykyaikana | User Story |
US49 | Palvelun kehittäjänä toivon, että kaikki käyttäjäpalaut tulee Gitlab Issue-muodossa eteeni, koska se on selkeämpää jatkokäsitellä | User Story |
US40 | Järjestelmän ylläpitäjänä haluan että testiympäristön tietokannasta voidaan ottaa tarvittaessa backup komentoriviltä | User Story |
US41 | Palvelun tuottajana haluan käytää konttien jakamisessa myös Docker Hubin konttirekisteriä | User Story |
US42 | Palvelun tuottajana haluan, että palvelu tallentaa päivittäin kättölogia, josta voidaa nähdä käyttäjien määrä ja palvelun käyttöaste | User Story |
US40 | Forumin käyttäjänä toivon voivani palata helposti WIMMA Capstone-sivustolle | |
ENHANCEMENT-4 | Delete-nappula on hyvä lisätä artikkelin muokkausnäkymään | EHDOTUS |
BUG | Artikkelin suuri koko aiheuttaa virheviestin ja istunto kaatuu tai jumittuu | VIKA |
ENHANCEMENT-5 | Tägin lisääminen vaatii syöttökentässä ENTER-painalluksen | EHDOTUS |