Ketterä kehitysmetodologia

Ketterä kehitysmetodologia ( englanniksi  agile software development , agile development ) on yleinen termi useille lähestymistavoille ja käytännöille, jotka perustuvat Agile Software Development Manifeston arvoihin ja sen taustalla oleviin 12 periaatteeseen [1] .

Ketteriin menetelmiin kuuluvat erityisesti äärimmäinen ohjelmointi , DSDM , Scrum , FDD , BDD ja muut.

Useimmat ketterät menetelmät pyrkivät minimoimaan riskit vähentämällä kehitystä lyhyiden syklien sarjaksi, joita kutsutaan iteraatioiksi, jotka tyypillisesti kestävät kahdesta kolmeen viikkoa. Jokainen iteraatio itsessään näyttää pienoisohjelmistoprojektilta ja sisältää kaikki tehtävät, jotka ovat tarpeen minikasvun tuottamiseksi toiminnallisuudessa: suunnittelu, vaatimusanalyysi , suunnittelu , ohjelmointi , testaus ja dokumentointi . Vaikka yksi iteraatio ei yleensä riitä julkaisemaan uutta versiota tuotteesta, oletetaan, että ketterä ohjelmistoprojekti on valmis julkaistavaksi jokaisen iteraation lopussa. Jokaisen iteraation lopussa tiimi arvioi kehitysprioriteetit uudelleen.

Ketterät menetelmät korostavat kasvokkain tapahtuvaa viestintää. Useimmat ketterät tiimit sijaitsevat samassa toimistossa, jota joskus kutsutaan englanniksi.  härkäkynä . Se sisältää vähintään myös "asiakkaat" ( englanninkielinen  tuotteen omistaja  - asiakas tai tämän valtuutettu edustaja, joka määrittää tuotteen vaatimukset; tätä roolia voi suorittaa projektipäällikkö, liikeanalyytikko tai asiakas). Toimistossa voi olla myös testaajia, käyttöliittymäsuunnittelijoita, teknisiä kirjoittajia ja johtajia.

Kettereiden menetelmien päämittari on työtuote. Priorisoimalla kasvokkain tapahtuvan viestinnän ketterät menetelmät vähentävät kirjallisen dokumentaation määrää muihin menetelmiin verrattuna. Tämä on johtanut kritiikkiin näitä menetelmiä kohtaan kurittomina.

Historia

1990-luvulla useita kevyitä ohjelmistokehitysmenetelmiä kehitettiin vastauksena vallitseviin raskaisiin menetelmiin, joita kriitikot kutsuivat ylisäänneltyiksi, suunnitelluiksi ja mikrohallituiksi. Näitä ovat: Rapid Application Development (RAD) vuodesta 1991 [2] [3] ; yhtenäinen prosessi ja menetelmä dynaamisten järjestelmien kehittämiseksi vuodesta 1994; Scrum vuodesta 1995; Crystal Clear and Extreme Programming (XP), molemmat vuodesta 1996; ja ominaisuuslähtöistä kehitystä vuodesta 1997 lähtien. Vaikka ne kaikki syntyivät ennen ketterän manifestin julkaisemista, niitä kutsutaan nykyään yhteisesti ketteräksi ohjelmistokehitykseksi.

Helmikuussa 2001 " Agile Software Development Manifesto " julkaistiin Utahissa, Yhdysvalloissa . Se tarjosi vaihtoehdon dokumenttipohjaisille "raskassarjan" ohjelmistokehityskäytännöille, kuten " vesiputousmenetelmälle ", joka oli tuolloin kehityksen kultainen standardi. Tämän manifestin hyväksyivät ja allekirjoittivat seuraavien menetelmien edustajat: Extreme Programming , Crystal Clear , DSDM , Feature driven development , Scrum , Adaptive Software Development , Pragmatic Programming . Ketterä kehitysmetodologiaa käytettiin monissa yrityksissä jo ennen manifestin hyväksymistä, mutta ketterän kehityksen tulo massoihin tapahtui juuri tämän tapahtuman jälkeen.

Periaatteet

Ketterä on kehitysprosessien perhe, ei yksittäinen lähestymistapa ohjelmistokehityksessä, ja sen määrittelee ketterä manifesti [4] . Agile ei sisällä käytäntöjä, vaan määrittelee tiimejä ohjaavat arvot ja periaatteet.

Agile Manifesto kehitettiin ja hyväksyttiin 11.-13. helmikuuta 2001 The Lodge at Snowbird -hiihtokeskuksessa Utahin vuoristossa. Ketterä manifesti sisältää 4 pääideaa ja 12 periaatetta. On huomionarvoista, että ketterä manifesti ei sisällä käytännön neuvoja.

Tärkeimmät ideat:

• ihmiset ja vuorovaikutus ovat tärkeämpiä kuin prosessit ja työkalut;
• toimiva tuote on tärkeämpi kuin kattava dokumentaatio;
• yhteistyö asiakkaan kanssa on tärkeämpää kuin sopimusehdoista sopiminen;
• muutosvalmius on tärkeämpää kuin alkuperäisen suunnitelman noudattaminen.

Ketterän manifestin [6] perusperiaatteet :

• asiakastyytyväisyys arvokkaiden ohjelmistojen varhaisen ja keskeytymättömän toimituksen kautta tunnustetaan ensisijaiseksi tavoitteeksi;
• muuttuvat vaatimukset ovat tervetulleita myös kehityksen loppuvaiheessa (tämä voi lisätä tuloksena olevan tuotteen kilpailukykyä);
• toimivien ohjelmistojen toistuva toimitus (parin viikon tai parin kuukauden välein, mieluiten lyhyemmälle ajanjaksolle);
• liike-elämän edustajien ja kehittäjien välisen viestinnän tulisi olla päivittäin koko hankkeen ajan;
• hankkeet olisi rakennettava kiinnostuneiden ihmisten ympärille, joille olisi tarjottava oikeat työolosuhteet, tuki ja luottamus;
• tehokkain tapa jakaa tietoa tiimissä on henkilökohtainen tapaaminen;
• toimiva ohjelmisto on paras edistymisen mitta;
• sponsorien, kehittäjien ja käyttäjien on voitava ylläpitää tasaista tahtia loputtomiin;
• jatkuva huomio tekniseen huippuosaamiseen ja hyvään suunnitteluun lisää joustavuutta;
• yksinkertaisuus, kuten taito olla tekemättä tarpeetonta työtä, on erittäin tärkeää;
• parhaat vaatimukset, arkkitehtuuri ja suunnitteluratkaisut tulevat itseorganisoituvilta tiimeiltä;
• tiimi pohtii säännöllisesti tapoja tehostaa toimintaansa ja säätää työnkulkua sen mukaisesti.

Kritiikki

Yksi toistuvista kritiikin kohdista: ketterässä lähestymistavassa laiminlyödään usein tuotekehityssuunnitelman ("roadmap") laatiminen sekä vaatimusten hallinta , jonka yhteydessä tällainen "kartta" muodostuu. Joustava lähestymistapa vaatimusten hallintaan ei tarkoita kauaskantoisia suunnitelmia (itse asiassa vaatimusten hallintaa ei yksinkertaisesti ole olemassa tässä metodologiassa), vaan se tarkoittaa asiakkaan kykyä asettaa yhtäkkiä ja odottamatta uusia vaatimuksia jokaisen iteraation lopussa, usein ristiriidassa jo luodun ja toimitetun tuotteen arkkitehtuurin kanssa. Tämä johtaa toisinaan katastrofaalisiin "käsien töihin" massiivisen uudelleenkäsittelyn ja uudelleenkäsittelyn kanssa lähes jokaisessa seuraavassa iteraatiossa.

Lisäksi uskotaan, että ketterässä työskentely motivoi kehittäjiä ratkaisemaan kaikki saapuvat tehtävät yksinkertaisimmalla ja nopeimmalla mahdollisella tavalla, mutta usein ei kiinnitetä huomiota koodin oikeellisuuteen taustalla olevan alustan vaatimusten kannalta ("toimii ja kaikki" -lähestymistapaa) ottamatta huomioon, että koodi saattaa lakata toimimasta, jos sitä muutetaan edelleen. Tämä johtaa tuotteen laadun heikkenemiseen ja vikojen kertymiseen (katso " tekninen velka ").

Metodologiat

On olemassa menetelmiä, jotka noudattavat ketterässä manifestissa esitettyjä arvoja ja periaatteita, joista osa ovat:

• Agile Modeling  on joukko käsitteitä, periaatteita ja tekniikoita (käytäntöjä), joiden avulla voit suorittaa mallinnuksen ja dokumentoinnin nopeasti ja helposti ohjelmistokehitysprojekteissa. Ei sisällä yksityiskohtaisia ​​suunnitteluohjeita, ei sisällä kuvauksia UML-kaavioiden rakentamisesta. Päätavoite: tehokas mallintaminen ja dokumentointi; mutta se ei kata ohjelmointia ja testausta, ei sisällä projektinhallintaa, järjestelmän käyttöönottoa ja ylläpitoa. Se sisältää kuitenkin mallin tarkistamisen koodilla [7] .
• Agile Unified Process (AUP) on yksinkertaistettu versio Scott Amblerin kehittämästä IBM Rational Unified Processista ( RUP ), joka kuvaa yksinkertaisen ja ymmärrettävän approksimoinnin (mallin) yrityssovellusten ohjelmistojen rakentamiseen.
• Agile Data Method  on ryhmä iteratiivisia ohjelmistokehitysmenetelmiä, joissa vaatimukset ja ratkaisut saavutetaan erilaisten poikkitoimisten tiimien yhteistyöllä.
• DSDM perustuu Rapid Application Development (RAD) -konseptiin. Se on iteratiivinen ja inkrementaalinen lähestymistapa, joka korostaa jatkuvaa käyttäjän/kuluttajan osallistumista prosessiin.
• Essential Unified Process (EssUP).
• Extreme ohjelmointi ( Extreme ohjelmointi , XP ) . 
• Feature driven development (FDD) – ominaisuuskeskeinen kehitys. FDD:ssä käytetty järjestelmäominaisuuden tai ominaisuuden käsite on  melko lähellä RUP:ssa käytettyä käyttötapauksen käsitettä, merkittävä ero on lisärajoitus: "Jokaisen ominaisuuden tulee sallia käyttöönotto enintään kahdessa viikossa." Eli jos käyttötapaus on tarpeeksi pieni, sitä voidaan pitää ominaisuutena. Jos se on suuri, se on jaettava useisiin suhteellisen itsenäisiin toimintoihin.
• Getting Real  on iteratiivinen, ei-toiminnallinen määrittelytapa, jota käytetään verkkosovelluksissa. Tässä menetelmässä kehitetään ensin ohjelman käyttöliittymä ja sitten sen toiminnallinen osa.
• OpenUP  on iteratiivisesti inkrementaalinen ohjelmistokehitysmenetelmä. Se on sijoitettu kevyeksi ja joustavaksi versioksi RUPista . OpenUP jakaa projektin elinkaaren neljään vaiheeseen: aloitus, jalostus, rakentaminen ja luovutus. Hankkeen elinkaari tarjoaa sidosryhmille ja tiimin jäsenille viitepisteitä ja päätöksentekoa koko projektin ajan. Näin voit hallita tilannetta tehokkaasti ja tehdä oikea-aikaisia ​​päätöksiä tulosten hyväksyttävyydestä. Hankesuunnitelma määrittelee elinkaaren ja lopputuloksena on lopullinen sovellus.
• Scrum määrittää säännöt kehitysprosessin hallintaan ja antaa sinun käyttää olemassa olevia koodauskäytäntöjä säätämällä vaatimuksia tai tekemällä taktisia muutoksia. Tämän menetelmän avulla voidaan tunnistaa ja eliminoida poikkeamat halutusta tuloksesta ohjelmistotuotekehityksen aikaisemmissa vaiheissa.
• Lean ohjelmistokehitys ( englanniksi  lean software development ) käyttää lähestymistapoja lean-valmistuksen käsitteestä .

Muistiinpanot

1. ↑ Mitä ketterä ohjelmistokehitys on? . Ketterä Alliance. - "Ketterä ohjelmistokehitys on kattotermi joukolle kehyksiä ja käytäntöjä, jotka perustuvat ketterän ohjelmistokehityksen manifestissa ja sen taustalla oleviin 12 periaatteeseen ilmaistuihin arvoihin ja periaatteisiin." Haettu 29. kesäkuuta 2019. Arkistoitu alkuperäisestä 31. heinäkuuta 2018. (määrätön)
2. ↑ Martin, James. Nopea sovelluskehitys . - Macmillan, 1991. - ISBN 978-0-02-376775-3 .
3. ↑ Kerr, James M.; Hunter, Richard. Inside RAD: Kuinka rakentaa täysin toimiva järjestelmä 90 päivässä tai vähemmän . - McGraw-Hil, 1993. - ISBN 978-0-07-034223-1 .
4. ↑ Agile Manifesto arkistoitu 23. helmikuuta 2011 Wayback Machinessa 
5. ↑ Ketterän manifestin perusperiaatteet . agilemanifesto.org. Käyttöpäivä: 8. joulukuuta 2016. Arkistoitu alkuperäisestä 25. joulukuuta 2014. (määrätön)
6. ↑ Ketterä mallinnus . Hoitopäivä: 25. joulukuuta 2011. Arkistoitu alkuperäisestä 31. joulukuuta 2008. (määrätön)

Kirjallisuus

• Mike Cohn. Scrum: Ketterä ohjelmistokehitys = Ketterän kanssa menestyminen: Scrum-ohjelmistokehitys (Addison-Wesley Signature Series). - M. : "Williams" , 2011. - S. 576. - ISBN 978-5-8459-1731-7 .
• Robert S. Martin, James W. Newkirk, Robert S. Koss. Nopea ohjelmistokehitys. Periaatteet, esimerkit, käytäntö = Ketterä ohjelmistokehitys. periaatteet, mallit ja käytännöt. - Williams, 2004. - 752 s. — ISBN 0-13-597444-5 .
• James A. Highsmith. Ketterät ohjelmistokehityksen ekosysteemit . - Addison-Wesley Professional, 2002. - ISBN 978-0-201-76043-9 .