Kurssin yleinen kuvaus: courses.helsinki.fi
- Kurssilla on telegram-kanava, linkki fuksiwikissä
Kurssilla kokeilukäytössä jatkuva palautteen keräys. Anna palautetta kurssikäytännöistä flingassa!
Demot:
- Välidemo 1.3. klo 9-12 CK112
- Loppudemo 3.5. klo 9-12 CK112
Vertaisarviot:
- puolessa välissä ja lopussa vertaisarvio
https://study.cs.helsinki.fi/projekti/peerreview
- Noudatetaan Scrum-henkistä prosessia.
- Kahden viikon välein asiakastapaaminen (Sprint Review), jonka jälkeen Sprint Planning ja Sprint Retrospective.
- Mahdollisuuksien mukaan päivän aluksi Daily Scrum.
- Ensimmäinen viikko ns. nollasprintti, josta lisää alempana.
- Tarkastellaan jatkuvasti prosessin toimivuutta Sprint Retrospectivessä.
- Transparency, Inspect & Adapt!
- Ensimmäisessä asiakastapaamisessa pyritään määrittelemään Minimum Viable Product, koska tarkoituksena on saada ohjelma tuotantoon mahdollisimman nopeasti.
Perustakaa heti jonkinlainen yhteinen TODO-lista. Kirjatkaa sinne nollasprintin tehtävät. Siellä tulisi olla ainakin nämä:
- Slack, tai vastaava keskustelualusta pystyyn.
- Ohjaajalle kutsu
- Product backlogin laatiminen
- Sprint Task Board / Sprint backlog (fyysinen tai sähköinen)
- Tuntikirjanpito, josta näkee jokaiseen viikkoon käytetyt tunnit opiskelijoittain
- Luokaa GitHub-organisaatio ja repository
- README standardin mukaiseksi, lisäksi "päärepoon" linkit muihin repositorioihin, backlogiin sekä sovellukseen.
- Sopikaa käytettävät teknologiat
- Huom! Asiakkailla voi olla mielipide käytettävistä teknologioista tai koodauskäytännöistä.
- CI- ja staging-ympäristö mahdollisimman nopeasti pystyyn
- Branching-käytännöistä sopiminen
- Hyvä käytäntö on pitää master-haarassa vain tuotantokelpoista (deployable) koodia. Näin voidaan aina siirtää koodi staging-palvelimelle (ja myöhemmin tuotantoon.)
- Ohtuprojektien OpenShift-konttialustaa voi käyttää staging-ympäristönä, erityisesti jos asiakas HY:llä
- Koodauskäytännöt
- Sopikaa Definition of Done
- Pitää olla sellainen, että DoDin kriteerit täyttävä story voitaisiin viedä sellaisenaan tuotantoon!
- Huom: DoD:ia voi päivittää tiukemmaksi projektin edetessä
- Valituilla teknologioilla toteutettu "hello world" / Walking skeleton -sovellus staging-ympäristöön.
- "A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function"
- DEEP Product Backlog pitää olla DEEP.
- User storyt Vaatimukset User Story -muodossa. INVEST on tärkeä!
- Hyväksymiskriteerit Storylla pitää olla hyväksymiskriteerit (Acceptance critieria), jos se on Product Backlogissa korkealla (=tulee kohta tehtäväksi). Kriteerit kannattaa käydä läpi koko tiimin ja asiakkaan kanssa, vaikka kaikkia ei tarvitse kirjoittaa asiakkaan läsnäollessa. Lue hyvistä käytännöistä alla.
- lue lisää hyväksymiskriteereistä omasta ohjeestaan
- Storyjen seuranta Seurataan missä sprintissä valmistuneen storyn tekeminen on aloitettu. Tarkoituksena on, että kaikki storyt olisivat valmiita samassa sprintissä kuin ne on aloitettu, mutta metriikoiden optimointi ei saa missään nimessä olla itsetarkoitus — storyn pitää olla aidosti laadukkaasti tehty ja muilta osin valmis ennen kuin se lasketaan tehdyksi.
- Sprint planning
- Sprint review
- Retrospektiivi
- Daily
- Open source
- GitHub Ohjaajan päästävä näkemään lähdekoodi ja commitit
- Staging-ympäristö mahdollisimman tuotannon kaltainen.
- Tuotantoon! Tuotos täytyy saada tuotantoon jo projektin aikana, mielellään mahdollisimman nopeasti.
- CD Tuotantoon päivityksen pitää olla tehokasta ja/tai jatkuvaa
- Demot stagingista tai tuotannosta Asiakkaalle demotaan ainoastaan vain ja ainoastaan staging- tai tuotantopalvelimelta, ei omalta koneelta.
- Testaus
- Automaatiotestauksen pitää olla riittävän kattava ja hyvin toteutettu
- Kaikkien yksikkötestien ajaminen on hyvä kestää korkeintaan muutaman minuutin. Korkeamman tason testien, kuten UI-testien ajo saa kestää pidempään, eikä niitä tarvitse ajaa yhtä usein.
- Erittäin tärkeä konsepti on ns. testipyramidi http://martinfowler.com/bliki/TestPyramid.html. Parin minuutin lukeminen voi säästää kymmeniä tunteja aikaa.
- Testikoodin laatu tulee mielellän olla yhtä hyvää kuin muunkin koodin.
- Tuntikirjapito Kurssin aikana seurataan tuntimääriä. Työtunneiksi lasketaan myös tapaamiset, esim. tiimin kanssa yhdessä lounastamiset ja itseopiskelu.
- Kirjaukset oltava kunnossa su 23:59 sekä sprintin vaihtuessa - mielummin päivittäin.
- Commit esiin Varmista että committisi näkyvät GitHubissa oikein. Ks. ohje
- Kurssi = 200h Vaatimuksena noin 200 tuntia työtä koko kurssin aikana, mikä on noin 15-16 tuntia viikossa.
- Tasaisuus Ehdottomana vaatimuksena työmäärien tasaisuus viikkotasolla, eli tuntimäärän kuuluu olla viikosta toiseen suunnilleen sama. Sairastumiset yms. neuvoteltava poikkeus. Ilmoita reilusti etukäteen jos tiedät, että osallistumisesi viikon töihin estyy jollain tapaa.
- Kunnioita kanssaopiskelijoitasi, kyseessä ei ole yksilökurssi.
- Käyttäydy samojen standardien mukaan kuin olisit töissä.
- Sovittuihin yhteisiin tapaamisiin pitää tulla. Myöhästymisistä, esteistä yms. pitää ilmoittaa ajoissa.
- Siiloutumista tulee välttää. Koodikatselmoinnit!
- Arvot ja käytännöt
- Ryhmän sovittava yhteiset käytännöt. Ks. esimerkki
- Asiakastapaamiset
- Tilavaraukset Ensimmäisen asiakastapaamisen jälkeen ryhmä on vastuussa asiakastapaamisten järjestämisestä.
- Agenda Asiakastapaamisiin kannattaa luoda melko yksityiskohtainen agenda ja se on hyvä lähettää asiakkaalle ennen varsinaista tapaamista.
- Roolit Kiertävä puheenjohtajan roolit. Lisäksi ainakin kirjuri ja demovastaava.
- Muistiinpanot Asiakastapaamisista tehtävä muistiinpanot. Keskusteltuja asioita ei saa jättää muistin varaan vaan ne tulee kirjata backlogille.
- Retrospektiivit dokumentoitava
- Ohjaajan oltava paikalla jokaisessa retrospektiivissä. Doodlaus tiimin vastuulla.
- Ryhmätyötaitojen harjoittelu.
- Tehtävien ja työn jakaminen
- Kommunikaatio
- Organisointi
- Ohjelmistotuotantomenetelmien käytännön harjoittelu.
- Yhteisen codebasen kanssa työskentely (git)
- Deployment
- Ketterät toimintatavat
- Transparency
- Inspect & Adapt
- Miksi Scrum? Kirjoitus ohtuprojektin tavoitteista ja miten scrum auttaa niiden saavuttamisessa.
Arvostelu perustuu seuraaviin asioihin
- Ryhmän sopimien työskentelytapojen noudattaminen
- Ryhmän työskentelytapojen (=prosessin) kehittäminen
- Ryhmätyöskentely
- Tekninen kontribuutio - koodi tai asiantuntijuus
- Valmistautuminen asiakastapaamisiin ja toiminta asiakaspalaverissa
- Työtuntien määrä ja tasaisuus sekä merkintöjen asiallisuus
Katso tarkemmat kriteerit arvostelumatriisista
- Töitä kannattaa tehdä mahdollisimman paljon muiden kanssa fyysisesti samassa tilassa.
- Sprintin aikana on hyvä olla tekeillä ainoastaan 2-3 storya kerrallaan. Tällöin storyt valmistuvat varmemmin. Muutama valmis > melkein kaikki kesken.
- Ohjelmiston arkkitehtuuriin kannattaa käyttää paljon huomiota ja jättää sprinttiin aikaa tehdä parannuksia sisäiseen laatuun. Puhdas User Story -hikipaja, jossa keskitytään ainoastaan mahdollisimman nopeaan ominaisuuksien tuottamiseen ei pitkällä tähtäimellä tuota hyviä tuloksia.
- Voi olla hyvä idea hahmotella hyväksymiskriteerit ennen varsinaista asiakastapaamista. Kannattaa kuitenkin jättää hieman pureskeltavaa kriteereihin ennen tapaamista.
- On hyvä käytäntö pitää agenda näkyvillä asiakastapaamisen aikana, jotta keskustelu saadaan pysymään paremmin aiheessa. Käydään kokouskäytäntöjä tarpeen mukaan läpi yhdessä.
- Vinkkejä asiakaspalaveriin
- ohtuprojektin OpenShift-konttialusta
- Tilat:
- DK107 eli "Luola" ensisijaisesti ohtuprojektiryhmien käytössä
- Myös muita saleja voi käyttää: esim B221 (yläpaja), BK107 (alapaja), C221, DK108 (haxo)
- Sali asiakaspalaverille: Palaverin voi pitää tiimitilassa tai "neukkarissa". Pyydä tilavaraus Reijo Siveniltä tai kysy ohjaajalta. Myös kirjaston ryhmätyötiloja voi käyttää. Varausohjeet: http://www.helsinki.fi/kirjasto/fi/asioi/tyoskentele-kirjastossa/ryhmatyotilat/
Staging nykyään Tiken OpenShift-klusterissa
Aina ei tarvitse keksiä pyörää uudelleen - katso vinkkejä täältä tai edellisten ryhmien repoista.