-
Notifications
You must be signed in to change notification settings - Fork 67
miniprojekti
Matti Luukkainen edited this page Apr 26, 2016
·
20 revisions
- toisen sprintin arvosteluperusteet
- kolmannen sprintin arvosteluperusteet
- neljännen sprintin arvosteluperusteet
- sprinttien 2-4 asiakastapaamiset
- projektien rekisteröinti
- 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 A218 tai pe 8.4. klo 14 C221
- Ryhmä keksii itselleen nimen, luo Github-repositorion ja rekisteröi itsensä tänne
- ryhmä varaa ajan asiakastapaamiselle
- asiakastapaamisia pidetään tiistaina, 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 (ti-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 varaavat tapaamisen seuraavien viikkojen asiakastapaamisille
- tapaamisaikojen varaaminen täältä
- ryhmät tapaavat asiakkaan (ti-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
- toisen sprintin jälkeen tulee ohjelman kyetä tuottamaan bibtex-tiedosto, joka toimii yhteen osoitteessa https://github.com/mluukkai/ohtu2013/blob/master/ohtu-bibtex.zip?raw=true olevan latex-dokumentin kanssa
- dokumentti "käännetään" suorittamalla komennot
pdflatex paper; bibtex paper; pdflatex paper; pdflatex paper
- tämän jälkeen tiedostossa paper.pdf tulisi kaikkien lähdeviitteiden toimia, eli tiedostosta ei saa löytyä yhtään [?]:tä
- viitteiden merkkijonotunnisteiden (eli bibtex-itemin ylimmän rivin merkkijonon, mihin artikkelin tekstissä viitataan \cite:llä) ei tarvitse olla samat kuin artikkelissa käyteytyt, niiden tulee mielellään olla käyttelijän vapaasti määrittelemät tai oletusarvoisesti muodostetut
- luodun bibitex-tiedoston nimen tulee olla valittavissa (esimerkkiprojektissa nimen tulee olla sigproc.bib, aina ei kuitenkaan ole näin)
- huom: saatat joutua asentamaan fonttipaketin texlive-fonts-recommended, debianpohjaisissa linuxeissa (mm ubuntu) komennolla
sudo apt-get install texlive-fonts-recommended
- ryhmät tapaavat asiakkaan (ti-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 (ti-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ä