-
Notifications
You must be signed in to change notification settings - Fork 67
miniprojekti
Matti Luukkainen edited this page Mar 29, 2016
·
20 revisions
- Kurssin viikoilla 3-6 tehdään miniprojekti
-
kurssin läpipääsy edellyttää hyväksyttyä osallistumista miniprojektiin
- miniprojektiin osallistuminen ei ole välttämätöntä jos täytät työkokemuksen perusteella tapahtuvan Ohjelmistotuotantoprojektin hyväksiluvun edellyttävät kriteerit ks. kohta "Laaja suoritus" sivulta
- jos "hyväksiluet" miniprojektin työkokemuksella, kerro asiasta välittömästi emailitse
- Projekti tehdään noin 4-5 hengen ryhmissä
- Projektissa ohjelmoidaan jonkin verran, pääpaino ei kuitenkaan ole ohjelmoinnissa vaan "prosessin" (tästä lisää myöhemmin) noudattamisessa
- jokaisen ryhmän jäsenen on tarkoitus tehdä kunkin sprintin aikana töitä noin 4 tuntia projektin eteen
- ryhmä tekee kussakin sprintissä sen minkä se sprinttiin varatussa ajassa pystyy tekemään, ei enempää eikä vähempää
- Ryhmä muodostetaan "spontaanisti", ma 44.4. ja ti 5.4. luennolla tai tulemalla paikalle saliin xxx:n ... tai ...
- Ryhmä keksii itselleen nimen, luo Github-repositorion ja rekisteröi itsensä tänne
- ryhmä varaa ajan asiakastapaamiselle täältä
- asiakastapaamisia pidetään keskiviikkona, torstaina ja perjantaina
- kun tulet asiakastapaamiseen, sinun tulee tuntea viikolla 2 käsitellyt termit User story, Product backlog ja Sprint backlog
- ryhmä muodostuu/muodostetaan
- ryhmät tapaavat asiakkaan (ke-pe)
- tapaamisaikojen varaaminen täällä
- asiakaspalaverin pohjalta ryhmä tekee alustavan product backlogin ja sopii asiakkaan kanssa ensimmäisen sprintin tavoitteesta
- ryhmä suunnittelee ensimmäisen sprintin ja aloittaa työskentelyn
- sprintin suunnittelun tuloksena ryhmä tekee sprint backlogin
- sprintin 1 arvosteluperusteet
- ryhmät tapaavat asiakkaan (ke-pe)
- tapaamisaikojen varaaminen täältä
- asiakaspalaverin pohjalta ryhmä ajantasaistaa product backlogin ja sopii asiakkaan kanssa toisen sprintin tavoitteesta
- ryhmä suunnittelee toisen sprintin ja työskentelee sen tavoitteiden saavuttamiseksi
- ryhmät tapaavat asiakkaan (ke-pe)
- asiakaspalaverin pohjalta ryhmä ajantasaistaa product backlogin ja sopii asiakkaan kanssa kolmanne sprintin tavoitteesta
- ryhmä suunnittelee kolmannen sprintin ja työskentelee sen tavoitteiden saavuttamiseksi
- ryhmät tapaavat asiakkaan (ke-pe)
- asiakaspalaverin pohjalta ryhmä ajantasaistaa product backlogin ja sopii asiakkaan kanssa kolmanne sprintin tavoitteesta
- ryhmä suunnittelee neljännen sprintin ja työskentelee sen tavoitteiden saavuttamiseksi
- ryhmä esittelee projektinsa lopputuloksen
- loppudemot tulevat olemaan xxx
- asiakkaan visio tuotteesta [täällä(]https://github.com/mluukkai/ohtu2016/wiki/miniprojekti-speksi)
- vaatimukset sovitaan ja niitä tarkennetaan viikoittaisissa palavereissa
- Ryhmä laatii yhdessä asiakkaan kanssa Product backlogin
- Vaatimukset kirjataan backlogiin User story:inä
- Sprintin suunnittelussa ryhmä sitoutuu toteuttamaan Backlogin kärjessä olevat User storyt
- jokaisen ryhmäläisen "työaika" on 4 tuntia viikossa
- ryhmä sitoutuu ainoastaan niihin User storyihin, jotka se kuvittelee kykenevänsä toteuttamaan sprintissä alla olevan Definition of Donen mukaan
- ryhmä ylläpitää Sprint Backlogia
- User storyt jaetaan sprintin suunnittelussa teknisen tason tehtäviksi
- ryhmä tekee päivittäin jäljellä olevan työajan arviointia ja dokumentoi tämän Sprintin Burndown-käyränä
- Koodi on talletettu GitHub:iin
- Ryhmä toteuttaa jatkuvaa integraatiota (Continuous Integration) https://travis-ci.org/
missä formaatissa product backlog ja sprint backlog pidetään?
- esim. Google Docs -spreadsheetinä, mallia voi ottaa seuraavista:
- http://www.mountaingoatsoftware.com/scrum/sprint-backlog
- erään ohtuprojektin backlogit
- Ryhmä lisää linkit backlogeihin, travisiin ja sovelluksen toimivaan versioon (jos sovellus on verkossa) miniprojektin Github-repositorion readmeen
- User storyille on määriteltävä hyväksymäkriteerit, jotka dokumentoidaan easyB:n Storyjen skenaarioiksi
- jokaista User storyä kohti siis pitää pääsääntöiseti olla oma easyB-story (esitellään viikolla 3)
- Toteututun koodin testikattavuus tulee olla mielellään 100% (rivikattavuus)
- Asiakas pääsee näkemään koko ajan koodin ja testien tilanteen CI-palvelimelta
- koodin ylläpidettävyyden tulee olla mahdollisimman hyvä
- järkevä nimeäminen
- järkevä/selkeä ja perusteltu arkkitehtuuri
- hyvän oliosuunnittelun periaatteita (luennot 7 ja 8) tulee noudattaa
- miniprojektista saa maksimissaan 10 kurssipistettä (muut laskarit 10 pistettä ja koe 20 pistettä)
- jokaisesta sprintistä on jaossa 2.5 kurssipistettä
- ensisijainen arvostelukriteeti on ohjelmaan toteutettujen featureiden laatu, tasainen eteneminen ja prosessin seuraaminen (ks. edellinen luku)
Täysiin pisteisiin kunkin viikon sprintissä vaaditaan kaikkien "Tekniset ja prosessiin liittyvät vaatimukset"-kohdassa mainittujen asioiden noudattamista
Tarkemmat sprinteittäiset arvosteluperusteet täällä