Ketterän manifestin selitys ja sen soveltaminen

Mikä on ketterän kehityksen manifesti?

Ketterän kehityksen manifesti on kirjallinen julistus, joka sisältää neljä arvoa ja 12 periaatetta, joiden tarkoituksena on parantaa työskentelytapoja ohjelmistokehityksessä.

Manifesti oli enemmän filosofinen kuin ohjeistava, ja sen oli tarkoitus mukautua erikokoisiin tiimeihin, erilaisiin tavoitteisiin ja erilaisiin olosuhteisiin.

Ketterän kehityksen manifestin 4 arvoa

Virallinen ketterän kehityksen manifesti koostuu näistä neljästä arvosta:

1. Yksilöt ja vuorovaikutus prosessien ja työkalujen sijaan
2. Toimiva ohjelmisto kattavan dokumentaation sijaan
3. Yhteistyö asiakkaan kanssa sopimusneuvottelujen sijaan
4. Muutokseen reagoiminen suunnitelman noudattamisen sijaan

On kiinnostavaa huomata, että kirjoittajat seurasivat arvoja tällä selventävällä lausumalla: "Toisin sanoen, vaikka oikealla olevilla asioilla on arvoa, arvostamme vasemmalla olevia asioita enemmän."

Tämä korostaa ajatusta siitä, että ketterän kehityksen manifestissa ei ole kyse tietyn prosessin noudattamisesta tai tietyn ketterän työkalun käyttämisestä. Kyse on tietyn ajattelutavan omaksumisesta.

Ketterän kehityksen manifestin 12 periaatetta

Neljän arvon lisäksi ketterän kehityksen manifesti sisältää 12 niitä tukevaa periaatetta, jotka selittävät, miten arvoja tulkitaan ja sovelletaan ketterissä projekteissa.

1. Aseta asiakas etusijalle

Tärkein tavoite on asiakkaan tyytyväisyyden varmistaminen toimittamalla arvokasta ohjelmistoa varhain ja jatkuvasti.

2. Toivota muutos tervetulleeksi

Toivota muuttuvat vaatimukset tervetulleiksi vielä myöhäisessäkin kehitysvaiheessa. Ketterät prosessit hyödyntävät muutosta asiakkaan kilpailuedun saavuttamiseksi.

3. Toimita usein

Toimita toimivaa ohjelmistoa usein, muutaman viikon tai muutaman kuukauden välein, mutta suosi lyhyempää aikaväliä.

4. Tee yhteistyötä tiimien välillä

Liiketoiminnan edustajien ja kehittäjien on työskenneltävä yhdessä päivittäin koko projektin ajan.

5. Kehitä osaamista

Rakenna projektit motivoituneiden yksilöiden ympärille. Tarjoa heille ympäristö ja tuki, joita he tarvitsevat, ja luota heidän hoitavan työnsä.

6. Keskustele

Tehokkain tapa välittää tietoa kehitystiimille ja sen sisällä on kasvokkain käytävä keskustelu.

7. Mittaa sitä, millä on merkitystä

Toimiva ohjelmisto on edistymisen ensisijainen mittari.

8. Rytmitä työ uupumisen välttämiseksi

Ketterät prosessit edistävät kestävää työskentelyä. Rahoittajien, kehittäjien ja käyttäjien pitäisi pystyä ylläpitämään tasaista työtahtia loputtomasti.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

9. Keskity laatuun, niin työ etenee nopeammin

Jatkuva huomion kiinnittäminen tekniseen erinomaisuuteen ja hyvään suunnitteluun lisää ketteryyttä.

10. Suosi yksinkertaisuutta

Yksinkertaisuus – tekemättä jätettävän työn määrän maksimoinnin taito – on olennaista.

11. Älä johda liian yksityiskohtaisesti

Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoituvissa tiimeissä.

12. Pohdi ja mukauta

Tiimi pohtii säännöllisin väliajoin, miten se voisi toimia tehokkaammin, ja hienosäätää sekä mukauttaa toimintaansa sen mukaisesti.

Ketterän kehityksen manifestin historia, laatijat ja syntytarina

Teknologiamaailmassa ketterän kehityksen manifestista keskustellaan samalla kunnioituksella ja epäkunnioituksella kuin mistä tahansa ajan kuluessa periytyneestä pyhästä tekstistä.

Helmikuussa 2001 17 ohjelmistoalan ammattilaista, jotka kutsuivat itseään nimellä ”The Agile Alliance”, kokoontui Yhdysvaltojen Utahin osavaltioon laatimaan asiakirjaa, jota he kutsuivat nimellä ”Manifesto for Agile Software Development”. Neljä arvoa ja 12 periaatetta sisältävä asiakirja tunnetaan nykyään ketterän kehityksen manifestina.

Ketterän kehityksen manifestin laatijoihin viitataan usein nimellä The Agile Alliance, ja heihin kuului edustajia useista kehitysprosesseista, kuten extreme-ohjelmoinnista, Scrumista ja Crystalista. 

Manifestin virallisella verkkosivustolla julkaistu nopea katsaus esittelee laatijat ympäristössä, joka saattaa tuoda mieleen salaseuran tai perustajaisien tapaamisen. Oli selvää, että heidän tarkoituksensa oli luoda jotakin, joka jättäisi alalle pysyvän vaikutuksen. Niin on myös käynyt.

Vaikka Utahissa kokoontuneet henkilöt eivät olleet ketterien periaatteiden yleisiä edelläkävijöitä, he vahvistivat arvot, jotka olivat kehittyneet jo jonkin aikaa ohjelmistokehitysmaailman taustalla.

Nykyään ketterä menetelmä on levinnyt lähes kaikille toimialoille.

Laatijoihin kuuluivat:

• Kent Beck
• Mike Beedle
• Arie van Bennekum
• Alistair Cockburn
• Ward Cunningham
• Martin Fowler
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick
• Robert C. Martin
• Steve Mellor
• Ken Schwaber
• Jeff Sutherland
• Dave Thomas

Miksi ketterän kehityksen manifesti on yhä tärkeä

Ketterän kehityksen manifesti on edelleen ajankohtainen, koska siinä keskitytään ihmiskeskeisiin työskentelytapoihin ja sallitaan joustavuus.

Nopeisiin teknologisiin muutoksiin liittyy usein projektin vaatimusten muuttuminen. Ketterän kehityksen manifesti auttaa projektipäälliköitä asettamaan mukautuvuuden ja yhteistyön etusijalle luomalla reagoivan ja sopeutumiskykyisen projektiympäristön, jossa voidaan samanaikaisesti toteuttaa työtä, innovoida ja vaihtaa suuntaa tarvittaessa.

Se edistää myös asiakaskeskeistä ajattelutapaa arvottamalla toimivia ratkaisuja kattavan dokumentaation sijaan. Näin projektipäälliköt voivat kerätä palautetta varhaisessa vaiheessa ja kehittää työtään jatkuvasti varmistaen, että projekti vastaa tiiviisti käyttäjien tarpeita. Tämä iteratiivinen ja asiakaslähtöinen lähestymistapa parantaa projektien onnistumisastetta ja tyytyväisyyttä.

Näin sovellat ketterän kehityksen manifestia

Syvennytään hieman tarkemmin ketterän manifestin neljään arvoon. Käymällä läpi perusarvot tarkastelemme samalla 12 periaatetta, jotka täydentävät kutakin niistä.

Arvo 1: Yksilöt ja vuorovaikutus prosessien ja työkalujen edelle

Ketteryyden ytimessä ovat ihmiset. Ketterässä toimintatavassa korostetaan, että tiimi työskentelee yhdessä, tekee tiivistä yhteistyötä ja tekee päätöksiä itsenäisesti. Ketterässä toimintatavassa ei ole kyse siitä, että tiimille kerrotaan, mitä sen tulee tehdä tai rakentaa. 

Ketterissä projekteissa viestinnän on oltava vapaasti kulkevaa ja jatkuvaa, ei ennalta määriteltyä ja aikataulutettua. Eristäytyneissä siiloissa työskentely ei kuulu ketterään toimintatapaan.

Arvioi tiimin viestintää

Kysy itseltäsi: käytkö sinä ja tiimisi kasvokkain keskusteluja? Vai luotatteko sähköposteihin, asiakirjoihin ja tiettyihin suuresti rakastettuihin viestintätyökaluihin (nimiä mainitsematta)? 

Vaikka työskentelisit etänä, kasvokkain käytävä keskustelu voi nopeuttaa asioiden etenemistä. Erityisesti uuden tiimin muodostuessa samanaikainen viestintä kannustaa luottamukseen ja avoimuuteen sekä auttaa rakentamaan suhteita.

Älä kontrolloi liikaa

Olemme kaikki joskus syyllistyneet tähän. Mutta luottamus on olennainen osa ketteryyttä. Etsitkö jotakin, jonka voit ottaa heti käyttöön? ÄLÄ HALLINNOI PIENINTÄKIN YKSITYISKOHTAA (kyllä, tarkoitin tuon huutaa).

On houkuttelevaa pilkkoa tehtävät yksityiskohtaisesti, jakaa ne tiimille ja seurata niitä siihen asti, että asetettu määräaika saavutetaan (tai ei saavuteta), jotta voit hallita kaikkea. Mutta jotta tiimisi voisi todella toimia itsenäisesti, sinun on astuttava hieman taaksepäin ja annettava heidän ottaa vastuu työstään!

Kannusta itseorganisoituvaa tiimiä

Kyse ei ole hallinnasta vaan johtamisesta ja työn mahdollistamisesta. Itseorganisoituva tiimi tarkoittaa tiimiä, joka päättää, miten työnsä kannattaa parhaiten toteuttaa. Sen tulisi päättää, miten työjonossa oleva työ muutetaan julkaistavaksi koodiksi. Älä kuitenkaan mene toiseen ääripäähän ja jätä kaikkea apua tai ohjausta pois – tiimi tarvitsee edelleen vision, motivaatiota ja apua esteiden ratkaisemiseen.

Miten siis voit luopua tehtävien jakamisesta ja sen sijaan selvittää, miten voit helpottaa työn tekemistä?

Älä stressaa prosessista tai työkalusta

Tiedän, tiedän – puhe projektinhallintatyökaluista ja ketterästä projektinhallintaohjelmistosta on ketterän projektinhallinnan maailmassa jatkuvasti läsnä.

Mutta tässä on asian ydin: asiakkaasi ei välitä sisäisestä ketterästä työnkulkuprosessistasi. Eikä hänen pidäkään välittää.

Ketteryydessä on kyse asiakaslähtöisestä toimintatavasta ja siitä, että tiimisi voi tuottaa parempaa ja arvokkaampaa työtä. Palaamme asiakaslähtöiseen toimintatapaan myöhemmin!

Poista siilot

Siilot haittaavat yhteistyötä ja ovat siksi ristiriidassa ketterien arvojen kanssa. 

Voit siirtyä pois siiloista seuraavien vinkkien avulla:

• Sijoita tiimi samaan paikkaan: Kyllä, tämä vielä kerran. On hienoa, jos suunnittelijasi voivat istua lähekkäin ja keskustella suunnitteluun liittyvistä asioista, mutta eikö olisi vielä parempi, jos he keskustelisivat kehittäjien kanssa tämän hienon tuotteen rakentamisesta? Tiedän, että tämä voi olla vaikea toteuttaa suuressa organisaatiossa tai etäympäristöissä, mutta jopa kokoontuminen yhteiseen Slack-kanavaan tai sovittujen yhteisten työskentelytuokioiden järjestäminen, joissa ihmiset voivat tehdä syvällistä työtä samanaikaisesti ja etänä, voi pitää tiimisi paremmin yhteydessä toisiinsa.
• Vältä osastojen välisiä luovutuksia: Tiukemmin vaiheittain etenevä vesiputousmallinen lähestymistapa, jossa kukin osasto työskentelee omassa vaiheessaan (UX, sitten suunnittelu, sitten kehitys ja lopuksi QA), voi usein aiheuttaa viestintäkatkoksia ja lisätä projektin hukkaa. Harkitse, että tiimi työskentelee ominaisuuksien parissa yhdessä sen sijaan, että työ siirrettäisiin ketjussa osastolta toiselle. Vaikka työskentelisitte sprinteissä ja aloittaisitte suunnittelusprintillä, ota kehittäjät mukaan suunnittelusprinttiin – hehän tulevat rakentamaan tämän kaiken jälkeen!

Arvo #2: Toimiva ohjelmisto kattavan dokumentaation sijaan

Muista, ettei manifestissa sanota, että dokumentaatiosta pitäisi luopua – siinä vain arvostetaan vasemmalla olevia asioita enemmän kuin oikealla olevia. Dokumentaatiota siis tarvitaan edelleen. Esimerkiksi Scrumissa käytetään käyttäjätarinoita kertomaan kehittäjälle, miten toteutus voidaan aloittaa.

Mitä voit kuitenkin tehdä siirtyäksesi pois raskaasta ja aikaa vievästä dokumentaatiosta ja päästäksesi nopeasti konkreettisen tekemisen pariin?

Sujuvoita käyttämääsi dokumentaatiota

Tunnista prosessisi kipukohdat tai esteet. Käytätkö liikaa aikaa dokumentointiin? Käytätkö ikuisuuden täydellisen vaatimusasiakirjan laatimiseen, kulutatko valtavasti aikaa toiminnallisen laajuuden määrittelyyn ja huomaatko sitten, ettei tuotteen rakentamiseen jää aikaa? Vähennä tarpeetonta dokumentaatiota seuraavasti:

• Keskittymällä suunnittelu- ja kehitystehtäviin, jotka edistävät itse tuotteen rakentamista, sen sijaan että keskittyisit kirjalliseen dokumenttiin, jota ei lopulta käytetä
• Järjestämällä heti alussa työpajoja vaatimusten ja seuraavien vaiheiden määrittämiseksi pitkien asiakirjojen kirjoittamisen sijaan. Dokumentoi ja jaa tulokset valokuvien ja lyhyiden muistiinpanojen avulla.

Siirry nopeasti toteutukseen

Laajojen vaatimusasiakirjojen kirjoittaminen on yksi tapa kartoittaa liiketoiminnan, asiakkaan ja loppuasiakkaan tarpeet. Viime kädessä on kuitenkin paljon hyödyllisempää nähdä jotakin toiminnassa, käyttäytymässä ja reagoimassa.

Harkitse seuraavia tapoja viedä projektiasi nopeasti eteenpäin:

• Tiivistä projektin alussa tehtävä selvitys tai määrittely lyhyempään aikatauluun: Kun rajoitat määrittelyyn ja asioiden selvittämiseen käyttämääsi aikaa, pääset nopeammin tilanteeseen, jossa suunnittelijat ja kehittäjät voivat tarttua työhön. Voit nopeuttaa prosessia näiden selvitysvaiheen kysymysten avulla.
• Järjestä työpajoja: Tiimityöpajojen järjestäminen tuo sidosryhmät yhteen, jotta päätökset voidaan tehdä nopeammin.
• Muuta projektisuunnitelmaasi: Oletko jaksottanut määrittelyn, sitten suunnittelun ja lopuksi kehityksen? Harkitse kehityksen aikaistamista ja sitä, että suunnittelijat ja kehittäjät tuottavat jotakin yhdessä aiemmin.

Käytä prototypointimenetelmiä litteiden suunnitelmien sijaan

Sen sijaan että näkisit edistymisen määrittelydokumenttina tai litteänä suunnitelmana, joka toimii asiakkaan hyväksyntää odottavana valintaruutuna, näytä heille jotain, josta tulee osa valmista tuotetta.

Käytä nopeaa prototypointia saadaksesi aikaan jotain toimivaa ja käyttökelpoista – ja mikä vielä tärkeämpää, jotain, jota voit testata asiakkaiden kanssa. Prototyypistä kerätty palaute on hyödyllinen tapa seurata edistymistä sen sijaan, että luotettaisiin toimitukseen, josta puuttuu se hyöty, että se olisi osa lopullista tuotetta.

Voit luoda prototyyppejä eri tarkkuustasoilla:

• Matala tarkkuus: Napsautettavat suunnitelmat. Näitä käytetään, kun jotain täytyy saada nopeasti hahmoteltua asiakkaiden kanssa testaamista varten – kyse on enemmän ulkoasun, tuntuman ja yksinkertaisten vuorovaikutusten testaamisesta.
• Keskitasoinen tarkkuus: Liikkeen tai animaation käyttäminen.
• Korkea tarkkuus: Toimiva HTML. Käytetään monimutkaisiin vuorovaikutuksiin, mutta sen voi viedä eteenpäin julkaistavaksi koodiksi.

Korkean tarkkuuden prototyypit ovat lähempänä ”toimivaa ohjelmistoa” kuin muut tyypit, mutta niiden tuottaminen voi viedä enemmän aikaa. Matalan tai keskitasoisen tarkkuuden prototyypit tarjoavat kehittäjille parempia ohjeita kuin litteät suunnitelmat.

Toimita jotain nopeasti loppukäyttäjälle tai asiakkaalle

Tämä on tärkeä asia.

Kun toimivaa ohjelmistoa julkaistaan usein, asiakas voi käyttää kaikkia uusia julkaistuja ominaisuuksia. Sen sijaan että odotettaisiin projektin loppuun asti yhtä suurta julkaisua, arvon tuottaminen asiakkaalle nopeammin on ratkaisevan tärkeää paremman tuotteen saavuttamiseksi.

Miten organisaatiosi voisi saavuttaa tiheämmän toimitustahdin?

• Tarkista projektisuunnitelmasi tai projektin etenemissuunnitelma: Oletko suunnitellut kehitystyön valmistuvan ja julkaisun tapahtuvan projektin lopussa? Työskentele sen sijaan tiimisi kanssa jakaaksesi työn ominaisuuksiin tai työkokonaisuuksiin, jotka voidaan julkaista itsenäisesti projektin aikana.
• Keskity esteisiin: Olennainen osa tehtävääsi on auttaa poistamaan tiimin työn esteitä ongelmien ilmetessä. Miten voit auttaa heitä toimittamaan tehokkaammin? Hidastavatko jotkin työskentelytavat julkaisuja? Sprintin retrospektiivin pitäminen tiimisi kanssa voi paljastaa mahdollisuuksia prosessien parantamiseen.
• Automatisoi: Jos organisaatiosi käyttää julkaisuihin valtavasti vaivaa, automatisoi prosesseja aina kun mahdollista. Esimerkiksi automaattinen testaus ja käyttöönotto voivat säästää manuaalista työtä ja vähentää julkaisuun tarvittavaa työmäärää. Keskustele ketterän kehitystiimisi kanssa heidän käyttämistään prosesseista ja automatisointimahdollisuuksista.

Arvo #3: Yhteistyö asiakkaan kanssa sopimusneuvottelujen sijaan

Sen sijaan että laatisit projektin alussa erittäin yksityiskohtaisen sopimuksen, jossa määritellään tarkat toimitukset, laajuus, budjetti ja aikataulut, pidä ketterä sopimuksesi mahdollisimman yleisellä tasolla. Tee päätöksiä projektin aikana tekemällä tiivistä yhteistyötä asiakkaidesi ja sidosryhmiesi kanssa.

Ketterässä toimintatavassa ei ole kyse siitä, että käytetään valtavasti aikaa vaatimusten määrittelyyn etukäteen. Kyse on projektin aloittamisesta ja oppimisesta matkan varrella asiakkaiden testausten ja toimivasta ohjelmistosta saadun palautteen perusteella.

Omaksu asiakaslähtöinen lähestymistapa

Pidän tästä Neil Killickin artikkelista peräisin olevasta lainauksesta:

”Ketterästi ajatteleva kysyy jatkuvasti: ’Mikä on yksinkertaisin ja nopein tapa tuottaa arvoa asiakkaalle?’ Esitätkö tämän kysymyksen päivittäin? Jos et, siinä on ensimmäinen askeleesi.”

Tätä eivät saa ajatella vain suunnittelijat ja kehittäjät – myös projektipäälliköiden pitäisi. Me vastaamme myös siitä, että asiakkaalle toimitetaan paras mahdollinen tuote tai palvelu. Asiakkaasi, tuotteesi tai palvelusi käyttäjän, tulisi olla kaiken tekemäsi keskiössä.

Aseta loppuasiakas suunnitelman keskiöön

Sen sijaan että suunnittelisit toimitusten ja arvioiden ympärille, suunnittele asiakkaalle arvokkaiden lopputulosten ympärille. Mitä haluamme asiakkaan tekevän ja miksi? Miten mittaamme, että tämä toimii?

Muotoile keskustelu uudelleen keskittymään siihen, kuinka paljon arvoa olemme tuottaneet asiakkaalle, sen sijaan että keskittyisimme toimitettujen työtehtävien määrään.

Ota asiakkaasi tiiviisti mukaan

Sen sijaan että pitäisit viikoittaisen tilannekatsauksen ja toimittaisit sitten työn asiakkaallesi ja sidosryhmillesi tietyn ajanjakson lopussa, pyri ottamaan asiakkaasi mukaan projektiin päivittäin.

Jos käytät enemmän Scrum-prosessia, tee asiakkaasta tuoteomistaja. Tuoteomistaja vastaa liiketoiminnan, teknisten ja asiakkaan vaatimusten kokoamisesta yhteen. Asiakkaan sitoutumisen ja yhteistyön saavuttaminen varhaisessa vaiheessa ja säännöllisesti on ratkaisevan tärkeää viivästysten välttämiseksi. Tämä tuottaa lopulta paremman tuotteen tai palvelun loppuasiakkaalle.

Ota etäinen asiakas mukaan

Jos asiakkaallasi ei ole aikaa osallistua projektiin tai hän ei muuten ole aktiivisesti mukana, varmista, että joku tiimin jäsen edustaa asiakasta. On ratkaisevan tärkeää, että joku huomioi asiakkaan ja liiketoiminnan tarpeet.

Vaikka asiakas ei osallistuisi päivittäiseen toimintaan, varmista, että viestit hänen kanssaan säännöllisesti ja otat hänet vähintään mukaan kaikkiin ketterän suunnittelun ja priorisoinnin keskusteluihin. Työskentele hänen kanssaan osoittaaksesi osallistumisen hyödyt.

Ota käyttöön tuotteen tiekartta

Harkitse tuotteen tiekartan käyttämistä tuotteesi kehityssuunnan kartoittamiseen. Tuotteen tiekartta viestii tuotetta koskevasta suunnitelmasta ja havainnollistaa toimitettaviksi suunnitellut ominaisuudet. Tiekartta ei ole projektin alussa kiinteä, vaan se kehittyy ajan mittaan prioriteettien muutosten mukaisesti.

Varmista, että keskustelet loppukäyttäjiesi tai asiakkaidesi kanssa

En voi korostaa tätä tarpeeksi – sinun on testattava tuotettasi loppukäyttäjien ja asiakkaiden kanssa varhaisessa vaiheessa ja usein. 

Testaamisesta on monia hyötyjä:

• Voit varmistaa, että tuotteesi vastaa asiakkaiden tarpeita – onko tuote asiakkaalle ja siten myös liiketoiminnalle arvokas? Tämä auttaa arvioimaan tuotteen ja markkinoiden yhteensopivuutta.
• Voit sisällyttää asiakkaiden palautteen suunnittelu- ja kehitysprosessiisi, mikä johtaa parempaan lopputuotteeseen.
• Voit saada oivalluksia, jotka tukevat tulevaa työtä.

• Asiakkaiden testaamiseen usein liittyvä ongelma on budjetti – se voi olla kallista. Tässä on joitakin tapoja testata projektin budjetista riippumatta:

Sissitestaus: Pidän tästä menetelmästä, koska se on halpa ja helppo. Tarjoa ihmisille oikea tai virtuaalinen kahvi, jos he vastaavat muutamaan suunnitelmiasi tai prototyyppiäsi koskevaan kysymykseen. Et voi yhtä tarkasti määritellä, kuka kysymyksiisi vastaa, mutta nopeasta palautteesta voi olla hyötyä ulkoasun, tuntuman tai yksinkertaisten vuorovaikutusten testaamisessa.

Kyselyt: Voit kerätä määrällistä tietoa laajemmalta ihmisjoukolta luomalla kyselyn, jolla arvioidaan suunnittelua tai perehdytään syvällisemmin asiakkaiden käyttäytymiseen.

user testing.comin kaltaiset sivustot: Voit ladata suunnitelmasi jollekin näistä sivustoista ja rekrytoida niiden kautta ihmisiä tarvittaessa määrittämiesi kriteerien perusteella. He käyvät sitten suunnitelmasi läpi napsauttamalla, tallentavat ajatuksiaan ja vastaavat kysymyksiin.

Kasvokkain tehtävä testaus: Kyllä, tämä voi olla kalliimpi vaihtoehto, sillä sinun on todennäköisesti rekrytoitava ihmisiä ja maksettava kannustimia. Se voi kuitenkin olla korvaamatonta, jos testaat monimutkaisia vuorovaikutuksia tai suuren riskin ominaisuuksia.

Arvo nro 4: Muutoksiin vastaaminen suunnitelman noudattamisen sijaan

Ketterät ja vesiputousprojektit eivät voisi tässä suhteessa olla erilaisempia. Perinteisissä ohjelmistokehitysprojekteissa vaatimukset, kustannukset ja aikataulut määritetään etukäteen, kun taas ketterä työskentely sallii muutokset ja suhtautuu niihin myönteisesti.

Muutos on hyvä asia! Se ei ole pahasta! Kuinka moni projektisuunnitelma on toteutunut täsmälleen sellaisena kuin loit sen alussa? Veikkaan, ettei kovinkaan moni (olen työskennellyt projektien parissa, joissa projektisuunnitelmaa on iteroitu kymmeniä kertoja).

Suunnitelmat ovat tietyllä hetkellä tehtyjä parhaita arvioita, joita voit tarkentaa edetessäsi – ne eivät kuitenkaan yleensä mahdollista muutoksia. Mitä tapahtuu, jos asiakkaan tarpeet muuttuvat? Liiketoiminta muuttaa suuntaa? Asiakkaasi muuttaa prioriteettejaan? Määritettyä ominaisuutta ei olekaan niin yksinkertaista rakentaa kuin ajattelit.

Ketterissä työskentelytavoissa epävarmuus hyväksytään omaksumalla mukautuva suunnittelutapa, kuten suunnittelupokeri. Esimerkiksi Scrumin arvot edellyttävät, että tiimi suunnittelee työn sprintti kerrallaan. Ennen ajallisesti rajatun työjakson aloittamista ketterät tiimit poimivat tehtäviä työjonosta ja priorisoivat ne kehitystä varten.

Vaikka projektin alussa usein pyritään määrittämään kustannukset, aikataulu ja laajuus tarkasti, kohtaamiesi epävarmuuksien realistisempi huomioiminen johtaa usein paljon parempaan lopputuotteeseen. Viime kädessä tätä sinun, asiakkaasi ja sidosryhmiesi pitäisi toivoa. 

Tässä on joitakin tapoja alkaa huomioida muutokset projekteissasi ja kannustaa suurempaan joustavuuteen:

Luo ”kevyt” suunnitelma sidosryhmien tarpeiden täyttämiseksi

”Mutta me tarvitsemme suunnitelman!”, sidosryhmäsi huutavat. Sen sijaan, että saisit heidät paniikkiin sanomalla: ”Yllätys, suunnitelmaa ei ole!”, luo kevyt julkaisusuunnitelma, joka antaa heille luottamusta hieman vähemmän muodolliseen lähestymistapaan.

Jos harjoitat ketterää projektinhallintaa Scrum-prosesseilla, työjonossasi on priorisoituja ja arvioituja käyttäjätarinoita. Tee yhteistyötä tuoteomistajan kanssa ryhmitelläksesi nämä alustaviksi julkaisuiksi ja sijoita ne tuote-etenemissuunnitelmallesi.

Älä yritä suunnitella kaikkea etukäteen, sillä se kumoaisi Scrum-menetelmän käytön hyödyt. Esittele sidosryhmillesi, mitä suunnittelet ensimmäisissä kahdessa tai kolmessa julkaisussa, ja kerro sitten, että uudelleensuunnittelu on keskeinen osa ketterää työskentelytapaa ja että viestit päivityksistä ja tulevista julkaisuista työn edetessä. Toivottavasti tämä antaa heille tarvittavaa luottamusta!

Totuta tiimi sprinttipohjaiseen lähestymistapaan

Mike Cohn ehdottaa artikkelissaan ”Ketterän prosessin käyttöönotto organisaatiossa”, että tiimejä autetaan siirtymään vähitellen Scrumin käyttöön määrittelemällä joukko sprinttityyppejä, esimerkiksi:

• Prototyypitys
• Vaatimusten keruu
• Analyysi ja suunnittelu
• Toteutus
• Vakauttaminen

Hän kuvailee tässä, miten tämä voi auttaa:

”Työskentelemme sitten tiimien kanssa määritelläksemme tuotokset, jotka syntyvät kustakin sprinttityypistä. Sprinttityyppien käyttö tuo juuri riittävästi muodollisuutta, jotta tiimit näkevät projektin etenemisen selkeämmin. Kun tiimit harjaantuvat ketterän prosessin epämuodollisuudessa, ne luopuvat vähitellen sprinttityyppien käsitteestä.”

Tämä on toinen tapa jäsentää julkaisusuunnitelmaasi. Jos määrität jokaiselle sprintille ”tyypin”, sidosryhmäsi näkevät, miten suunnitelma muotoutuu, eikä sinun tarvitse luvata tiettyjä ominaisuuksia. Tiimisi saa myös paremman käsityksen siitä, mitä se tulee tekemään.

Luovu kiinteistä määräajoista

Jos annat tiimillesi määräajan tai ilmoitat asiakkaallesi kiinteän päivämäärän, kumpikin strategia epäonnistuu väistämättä tai ainakin aiheuttaa matkan varrella stressiä. Luottamuksen rakentaminen sinun, tiimisi ja asiakkaasi tai sidosryhmäsi välille on olennaista, jotta voit osoittaa toimittavasi lopputuotteelle arvoa ja saavasi sen toimitettua loppuasiakkaalle.

Muista, että yrität vähentää useiden tarkistuspisteiden ja hyväksyntöjen tarvetta. Määräaikojen asettaminen projektille ei auta sinua saavuttamaan tätä tavoitetta. Ei myöskään ole hyvä hengittää tiimisi niskaan ja jahdata sitä sen työn vuoksi, jonka se ”lupasi” toimittaa.

Kuten edellä mainitsin, etenemissuunnitelmat ja julkaisusuunnitelmat voivat olla hyvä keino siirtyä pois kiinteisiin päivämääriin perustuvasta lähestymistavasta. Kun sidosryhmät saavat käsityksen siitä, mitä lähitulevaisuudessa julkaistaan, he voivat luottaa siihen, että suunnitelma on olemassa.

Käytä aikaan ja materiaaleihin perustuvaa laajuutta

Jos projektilla on kiinteä hinta ja kiinteisiin toimituksiin perustuva laajuus, sitä on vaikea toteuttaa ketterämmin. Voit ehdottomasti hyödyntää joitakin aiemmin käsittelemiäni tekniikoita, kuten yhteistyöhön kannustavan tiimin mahdollistamista. Mahdollisuutesi vastata muutoksiin ja mukautua niihin, antaa tiimin päättää työskentelykohteistaan tai käyttää asiakaskeskeisempää lähestymistapaa ovat kuitenkin rajalliset.

Työskentele sisäisen tiimisi ja asiakkaan kanssa luodaksesi aikaan ja materiaaleihin perustuvan laajuuden – eli asiakas maksaa tiimistä kiinteiden toimitusten sijaan. Aluksi asiakkaat saattavat hermostua, jos he eivät tiedä tarkalleen, mitä saavat.

Voit lieventää tätä huolta sisällyttämällä laajuuteen julkaisua varten harkittavan toiminta- tai tehtäväjonon. Määritä sopimuksessa, että tiimi suunnittelee työjonon uudelleen ja priorisoi sen yhdessä asiakkaan kanssa projektin edetessä, vaikka kaikkia kohtia ei välttämättä käsitellä.

Muuttuvien prioriteettien ja toimitusten hallinnassa tiimit voivat hyödyntää ketterän hallinnan ohjelmistoja työjononsa jatkuvaan uudelleenpriorisointiin sekä ohjelmistokehityksen yhteistyötyökaluja monialaiseen yhteistyöhön.

Näin et sitoudu kiinteään laajuuteen, mutta asiakkaalla on vähemmän huolia siitä, miltä lopputuote näyttää.

Seuraa edistymistä edelleen

Edistymisen seuraamista ja visualisointia ei hylätä muodollisen projektisuunnitelman puuttuessa. Kun edistyminen pidetään tiimin ja sidosryhmien nähtävillä, et ainoastaan huomaa mahdollisia esteitä ja pullonkauloja, vaan myös pidät sidosryhmät ajan tasalla. 

Kanban-tyylinen WIP-taulu tai ketterät koontinäytöt toimivat hyvin ketterissä projekteissa. Kun olet visualisoinut prosessisi, voit alkaa hahmotella sitä tukevia tehtäviä ja toimintoja. Tämä auttaa havaitsemaan pullonkaulat, joita voit poistaa nopeamman toimituksen mahdollistamiseksi asiakkaalle.

Ketterän manifestin kritiikki

Kuten kaikki muutkin projektinhallintamenetelmät, ketterä menetelmä ei ole täydellinen. Kriitikot huomauttavat, että Ketterän manifestin kirjoittajat olivat homogeeninen ryhmä, joka ei ehkä ottanut huomioon vaihtoehtoisia työskentelytapoja, kuten etätyöskentelyn hyötyjä tai sitä, miten ketteryyttä voidaan soveltaa ohjelmistokehityksen ulkopuolella.

Liian pitkälle vietynä ketterä menetelmä saattaa tarkoittaa päätöksentekoa komiteassa, mikä hidastaa työn etenemistä. Dokumentoinnin puute voi lopulta haitata projektin toimitusta, erityisesti etäympäristössä, jossa asynkroninen viestintä on ratkaisevan tärkeää.

Jos päätät käyttää ketterää menetelmää projekteissasi, tutustu huolellisesti ketteryyden arvoihin ja periaatteisiin. Ne ovat hyödyllinen opas ketterän menetelmän haitallisimpien taipumusten pitämiseen kurissa.

Lue lisää keskustelusta siitä, onko ketterä menetelmä vai ajattelutapa.

Ketteryys, ei ketterä menetelmä

Vielä yksi asia: muistathan retrospektiivin! Kuten manifestissa todetaan:

Säännöllisin väliajoin tiimi pohtii, miten siitä voisi tulla tehokkaampi, ja hienosäätää sekä mukauttaa toimintaansa sen mukaisesti.

Riippumatta käyttämästäsi prosessityypistä retrospektiivi on tehokas tapa tarkastella työskentelytapojasi ja optimoida toiminta onnistumista varten. Varmista, että sisällytät projektin retrospektiivit säännöllisesti käyttämääsi prosessiin ja että sinulla on mekanismi oppien hyödyntämiseen! PS: On tärkeää saada hiljaisemmat tiimin jäsenet osallistumaan retrospektiiveihin – näin se onnistuu.

Mitä seuraavaksi?

Jos haluat oppia lisää ketterien työskentelytapojen käyttöönotosta ja oppia alan parhailta projektipäälliköiltä, tutustu DPM-jäsenyysvaihtoehtoihimme.