Projektiryhmän kokous

Aika: 2.6.2014 klo 12.00 - 16.00

Paikka: Eduix Oy, Tampere

Läsnä:

• Jaakko Rannila
• Virve Peltoniemi
• Anna-Liisa Karjalainen, sisällöllinene asiantuntija
• Juhani Gurney, tietojärjestelmätyöryhmä, projektin omistaja Eduixilla
• Eero Manninen, suunnittelu, arkkitehtuuri, toteutus
• Kristoffer Michael, suunnittelu, arkkitehtuuri, toteutus
• Rami Heinisuo, toimittajan edustaja johtoryhmässä
• Leena Tuomela, Pepissä toimittajan pp; nyt koordinaattori Peppi-liitännäisten osalta
• Hannu Lakervi, tietorakenteet, 
• Kirsi Vikström (Virven apuna - koordinaattori tekniselle porukalle, liitännäisyydet jne)
• Virve Peltoniemi, TAMK projektipäällikkö tämä + PAKKI
• Janne Riihimäki, kälit
• Heidi Lehtonen, kälit
• Tuomas Orama, + Jussi Kivinen omistaja
• Lauri Stigell, toimittajan projektipäällikkö

Agenda

1. Kokouksen avaus
2. Projektin tilannekatsaus (projektipäälliköt)
   
   1. Projekti- ja kehitysmalli
      
      1. Tilaajan backlog - Toimittajan backlog
         
         1. jira-käytännöt
      2. Määritysten tarkentaminen
      3. Toimittajan kehitysmalli
      4. Toimittajan kehityskäytännöt ja -periaatteet
   2. Resurssit
      
      1. Toimittajan resurssit
      2. Tilaajan resurssit
   3. Aikataulu
      
      1. Karkea aikataulu
      2. Milestonet
      3. Kehityssprinttien niveltäminen aikatauluun
      4. Sprintti 0 (tämä viikko)
      5. Ensimmäinen kehityssprintti
   4. Kehitystyön tilannekatsaus
      
      1. Moduulijakosuunnitelma
      2. Tietomalli
      3. Migraatio
3. Muut asiat
   
   1. Perusrekisterin nimi - lähetekeskustelu
4. Seuraavat kokoukset
5. Kokouksen päätös

Muistio

1 Kokouksen avaus

• Jaakko Rannila avasi kokouksen ja esitteli ohjausryhmälle perusrekisteristä pidetyn esityksen (diat)
• Projektiryhmän jäsenet esittäytyivät

2 Projektin tilannekatsaus (projektipäälliköt)

Resurssit

• Projektipäälliköt esittelivät toimittajan ja tilaajan projektiin asettamat resurssit
• Tilaajan puolelta keskeiset resurssit projektipäälliköt Lavikainen, Rannila, Peltoniemi
• Toimittajan puolelta keskeiset resurssit projektipäällikkö Stigell, arkkitehdit/kehittäjät Manninen, Michael, Rauta, käyttöliittymäsuunnittelijat Riihimäki, Lehtonen + teknologiajohtaja Gurney

Projekti- ja kehitysmalli

• Toteutusprojektissa käytetään scrumia
• 2 viikon sprintit, kesän aikana mukautettu malli lomat huomioiden
  
  • sprintti 0 alkaa ma 2.6.
    
    • luodaan product vision
    • valmistaudutaan huolella ensimmäiseen oikeaan sprinttiin
    • sovitaan projektikäytännöistä lopullisesti tilaajan kanssa, kun miehitys on kunnossa ja vapautunut vanhoista töistä
    • täsmennetään aikataulut kesän yli
    • laaditaan karkeaan aikatauluun pohjautuen milestonet projektin ajalle
    • nivelletään sprintit aikatauluihin soveltuvasti
    • määritellään definition of done
    • hyväksytetään tarvittavat toteutukseen liittyvät suunnitelmat tilaajalla / ohjausryhmällä
  • sprintti 1 suunniteltu aloitettavaksi ma 9.6.
• Roolit:
  • Projektin omistaja
    
    • Tilaajalla Tuomas Orama ja Jussi Kivinen
    • Toimittajalla Juhani Gurney
  • Projektipäällikkö / Product Owner
  • • Tilaajalla Mika Lavikainen
    • Toimittajalla Lauri Stigell
    • Vastaa projektin läpiviennistä + siitä, että palvelu vastaa sisällöllisesti sitä, mitä tavoitellaan
  • Scrum master
  • • Kiertävä vastuu Eduixilla
    • Vastaa, että kehittäjät noudattavat sovittuja (teknisiä) käytäntöjä; vastaa DS:ien läpiviennistä

• Sprintin käytänteet
  
  • Esisuunnitteluvaihe
    
    • Projektipäällikkö tuo alustavan listan seuraavan (ja sitä seuraavan) sprintin tehtävistä kehittäjille kaksi työpäivää ennen edellisen sprintin loppua. (Omat deadlinet nivelletään asiakkaan asettamiin deadlineihin siten, että mahdollisiin korjauksiin jää aikaa vähintään viikko ennen asiakkaan DL:ia.)
    • Kehittäjät käyvät suunnitellut tehtävät läpi ja tarkentavat työmääräarviot (Story Points / vast.). Projektipäällikkö on käytettävissä täsmentävän suunnittelun ja työmääräarvion tekemisen aikana.
    • Projektipäällikkö hyväksyy alustavan tehtävälistan seuraavaa sprinttiä varten
  • Sprintin aloitus
    
    • Sprintin aloituspäivänä käydään esisuunniteltu tehtävälista vielä uudelleen läpi priorisoidusta backlogista - huomioidaan edellisestä sprintistä mahdollisesti siirtyvät tehtävät ja näiden vaikutus kokonaistyömäärään
    • Tarvittaessa tarkennetaan työmääräarvioita ja vaaditaan selvennystä epäselviin tehtäviin.
    • Projektipäällikkö ja kehittäjät sitoutuvat ottamiensa tehtävien tekemiseen sprintin aikana
  • Sprintin aikana
    
    • Kehittäjät ottavat backlogista tehtäviä sitä mukaa, kun saavat edellisiä valmiiksi
    • Epäselvyyksistä, aikatauluongelmista jne. tulee välittömästi ilmoittaa projektipäällikölle, jotta seuraavan sprintin työmäärissä kuluvan sprintin ongelmat voidaan huomioida
    • Alussa daily scrumit pidetään päivittäin (klo 9.00 - 9.10 (max.)), tarvittaessa vähennetään esim. 2 - 3 x vk
      
      • Mitä olen tehnyt eilen?
      • Mitä aion tehdä tänään?
      • Onko näköpiirissä työtäni hidastavia tai estäviä asioita?
      • Onko näköpiirissä riippuvuuksia tai esteitä muille kehittäjille?
  • Sprintin päättyessä
    
    • Sprint Review
      
      • Mitä saatu aikaiseksi - näytetään miten toimii
      • Mitä mahdollisesti ei saatu aikaiseksi - miksi
      • Päätetään sprintti
    • Retrospektiivi
      
      • Mikä onnistui?
      • Mikä ei onnistunut?
      • Mitä voin itse muuttaa, että jatkossa menee paremmin?
      • Mitä projektissa tulisi muuttaa, että jatkossa menee paremmin?
• Backlogin muodostaminen
  • Vaihtoehto 1: tilaajan edustaja on sprittien suunnittelussa mukana
  • Vaihtoehto 2: toimittajan projektipäällikkö tuo kehittäjille suunnittelutilaisuuteen asiakkaan esittämän alustavan työlistan, jonka pohjalta toimittaja jatkaa suunnittelua
  • Päätös: alkuvaiheessa toimittaneen vaihtoehdon 1 mukaan; oleellista joka tapauksessa, että malli toimii ja riittävät resurssit käytettävissä molemmilla osapuolilla - muutetaan tarvttaessa toimimattomia käytäntöjä matkan varrella. 
• Jira-käytännöt
  • Päätös: perusrekisterissä toimitaan vain yhdellä Jiralla, jonka Eduix pystyttää; kyseessä on uusi jira-instanssi, joka on suorassa yhteydessä tuotantoympäristöön;  Eduix järjestää tarvittavat oikeudet tilaajan edustajille (tarkastelu, muokkaus)
• Käli-tiimi
  • Päätös: perustetaan käli-tiimi, johon tilaajan ja toimittajan edustajat
  • ensimmäiseen sprinttiin olemassa olevien käli-suunnitelmien / ohjeistuksien kokoaminen + askelmerkit jatkokehitykselle; yhteiset tyylit eri palveluihin -> työpöytiin
  • pitkälti kyse lomakelistaus-tyyppisistä asioista - toisaalta toimijat hahmottavat asioita kälien kautta, sikäli käli edellä meneminen perusteltua
  • päätettiin, että edetään pepin tavoin kälit edellä
• Määritysten tarkentaminen
  • tarvittaessa asiantuntijaryhmiä hyödynnetään määritysten tarkentamisessa, mutta ennen muuta katselmoinnissa / hyväksynnässä
  • alustava toimintamalli
    • tehdään käli-proto (toteutettu vaatimusten mukaan)
    • testaukseen viikko-pari aikaa
    • palaute: miten pitäisi kehittää
    • varsinainen kehitys tähän pohjautuen
• Projektien välinen yhteistyö (perusrekisteri ja pakki)
  • Pakin kilpailutus käynnissä (hops, suoritustiedot ja ilmoittautumiset - ei lueta winhasta vaan uudesta perusrekisteristä); palvelut oltava perusrekisterissä näiden tietojen välittämiseen pakille
  • Kun kilpailutus tehty, sovitaan Pakki-projektin kanssa projektien välisestä yhteistyöstä ja synergiasta

Aikataulu

• Karkea aikataulu ennen kesää ja kesän yli
  
  • Tietokannan suunnittelu ja toteutuksen aloittaminen
  • Moduulijaon tarkentaminen
  • Kehitysympäristön pystyttäminen, uuden versionhallinnan käyttöönotto
  • Migraatio
    
    • testiwinha asennus 16.6. Metropolia; TAMK:llal jo olemassa
  • Käyttöliittymäohjeistuksen laatiminen
  • Tietosuoja ja tietoturvaperiaatteet
    
    • Nixu + Ilkka
  • Dokumentaatiokäytäntöjen tarkentaminen
  • Milestonejen alustava määrittely
  • Kehityssprinttien niveltäminen aikatauluun
• Pepin dokumentaatiota on esitelty todella paljon - toive (käsky), että esitellään perusrekisterin sivustolla
  • wikin oltava avoin

Moduulijakosuunnitelma (luonnos)

• Yleistä rajapinnoista:
  
  • rajapinnat vain restillä
  • ei hienojakoisia rooleihin perustuvia tarkistuksia rajapintoihin
• MODUULI: integration / data-transfer
  
  • datan siirto järjestelmään ja toimittaminen ulos. 
  • rajapinta tietojen viemiseksi virta muodossa
  • rajapinta tietojen hakemiseksi virta muodossa
  • käyttöliittymä monitorointiin. Mitä on viety, mitä on haettu. kuinka kauan kestänyt. ylimääräistä validointia viesteihin?
• MODUULI: data-import
  • winha-datan muuntaminen virta muotoon ja sen vieminen järjestelmään
  • ajastettu integraatio
  • käytössä vain kehitysvaiheessa sekä käyttöönotossa
• MODUULI: student-registry
  • opiskelijan henkilötiedot
  • endpoint: student-registry-manager
    • opiskelijoiden tiedot
    • ryhmien halinta
  • endpoint: student-registry-admin
    • student-registry + auditointi/monitorointi
    • siirrettyjen hakijoiden hyväksyminen
• MODUULI: registration-assessment-service
  • endpoint: registration-assessment
    • vain omat tiedot
      • ilmoittautuminen toteutuksille
      • opintosuoritusote
  • endpoint: registration-assessment-manager
    • rajaus: vain omat toteutukset
      • ilmoittautuminen toteutuksille
      • ilmoittautumisten hyväksyminen
      • suoritusten arviointi
      • opintosuoritusote
  • endpoint: registration-assessment-admin
    • ilmoittautuminen toteutuksille
    • ilmoittautumisten hyväksyminen
    • suoritusten arviointi
    • tutkintotodistus?
• MODUULI: configuration
  • endpoint: configuration-admin
    • koodistot
    • organisaatiot
    • rahoitukseen liittyviä tietoja?
• MODUULI: reporting
  • erilaiset listaukset ja tulosteet
• Keskustelua moduulijaosta
  • identiteettiin liittyvät henkilötiedot tulee erottaa opiskelijaroolin tiedoista (joka liittyy opiskeluoikeuteen) - vain OID jatkossa
  • opiskeluoikeuteen liittyvät tiedot ylläpidetään jatkossakin perusrekisterissä

Tietorakenteiden suunnittelu

• relaatiotietokannan suunnittelu käynnissä; pääasiallinen tiedon säilö; tietokanta-alustariippumaton (tietokantatasolla tietojen suojaus)

• dokumenttipohjainen tietokantasäiliö (vrt. elastic search, joka pohjana kälien perushaulle ja raportoinnille)

• seuraavassa vaiheessa moduulisuunnitelmaan matchaaminen

3 Muut asiat

• Perusrekisterin nimi - lähetekeskustelu
  
  • Keskusteltiin siitä, että perusrekisterille olisi hyvä saada hieman iskevämpi nimi
  • Sinänsä lennokkaiden ja arvattavien nimiehdotusten jälkeen päädyttiin odottamaan projektipäällikön lapsen nimen julkistamista

4 Kokouksen päätös

• Päätettin kokous ja siirryttiin vapaan speksauksen osioon.