-
Notifications
You must be signed in to change notification settings - Fork 67
miniprojekti
Matti Luukkainen edited this page Mar 31, 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 4.4. ja ti 5.4. luennolla tai tulemalla paikalle ti 5.4. klo 15 C221, ke 6.4. klo 17 tai pe 8.4. A218 klo 14 C221
- 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ä
- 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ä)
- sprinteistä 1 ja 2 on jaossa 2 kurssipistettä, sprintistä 3 ja 4 jaossa 3 kurssipistettä
- ensisijainen arvostelukriteeti on ohjelmaan toteutettujen featureiden laatu, tasainen eteneminen ja prosessin seuraaminen (ks. edellinen luku)
- osa jaossa olevista pisteistä perustuu henkilökohtaiseen suoritukseen, eli passiivinen osallistuminen ryhmään ei tuo automaattisesti samoja pisteitä kuin aktiivisille ryhmäläisille
Täysiin pisteisiin kunkin viikon sprintissä vaaditaan kaikkien "Tekniset ja prosessiin liittyvät vaatimukset"-kohdassa mainittujen asioiden noudattamista
Tarkemmat sprinteittäiset arvosteluperusteet täällä