Jokainen teknologiaorganisaatio näyttää nykyään harjoittavan ohjelmistokehityksen ketterää metodologiaa tai sen versiota. Tai ainakin he uskovat tekevänsä. Olitpa uusi ketterässä sovelluskehityksessä vai oletko oppinut ohjelmistokehityksen vuosikymmeniä sitten vesiputouksen ohjelmistokehitysmenetelmien avulla, tänään ainakin ketterä menetelmä vaikuttaa työsi.
Mutta mikä on ketterä metodologia, ja miten sitä tulisi käyttää ohjelmistokehityksessä? Kuinka ketterä kehitys eroaa käytännössä vesiputouksesta? Mikä on ketterä ohjelmistokehityksen elinkaari tai ketterä SDLC? Ja mitä scrum ketterä verrattuna Kanbaniin ja muihin ketteriin malleihin?
Ketterä otettiin virallisesti käyttöön vuonna 2001, kun 17 teknikkoa laati Agile-manifestin. He kirjoittivat neljä pääperiaatetta ketterälle projektinhallinnalle parempien ohjelmistojen kehittämiseksi:
- Yksilöt ja vuorovaikutus prosessien ja työkalujen suhteen
- Toimiva ohjelmisto kattavan dokumentaation avulla
- Asiakasyhteistyö sopimusneuvotteluissa
- Suunnitelman muuttamiseen vastaaminen
Ennen ketterää: Vesiputousmenetelmien aikakausi
Vanhat kädet, kuten minä, muistavat päivät, jolloin vesiputousmenetelmä oli ohjelmistokehityksen kultastandardi. Ohjelmistokehitysprosessi vaati paljon dokumentaatiota ennen koodauksen aloittamista. Joku, yleensä yritysanalyytikko, kirjoitti ensin liiketoiminnan vaatimuksia koskevan asiakirjan, joka kuvasi kaiken sovelluksessa tarvittavan liiketoiminnan. Nämä liiketoimintaa koskevat asiakirjat olivat pitkiä, ja niissä kuvattiin kaikki: yleinen strategia, kattavat toiminnalliset eritelmät ja visuaaliset käyttöliittymäsuunnitelmat.
Teknologit ottivat yritysvaatimusasiakirjan ja laativat oman teknisten vaatimusten asiakirjan. Tässä asiakirjassa määriteltiin sovelluksen arkkitehtuuri, tietorakenteet, olio-suuntautuneet toiminnalliset mallit, käyttöliittymät ja muut ei-toiminnalliset vaatimukset.
Tämä vesiputousohjelmistojen kehitysprosessi aloitti lopulta koodauksen, sitten integroinnin ja lopulta testauksen ennen kuin sovelluksen katsottiin olevan valmis tuotantoon. Koko prosessi voi helposti kestää pari vuotta.
Meiltä kehittäjiltä odotettiin tietävän ”tekniset tiedot”, kuten täydellistä dokumentaatiota kutsuttiin, samoin kuin asiakirjojen kirjoittajat, ja meitä usein rangaistiin, jos unohdimme toteuttaa asianmukaisesti keskeisen yksityiskohdan, joka on kuvattu 200 sivun asiakirja.
Silloin myös ohjelmistokehitys ei ollut helppoa. Monet kehitystyökalut vaativat erikoiskoulutusta, eikä nykyisen avoimen lähdekoodin tai kaupallisten ohjelmistokomponenttien, sovellusliittymien ja verkkopalveluiden läheisyydessä ollut mitään. Meidän oli kehitettävä matalan tason asioita, kuten tietokantayhteyksien avaaminen ja monisäikeinen tietojenkäsittely.
Jopa perussovelluksissa joukkueet olivat suuria ja viestintävälineet rajalliset. Tekniset määrittelyt sovittivat meitä, ja käytimme niitä hyväksi Raamatun tavoin. Jos vaatimus muuttuisi, saisimme yritysjohtajat käymään läpi pitkän prosessin ja allekirjoittamaan, koska muutosten tiedottaminen tiimin sisällä ja koodin korjaaminen oli kallista.
Koska ohjelmisto kehitettiin teknisen arkkitehtuurin perusteella, alemman tason artefaktit kehitettiin ensin ja riippuvat artefaktit myöhemmin. Tehtävät jaettiin taitojen mukaan, ja tietokanta-insinöörien oli yleistä rakentaa ensin taulukot ja muut tietokannan artefaktit, minkä jälkeen sovelluskehittäjät koodaivat toiminnallisuutta ja liiketoimintalogiikkaa, ja sitten lopulta käyttöliittymä peitettiin. Kesti kuukausia, ennen kuin kukaan näki sovelluksen toimivan, ja siihen mennessä sidosryhmät saivat antsy ja usein älykkäämpiä siitä, mitä he todella halusivat. Ei ihme, että muutosten toteuttaminen oli niin kallista!
Kaikki, mitä asetit käyttäjien eteen, ei toiminut odotusten mukaisesti. Joskus käyttäjät eivät käytä ominaisuutta ollenkaan. Toisinaan ominaisuus oli laajalti onnistunut, mutta vaati uudelleensuunnittelua tarvittavan skaalautuvuuden ja suorituskyvyn tukemiseksi. Vesiputousmaailmassa opit nämä asiat vasta ohjelmiston käyttöönoton jälkeen pitkän kehitystyön jälkeen.
Aiheeseen liittyvä video: Kuinka ketterä menetelmä todella toimii
Kaikki näyttävät puhuvan ketterästä ohjelmistokehityksestä, mutta monilla organisaatioilla ei ole vankkaa käsitystä prosessin toiminnasta. Katso tämä viiden minuutin video saadaksesi vauhtia nopeasti.
Ketterä ohjelmistokehitys
Vuonna 1970 keksitty vesiputousmenetelmä oli vallankumouksellinen, koska se toi kurinalaisuutta ohjelmistokehitykseen sen varmistamiseksi, että seurattavia selviä tietoja oli olemassa. Se perustui vesiputousvalmistusmenetelmään, joka johtui Henry Fordin vuoden 1913 kokoonpanolinjan innovaatioista, mikä antoi varmuuden tuotantoprosessin jokaisesta vaiheesta sen varmistamiseksi, että lopputuote vastaa ensinnäkin spesifioitua.
Kun vesiputousmenetelmä tuli ohjelmistomaailmaan, tietojenkäsittelyjärjestelmät ja niiden sovellukset olivat tyypillisesti monimutkaisia ja monoliittisia, ja niiden toteuttaminen vaati kurinalaisuutta ja selkeää lopputulosta. Myös vaatimukset muuttuivat hitaasti nykypäivään verrattuna, joten laajamittaiset toimet eivät olleet yhtä ongelmallisia. Itse asiassa järjestelmät rakennettiin olettaen, että ne eivät muutu, vaan ne ovat ikuisia taistelulaivoja. Monivuotiset aikataulut olivat yleisiä paitsi ohjelmistokehityksessä myös valmistuksessa ja muussa yritystoiminnassa. Vesiputouksen jäykkyydestä tuli kuitenkin Achilles-kantapää Internet-aikakaudella, jossa vaadittiin nopeutta ja joustavuutta.
Ohjelmistokehitysmenetelmät alkoivat muuttua, kun kehittäjät alkoivat työskennellä Internet-sovellusten parissa. Paljon varhaisesta työstä tehtiin startup-yrityksissä, joissa joukkueet olivat pienempiä, sijaitsi ja joilla ei usein ollut perinteistä tietojenkäsittelytaustaa. Oli taloudellisia ja kilpailupaineita tuoda verkkosivustoja, sovelluksia ja uusia ominaisuuksia markkinoille nopeammin. Kehitystyökalut ja -alustat muuttuivat nopeasti vastauksena.
Tämä sai monet meistä startup-yrityksissä kyseenalaistamaan vesiputousmenetelmät ja etsimään tapoja olla tehokkaampia. Meillä ei ollut varaa tehdä kaikkia yksityiskohtaisia asiakirjoja etukäteen, ja tarvitsimme iteratiivisempaa ja yhteistyöprosessia. Keskustelimme edelleen vaatimusten muutoksista, mutta olimme avoimempia kokeilulle ja sopeutumiselle loppukäyttäjien tarpeisiin. Organisaatiomme olivat vähemmän jäsenneltyjä ja sovelluksemme vähemmän monimutkaisia kuin yrityksen vanhat järjestelmät, joten olimme paljon avoimempia rakentamiseen verrattuna ostosovelluksiin. Mikä tärkeintä, yritimme kasvattaa yrityksiä, joten kun käyttäjät kertoivat meille, että jokin ei toiminut, päätimme useammin kuin ei kuunnella niitä.
Taidoistamme ja kyvystämme innovoida tuli strategisesti tärkeitä. Voisit kerätä kaiken haluamasi rahan, mutta et voi houkutella lahjakkaita ohjelmistokehittäjiä, jotka kykenevät työskentelemään nopeasti muuttuvien Internet-tekniikoiden kanssa, jos aiot kohdella heitä alistuvina koodereina orjuudella "spesifikaation" mukaisesti. Hylkäsimme projektipäälliköt, jotka saapuivat end-to-end-aikatauluilla, joissa kuvataan, mitä meidän tulisi kehittää, milloin sovellusten pitäisi toimittaa, ja joskus jopa kuinka koodi rakennetaan. Olimme kauheita lyömällä kolmen ja kuuden kuukauden aikatauluja, jotka vesiputouksen projektipäälliköt laativat ja päivittivät lakkaamatta.
Sen sijaan aloimme kertoa heille, kuinka Internet-sovellukset oli suunniteltava, ja toimitimme tulokset aikataulun mukaisesti, jonka laadimme iteratiivisesti. On käynyt ilmi, että emme olleet niin huonoja toimittamaan sanomiamme, kun sitoutuimme siihen pienissä, viikon tai neljän viikon välein.
Vuonna 2001 ryhmä kokeneita ohjelmistokehittäjiä kokoontui yhteen ja huomasi harjoittavansa yhdessä ohjelmistokehitystä eri tavalla kuin perinteinen vesiputousmenetelmä. Ja he eivät kaikki olleet startup-yrityksissä. Tämä ryhmä, johon kuului teknologiavalaisimet Kent Beck, Martin Fowler, Ron Jeffries, Ken Schwaber ja Jeff Sutherland, keksi Agile-manifestin, joka dokumentoi heidän yhteiset uskomuksensa modernin ohjelmistokehitysprosessin toiminnasta. He korostivat dokumentointiin liittyvää yhteistyötä, itseorganisaatiota pikemminkin kuin jäykkiä hallintokäytäntöjä ja kykyä hallita jatkuvaa muutosta sen sijaan, että lukitsisit itsesi jäykkään vesiputouksen kehitysprosessiin.
Näistä periaatteista syntyi ohjelmistokehityksen ketterä metodologia.
Roolit ketterässä metodologiassa
Ketterä ohjelmistokehitysprosessi alkaa aina määrittelemällä käyttäjät ja dokumentoimalla visio lausunnosta käsiteltävien ongelmien, mahdollisuuksien ja arvojen laajuudesta. Tuotteen omistaja kuvaa tämän vision ja työskentelee monialaisen tiimin (tai ryhmien) kanssa tämän vision toteuttamiseksi. Tässä ovat roolit prosessissa.
Käyttäjä
Ketterät prosessit alkavat aina käyttäjän tai asiakkaan mielessä. Tänään määritämme ne usein käyttäjähenkilöillä havainnollistamaan ohjelmiston tukeman työnkulun erilaisia rooleja tai erityyppisiä asiakkaiden tarpeita ja käyttäytymistä.
Tuotteen omistaja
Ketterä kehitysprosessi alkaa itse joku, jonka vaaditaan olevan asiakkaan ääni, mukaan lukien kaikki sisäiset sidosryhmät. Kyseinen henkilö tislaa kaikki oivallukset, ideat ja palautteen tuotevision luomiseksi. Nämä tuotevisiat ovat usein lyhyitä ja suoraviivaisia, mutta silti ne kuvaavat kuvan siitä, kuka asiakas on, mitä arvoja käsitellään, ja strategian siitä, miten niihin vastata. Voin kuvitella, että Googlen alkuperäinen visio näytti olevan "Tehkäämme jokaiselle, jolla on internetyhteys, helppo löytää asiaankuuluvia verkkosivustoja ja verkkosivuja yksinkertaisella, avainsanavetoisella käyttöliittymällä ja algoritmilla, joka sijoittaa hyvämaineiset lähteet hakutuloksiin."
Kutsumme tätä henkilöä tuotteen omistaja. Hänen vastuullaan on määritellä tämä visio ja työskennellä sen jälkeen kehitystiimin kanssa sen toteuttamiseksi.
Yhteistyössä kehitystiimin kanssa tuotteen omistaja jakaa tuotevision sarjaksi käyttäjäkertomuksia, joissa kerrotaan tarkemmin kuka on kohdekäyttäjä, mikä ongelma heille on ratkaistu, miksi ratkaisu on tärkeä heille, ja mitkä rajoitukset ja hyväksymiskriteerit määrittävät ratkaisun. Tuotteen omistaja priorisoi nämä käyttäjäkertomukset, ja tiimi tarkistaa ne, jotta heillä olisi yhteinen käsitys siitä, mitä heiltä kysytään.
Ohjelmistokehitystiimi
Ketterässä kehitystiimin ja sen jäsenten vastuut eroavat perinteisen ohjelmistokehityksen vastuista.
Joukkueet ovat monitieteisiä, ja ne koostuvat monipuolisesta joukosta ihmisiä, joilla on taidot työn suorittamiseen. Koska painopiste on toimivien ohjelmistojen toimittamisessa, tiimin on saatava valmiiksi toimivat sovellukset valmiiksi. Joten tietokanta, liiketoimintalogiikka ja käyttöliittymä osa sovelluksen osa kehitetään ja esitellään sitten - ei koko sovellusta. Tätä varten tiimin jäsenten on tehtävä yhteistyötä. He tapaavat usein varmistaakseen, että kaikki ovat linjassa sen kanssa, mitä he rakentavat, kuka tekee mitä ja miten ohjelmistoa kehitetään.
Kehittäjien lisäksi ohjelmistokehitystiimeihin voi kuulua laadunvarmistusinsinöörejä (QA), muita insinöörejä (kuten tietokantoihin ja taustajärjestelmiin), suunnittelijoita ja analyytikkoja ohjelmistoprojektin tyypistä riippuen.
Scrum, Kanban ja muut ketterät kehykset
Monet ketterät kehykset, jotka tarjoavat kehitysprosessien ja ketterien kehityskäytäntöjen yksityiskohtia ohjelmistokehityksen elinkaaren mukaisesti.
Suosituinta ketterää kehystä kutsutaan scrum. Se keskittyy toimitusajoon, jota kutsutaan a sprintti ja kokousrakenteet, jotka sisältävät seuraavat:
- Suunnittelu - missä sprintin prioriteetit määritetään
- Sitoutuminen - jossa tiimi tarkistaa luettelon tai myöhästyneiden käyttäjien tarinoista ja päättää kuinka paljon työtä sprintin aikana voidaan tehdä
- Päivittäiset standup-kokoukset - jotta tiimit voivat välittää päivityksiä kehitystilastaan ja strategioistaan)
Sprintit päättyvät esittelykokoukseen, jossa toiminnot näytetään tuotteen omistajalle, minkä jälkeen seuraa retrospektiivinen kokous, jossa tiimi keskustelee siitä, mikä meni hyvin ja mitä prosessissa on parannettava.
Monet organisaatiot käyttävät scrum-päälliköitä tai -valmentajia auttamaan tiimejä hallitsemaan scrum-prosessia.
Vaikka scrum hallitsee, on olemassa myös muita ketteriä kehyksiä:
- Kanban toimii fan-in- ja fan-out -prosessina, jossa joukkue vetää käyttäjäkertomuksia sisääntulolaudalta ja lähettää ne vaiheittaisessa kehitysprosessissa loppuun saakka.
- Jotkut organisaatiot omaksuvat hybridi ketterän ja vesiputoisen lähestymistavan, jossa käytetään ketteriä prosesseja uusissa sovelluksissa ja vesiputouksia vanhoissa.
- On myös useita kehyksiä, joiden avulla organisaatiot voivat skaalata käytännön useaan ryhmään.
Ketterät kehykset määrittelevät prosessin ja yhteistyön, mutta ketterät kehityskäytännöt koskevat erityisesti ohjelmistokehitystehtäviä, jotka suoritetaan ketterän kehyksen mukaisesti.
Joten esimerkiksi:
- Jotkut joukkueet ottavat käyttöön pariohjelmoinnin, jossa kaksi kehittäjää koodaa yhdessä saadakseen parempaa laatua koodin ja antaakseen vanhemmille kehittäjille mahdollisuuden ohjata nuorempia.
- Kehittyneemmät tiimit ottavat käyttöön testilähtöisen kehityksen ja automaation varmistaakseen, että taustalla oleva toiminnallisuus tuottaa odotetut tulokset.
- Monet tiimit ottavat käyttöön myös tekniset standardit, jotta kehittäjän tulkinta käyttäjäkertomuksesta ei johda vain haluttuun toiminnallisuuteen, vaan täyttää myös suojauksen, koodin laadun, nimeämiskäytännöt ja muut tekniset standardit.
