Miten / kuinka tarkkaan työelämässä järjestetään ohjelmistoprojektin käytännöt?
Vaikkapa sovelluksen funktioiden ja muutujien nimeämiskäytäntö?
Olen ollut koulussa mukana parissa pikkuprojektissa, mukavaa hommaa.
Pitäisikö tiimityön nopeuttaa ja/tai parantaa sovelluskehitystä muutenkin kuin
leikata valmistumisaikaa suurissa projekteissa?
Tuntuu, että pikkuprojekteissa tiimityö vaatii aikalailla aikaa kommunikointiin, erilaisten taitotasojen yhteensovittamiseen ja käytäntöjen puutteesta johtuvaan, ööh... epävarmuuteen. Tekemällä varmaan oppii kuitenkin tekemään tiimityötäkin =)
Kuitenkin askarruttaa, miten oikeassa elämässä? Miten ohjelmistoproketit oikeasti etenevät, onko jokaisella oma vastuualueensa, tuleeko päällekkäisyyksiä, miten dokumentointi hoituu / hoidetaan, ja pyritäänkö sovelluksesta tekemään jo varhaisessa vaiheessa ajettava, jotta voidaan testata ajonaikaista toimintaa?
Kertokaa kokemuksia?
Terkuin tuleva SW developer :-)
Vaikkapa sovelluksen funktioiden ja muutujien nimeämiskäytäntö?
Olen ollut koulussa mukana parissa pikkuprojektissa, mukavaa hommaa.
Pitäisikö tiimityön nopeuttaa ja/tai parantaa sovelluskehitystä muutenkin kuin
leikata valmistumisaikaa suurissa projekteissa?
Tuntuu, että pikkuprojekteissa tiimityö vaatii aikalailla aikaa kommunikointiin, erilaisten taitotasojen yhteensovittamiseen ja käytäntöjen puutteesta johtuvaan, ööh... epävarmuuteen. Tekemällä varmaan oppii kuitenkin tekemään tiimityötäkin =)
Kuitenkin askarruttaa, miten oikeassa elämässä? Miten ohjelmistoproketit oikeasti etenevät, onko jokaisella oma vastuualueensa, tuleeko päällekkäisyyksiä, miten dokumentointi hoituu / hoidetaan, ja pyritäänkö sovelluksesta tekemään jo varhaisessa vaiheessa ajettava, jotta voidaan testata ajonaikaista toimintaa?
Kertokaa kokemuksia?
Terkuin tuleva SW developer :-)
Vastaukset 3
Vanhimmat
Nuo asiat ovat kuule ihan firmasta, projektipäälliköstä ja sattumastakin kiinni. On taloja, joissa panostetaan menetelmiin ja laatuasioihin, mutta suurin osa alan duunista taitaa olla sellaista myyntimies edellä -touhua.
Väki vaihtuu kuin postitoimistossa ikään ja lopputulos sen mukaista :)
eli ensin myydään mitä sattuu ja sitten tehdään vielä enemmän mitä sattuu..
On myös olemassa ihmisiä, jotka eivät työtapansa puolesta sovellu alalle, mutta ovat jääneet tänne roikkumaan kun takavuosina rima oli suhteellisen matalalla.
"Kuitenkin askarruttaa, miten oikeassa elämässä? Miten ohjelmistoproketit oikeasti etenevät, onko jokaisella oma vastuualueensa, tuleeko päällekkäisyyksiä, miten dokumentointi hoituu / hoidetaan, ja pyritäänkö sovelluksesta tekemään jo varhaisessa vaiheessa ajettava, jotta voidaan testata ajonaikaista toimintaa?"
Scrumilla tehtäessä varsinaisia vastuualueita ei ole, sprintin taskeista voi jokainen valita haluamansa. Käytännössä joku tietysti hallitsee tietyn osa-alueen paremmin ja sitä kautta vastuualueita voi syntyä, mutta siitä pyritään eroon että oltaisiin riippuvaisia yhden tyypin osaamisesta. Dokumentointi koodiin, doxygenilla HTML:ää. Ja scrumia kun tehdään niin ajettavaa ja toimivaa koodia tulee joka commitilla.
Koodin tyyliohjeet päätetään projektin alussa ja kirjataan johonkin wikiin. Dokumentoinnin ja tyylin seuraamisesta pidetään huoli koodinkatselmoinneilla.
kohti milestonea. On se hienoo kun kukaan ei vastaa mistään. Tulokset on sen mukaiset ja niistä joutuu joku aina vastaamaan asiakkaalle.