Mikä on niin upea ketterästä? Peruste ketterälle metodologialle
Ketterä Määrittele ketteriksi hallintajärjestelmiksi, jotka ovat olleet olemassa jo jonkin aikaa, mutta jotka ovat viime aikoina saaneet valuuttaa. Itse asiassa ketterä hallinta on jatkuvasti esillä melkein jokaisessa IT-projektihallinnan blogissa joka vuosi tärkeimmissä projektinhallinnan suuntauksissa.
Agile-sovellusten käyttö tietotekniikkapohjaisissa projekteissa on kiistaton, koska sitä löytyy paitsi IT-ohjelmistoprojekteista myös tuotekehityksessä ja innovaatioissa.
Joten mikä on niin upea Agilessa? Kysy työntekijöiltä, jotka ovat siirtyneet perinteisestä järjestelmästä ketterään, ja he saattavat valittaa jatkuvia kokouksia ja ”kokouskokouksia”.
Osoittautuu, että ketterällä on paljon muutakin kuin pelkkää kokousta ja palautetta. Se keskittyy tiimien valtuuttamiseen ja peräkkäisten projektin kehittämistapojen poistamiseen, jotta saadaan enemmän joustavuutta ja innovaatioita. Vaikka se tarkoittaa kokouksia ja toimituksia useammin kuin perinteisissä järjestelmissä, se tarkoittaa myös sitä, että iteraatioita ja muutoksia on myöhemmin vähemmän. päälle projektisyklissä.
Sitä pidetään parannuskeinona yleisille ongelmille, jotka ruttoavat tietotekniikkaan liittyviin hankkeisiin. Mikä se tarkalleen on ja miten se on parempi kuin perinteiset järjestelmät?
Ketterän metodologian tarve - johtamiskäytännöt
Jokaisella, joka on työskennellyt ketterän metodologian kehittämisessä ohjelmistokehitysprojekteissa, on jonkinlainen käsitys joistakin projektin aikana esiin nousevista tavallisista ongelmista: laajuuden muutoksesta, määräajoista, joita ei voida noudattaa, ja resursseista ylityöhön.
Projektinhallinnan perinteisillä ketterillä menetelmillä oli monia haittoja, joiden vuoksi he eivät pystyneet selviytymään jatkuvasti muuttuvasta liiketoimintaympäristöstä, etenkin ohjelmistokehityksessä, ja yllä olevat tilanteet olivat valitettavasti liian yleisiä. Tämä ei tarkoita, että perinteisiä menetelmiä ei voida soveltaa missään. Ne ovat edelleen paras veto hankkeille, joissa idea on täysin muodostettu alusta alkaen.
Ketteristä johtamiskäytännöistä tuli tunnin tarve, koska ne tyydyttävät seuraavat dynaamisessa ympäristössä lanseeratun tuotteen tarpeet:
- Nopeuden tarve saavuttaa tuote markkinoille
- Joustavuuden tarve eritelmien useiden muutosten huomioon ottamiseksi
- "Työnjako" -skenaarion puutteet
- Asiakkaan ongelma
- Kustannussäästöjen tarve
Nopeuden tarve tuotteen saavuttamiseksi markkinoille:
Elämme nopeatempoisessa ympäristössä, jossa joustavuus ja nopeus ovat avain menestykseen.
Teknologia on yksi nopeimmin muuttuvista aloista teollisuudessa. Joka minuutti on uudempi idea, tuote tai innovaatio. Tässä tilanteessa perinteinen projektijohtamistapa ei tuota tulosta. Peräkkäinen projekti on välttämättä riippuvainen ketterien menetelmävaiheiden suorittamisesta tyydyttävästi järjestyksessä. Perinteisesti johdettujen projektien aikataulut ovat aina kiistanalaisia.
Organisaatiot ja joukkueet, jotka eivät ole dynaamisia, menettävät kilpailun niille, jotka morfioivat itsensä sopimaan muuttuvaan ympäristöön.
Joustavuuden tarve eritelmien useiden muutosten huomioon ottamiseksi:
Asiakkaiden odotukset ja vaatimukset muuttuvat usein tuotekehityksen aikana. Ennen ketterien hallintajärjestelmien sisällyttämistä valtavirtaan, IT-projektit epäonnistuivat usein, koska perinteinen projektinhallintajärjestelmä rakennettiin "kynnettäväksi". Jos muutoksia tapahtui, asiakkaat tunsivat usein hyppysensä lompakkoihinsa tai aikatauluihinsa. Muilta toimialoilta mukautettu perinteinen projektihallintamalli ei yksinkertaisesti toiminut dynaamisessa teollisuudessa, kuten tietotekniikassa.
Työnjako:
Perinteisessä mallissa on erilliset vaiheet, jotka alkavat järjestelmävaatimusten analysoinnista ja johtavat tuotteen julkaisuun ja ylläpitoon. Tämä johtaa työnjakoon ja jäsenten merkitsemiseen "suunnittelijoiksi", "ohjelmoijiksi" tai "testaajiksi". Mutta todellisuudessa nykypäivän resurssit ovat erittäin toiminnallisia, ja tällainen roolien selkeä erottaminen ei ole mahdollista useimmissa hankkeissa.
Asiakkaan ongelma:
Haihtuvissa projekteissa asiakkaat eivät useinkaan ole täysin varmoja siitä, minkä heidän lopputuotteensa kaikkien eritelmien kanssa on oltava. Toiminnot ja vaatimukset muuttuvat usein työkappaleiden valmistuttua. Perinteiset mallit, kuten vesiputousmalli, korostavat selvyyttä lopputuotteeseen nähden, ja suunnitelmien poikkeamat asettavat järjestelmään valtavan paineen. Tämä vie meidät viimeiseen tekijään, joka johti ketterien järjestelmien kehittämiseen.
Kustannussäästöjen tarve:
Perinteisesti vaatimuksia muutettiin milloin tahansa projektin alkamisen jälkeen. Pikemminkin minkä tahansa lisäkomponentin kustannukset olivat korkeat, toisinaan kohtuuttomasti. Siksi oli välttämätöntä sisällyttää kaikki mahdolliset skenaariot itse suunnitteluvaiheeseen. Tämä tarkoitti, että kaikki skenaariot harkittiin ja ratkaisua ehdotettiin. Mutta koska on lähes mahdotonta tietää tietystä osasta tuotetta käyttäjä haluaa, joukkueet kehittivät usein tuotteen “paisuneita versioita”. Tämä sisälsi kaikki mahdolliset skenaariot, joista tyypillinen käyttäjä käyttäisi enintään 20%. Tämä johti tarpeettomiin kustannuksiin ja kehitykseen.
Sanomattakin on selvää, että tämä tarkoitti, että kaikki hankkeet olivat suunnittelussaan globaaleja.
Ja kun syntyi aivan uusi suunnittelematon skenaario, siitä aiheutui kuitenkin lisäkustannuksia kaikesta suunnittelusta huolimatta.
Ryhmä ihmisiä kokoontui helmikuussa 2001 keskustelemaan tarkalleen tästä: joustavan ja ketterän ohjelmistokehitysmallin tarpeesta, joka auttoi kehittämään tuotteita, jotka todella toimivat asiakkaan ja kehittäjän hyväksi. Tuloksena oli ”Ketterä manifesti”, joka hyötyi ketterästä metodologiaohjelmistokehityksestä eli joukosta neljä periaatetta, jotka ovat yhtä yksinkertaisia kuin kuvailevat. Lisäksi kehitettiin 12 "ketterää periaatetta", jotka selittävät ketterien järjestelmien todellisen toimimisen projektiympäristössä.
Tämän työn kautta olemme tulleet arvoon:
- Henkilöt ja prosessien ja työkalujen vuorovaikutus
- Toimivat ohjelmistot kattavan dokumentoinnin yli
- Asiakasyhteistyö sopimusneuvotteluissa
- Vastaus muutokseen suunnitelman seuraamisessa
Toisin sanoen, vaikka oikealla olevilla esineillä on arvoa, arvostamme vasemmalla olevia esineitä enemmän.
12 ketterää periaatetta
12 ketterää periaatetta on ketterä manifesti, joka tukee projektiryhmiä ketterien projektien toteuttamisessa. He ovat:
- Ensisijainen tavoitteemme on tyydyttää asiakas asiakkaamme toimittamalla varhain ja jatkuvasti arvokkaita ohjelmistoja.
- Tervetuloa muuttuviin vaatimuksiin jopa myöhäisessä kehitysvaiheessa. Ketterät metodologiaprosessit valjastaa muutoksen asiakkaan kilpailuetua varten.
- Toimita toimivia ohjelmistoja usein, muutamasta viikosta pariin kuukauteen, mieluummin lyhyemmälle aikavälille.
- Liikemiesten ja kehittäjien on työskenneltävä yhdessä päivittäin koko projektin ajan.
- Rakenna projekteja motivoituneiden henkilöiden ympärille. Anna heille ympäristö ja tuki, jota he tarvitsevat, ja luota heihin työn saamiseksi.
- Tehokkain ja tehokkain tapa välittää tietoa kehitysryhmälle ja sen sisällä on kasvotusten käytävä keskustelu.
- Toimivat ohjelmistot ovat edistyksen ensisijainen mitta.
- Ketterät metodologiset prosessit edistävät kestävää kehitystä. Sponsorien, kehittäjien ja käyttäjien tulisi pystyä ylläpitämään vakiona vauhtia määräämättömän ajan.
- Jatkuva huomiota tekniseen huippuosaamiseen ja hyvään suunnitteluun lisää ketteryyttä.
- Yksinkertaisuus - taito maksimoida tekemättömän työn määrä - on välttämätöntä.
- Parhaat arkkitehtuurit, vaatimukset ja mallit syntyvät itseorganisoivista ryhmistä.
- Säännöllisin väliajoin joukkue pohtii, kuinka tulla tehokkaammaksi, virittää ja säätää sitten käyttäytymistään vastaavasti.
Esimerkki projektista, joka tarvitsee ketterää hallintaa
Kuvittele käynnistysyritys, joka kehittää mobiilisovelluksen asiakkaalle. Koko sovellussuunnitelman jäädyttäminen ennen kehittämisen aloittamista voi olla tuhoisa. Markkinatutkimuksen suorittamiseen, yksityiskohtaisen suunnitelman piirtämiseen, päättämiseen vaihtoehdoista, joita he haluavat tarjota, on kehitetyn aikaa ja tuotteen kehittämiseen. Tähän lähestymistapaan liittyvien valtavien kustannusten lisäksi he ovat vaarassa, että jokin muu yritys saattaa kehittää sovelluksen ennen kuin he tekevät.
Ketterä projektijohtamismenetelmä auttaa voittamaan nämä ongelmat. Tämän järjestelmän puitteissa sovellus kehitetään vaiheittain, jolloin asiakas on vuorovaikutuksessa joka päivä, ja toimitukset tai projektin virstanpylväät, esimerkiksi, joka viikko tunnistetaan.
Useat joukkueet voivat myös työskennellä samalla sovelluksella, joten kehitysaika lyhenee huomattavasti.
Toiminnallisuuksia tarkennetaan jokaisessa kokouksessa ja lopputuote heijastaa lopullista tarvetta. He oppivat askel askeleelta, mikä toimii asiakkaalle, ja improvisoi tarjouksia, kunnes he saavat halutun tuotteen.
Perinteisessä projektinhallintatavassa ajatellaan kaikkia tarkistuksia ennen tuotteen julkaisua. Tämä johtaisi aikataulujen noudattamatta jättämiseen, lisääntyneeseen työmäärään ja kustannusinflaatioon. Lisäksi tuote on ehkä menettänyt merkityksensä täysin julkaisuhetkellä.
Kuinka ketterä hallinta toimii?
Vaikka ketterälle johtamiselle viitataan pääasiassa IT-konseptinä, sen käyttö ei rajoitu IT-alaan. Esimerkiksi vaatekauppaketju Zara käytti ketterän johdon periaatteita liiketoiminnan muuttamiseen.
Ketterien periaatteiden mukaisesti Zara valmisti tuotteita pienissä erissä sen sijaan, että keskittyisi suureen tuotantoon ennen uutta kausia. Yhtiö vältti tällä menetelmällä korkean varaston ja ennakoimattomien alennustarjousten kustannukset.
Jotkut ketterän projektinhallinnan avainkysymykset ovat:
- Ketterä projektijohtaminen noudattaa joustavaa lähestymistapaa.
Ketterä johto suhtautuu myönteisesti lisäyksiin ja muutoksiin koko tuotekehityksessä sen sijaan, että noudattaa alkuperäisiä vaatimuksia.
- Ketterät projektit jaetaan yleensä erillisiin työpalasiin, ja ryhmät osallistuvat yhden tai useamman näistä työn palasten kehittämiseen.
Joten on mahdollista, että esimerkiksi neljä ryhmää työskentelee samanaikaisesti projektin eri osissa, niin että projektin aikatauluja lyhennetään. Joukkueet koordinoivat toistensa ja asiakkaan kanssa päivittäin suoritteita.
- Projektin etenemisestä tai esteistä käydään päivittäin kokouksia, joissa annetaan jatkuvaa palautetta.
Saatuaan asiakaspalautetta muutokset sisällytetään ja joukkueet siirtyvät seuraavaan kohtaan. Tämä prosessi tuottaa edelleen dynaamisemman ja asiakkaan tarpeita paremmin vastaavan tuotteen.
- Tiimin jäsenet osallistuvat enemmän kuin ylhäältä alaspäin suuntautuva lähestymistapa.
Ohjelmistokehityksen elinkaaren aikana tiimin jäsenet ovat mukana kaikissa vaiheissa: vaatimukset, suunnittelu, kehitys ja ketterä metodologinen testaus. Koska tehtävän tehokkuudesta on säännöllinen katsaus, ryhmän jäsenet säätävät käyttäytymistä ja menettelytapoja vastaavasti.
- Ketterän projektin projektipäällikön profiili muuttuu perinteisestä roolista.
Hän ei enää vie vie paljon aikaa resurssien suunnitteluun tai seurantaan, mutta viettää nyt enemmän aikaa yhteistyöhön joukkueiden kanssa ja varmistaakseen, että kokonaiskuva on aina näkyvissä. Tämä ei ole helppo siirtyminen, ja ketteriin järjestelmiin siirtyvien johtajien on sopeuduttava nopeasti projektin onnistumiseen.
Muutama sana Scrumista:
Scrum on yksi suosituimmista kehyksistä ketterän metodologian toteuttamiseksi. Mikä on ketterä menetelmä? Se on edeltävä Agilea, ja sitä ehdotettiin ensimmäistä kertaa vuonna 1986, ja se otettiin käyttöön auto- ja tulostusteollisuudessa.
Ketterä metodologia ja scrum eivät ole synonyymejä; on myös muita kehyksiä, joita voidaan käyttää ketterän toteuttamiseen, mutta Scrum on yksi tehokkaimmista ja todennäköisesti suosituimmista. Mikä on scrum? Scrumilla on tyypillisesti vain kolme roolia: tuotteen omistaja, tiimi ja Scrum-päällikkö. Scrum-menetelmien päällikkö ei ole projektipäällikkö. Perinteisen projektipäällikköroolin vastuut on jaettu kolmeen Scrum-projektijohtamisrooliin. Projekti on rakennettu sarjaan kiinteän pituisia iteraatioita, joita kutsutaan sprinteiksi. Jokaisen ketterän metodistisen sprintin menestys tuo tunteen konkreettisesta edistymisestä ja jatkuvasta inspiraatiosta. Jokaisen iteraation tavoitteena on tuottaa toimiva tuote, joka voidaan osoittaa sidosryhmille. Ketterä menetelmämenetelmäkerroin toimii yhdessä tuotteen omistajan ja tiimin kanssa tavoitteiden saavuttamisen helpottamiseksi poistamalla tukokset. Ketterä metodologian kehittämistiimi on ristitoiminnallinen ja sisältää kehittäjien lisäksi testaajia, suunnittelijoita ja op-insinöörejä.
Perinteinen projektinhallinta: Vesiputous
Yksi näkyvimmistä perinteisistä projektinhallintajärjestelmistä on vesiputous. Sitä käytettiin usein 1970-luvulta lähtien. IT-hankkeissa on useita tunnettuja ja laajasti toteutettuja vesiputousmenetelmiä. Näihin kuuluvat PRINCE2, jonka Yhdistyneen kuningaskunnan hallitus on luonut julkiselle sektorilleen.
Aivan kuten nimensä viittaa, se on peräkkäinen työnkulku. Lopputuote vahvistetaan projektin alussa. Sitten työnkulun eri vaiheet saadaan päätökseen peräkkäin (suunnittelun aloittaminen, analysointi, suunnittelu, rakentaminen, testaus, toteutus ja ylläpito). Kun edellinen vaihe on suoritettu, kehittäjät siirtyvät seuraavaan vaiheeseen. Projektisuunnitelman tulee olla tyhmätön; Kun sekvenssin vaihe on suoritettu, kehittäjät eivät voi käydä uudelleen alustamatta alusta kokonaan. Se on staattinen lähestymistapa ketterään metodologiaan projektijohtamisessa. Ei ole tilaa muutoksille tai virheille, ja ketterää metodologiaprojektisuunnitelmaa on noudatettava huolellisesti.
Vesiputoushallinnan ja mestariteoksen maalaamisen välillä voidaan vetää analogia. Kuva viimeisestä mestariteoksesta on jo taiteilijan mielessä, ja hän työskentelee tasaisesti sitä kohti. Jos lopputuote jostakin syystä eroaa näkemästään, hän ei voi muokata sitä helposti.
Ketterä vai vesiputous?
- Mikä on ketterä? Ketterä sopii paremmin pienille ryhmille, jotka työskentelevät inkrementaalisten ja evoluutioprojektien parissa, kun taas Waterfall sopii suuriin suunnitelmiin tai kehityshankkeisiin. Vesiputoushallinta saattaisi sopia paremmin toimialoille, kuten rakennusteollisuudelle. Ketterää käytetään dynaamisissa projekteissa, kuten IT-teollisuudessa.
- Ketterät järjestelmät vaativat erittäin taitavia tiimin jäseniä, jotka pystyvät käsittelemään projektin kaikkia vaiheita. Se vaatii dramaattista muutosta projektipäällikön roolissa. Vesiputousprosessi on rakennettu perinteisemmällä tavalla, se on lineaarinen, ja se on ehkä helpompi ymmärtää muille kuin kehittäjille ja niille, jotka ovat ohjelmistojen kehittämisen aloilla uusia.
- Monet organisaatiot pitävät Waterfall-menetelmää lohduttavana, koska se on paremmin dokumentoitu. Ketterä tunnetaan siitä, ettei hän korosta laajaa dokumentaatiota. Se on enemmän ihmisistä riippuvaista, mikä voi olla epämukavaa organisaatioissa, joissa heikentymisaste on korkea.
- Pienemmät suoraviivaiset projektit eivät ehkä vaadi ketterää metodologiakehystä, ja peräkkäinen vesiputomalli voivat toimia samoin.
Missä tämä kaikki menee?
HP: n toukokuussa 2015 tekemän tutkimuksen mukaan ketterä kehitysmenetelmä muodostaa yli kaksi kolmasosaa kaikista Yhdysvaltojen IT-hankkeista.
Mutta ketterä ei aina ole ”täydellinen” ratkaisu. Se ei ole kaikille sopiva ratkaisu, ja sen seurauksena monet organisaatiot (HP: n tutkimuksen mukaan 24%) ovat nyt ottaneet käyttöön hybridi-lähestymistavan.
Ketterän ja vesiputousmenetelmän yhdistelmä voisi hyödyntää molempien etuja. Tämä hybridi-lähestymistapa voisi toimia monimutkaisissa projekteissa ulkoisten asiakkaiden ja suurten ryhmien kanssa. Tätä lähestymistapaa ovat kuvanneet Erick Bergmann ja Andy Hamilton. Se on kompromissi näiden kahden menetelmän välillä, jonka avulla ohjelmistoryhmät voivat toimia "ketterästi", kun taas laitteistokehitysryhmät ja tuotepäälliköt käyttävät perinteistä menetelmää.
Digitaalinen konsultti Mark Fromson tuo esiin toisen tavan, jolla hybridi voi toimia:
Hajottamalla projekti vesiputousmaisiin vaiheisiin, jotta voidaan tehdä kiinteähintaisia sopimuksia ja määritelty soveltamisala pienemmässä vaiheessa, mutta pitää projekti kokonaisuutena.
Riippumatta tulevien joukkueiden muodosta, on selvää, että ketterä metodologian kehittäminen on täällä. Se on antanut mahdollisuuden joustavuuteen, aika- ja kustannusetuihin, yhdessä tärkeimmän tekijän kanssa: antanut tyydytyksen tunteen ja motivoivan ilmapiirin ihmisille, jotka työskentelevät näiden projektien parissa.
Lähde:
Ketterälle manifestille ja 12 ketterälle periaatteelle - www.agilemanifesto.org
Aiheeseen liittyvät kurssit: -
Ketterä projektijohtaminen - Opi ketterät metodologiat