@pe3, missä mielessä? Varmaan useimmat Jaikun 'perusverkostostamme' ovat törmänneet ao. käsitteeseen työ- ja vapaa-aikana. Netti on valtoimenaan mainioita perustiivistelmiä ja oppaiksi asti, niihin voinee viitata suoraan ensi alkuun. Viidestä vaiheesta eli projektin pilkkomisesta kannattanee aloittaa. Sekä critical pathista.
Kiitti linkistä @ubiq. Se auttoi mua tajuamaan, että kaipaisin tähän mielummin ketterän koulukunnan juttuja. Okei klassisesta projektinhallinnasta on varmaan hyvä tietää jotkin peruskäsitteet, kuten kriittinen polku.
Klassisen koulukunnan mallit taitaa olla sidoksissa top-down meininkiin. Haluisin tähän parvimaisemman vellovan vapaaehtoisprojektin näkökulmaa. Down-up.
Paljon tunteita herättävän - hypetetyn - GTD:n hyvä puoli on down-up ajattelu. Eli ei lähdetä jostain suuresta strategisen ajattelun tasosta. Vaan koitetaan tunnistaa välittömiä konkreetteja tekoja ja välivaiheita. Ja pyritään joustavuuteen.
@pe3 jos scrum on yleistymässä, niin kyse on varmaan tuollaisen ketterän, viestintää ja avoimuutta korostavan projektityöskentelyn etujen tunnistamisessa. Tästä aiheestahan oli tarkoitus kutsua joku Reaktor Innovationsin tyyppi kertomaan, sitten kun se somekan avoimuus-seminaari järjestetään...
En yritä olla nokkela, kun heitän, että syy Scrumin yleistymiseen on luultavimmin se, että tekijäpuolella on paljon porukkaa, joille Scrum on mielekäs (@akonan'ia lainatakseni) toiminnan muoto.
Eli kiinnostavaa on funtsia minkälaisia tekijäkulttuureita on olemassa. Toiminnan mallit ja työvälineet on melko helppo johtaa näistä.
tämä tulee melko hatusta kyllä... Perinteisessä mallissa projekti ja toteutettava palvelu/tuote/juttu suunnitellaan valmiiksi kattavien käsikirjoitusten avulla. Sitten käsikirjoitusten pohjalta tarvittavat työvaiheet toteutetaan oikeaan aikaan siten, että homma etenee kohti lopputulostaan käsikirjoitusten mukaan. Ongelmaksi muodostuvat kaikki muutokset ja yllätävät käänteet, joita ei olla ennakoitu. Scrum / ketterät menetelmät muodostuvat lyhyistä iteraatioista, jotka aina suunnitellaan erikseen. Iteraation päätteeksi voidaan tarkastella etenemistä ja tehdä korjaavia liikkeitä porjektin kulkuun. Myös viestintää korostetaan näissä malleissa...
@pe3, mä heittäisin että scrum on yleistynyt (verrattuna muihin "ketteriin" prosessimalleihin) koska se on yksinkertainen ja soveltuu monenlaisiin projekteihin. Periaatteet oppii helposti ja mun mielestä scrum on mukava tapa työskennellä.
@linkola selvensi jo hyvin! Lisäisin vielä, että pohjalla oleva ero on siinä, että Scrumissa tunnustetaan, ettei tiedetä mitä ollaan rakentamassa vs. perinteinen malli jossa luullaan, että tiedetään mitä ollaan rakentamassa. Tämä myös iteraation sisällä - ikinä ei tiedetä kuinka kauan johonkin oikeasti tulee menemään aikaa / onko se edes mahdollista.
Yhdyn tuohon @vesan kommenttiin. Se mitä olen kuullut tyypeiltä, joiden työpaikoilla on siirrytty Scrumiin, on juuri tuo että se on yksinkertainen ja helppo ottaa käyttöön.
@pe3 jos nyt vaikka miettii Fooga-projektia, niin sen suunnitteleminen ja käsikirjoittaminen siten, että kaikki osapuolet olisivat käsikirjoitusten pohjalta voineet toteuttaa oman osansa, olisi ollut melkoinen ihme.
Sanottakoon, että moni Scrum-käyttöönotto menee myös persiilleen. Usein syyt ovat ettei johto oikeasti sitoudu muutokseen tai että otetaan käyttöön vain mielekkäät osat Scrumia. Scrum-prosessia voi muokata organisaatioonsa sopivaksi, mutta sitä ennen olisi hyvä ymmärtää alkuperäisen prosessin toimintapa. Yleensä suositellaan, että organisaatio käyttäisi Scrumia muuntamattomana 1-2kk.
@linkola: Foogahan eli ainakin kevätkesällä kutakuinkin jatkuvasti, joten sen käsikirjoittaminen etukäteen olisi ollut ainakin siinä vaiheessa mahdotonta. Vai olenko täysin väärässä/pihalla?
Jos miettii esimerkiksi verkkopalvelu- tms. tietojärjestelmäprojekteja niin erona on varmaan myös että perinteisessä vaatimusmäärittely - projektin suunnittelu ja hallinta sen pohjalta -kuviossa pystytään melko tarkasti (ainakin periaatteessa) arvioimaan kustannukset, jos kaikki osapuolet sitoutuvat pysyttelemään alun perin määrittelyissä vaatimuksissa. Samalla sitoudutaan siihen että iteraatiotarpeet (joita aina tulee) vain kirjataan ylös ja hoidetaan seuraavan kehitysprojektin aikana.
Puhtaassa ketterässä mallissa taas kirjoitetaan tavallaan avoin shekki jos sitoudutaan siihen että iterointia voi tapahtua vapaasti (tai vaihtoehtoisesti otetaan se riski että projektin päätyttyä = rahan loputtua ei olekaan käsissä valmista tuotetta). Ellei sitten iterointia alisteta johonkin tavoitekehykseen.
Menin vähän ohi alkuperäisestä kysymyksestä, ei valitettavasti oo niin paljoa kokemusta/kontakteja ketteristä kehitysmalleista että pystyisin olemaan oikeasti avuksi. Tollasesta kirjasta pohdin itse että voisin tilata niinku perusteokseksi aiheesta:
http://www.amazon.com/Agile-Software-Development-Ecosystems/dp/0201760436/ref=si3rdrbb_product
Juuri tuota Scrumin avoin shekki myyntitapaa yritetään tässä oman yrityksen kanssa haastaa rankalla tuotteistuksella. Kiinteät hinnat, kiinteät resurssit, kiinteät aikataulut, mutta muuttuva scope. Scrumin ideana on myös tuottaa jokaisena ajan hetkenä eniten arvoa tuottavat ominaisuudet - tämä taas istuu tuohon hienosti. Asiakas saa aina parasta vastinetta rahalle.
Joo niin just, toi kuulostaa asiakasnäkökulmasta just järkevältä tavalta ratkoa tota. Eli että Scrum on tavallaan sisäinen projektimalli ja hyödyttää asiakasta mutta ei tavallaan riskeeraa mitään sinne päin.
@akonan: en varsinaisesti, mut sen sijaan koitan miettiä meille (NK) tekemisen runkoja. Meidän perusprosessi on hämmästyttävän paljon GTD-workflow'n tyylinen kyllä.
hei @akonan ja @samin ja @kaikki tuleeko teille mieleen mitään yhteisoppimisprosesseja, joita wikiopistossa voisi työstää? gtd-elämääsi "opintopiiri" :-)
Ei vaan. "Miten epäonnistua tässä kyseisesä proggiksessa täysin, nopeiten ja isoiten"-projisointi vois auttaa. Me käytetään sitä joskus fokusoinnin apuna.
31 comments so far
Löytyykö teknistä osaamista tai oppia kevyestä projektinhallinnasta tai tuttuja auttamaan?
1 year, 7 months ago by pe3
@pe3, missä mielessä? Varmaan useimmat Jaikun 'perusverkostostamme' ovat törmänneet ao. käsitteeseen työ- ja vapaa-aikana. Netti on valtoimenaan mainioita perustiivistelmiä ja oppaiksi asti, niihin voinee viitata suoraan ensi alkuun. Viidestä vaiheesta eli projektin pilkkomisesta kannattanee aloittaa. Sekä critical pathista.
1 year, 7 months ago by ubiq
Yllättäen WP auttaa taas alkuun http://fi.wikipedia.org/wiki/Projektinhallinta ja lopun linkit.
1 year, 7 months ago by ubiq
Kiitti linkistä @ubiq. Se auttoi mua tajuamaan, että kaipaisin tähän mielummin ketterän koulukunnan juttuja. Okei klassisesta projektinhallinnasta on varmaan hyvä tietää jotkin peruskäsitteet, kuten kriittinen polku.
Klassisen koulukunnan mallit taitaa olla sidoksissa top-down meininkiin. Haluisin tähän parvimaisemman vellovan vapaaehtoisprojektin näkökulmaa. Down-up.
1 year, 7 months ago by pe3
Paljon tunteita herättävän - hypetetyn - GTD:n hyvä puoli on down-up ajattelu. Eli ei lähdetä jostain suuresta strategisen ajattelun tasosta. Vaan koitetaan tunnistaa välittömiä konkreetteja tekoja ja välivaiheita. Ja pyritään joustavuuteen.
1 year, 7 months ago by pe3
Esimerkit projektinhallinnasta Mediawikillä olis hyviä. Kuinka vaikka toteuttaa issue tracker.
1 year, 7 months ago by pe3
Tuolla oli hyvää juttua itseorganisoituvuudesta. Etsitään itseorganisoituvuuteen perustuvaa projektinhallintaa ja käsitystä organisaatiosta.
1 year, 7 months ago by pe3
Mistä on kyse Scrum-menetelmän jatkuvassa yleistymisessä?
1 year, 7 months ago by pe3
@pe3 jos scrum on yleistymässä, niin kyse on varmaan tuollaisen ketterän, viestintää ja avoimuutta korostavan projektityöskentelyn etujen tunnistamisessa. Tästä aiheestahan oli tarkoitus kutsua joku Reaktor Innovationsin tyyppi kertomaan, sitten kun se somekan avoimuus-seminaari järjestetään...
1 year, 7 months ago by linkola
@pe3: Scrumin yleistymiseen on varmasti monia syitä. Se on mielekästä, realistista ja tuloksellista. Fiksu tapa tehdä asioita.
1 year, 7 months ago by akonan
En yritä olla nokkela, kun heitän, että syy Scrumin yleistymiseen on luultavimmin se, että tekijäpuolella on paljon porukkaa, joille Scrum on mielekäs (@akonan'ia lainatakseni) toiminnan muoto.
Eli kiinnostavaa on funtsia minkälaisia tekijäkulttuureita on olemassa. Toiminnan mallit ja työvälineet on melko helppo johtaa näistä.
1 year, 7 months ago by tommi
Hei verratkaas vähän Scrummia perinteiseen projektijohtamiseen? Mitkä on niiden kummankin taustaoletukset?
1 year, 7 months ago by pe3
tämä tulee melko hatusta kyllä... Perinteisessä mallissa projekti ja toteutettava palvelu/tuote/juttu suunnitellaan valmiiksi kattavien käsikirjoitusten avulla. Sitten käsikirjoitusten pohjalta tarvittavat työvaiheet toteutetaan oikeaan aikaan siten, että homma etenee kohti lopputulostaan käsikirjoitusten mukaan. Ongelmaksi muodostuvat kaikki muutokset ja yllätävät käänteet, joita ei olla ennakoitu. Scrum / ketterät menetelmät muodostuvat lyhyistä iteraatioista, jotka aina suunnitellaan erikseen. Iteraation päätteeksi voidaan tarkastella etenemistä ja tehdä korjaavia liikkeitä porjektin kulkuun. Myös viestintää korostetaan näissä malleissa...
1 year, 7 months ago by linkola
@pe3, mä heittäisin että scrum on yleistynyt (verrattuna muihin "ketteriin" prosessimalleihin) koska se on yksinkertainen ja soveltuu monenlaisiin projekteihin. Periaatteet oppii helposti ja mun mielestä scrum on mukava tapa työskennellä.
1 year, 7 months ago by vesan
@linkola selvensi jo hyvin! Lisäisin vielä, että pohjalla oleva ero on siinä, että Scrumissa tunnustetaan, ettei tiedetä mitä ollaan rakentamassa vs. perinteinen malli jossa luullaan, että tiedetään mitä ollaan rakentamassa. Tämä myös iteraation sisällä - ikinä ei tiedetä kuinka kauan johonkin oikeasti tulee menemään aikaa / onko se edes mahdollista.
1 year, 7 months ago by akonan
Yhdyn tuohon @vesan kommenttiin. Se mitä olen kuullut tyypeiltä, joiden työpaikoilla on siirrytty Scrumiin, on juuri tuo että se on yksinkertainen ja helppo ottaa käyttöön.
1 year, 7 months ago by kaikousa
@pe3 jos nyt vaikka miettii Fooga-projektia, niin sen suunnitteleminen ja käsikirjoittaminen siten, että kaikki osapuolet olisivat käsikirjoitusten pohjalta voineet toteuttaa oman osansa, olisi ollut melkoinen ihme.
1 year, 7 months ago by linkola
Sanottakoon, että moni Scrum-käyttöönotto menee myös persiilleen. Usein syyt ovat ettei johto oikeasti sitoudu muutokseen tai että otetaan käyttöön vain mielekkäät osat Scrumia. Scrum-prosessia voi muokata organisaatioonsa sopivaksi, mutta sitä ennen olisi hyvä ymmärtää alkuperäisen prosessin toimintapa. Yleensä suositellaan, että organisaatio käyttäisi Scrumia muuntamattomana 1-2kk.
1 year, 7 months ago by akonan
@linkola: Foogahan eli ainakin kevätkesällä kutakuinkin jatkuvasti, joten sen käsikirjoittaminen etukäteen olisi ollut ainakin siinä vaiheessa mahdotonta. Vai olenko täysin väärässä/pihalla?
1 year, 7 months ago by MjL
Jos miettii esimerkiksi verkkopalvelu- tms. tietojärjestelmäprojekteja niin erona on varmaan myös että perinteisessä vaatimusmäärittely - projektin suunnittelu ja hallinta sen pohjalta -kuviossa pystytään melko tarkasti (ainakin periaatteessa) arvioimaan kustannukset, jos kaikki osapuolet sitoutuvat pysyttelemään alun perin määrittelyissä vaatimuksissa. Samalla sitoudutaan siihen että iteraatiotarpeet (joita aina tulee) vain kirjataan ylös ja hoidetaan seuraavan kehitysprojektin aikana.
Puhtaassa ketterässä mallissa taas kirjoitetaan tavallaan avoin shekki jos sitoudutaan siihen että iterointia voi tapahtua vapaasti (tai vaihtoehtoisesti otetaan se riski että projektin päätyttyä = rahan loputtua ei olekaan käsissä valmista tuotetta). Ellei sitten iterointia alisteta johonkin tavoitekehykseen.
1 year, 7 months ago by totoroki
Menin vähän ohi alkuperäisestä kysymyksestä, ei valitettavasti oo niin paljoa kokemusta/kontakteja ketteristä kehitysmalleista että pystyisin olemaan oikeasti avuksi. Tollasesta kirjasta pohdin itse että voisin tilata niinku perusteokseksi aiheesta: http://www.amazon.com/Agile-Software-Development-Ecosystems/dp/0201760436/ref=si3rdrbb_product
1 year, 7 months ago by totoroki
Juuri tuota Scrumin avoin shekki myyntitapaa yritetään tässä oman yrityksen kanssa haastaa rankalla tuotteistuksella. Kiinteät hinnat, kiinteät resurssit, kiinteät aikataulut, mutta muuttuva scope. Scrumin ideana on myös tuottaa jokaisena ajan hetkenä eniten arvoa tuottavat ominaisuudet - tämä taas istuu tuohon hienosti. Asiakas saa aina parasta vastinetta rahalle.
1 year, 7 months ago by akonan
Ai nyt vasta okeastaan hogasin koko Wikiopiston! Ässää, tuolle kurssille haluan osallistua!
1 year, 7 months ago by totoroki
Mun medianomi-opinnäytetyö liippaa myös tätä aihetta. Siellä on haettu mallia 37Signalsin Getting Realista.
1 year, 7 months ago by linkola
Joo niin just, toi kuulostaa asiakasnäkökulmasta just järkevältä tavalta ratkoa tota. Eli että Scrum on tavallaan sisäinen projektimalli ja hyödyttää asiakasta mutta ei tavallaan riskeeraa mitään sinne päin.
1 year, 7 months ago by totoroki
Toi GTD vaikuttaa mielenkiintoiselta. Tuntuis olevan paljon yhtymäkohtia luovan työn intuitiiviseen tekemiseen.
1 year, 7 months ago by samin
@samin: "luovan työn intuitiiviseen tekemiseen" käytätkö tähän jotain tiettyä metodia tms? GTD ja OmniFocus rocks! Paaaaljon vähemmän stressiä :)
1 year, 7 months ago by akonan
@akonan: en varsinaisesti, mut sen sijaan koitan miettiä meille (NK) tekemisen runkoja. Meidän perusprosessi on hämmästyttävän paljon GTD-workflow'n tyylinen kyllä.
1 year, 7 months ago by samin
hei @akonan ja @samin ja @kaikki tuleeko teille mieleen mitään yhteisoppimisprosesseja, joita wikiopistossa voisi työstää? gtd-elämääsi "opintopiiri" :-)
1 year, 7 months ago by pe3
@pe3: ööö, simuloitu SNAFU-prosessi? :)
Ei vaan. "Miten epäonnistua tässä kyseisesä proggiksessa täysin, nopeiten ja isoiten"-projisointi vois auttaa. Me käytetään sitä joskus fokusoinnin apuna.
1 year, 7 months ago by samin
@pe3 mulla lyö tyhjää.. sori! Huutelen jos tulee mieleen :)
1 year, 7 months ago by akonan