-
Notifications
You must be signed in to change notification settings - Fork 4
Home
Ohjelmistoa on tehty kolmen ohjelmistotuotantoprojekti-kurssin ajan, aloitettu keväällä 2020 ja jatkettu syksyllä 2020 sekä keväällä 2021. Ohjelmisto on Helsingin yliopiston TOSKA-ryhmän tilaama, ja sitä on jo käytetty yliopiston kursseilla ryhmäjakoihin. Tämän wiki-sivuston on tarkoitus tehdä projektin mahdollisesta jatkokehityksestä seuraavalla Ohtuprojekti-kurssilla mahdollisimman jouhevaa ja kivutonta. Seuraavassa yleiskatsaus siitä, miten projektia on toteutettu. Tulevat ryhmät luonnollisesti toteuttavat projektia parhaaksi katsomillaan tavoilla, eivätkä ota näitä periaatteita annettuina.
Projektin tilaa ja backlogia ylläpidetään Backlog-boardilla.
- New-sarakkeesseen lisätään uudet, groomausta vaativat featuret. Nämä ovat pääasiassa user storyja, mutta voivat olla muitakin, esim. bugikorjauksia tai refaktorointeja tms.
- Backlog (DEEP) -sarake pidetään prioriteettijärjestyksessä (asiakkaan kanssa).
- Kaikista user storyistä pitää tehdä Githubin issue.
- Sprint log -sarake täytetään uuden sprintin alkaessa (lähtökohtaisesti backlog-sarakkeesta, mutta asiakkaan tarpeesta myös new-sarakkeesta).
- User storyt jaetaan pienempiin tehtäviin käyttämällä Markdownin tickboxeja.
- Issuet assignataan tiimin jäsenille.
- Feature toimii.
- Featurelle on tehty omat testit ja kaikki testit menevät läpi.
Ensimmäinen ryhmä vaati myös, että koodi on katselmoitu.
- Opettaja voi määritellä kurssin, deadlinen ja ryhmän koon.
- Opiskelija voi kirjautua järjestelmään ja täyttää kalenterin (aikataulut), arvosana toivomuksen. Deadlinen jälkeen näiden vaatimuksien perusteella algoritmi jakaa ryhmät.
MVP saavutettiin ensimmäisessä iteraatiossa.
- Node 12
- React 16
- Postgres 12
- GraphQL (TypeGraphQL)
- Apollo Client
Projekti vaihtoi kolmannessa iteraatiossa UI frameworkin Semanticista Materialiin. Materialin komponenttien tyylitys on toteutettu pääosin erillisillä importatuilla tyylitiedostoilla kansiosta /client/styles. Jotkut tiedostot kuitenkin käyttävät omia sisäisiä useStyles-metodeitaan ilman erillisiä importattuja tyylitiedostojaan. Näiden kahden tyylittämistavan sekoittamisen kanssa ei esiintynyt ongelmia, mutta selkeyden vuoksi olisi mahdollista refaktoroida projekti käyttämään vain jompaa kumpaa. Jos Materialin dropdownien kanssa ilmenee päänvaivaa, suosittelee kolmas iteraatio tarkastelemaan tiedoston CourseList.js sisäistä Dropdown-muuttujaa.
Linkki Materialin dokumentaatioon
Projektissa alettiin siirtää kaikkea frontendin tilaa (state) Apollo Clientillä hallittavaksi. Apollo Client soveltuu sellaisen tilan säilömiseen, jota tarvitaan useammassa komponentissa. Apollo Clientin käyttö on tapauskohtaista. Tilaa voi lukea ja muokata joko GraphQL-kyselyillä, tai kirjaston omilla muuttujatyypeillä. Komponentin sisäinen tila, jota ei tarvita missään muualla, kannattaa silti luultavasti toteuttaa Reactin useState-hookilla. Osaa tilasta säilytetään vielä react-hookstore:ssa, joka tulisi deprekoida. (#286)
Linkki Apollo Clientin dokumentaatioon
Ensimmäisessä iteraatiossa tiimi käytti Slackia. Slack-kanavalle pääsyä voi pyytää niin ikään ryhmän ohjaajalta tai asiakkaalta. Slackista voi löytää kevään ryhmän jäseniä ja keskusteluja, sekä muita TOSKA-ryhmän jäseniä.
Toinen iteraatio suoritettiin kokonaan etätyöskentelynä korona-rajoituksista johtuen. Tiimi käytti Discordia kaikkeen viestintään. Discord-kanavalle pääsyä voi pyytää ryhmän ohjaajalta tai asiakkaalta. Discord-kanavalta saattaa löytyä syksyn ryhmän jäseniä ja keskustelut yms. materiaalit.
Kolmas iteraatio jatkoi korona-rajoituksien vuoksi etätyöskentelyä. Viestintään käytettiin toisen ryhmän luomaa Discord-kanavaa, jonne kolmannelle iteraatiolle luotiin oma alikanavansa.
Projektin tilaa ja backlogia ylläpidetään Backlog-boardilla.
- Kevät 2022-sarakkeesseen (ylimmäksi) lisätään uudet featuret. Nämä ovat pääasiassa user storyja, mutta voivat olla muitakin, esim. bugikorjauksia tai refaktorointeja tms. Uudet issuet voivat olla keskeneräisiä.
- Uudet issuet merkitään labelilla New, jotta product owner / asiakas huomaa sen.
- Kaikista user storyistä pitää tehdä Githubin issue.
- User storyt jaetaan pienempiin tehtäviin käyttämällä Markdownin tickboxeja.
- Backlog (DEEP) -sarake pidetään prioriteettijärjestyksessä. Prioriteetin päättää asiakas / product owner.
- Tiimi siirtää Backlog (DEEP) sarakkeesta ylimmän issuen työn alle eli sarakkeeseen In progress kiinnittäen huomiota, että työn alla ei ole liian monta issueta.
- Issuet voidaan tiimin jäsenten toimesta täsmentää tai jakaa myös ollessaan työn alla.
- Issuet assignataan tiimin jäsenille.(maksimimäärä asioita työn alla per henkilö?)
- Google sheetiin kirjataan ylös seuraavat päivämäärät: siirto backlogiin, ottaminen työn alle, feature tuotannossa.
- Jos työn alla oleva issue jaeteen kahdeksi, uuden osa-issuen aloituspäiviksi kirjataan alkuperäisen issuen päivämäärät. (ok?)
- DEEP: Detailed Appropriately, Estimates, Emergent, Prioritized
- INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable
- Kolmenlaisia issueita: Userstory, bug ja refaktorointi. (?) Label
- Estimointi: Small, medium, large, epic. Label (?)
- Userstorylle määritellään hyväksymiskriteerit.
- Feature toimii.
- Featurelle on tehty omat testit ja kaikki testit menevät läpi.
- Koodi on katselmoitu
Definition of Done mukainen feature esitellään Asiakkaalle, jonka jälkeen se viedään tuotantoon. Tuotantoonvientipäivä kirjataan Google Sheetiin.
- Viikon tapaamiset pyritään sopimaan edellisellä viikolla. Tapaamisten vakioaika yleensä klo 12 (muutetaan tarpeen mukaan).
- Yhteinen Google Sheets kalenteri.
- Daily palaverit pidetään lyhyinä, tavoite alle 15 minuuttia.
- Muut tapaamiset pyritään myös pitämään kohtuullisen lyhyinä, tavoite enintään 60 minuuttia.
- Lyhyet 15 min tapaamiset pideteen Discordissa ja pidemmät Zoomissa.