Agilen 12 periaatteen hyvät ja huonot puolet

Agile-manifesti koostuu 12 periaatteesta, jotka määrittelevät ketterän lähestymistavan ohjelmistokehitykseen. Nykyään ketterä lähestymistapa hahmottaa selkeästi säännöt tiimityölle IT-alalla. Sitä voidaan pitää menestyneimpänä ja tehokkaimpana kevyen projektinhallinnan metodologiana. Mitkä ovat ketterän projektinhallinnan hyvät ja huonot puolet?

12 periaatetta ketterästä – sisällysluettelo:

1. 12 periaatetta ketterästä
2. Yhteenveto

12 periaatetta ketterästä

Ketterä projektinhallinta perustuu sääntöihin, jotka on selkeästi ilmoitettu ja helppo muistaa. Neljän arvon lisäksi, jotka kuvasimme tässä tekstissä, Agile-manifesti koostuu 12 ketterästä periaatteesta.

Alla esittelemme 12 ketterän periaatteen hyvät ja huonot puolet. Keskustelemme niistä yksi kerrallaan, kuten ne esitetään Agile-manifestin viimeisessä versiossa, joka julkaistiin vuonna 2019. Ne ovat seuraavat:

1. Asiakkaan tyydyttäminen varhaisen ja jatkuvan arvokkaan ohjelmiston toimituksen kautta on meille tärkein prioriteetti.

Nopean tuotteen toimituksen asettaminen korkeimmaksi prioriteetiksi on suuri etu asiakkaan näkökulmasta. Tuotteen ensimmäinen toimiva versio voidaan julkaista heti, kun se täyttää sovitut kriteerit. Tiimi työskentelee nopeasti seuraavien päivitysten parissa, joita voidaan julkaista jopa joka päivä. Tällä tavoin tuote on aina uusi ja aina toimiva.

Kuitenkin lähestymistavassa on myös joitakin haittoja, sillä tuote on aina kehitysvaiheessa. Siksi loppukäyttäjien ostamat vanhemmat versiot voivat nopeasti tulla yhteensopimattomiksi tai vaatia jatkuvaa päivitystä toimiakseen oikein.

2. Tervetuloa muuttuvat vaatimukset, jopa kehityksen myöhäisessä vaiheessa. Ketterät prosessit hyödyntävät muutosta asiakkaan kilpailueduksi.

Kun tiimi pystyy omaksumaan muuttuvat vaatimukset, tuotetta voidaan mukauttaa nopeasti ja tehokkaasti asiakkaan ja markkinoiden tarpeisiin. Haastava ympäristö lisää luovuutta ja voi johtaa innovaatioihin. Kuitenkin muutoksen hyödyntäminen ei ole vain jännittävää, vaan myös hyvin vaativaa tiimille. Heidän on opittava päivittäin ja oltava avoimia usein esiintyville tilanteille, joissa kehitetyt ratkaisut eivät jatku, tai niitä ei edes toteuteta tuotteeseen lainkaan.

3. Toimivaa ohjelmistoa on toimitettava usein, parista viikosta pariin kuukauteen, mieluummin lyhyemmällä aikavälillä.

Usein toimitussääntö on erittäin tärkeä erittäin kilpailukykyisessä ja nopeasti muuttuvassa markkinaympäristössä. Se myös saa tiimin välttämään tuotteen sivutoimintojen kehittämistä ja keskittymään asiakkaan asettamiin päämääriin.

Kuitenkin, kun tuotteen osalta on suunniteltu suuria muutoksia, tätä sääntöä ei tulisi noudattaa liian tiukasti. Tässä tapauksessa on parempi testata uusi ratkaisu perusteellisesti kuin julkaista keskeneräinen versio tuotteesta.

4. Liiketoimintaihmiset ja kehittäjät on saatava työskentelemään yhdessä päivittäin koko projektin ajan.

Tiivis yhteistyö liiketoiminta- ja kehitystiimien välillä on ratkaisevan tärkeää arvokkaan tuotteen toimittamiseksi markkinoille. Ongelmat, jotka voivat ilmetä tässä, liittyvät viestintään ja odotuksiin. Syynä on se, että kehitystiimit eivät aina pysty viestimään ratkaisujensa teknisiä rajoituksia. Liiketoimintakumppanit puolestaan saattavat kamppailla odotustensa selkeyttämisessä, mikä voi nousta tai jäädä määrittelemättömäksi.


5. Rakenna projekteja motivoituneiden yksilöiden ympärille. Anna heille tarvittava ympäristö ja tuki, ja luota heidän hoitavan työnsä.

Keskinäinen luottamus tiimin jäsenten välillä sekä terve annos vapautta ovat onnistuneen ja tehokkaan työn välttämättömiä elementtejä. Kun motivoitunut tiimi tuntee vastuuta tehtävästään, he yleensä keskittyvät ponnistelunsa työn saamiseen valmiiksi. Kuitenkin tämä projektinhallintalähestymistapa vaatii oikeaa tasapainoa itsenäisyyden ja kontrollin välillä. Tiimillä on oltava avoin ympäristö ollakseen luova, mutta sen on myös oltava rajat, joihin työskennellä tavoitteiden saavuttamiseksi.

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

Kasvokkain käytävät keskustelut on nykyään pääasiassa korvattu verkkokokouksilla. Meidän on muistettava, että Agile-manifesti kirjoitettiin vuonna 2001, jolloin etätyö ei ollut yhtä yleistä kuin tänään, ja verkkokokousten mahdollisuudet olivat melko rajalliset. Kuitenkin kasvokkain käytävät kokoukset tai vain videokonferenssit ovat erittäin tärkeitä tiimin motivoimiseksi. Tämä on kuitenkin aikaa vievä ratkaisu. Siksi ketterät projektipäälliköt rajoittavat usein aikarajoja ja ohjaavat kokouksen kulkua.

7. Toimiva ohjelmisto on edistymisen ensisijainen mittari.

Uusi versio toimivasta ohjelmistosta tai muu potentiaalisesti markkinavalmiina oleva tuote on ehdottomasti paras edistymisen mittari. Kuitenkin joskus on tarpeen suorittaa joitakin ylläpitotöitä. Siksi tätä periaatetta ei voida ottaa kirjaimellisesti jokaisessa tapauksessa.

8. Ketterät prosessit edistävät kestävää kehitystä. Sponsorien, kehittäjien ja käyttäjien tulisi pystyä ylläpitämään jatkuvaa tahtia loputtomiin.

Kestävä kehitys tarkoittaa tiimin kykyä arvioida omaa kapasiteettiaan. Tämä on yksi tärkeimmistä kyvyistä kypsällä tiimillä. Niin kauan kuin tiimin ei tarvitse työskennellä täydessä kapasiteetissaan koko ajan, on olemassa erityisiä hetkiä tuotteen elinkaaressa, jolloin tällaiset jaksot, kuten esimerkiksi kiire, ovat tarpeen.

9. Jatkuva huomio tekniseen erinomaisuuteen ja hyvään suunnitteluun parantaa ketteryyttä.

Tekninen erinomaisuus tarkoittaa tarvetta välttää aikaa ja resursseja kuluttavia tarkistuksia. Ja tämä on yksi tärkeimmistä syistä kiinnittää jatkuvaa huomiota kehitetyn tuotteen laatuun. Tämän ketterän periaatteen osalta emme pysty osoittamaan mitään haittoja tälle lähestymistavalle.

10. Yksinkertaisuus – taide maksimoida tekemättömien töiden määrä – on olennaista.

Ketterän 10. periaatteen voi ilmaista tunnetussa sanonnassa “Työskentele älykkäämmin, älä kovemmin”. Toisin sanoen, jos tuotteen jokin toiminnallisuus ei ole tulossa julkaistavaksi, älä työskentele sen parissa. Tämän lähestymistavan haittana on tarve suurelle projektipäällikölle, joka pystyy priorisoimaan työn reaaliajassa ja säätämään sen laajuutta asiakkaan vaatimusten mukaan.

11. Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoituvista tiimeistä.

Itseorganisoituvat tiimit tuntevat vastuuta työstään, sillä he eivät voi sanoa, että epäonnistuminen johtuu huonosta hallinnosta tai vanhentuneesta valvonnasta. Kuitenkin nuoremmat tiimit tarvitsevat usein valmennusta tai mentorointia. Siksi alussa voi olla järkevää työskennellä kokeneen Scrum Masterin kanssa, jonka rooli on kuvattu tässä, tai muunlaisen ketterän valmentajan kanssa.

12. Säännöllisin väliajoin tiimi pohtii, miten tulla tehokkaammaksi, ja säätää ja mukauttaa käyttäytymistään sen mukaisesti.

Reflektio ja mukautuminen ovat perusasioita ei vain yleisessä ketterässä lähestymistavassa, vaan myös Scrum-kehyksen perustana. On erittäin vaikeaa löytää haittaa tälle mukautuvalle lähestymistavalle, sillä reflektio tiimityöstä johtaa yleensä parempaan tehokkuuteen sekä tiimin integraatioon.

Yhteenveto

Ketterä kehitettiin ohjelmistokehitysmenetelmäksi, joka korostaa iteratiivista kehitystä, tiimiyhteistyötä ja asiakaspalautetta. Agile-manifesti hahmottaa 12 ketterää periaatetta, jotka ohjaavat ketterää projektinhallintaa. Ne keskittyvät arvon tuottamiseen asiakkaalle jatkuvan toimivan ohjelmiston toimituksen kautta.

Ketterällä lähestymistavalla on monia etuja; se on nopea ja jatkuva prosessi, joka on suunniteltu seuraamaan asiakkaan muuttuvia tarpeita. Se reagoi markkinoihin ja tarjoaa korkean joustavuuden.

Kun tiedät nyt 12 ketterää periaatetta, voit tarkistaa kuinka käyttää ketterää metodologiaa freelance-projekteissa.

Jos pidät sisällöstämme, liity vilkkaaseen mehiläisyhteisöömme Facebookissa, Twitterissä, LinkedInissä, Instagramissa, YouTubessa, Pinterestissä.