Scrum - Ketterä ohjelmistokehitys?

eXtreme Programmingiin kuuluu ainakin parikoodaus ja paljon muitakin tekniikoita, kuten säännöllistä refaktorointia ja yksikkötestausta. Tuotahan on käytetty paljon väärin ja jossain on kritisoitukin, että jos jonkin osan jättää pois niin syntyy helposti sekundaa kun koko prosessi pettää.

Xprammer kirjoitti:

eXtreme Programmingiin kuuluu ainakin parikoodaus ja paljon muitakin tekniikoita, kuten säännöllistä refaktorointia ja yksikkötestausta. Tuotahan on käytetty paljon väärin ja jossain on kritisoitukin, että jos jonkin osan jättää pois niin syntyy helposti sekundaa kun koko prosessi pettää.

Lue lisää

Siis en tajua miten tuommoinen "parikoodaus" voi onnistua käytännössä? Ehkäpä jos on tosi "symppis" lapsuuden aikainen kaveri "nörtti" pari, tuommoinen voisi onnistua.

Jos ajattelisin vaikka parikoodausta omalle kohdalle, yhden toisen työpaikallani olevan kaverin kanssa, niin ei tulis paskaakaan, jos hänen kanssan yrittäis koodata jotain yhdessä, siitä ei tulis helvettiäkään! Hän ei esim. tajua olio-ohjelmoinnista paskan vertaa, ikuinen VB-6 koodari, minulle taas olio-ohjelmointi on ollut tuttua viimeiset 10 vuotta. Se olis yhtä helvettiä, jos hänen kanssaan joutuin harjoittamaan parikoodausta, voi helevetti!

mies.. kirjoitti:

Siis en tajua miten tuommoinen "parikoodaus" voi onnistua käytännössä? Ehkäpä jos on tosi "symppis" lapsuuden aikainen kaveri "nörtti" pari, tuommoinen voisi onnistua.

Jos ajattelisin vaikka parikoodausta omalle kohdalle, yhden toisen työpaikallani olevan kaverin kanssa, niin ei tulis paskaakaan, jos hänen kanssan yrittäis koodata jotain yhdessä, siitä ei tulis helvettiäkään! Hän ei esim. tajua olio-ohjelmoinnista paskan vertaa, ikuinen VB-6 koodari, minulle taas olio-ohjelmointi on ollut tuttua viimeiset 10 vuotta. Se olis yhtä helvettiä, jos hänen kanssaan joutuin harjoittamaan parikoodausta, voi helevetti!

Lue lisää

Olio paradigmat ovat perseestä. Naputtele siinä sitten olio->teeSitä paskaasi ihan rauhassa :D

Assembly on ainoa oikea tie.

haluan sanoa... kirjoitti:

Olio paradigmat ovat perseestä. Naputtele siinä sitten olio->teeSitä paskaasi ihan rauhassa :D

Assembly on ainoa oikea tie.

Mihin tarvitaan nykyaikana Assembleria? Ellet tee hommia sulautettujen hommien ääressä tai jotain joka tosiaan vaatii asmia, kuten itse kääntäjän kehittely jollekkin prossuarkkitehtuurille.

Jos kaikki pitäis koodata assemblerilla, meillä kaikilla kasvais valkee naavaparta, ennen kuin hommat saa tehtyä! Toki softat olis tehokkaita (ja pieniä), mutta mikä olis tehokkuuden hinta?

Sitä paitsi Delphin etuihin kuuluu se, että voit koodata assemblerilla tavan Pascal-koodin sekaan melkeimpä milloin lystää :)

Olen itse koodannut joskus kivikaus sitten jonku "Hello World" ohjelman asmilla, mutta se sai jäädä siihen... Nykyään kun konetehoa riittää ja muistia.. siitä ei ole enään kiinni että perusohmmelit asmia tarvitsis.

Vielä muistuttaisin, etten lähettänyt edellistä viestiä 5.8!

"käyttäjät vaan kertovat minkälaisia nappeja ja käppyröitä haluavat, ja ohjelmoijat toteuttavat jotain sinnepäin."

Eli tuttua on se, että asiakkaat toivovat ja toivovat aina uusia ominaisuuksia "ehkä heille tulevaan ohjelmaan"? Ohjelman koodi paisuu kuin pullataikina ja samalla disabloidaan vanhoja osia koodista, kohta koko projekti on kuin korttitalo, että pysyykö se edes pystyssä! TÄMÄ ON PAINAJAINEN!

Eiköhän täkeintä ole se, että 1) tietyt ominaisuudet lyödään lukkoon 2) TEHDÄÄN NE VALMIIKSI! 3) Otetaan asiakkailta toiveiden tynnyriin lisää ajatuksia 4) toteutetaan niistä seuraavat hyvät ideat! 5) jne... homma jatkuu. Täytyy olla jokin PISTE, mihin homma viedään!

Jos jatkuvasti toteutetaan asiakkaiden hetken mielijohteesta saatuja ajatukia, kohta koko projekti on yks paskaläjä, jolla ei tee yhtään mitään! Siinä on paljon ominaisuuksia SEKAISIN, joista ei saa PÄSSIKÄÄN selvää, kokemusta ON!

Maccileipä kirjoitti:

"käyttäjät vaan kertovat minkälaisia nappeja ja käppyröitä haluavat, ja ohjelmoijat toteuttavat jotain sinnepäin."

Eli tuttua on se, että asiakkaat toivovat ja toivovat aina uusia ominaisuuksia "ehkä heille tulevaan ohjelmaan"? Ohjelman koodi paisuu kuin pullataikina ja samalla disabloidaan vanhoja osia koodista, kohta koko projekti on kuin korttitalo, että pysyykö se edes pystyssä! TÄMÄ ON PAINAJAINEN!

Eiköhän täkeintä ole se, että 1) tietyt ominaisuudet lyödään lukkoon 2) TEHDÄÄN NE VALMIIKSI! 3) Otetaan asiakkailta toiveiden tynnyriin lisää ajatuksia 4) toteutetaan niistä seuraavat hyvät ideat! 5) jne... homma jatkuu. Täytyy olla jokin PISTE, mihin homma viedään!

Jos jatkuvasti toteutetaan asiakkaiden hetken mielijohteesta saatuja ajatukia, kohta koko projekti on yks paskaläjä, jolla ei tee yhtään mitään! Siinä on paljon ominaisuuksia SEKAISIN, joista ei saa PÄSSIKÄÄN selvää, kokemusta ON!

Lue lisää

Kaikista pahin on tällainen hyvin usein pikkufirmoissa nähty ohjelmistokehitysmenetelmä:

1. Ohjelmistoa tai järjestelmää X yritetään myydä asiakkaalle ja se annetaan koekäyttöön asiakkaalle, ehkä pientä korvausta vastaan tai jopa ilmaiseksi.

2. Asiakas sanoo myyjälle, että emme voi ottaa X:ää ellei siihen lisätä toiminteita A, B ja C.

3. Myyjä sanoo kehittäjille, että nyt on pakko tehdä toiminteet A, B ja C, muutoin diiliä ei saada ja firma menee kohta konkurssiin jne.

4. Kehittäjät kehittävät uuden systeemin X ominaisuuksilla A, B, C.

5. Aseta X Toteutus -> Dokumentointi -> Testaus -> Tuotanto.

nähty on kirjoitti:

Kaikista pahin on tällainen hyvin usein pikkufirmoissa nähty ohjelmistokehitysmenetelmä:

1. Ohjelmistoa tai järjestelmää X yritetään myydä asiakkaalle ja se annetaan koekäyttöön asiakkaalle, ehkä pientä korvausta vastaan tai jopa ilmaiseksi.

2. Asiakas sanoo myyjälle, että emme voi ottaa X:ää ellei siihen lisätä toiminteita A, B ja C.

3. Myyjä sanoo kehittäjille, että nyt on pakko tehdä toiminteet A, B ja C, muutoin diiliä ei saada ja firma menee kohta konkurssiin jne.

4. Kehittäjät kehittävät uuden systeemin X ominaisuuksilla A, B, C.

5. Aseta X Toteutus -> Dokumentointi -> Testaus -> Tuotanto.

Lue lisää

"Vaatimusmäärittely -> Toteutus -> Dokumentointi -> Testaus -> Tuotanto."

Ketterissä menetelmissä on kyse pikemminkin siitä, että tekeminen kohdistuu pienempiin osasiin. Jos tehdään Microsoftit eli päätetään että vuonna 2012 julkaistaan seuraava versio ja sitä sitten aletaan vaatimusmäärittelemään, tämä on varmasti hyvä tie. Ongelma vain on siinä, että nykyisin pitäisi tuotteita ja ominaisuuksia saada markkinoille paljon nopeammin.

Olennaista myös on se, että kun tulee uusi tuote sen ominaisuudet ovat myös käyttäjän kannalta relevantteja. Monessa firmassa on nähty sekin, että kun töihin tulee uusi arkkitehti ensitöikseen aletaan korjaamaan "väärin" tehtyä arkkitehtuuria eikä ymmärretä sitä, että asiakkaalle on kohtuullisen sama mitä siellä ikkunan takana oikein tapahtuu. Pahinta mitä ohjelmistoyritys voi tehdä on käpistellä vuosi uutta versiota joka ei tarjoa asiakkaalle mitään uutta.

Yksi hyvä tapa parantaa laatua on pienentää kokonaisuuksia. Siirretään vaatimusmäärittelyt Wordistä tai LaTexista tietokantaan, johon tuki, asennus ja myynti voi syöttää yksittäisiä toiveita joista sitten jalostetaan ominaisuuksia jos siltä tuntuu. Näin koko kehitystä on myös helpompi johtaa kun koko prosessi voidaan määritellä siltä pohjalta, että päivänä X julkaistaan versio jossa on kymmenen tärkeintä systeemin läpi käynyttä ominaisuutta.

nähty on kirjoitti:

Kaikista pahin on tällainen hyvin usein pikkufirmoissa nähty ohjelmistokehitysmenetelmä:

1. Ohjelmistoa tai järjestelmää X yritetään myydä asiakkaalle ja se annetaan koekäyttöön asiakkaalle, ehkä pientä korvausta vastaan tai jopa ilmaiseksi.

2. Asiakas sanoo myyjälle, että emme voi ottaa X:ää ellei siihen lisätä toiminteita A, B ja C.

3. Myyjä sanoo kehittäjille, että nyt on pakko tehdä toiminteet A, B ja C, muutoin diiliä ei saada ja firma menee kohta konkurssiin jne.

4. Kehittäjät kehittävät uuden systeemin X ominaisuuksilla A, B, C.

5. Aseta X Toteutus -> Dokumentointi -> Testaus -> Tuotanto.

Lue lisää

ja koodaat vaan kiltisti kaikki asiakkaan typerimmätkin päähänpinttymät.

Ei oo mun ongelma ja kuitenkin haukun softan ihan paskaksi, kun mikään ei toimi tai siitä puuttuu ominaisuuksia, kun on vaan räpelletty purkka koodia =D

Ja jos ominaisuuksien saaminen kestää liian kauan haukun koko firman ihan paskaksi ja ammattitaidottomaksi =D

ps. tällä alalla tarvitsee tosiaan hyvät hermot, itse en puuhaile softien parissa, mutta saan kyllä osani asiakkaiden haistattelusta =)

rmac kirjoitti:

"Vaatimusmäärittely -> Toteutus -> Dokumentointi -> Testaus -> Tuotanto."

Ketterissä menetelmissä on kyse pikemminkin siitä, että tekeminen kohdistuu pienempiin osasiin. Jos tehdään Microsoftit eli päätetään että vuonna 2012 julkaistaan seuraava versio ja sitä sitten aletaan vaatimusmäärittelemään, tämä on varmasti hyvä tie. Ongelma vain on siinä, että nykyisin pitäisi tuotteita ja ominaisuuksia saada markkinoille paljon nopeammin.

Olennaista myös on se, että kun tulee uusi tuote sen ominaisuudet ovat myös käyttäjän kannalta relevantteja. Monessa firmassa on nähty sekin, että kun töihin tulee uusi arkkitehti ensitöikseen aletaan korjaamaan "väärin" tehtyä arkkitehtuuria eikä ymmärretä sitä, että asiakkaalle on kohtuullisen sama mitä siellä ikkunan takana oikein tapahtuu. Pahinta mitä ohjelmistoyritys voi tehdä on käpistellä vuosi uutta versiota joka ei tarjoa asiakkaalle mitään uutta.

Yksi hyvä tapa parantaa laatua on pienentää kokonaisuuksia. Siirretään vaatimusmäärittelyt Wordistä tai LaTexista tietokantaan, johon tuki, asennus ja myynti voi syöttää yksittäisiä toiveita joista sitten jalostetaan ominaisuuksia jos siltä tuntuu. Näin koko kehitystä on myös helpompi johtaa kun koko prosessi voidaan määritellä siltä pohjalta, että päivänä X julkaistaan versio jossa on kymmenen tärkeintä systeemin läpi käynyttä ominaisuutta.

Lue lisää

Vaatimusmäärittelyssä tuotteen problematiikkaa käsitellään korkeimmalla mahdollisella abstraktiotasolla. Joskus tuotteen tuominen markkinoille 2012 voi olla oikea ratkaisu, toisinaan taas voi olla välttämätöntä saada aikaiseksi jotain seuraavassa kuussa. Määrittelyvetoisella prosessilla voidaan myös tehdä nopeasti tuotteita. Oleellista kuitenkin on, ettei toteutusta aloiteta ennenkuin ymmärretään mitä ongelmaa ollaan ratkaisemassa ja miten.

Ketterissä menetelmissä näen ongelmana juuri tuon, että keskustelua käydään yksittäisten ominaisuuksien (kuten käyttäjä ne näkee) ja koodin tasolla. Alkuun sillä saadaan varmasti nopeasti näyttävää toiminnallisuutta aikaiseksi, mutta vaarana on kokonaiskuvan hämärtyminen ja se, ettei ratkaista niitä olennaisia ongelmia (=ohjelmassa ei sitten olekaan sitä olennaista toiminnallisuutta, tai sitten joku ei-toiminnallinen vaatimus on jäänyt toteuttamatta ja ohjelmisto on sen vuoksi käyttökelvoton).

Loppupeleissä hyvin tehty vaatimusmäärittelyvetoinen tuotekehitys on kertaluokkaa tehokkaampaa kuin mitkään agile menetelmät. On paljon nopeampaa muuttaa esim. yksittäistä kappaletta tai diagrammia määrittelyssä, kuin toteuttaa vastaava toiminnallisuus ensin koodissa ja sitten vasta huomata virhe.

'töihin tulee uusi arkkitehti ensitöikseen aletaan korjaamaan "väärin" tehtyä arkkitehtuuria'

En näe tuossa mitään eroa siihen toimintamalliin, että aletaan koodailemaan jotain tukkua ominaisuuksia ennenkuin ymmärretään edes ongelmakentän perusteita. Hyvälle arkkitehdille/vaatimusmäärittelijälle arkkitehtuuri on vain yksi muuttuja lukuisten tekijöiden joukossa. Sitä muutetaan vain, jos se on lopputuloksen kannalta hyödyllistä.

nähty on kirjoitti:

Kaikista pahin on tällainen hyvin usein pikkufirmoissa nähty ohjelmistokehitysmenetelmä:

1. Ohjelmistoa tai järjestelmää X yritetään myydä asiakkaalle ja se annetaan koekäyttöön asiakkaalle, ehkä pientä korvausta vastaan tai jopa ilmaiseksi.

2. Asiakas sanoo myyjälle, että emme voi ottaa X:ää ellei siihen lisätä toiminteita A, B ja C.

3. Myyjä sanoo kehittäjille, että nyt on pakko tehdä toiminteet A, B ja C, muutoin diiliä ei saada ja firma menee kohta konkurssiin jne.

4. Kehittäjät kehittävät uuden systeemin X ominaisuuksilla A, B, C.

5. Aseta X Toteutus -> Dokumentointi -> Testaus -> Tuotanto.

Lue lisää

ja huonosti suunniteltu olisi jo valmis!

näinhän se menee.. ja kirjoituksesi kuvasi alalla vallitsevaa tilannetta. Eiköhän vähintään puolet maamme ohjelmistotaloista toimi jotakuinkin tuolla periaatteella ainakin jos puhutaan kaupallis-hallinnollisista softista.

Softan kustannukset pitäisikin pystyä arvioimaan koko sen elinkaaren yli. Määrittelyssä ja suunnittelussa tingitty raha joudutaan yleensä maksamaan moninkertaisesti takaisin ylläpidon hitautena ja toistuvina bugikorjauksina.

Harva asiakas on laadusta valmis maksamaan, vrt. vaikka Olkiluodon uuden ydinvoimalan rakennusprojekti.

> Saas nähdä milloin esimerkiksi
> rakennusteollisuudessa markkinavoimat ajavat
> tähän samaan ajettelumaailmaan.

Jos taas ajatellaan järjellä eikä huulenheitolla niin ei taida Scrumilla tehdyt rakennusteollisuuden isot kohteet esim. lujuuslaskemineen oikein pitää paikkaansa. Eli vaikka kuinka olisi Scrumit sun muut jotka ohjeistavat pois määrittelystä niissä caseissä jossa ne yksinkertaisesti on oltava mukana niin
ei tule hommat toimimaan.

Viime vuosina on kattoja ja muita rakennelmia tippunut siihen tahtiin, että on laskemat jätetty
selvästi väliin vaikkei mitään Scrumeja ole edes ollut käytössä.

Kyllä asiat ovat vain niin, että ensin pitää tietää mitä tehdään (edes jollain tasolla) ja sitten aletaan kokoamaan rakennuspalikoista sitä kokonaisuutta. Tämä totuus sopii sekä ohjelmisto- että muillekin aloille.

17 vuotta alalla kirjoitti:

ja huonosti suunniteltu olisi jo valmis!

näinhän se menee.. ja kirjoituksesi kuvasi alalla vallitsevaa tilannetta. Eiköhän vähintään puolet maamme ohjelmistotaloista toimi jotakuinkin tuolla periaatteella ainakin jos puhutaan kaupallis-hallinnollisista softista.

Softan kustannukset pitäisikin pystyä arvioimaan koko sen elinkaaren yli. Määrittelyssä ja suunnittelussa tingitty raha joudutaan yleensä maksamaan moninkertaisesti takaisin ylläpidon hitautena ja toistuvina bugikorjauksina.

Harva asiakas on laadusta valmis maksamaan, vrt. vaikka Olkiluodon uuden ydinvoimalan rakennusprojekti.

Lue lisää

On nähty tuo "uusi arkkitehti" tilanne. On suunnittelijoita jotka selvittävät mitä asiakas tarvitsee ja miten se ratkaistaisiin ja on propellihattuja joille itse koodi ja tekniikka on tärkeintä. Toki on tärkeää että koodi on ylläpidettävää ja selkeää mutta usein käy myös niin että selkeä, _riittävän nopea_ ja toimiva koodi halutaan jonkun arkkitehdin mielestä uudistaa. Seurauksena saadaan sama koodi toimimaan useammassa paikassa mutta seurauksena tuhottomasti monimutkaisuutta ja jopa hitautta.

Esimerkkinä; yksinkertainen lomake jolla lisätään tietokantaan tietue on toteutettu määrittelemällä lomakkeelle syöttökenttiä ja tallenna painike vie arvot kantaan. Propellihattu haluaakin päästä eroon näin sovelluskohtaisesta koodista joten tehdään funktio joka dynaamisesti luo lomakkeen sekä lukee lomakkeen arvot ja vie ne kantaan. Seurauksena pitää tehdä asetustiedosto jossa määritellään mikä kenttä on minkäkin tyyppinen ja mihin tietokannan kenttään se tallennetaan. Asetuksia varten pitää tehdä käyttöliittymä jne...

Seuraus; yksinkertainen toimiva asia saatiin monimutkaiseksi. OK. Homma toimisikin JOS jokainen lomake olisi luotavissa samalla funktiolla helposti. Käytännössä jokainen lomake on erilainen ja sisältää omia erikoistoimintoja kuten pudotuslistan joka luodaan dynaamisesti tilanteen mukaan. Niinpä tähän propellihatun funktioon pitääkin tehdä poikkeuksia ja lopulta poikkeuksia on niin paljon että loppujen lopuksi olisi ollut selkeämpää pitää sovellukset erillisinä ja keskittyä johonkin järkevämpään toimintaan.

Kauhuskenaariona tämä uusi arkkitehtuuri sekä vanhojen tietojen konvertoiminen uutta arkkitehtuuria tukevaan muotoon tuo bugeja jolloin vuosia asiakkaalla hyvin ja sujuvasti toimiva sovellus alkaakin yhtäkkiä kenkkuilla VAIKKA käyttöliittymä ja toiminteet toimivat täysin samalla tavalla kuin ennenkin.

Eli asiakas ei näe mitään hyötyä. Suoritusnopeus saattaa jopa hidastua. Asiakas törmää sovellusvirheisiin. Kannattiko?

IT hemmo kirjoitti:

ja koodaat vaan kiltisti kaikki asiakkaan typerimmätkin päähänpinttymät.

Ei oo mun ongelma ja kuitenkin haukun softan ihan paskaksi, kun mikään ei toimi tai siitä puuttuu ominaisuuksia, kun on vaan räpelletty purkka koodia =D

Ja jos ominaisuuksien saaminen kestää liian kauan haukun koko firman ihan paskaksi ja ammattitaidottomaksi =D

ps. tällä alalla tarvitsee tosiaan hyvät hermot, itse en puuhaile softien parissa, mutta saan kyllä osani asiakkaiden haistattelusta =)

Lue lisää

Ihmiset jakautuvat aika vahvasti ennakointikykynsä mukaan eri luokkiin, mutta jostain syystä ihmiset eivät yleensä tajua tätä itse. Tämä on aika ällistyttävää, etteivät ihmiset pysty arvioimaan toistensa ennakointikykyä.

Niin, kyseessähän on vain asiakkaan ja tuottajan ennakkointivaje. Kumpikaan ei pysty arvioimaan, mikä on asiakkaan reaktio sitten kun asiakas näkee valmiin tuotteen edessään. Tällöin asiakkaan reaktio on usein: "Nyt vasta kun mä näen tämän toiminnassa niin mä tajuan, että en mä tätä halua, vaikka mä kuvittelin aiemmin ihan jotain muuta"

Joskus valmista tuotetta kutsutaan myös vaimoksi, joten kenties moinen älyllinen kyvyttömyys on darwinismin suosima ominaisuus?