Mun mielestä se puhuu tossa suurimmaksi osaksi niin yleisellä/ideaalilla tasolla, ettei siitä saa kauheasti välineitä oikeiden (ts. sotkuisempien) ongelmien ratkaisuun. Mutta jos on aloittamassa projektia jota meinaa hallita agile-menetelmillä niin monet tuossa mainitut asiat saattavat tulla vastaan ja ovat sinänsä ihan hyviä (joskaan eivät kauhean uusia tai omaperäisiä) pointteja.
Agilen iteratiivisuus siirtyy hyvin suunnittelu/käytettävyysjuttuihin, siltä osin kuin niitä voidaan tehdä devauksen kanssa samassa rytmissä. Mutta mielestäni Nielsen ei tossa puutu erääseen isoimmista asioista, eli siihen että agile-metodeissa speksit suurimmalta osin luodaan lennosta devaaja-asiakas(edustaja)-yhteistyössä. Se design-kuvio ei käsittääkseni perinteisesti kuulu siihen. Käytettävyyttä voidaan toki aina parantaa sillä devaaja/asiakas/käyttäjä-akselilla, mutta laajemman (yli parin sprintin yltävän) kuvion/käyttäjäkokemuksen suunnittelu voi helposti hajota käsiin. Hyviä puolia on, että featuret tulee perusteltua, ja agile-menetelmät tarjoaa hyvät välineet yksittäisten featurejen niin käytettävyyden kuin koodin kehittämiselle.
Mutta sen isomman kuvion hallinnan haluaisin ymmärtää siinä paremmin, kun se tuntuu noiden agile-menetelmien heikolta kohdalta.
Mitä mieltä olet itse agile-juttujen käytöstä (eri asteisesti) design-vetoisissa projekteissa?
heh.
Muistaakseni luin tuon. Siinä oli hyviä ajatuksia, paljon selkeämpi ja jäsennellympi kuin Nielsenin teksti. Toisaalta Nielsenillä se onkin lähinnä mainospuhe siitä 96-sivun raportista mitä he myyvät.
"Mutta mielestäni Nielsen ei tossa puutu erääseen isoimmista asioista, eli siihen että agile-metodeissa speksit suurimmalta osin luodaan lennosta devaaja-asiakas(edustaja)-yhteistyössä."
Tuon pitäisi olla "tiimi-asiakas(edustaja)-yhteistyössä". Jos tiimissä on designeri niin homma toimii.
akonan: totta tiimiä tarkoitin. Ehkä omassa kokemuksessa on painottunut devaus-vetoiset projektit, mikä ei ole tietenkään menetelmän vika.
ville: "design-vetoinen" taitaa olla mulla jäänne hyvin softapainotteisista projekteista. Tarkoitan, että suunnittelu tehdään kokonaisuutta ajatellen, ei pelkästään yksinkertaisinta teknistä toteutusta.
4 comments so far
Mun mielestä se puhuu tossa suurimmaksi osaksi niin yleisellä/ideaalilla tasolla, ettei siitä saa kauheasti välineitä oikeiden (ts. sotkuisempien) ongelmien ratkaisuun. Mutta jos on aloittamassa projektia jota meinaa hallita agile-menetelmillä niin monet tuossa mainitut asiat saattavat tulla vastaan ja ovat sinänsä ihan hyviä (joskaan eivät kauhean uusia tai omaperäisiä) pointteja.
Agilen iteratiivisuus siirtyy hyvin suunnittelu/käytettävyysjuttuihin, siltä osin kuin niitä voidaan tehdä devauksen kanssa samassa rytmissä. Mutta mielestäni Nielsen ei tossa puutu erääseen isoimmista asioista, eli siihen että agile-metodeissa speksit suurimmalta osin luodaan lennosta devaaja-asiakas(edustaja)-yhteistyössä. Se design-kuvio ei käsittääkseni perinteisesti kuulu siihen. Käytettävyyttä voidaan toki aina parantaa sillä devaaja/asiakas/käyttäjä-akselilla, mutta laajemman (yli parin sprintin yltävän) kuvion/käyttäjäkokemuksen suunnittelu voi helposti hajota käsiin. Hyviä puolia on, että featuret tulee perusteltua, ja agile-menetelmät tarjoaa hyvät välineet yksittäisten featurejen niin käytettävyyden kuin koodin kehittämiselle.
Mutta sen isomman kuvion hallinnan haluaisin ymmärtää siinä paremmin, kun se tuntuu noiden agile-menetelmien heikolta kohdalta.
Mitä mieltä olet itse agile-juttujen käytöstä (eri asteisesti) design-vetoisissa projekteissa?
1 year ago by marqs
heh. Muistaakseni luin tuon. Siinä oli hyviä ajatuksia, paljon selkeämpi ja jäsennellympi kuin Nielsenin teksti. Toisaalta Nielsenillä se onkin lähinnä mainospuhe siitä 96-sivun raportista mitä he myyvät.
1 year ago by marqs
"Mutta mielestäni Nielsen ei tossa puutu erääseen isoimmista asioista, eli siihen että agile-metodeissa speksit suurimmalta osin luodaan lennosta devaaja-asiakas(edustaja)-yhteistyössä."
Tuon pitäisi olla "tiimi-asiakas(edustaja)-yhteistyössä". Jos tiimissä on designeri niin homma toimii.
1 year ago by akonan
akonan: totta tiimiä tarkoitin. Ehkä omassa kokemuksessa on painottunut devaus-vetoiset projektit, mikä ei ole tietenkään menetelmän vika.
ville: "design-vetoinen" taitaa olla mulla jäänne hyvin softapainotteisista projekteista. Tarkoitan, että suunnittelu tehdään kokonaisuutta ajatellen, ei pelkästään yksinkertaisinta teknistä toteutusta.
1 year ago by marqs