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?

Tilaajan backlog - Toimittajan backlog

Keskusteltiin sprinttien suunnittelukäytänteistä

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

yksi vai kaksi jiraa?

Viime viikolla alustavasti keskusteltiin, että asiakkaalla olisi oma, Eduixilla oma, johon siistitään toteutettavat tehtävä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 + muun toteutuksen tiimi?

yhteinen ohjeistus käleille - pepin alussa oli, hieman lipsuttu sittemmin

peppi-perusrekisteri-pakki - yhteinen ohjeistus

Päätös: 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ä

kootaan käli-tiimi, johon tilaajan ja toimittajan edustus

Määritysten tarkentaminen

organisatoristen kerrosten toiminta (ohjausryhmä - projektiryhmä - asiantuntijaryhmät)

asiantuntijaryhmän hyödyntäminen

käli-proto (toteutettu vaatimusten mukaan)

testaukseen viikko-pari

palaute: miten pitäisi kehittää

varsinainen kehitys tähän pohjautuen

Toimittajan kehityskäytännöt ja -periaatteet

scrum - ok, tarkennetaan tarvittaessa

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

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

Pepin dokumentaatiota on esitelty todella paljon - toive (käsky), että esitellään perus-sivustolla

wikin oltava avoin

Milestonejen määrittely

suunnitellaan projektipäälliköiden kesken ->projektiryhmö -> ohjausryhmä

Kehityssprinttien niveltäminen aikatauluun

Sprintti 0 (tämä viikko)

Ensimmäinen kehityssprintti

Kehitystyön tilannekatsaus

Moduulijakosuunnitelma

Yleistä rajapinnoista:
- rajapinnat vain restillä
- ei hienojakoisia rooleihin perustuvia tarkistuksia rajapintoihin


MODUULI: integration / data-transfer

Yleistä: 
- 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 + Ilkan kanssa speksaus

Migraatio

1. Muut asiat
   
   1. Perusrekisterin nimi - lähetekeskustelu
      
      1. kirjattiin lähetekeskustelussa termit: pere, perse, perusrekisteri, odotetaan Lavikaisen lapsen nimeä - ohry päättää
2. Seuraavat kokoukset
3. Kokouksen päätös