Kuvalähde: pixabay.com

Äärimmäinen ohjelmointi

Kuvittele tätä: Uuden tuotteen ohjelmistokehitysprojekti, joka perustuu markkinoille saattamisen etuihin, on juuri havaittu yrityksen tutkassa. Äärimmäisen ohjelmoinnin perinteiset menetelmät, joissa asiakas tietää ”tarkalleen” mitä haluavat, ovat ulkona. Tiimisi on pieni, ja se koostuu nuorista ammattilaisista, jotka todennäköisesti reagoivat hyvin radikaaliin projektinhallintamalliin. Mitkä ovat vaihtoehtosi?

Sanot todennäköisesti, ketterä projektijohtaminen, tietysti! Mutta mitä metodologiaa haluaisit käyttää? Vaihtoehtoja on useita: yhdestä löytyy erittäin suosittu Scrum: johon sisältyy lyhyiden ”sprinttien” luominen asiakkaan tehtävämäärien perusteella. Sitten siellä on Kanban, joka pyrkii optimoimaan työn kokonaisuuden. Mukana on myös Extreme-ohjelmointi, usein lyhennettynä XP: lle, joka keskittyy vahvistamaan perinteisten ohjelmointimallien positiivisia puolia, jotta ne toimisivat parhaalla mahdollisella tavalla.

Ääriohjelmointi on erittäin suosittu (vaikkakaan ei niin suosittu kuin Scrum) menetelmä, joka keskittyy vastaamaan muuttuviin asiakasvaatimuksiin. Ensimmäisen Extreme Programming -projektin aloitti maaliskuussa 1996 Kent Beck Chryslerissä. Hänen vuoden 1999 kirjassaan Extreme Programming Explained: Embrace Change hän selosti ohjelmistokehityksen näkökohtia.

Kent Beck oli myös edelläkävijä testilähtöisessä kehityksessä, joka asetti käyttötapatestauksen tutkaan parannuksena tapaan, jolla asiat sitten tehtiin: rivien ja koodirivien kirjoittamiseen ja sen testaamiseen. Hän oli myös yksi ketterän manifestin alkuperäisistä allekirjoittajista, auttaen manifestin muotoilemisessa muuttaa äärimmäisen ohjelmointiohjelmiston kirjoitustapaa.

Extreme-ohjelmoinnin viisi arvoa, jotka perustuvat selitettyyn ovat:

viestintä

Ääriohjelmointi ei riipu laajasta dokumentoinnista. Itse asiassa äärimmäisiä ohjelmointdokumentaatioita ehdotetaan vain tarvittaessa. Joten metodologia riippuu suuresti viestinnästä ryhmän jäsenten välillä ja myös käyttäjien kanssa.

Yksinkertaisuus

Tämä on Extreme-ohjelmoinnin ydin. Menetelmä suosii yksinkertaisia ​​malleja, ajattelematta liian kauas tulevaisuuteen, mutta keskittyen nykypäivän vaatimuksiin, samalla kun ohjelma itsessään on riittävän vankas lisäämään tulevaisuuden vaatimukset.

palaute

Tämä välttämätön silmukka eteen- ja taaksepäin erottaa ketterät järjestelmät yleensä ja erityisesti Extreme-ohjelmoinnin muista ohjelmistoprojektinhallintamenetelmistä. Jatkuva palaute voi toimia eri tavoin, mutta ne kaikki pyrkivät järjestelmän tehostamiseen ja luotettavuuteen.

Palaute voi olla eri makua:

  • Itse ohjelmasta: Koodi testataan voimakkaasti koko projektin kehitysjakson ajan, jotta kehittäjät voivat toteuttaa muutokset.
  • Asiakkaalta: Tämä on olennainen osa kaikkein ketterimpiä järjestelmiä. Asiakkaat kirjoittavat hyväksymistestejä, joihin kehitys perustuu, ja tämä muodostaa kehitysprosessin selkärangan. Kaikki iteraatiot toimitetaan myös asiakkaalle säännöllisen palautteen saamiseksi.
  • Ryhmästä: Kun uusi käyttötapaus / tarina on luotu, ryhmä palaa heti kustannuslaskelmien ja aikajanan arviointiin, vahvistaen vaatimuksia niiden noustessa. Ääriohjelmoinnissa kukaan ei “omista” mitään koodia, ja siksi äärimmäisissä ohjelmointiryhmissä kannustetaan palautetta toisen koodista.

rohkeus

Tämä saattaa tuntua oudolta arvolta äärimmäisissä ohjelmistojen kehittämisohjelmissa, jotka sopivat paremmin armeijan tai merijalkaväen kaltaisille! Ajattele kuitenkin sitä: Ohjelmistoprojektit ovat jo pitkään ollut perinteisten äärimmäisten ohjelmointimenetelmien mukaisten hallintotapojen takana; turvallinen mukavan laajan dokumentoinnin ja hierarkian avulla, joka ei salli innovaatioita. Tämä arvo on esimerkki Extreme-ohjelmoinnin ytimestä: Ole valmis hyppäämään ilman laskuvarjoa, jos se tulee siihen! Tarkastele tätä erilaista projektinjohtotyyliä ja ole valmis olemaan vastuullinen, luopumaan hierarkiasta ja olemaan vastuullinen ja työskentelemään tietämättä kaikkea alussa.

Kunnioittaminen

Kunnioitus, viides arvo, lisättiin myöhemmin, ja se tarkoittaa kunnioitusta muille ja itselleen. Se tarkoittaa myös koodin kirjoittamisen ja asiakkaan odotusten ja tarpeiden kunnioittamista. Tämä arvo perustuu myös eri sidosryhmien väliseen viestintään.

Äärimmäisen ohjelmointiprojektin aktiviteetit

Ääriohjelmointi erottaa projektin neljä yksinkertaista toimintaa. He ovat:

  • Koodaus : Ääriohjelmointi pitää tätä tärkeimpänä toimintana. "Ilman koodia ei ole mitään", sanoo Extreme-ohjelmoinnin perustaja Kent Beck.
  • Testaus : Koodi on vain se, ellei sitä testata. Ääriohjelmointi on pakkomielteinen testaamisessa: yksikkötesteillä varmistetaan, että koodi toimii, ja asiakkaan luomilla hyväksymistesteillä, joilla varmistetaan, että koodi testaa mitä on testattava.
  • Kuunteleminen: Kuuntelu, josta esimerkkinä viestinnän perusarvo, on toiminta, joka vaatii kehittäjiä olemaan vain kuulematta asiakkaita, mutta todella kuuntelemaan mitä he haluavat. Kehittäminen ja liiketoiminta ovat kaksi eri asiaa, ja usein kehittäjät eivät ymmärrä tietyn päätöksen liiketapausta. Asiakkaan tarpeet, samoin kuin kehittäjien tarpeet, muodostavat perustan “kuuntelemiselle”.
  • Suunnittelu : Se voi yllättää sinut, että ohjelmistokehitysprojektissa suunnittelutoiminta, usein niin tärkeä ja ensisijainen, sijoitetaan loppuun. Tämä johtuu siitä, että Extreme-ohjelmointi haluaa tietoisesti saada ihmiset pois "suunnitella ja kehittää" -mielestä, jota teollisuus on vaalinut monien vuosien ajan. Suunnittelun merkitystä ei pidä rajoittaa. Hyvä ja minimaalinen suunnittelu on pikemminkin yksi hankkeen tunnusmerkeistä.

Arvoista ja toiminnoista ilmenee Extreme-ohjelmoinnin 12 periaatetta, kuten sen perustaja on suunnitellut kirjassaan Extreme Programming Explained.

  • Suunnittelupeli
  • Pariohjelmointi
  • Testiohjattu kehitys
  • Koko joukkue
  • Jatkuva integraatio
  • Suunnittelun parantaminen
  • Pieniä julkaisuja
  • Koodausstandardit
  • Kollektiivinen koodinomistus
  • Yksinkertainen suunnittelu
  • Järjestelmän metafora
  • Kestävä vauhti

Muutama näistä äärimmäisistä ohjelmointikäytännöistä, jotka kaikki on kartoitettu ohjelmistosuunnittelun parhaisiin käytäntöihin, eroavat yleisistä Agile-menetelmistä. Joitakin äärimmäisen ohjelmoinnin käytäntöjä selitetään alla:

  1. Suunnittelupeli

Tämä on projektin suunnitteluosa, josta käytetään nimitystä “Planning Game”. Se sisältää suunnittelun seuraavalle iteraatiolle ja julkaisulle, neuvotellen käyttäjän / asiakkaan kanssa, sekä ryhmien sisäisen suunnittelun tehtävistä, joihin he työskentelevät.

  1. Pariohjelmointi

Tässä tarkoitetaan kahta ihmistä, jotka työskentelevät koodin palassa. Yksi henkilö, jota kutsutaan näppäimistöksi, kirjoittaa koodin, kun taas toinen, nimeltään näyttö, valvoo koodia kommentoidessaan ja tarkentamalla sitä tarpeen mukaan. Nämä kaksi ihmistä vaihtavat usein rooliaan. Tämän on osoitettu parantavan merkittävästi koodin tehokkuutta. Tämä ei välttämättä sovi kaikkiin kehitysskenaarioihin, ja se on jotain harkittavaa ennen Extreme-ohjelmointiin liittymistä.

  1. Testilähtöinen kehitys

Kaikki kirjoitettu koodi tarkistetaan yksikkökohtaisesti, ts. Jokainen koodiosa, jolla voidaan tehdä jotain, testataan ensin. Ääriohjelmointi painottaa paljon testausta. Tämä auttaa varmistamaan, että koodi toimii, ja niin, että sitä voidaan sitten harkita sisällyttämistä itse ääriohjelmointiprojektiin. Se on analoginen yksikkökokeisiin koulussa: testataan pieniä tietoja, jotta opettaja / opiskelija voi tehdä kurssikorjauksia eikä ryöstää vuotuisten kokeiden aikana!

  1. Suunnittelun parantaminen (reaktorointi)

XP-projektit pyrkivät yksinkertaisuuden ominaisuuteen perustuen parantamaan jatkuvasti kirjoitettua koodia. Tämä tarkoittaa, että koko koodia (ja joskus myös tietokantaa) parannetaan aina. Refaktorointi ei lisää mitään toimintoja; se vain parantaa olemassa olevaa koodia. Tekee siitä tiukemman ja selkeämmän. Se muistuttaa kirjoituskappaleen muokkaamista, kiillottamista ja parantamista.

  1. Yksinkertainen suunnittelu

Ääriohjelmoinnissa ominaisuuksia ei lisätä ennen kuin sitä erikseen vaaditaan. Vaikka tällä hetkellä työskentelevä koodi on hyvin samankaltainen kuin mitä tulevaisuudessa voidaan tarvita, sitä ei oteta käyttöön, ellei siitä sovitaan käyttäjän tarinaa.

  1. Järjestelmän metafora

Tähän sisältyy kaikkien nimeämiskäytäntöjen standardisointi siten, että niiden tarkoitus ja toiminta voidaan helposti selvittää. Esimerkiksi tai toiminnot voivat auttaa ohjelmoijia ymmärtämään niiden toiminnallisuuden. Tämä tulisi tehdä koko äärimmäisen ohjelmointiprojektin läpi, jotta kenen tahansa on helppo katsoa koodia ja muuttaa tai parantaa sitä tapauksen mukaan.

Roolit Extreme-ohjelmointiprojektissa:

Kuten Scrum, Extreme-ohjelmoinnilla on muutama nimetty rooli kussakin projektissa. Nyt rooleja ei tarvitse aina suorittaa erilliset ihmiset, ja henkilö voi ottaa useamman kuin yhden roolin.

Äärimmäiset ohjelmointiroolit ovat:

  • Asiakas : Selkeä. Projektin syy. Hän päättää, mitä projektin on tehtävä. Hän tarjoaa käyttäjän tarinoita.
  • Ohjelmoija : Tämä on henkilö, joka:
    • Tarinoita, jotka asiakas keksii
    • Luo ohjelmointitehtäviä tarinoista
    • Toteuttaa käyttäjän tarinat
    • Testaa koodin yksikkökohtaisesti
  • Valmentaja : Valmentaja yleensä varmistaa, että projekti on oikealla radalla, ja hyppää myös apua tarvittaessa.
  • Tracker : Tracker tekee erityisiä tiedusteluja ohjelmoijille asetetulla aikavälillä. Tyypillisesti hän kiertää ohjelmoijien edistymistä tarjoamalla apua tarvittaessa useilla tavoilla: kääntämällä hihat ylös ja auttamalla suoraan koodilla, antamalla valmentajalle tiedon tai perustamalla tapaamisen asiakkaan kanssa tarpeen mukaan.
  • Testeri : Suorittaa toiminnalliset testit. Testaaja ei suorita yksikkötestejä, jotka ohjelmoijat itse suorittavat.
  • Doomsayer: Tämä, kuten nimestä voi päätellä, muistuttaa mustaa hattua Edward De Bonon ryhmäajattelujärjestelmässä. Kuka tahansa voisi olla teeskentelijä, joka tyypillisesti merkitsee mahdolliset ongelmat ja auttaa pitämään vaikeudet oikeassa perspektiivissä.
  • Johtaja : Äärimmäisen ohjelmoinnin projektipäällikkö muistuttaa enemmän aikataulua, varmistaa, että kokoukset tapahtuvat suunnitellusti, ja varmistaa, että kokousten aikana tehdyt päätökset välitetään asianmukaiselle henkilölle, useimmiten Trackerille. Johtaja ei kuitenkaan kerro ihmisille, mitä tehdä ja milloin tehdä. Tämän tekevät asiakas ja / tai itse käyttäjätiedot.
  • Kullan omistaja : Kullan omistaja on henkilö, joka rahoittaa hanketta. Tämä voi olla asiakas, mutta ei välttämättä.

Jotkut yllä kuvatuista äärimmäisistä ohjelmointirooleista voidaan yhdistää, mutta osa selvästi ei.

Esimerkiksi asiakas ei voi myöskään olla Ohjelmoija. Ohjelmoija ja jäljittäjä eivät myöskään voi menestyksekkäästi olla sama henkilö.

Äärimmäiset ohjelmointiroolit on määritelty riittävän selkeästi, jotta ei tapahdu sekaannusta, ja ne luodaan maksimaalisen joustavuuden ja tehokkuuden kannalta.

Äärimmäisen ohjelmoinnin haitat:

Vaikka Ääriohjelmoinnin kannattajat maalaavat ruusuisen kuvan, tosiasia on, että Ääriohjelmointi, kuten nimi todennäköisesti viittaa, on erittäin vaikea toteuttaa. Äärimmäisen ohjelmoinnin piirteet voidaan sisällyttää hankkeisiin onnistuneemmin kuin XP: n täydellinen käyttöönotto.

Jotkut Extreme-ohjelmoinnin kielteistä ovat:

  • Ääriohjelmoinnin on todettu olevan tehokkaampi pienemmissä ryhmissä . Sen tehokkuus suuremmissa ryhmissä on kiistetty, ja parempi vaihtoehto on jakaa äärimmäiset ohjelmointiryhmät siten, että ryhmät ovat pienempiä.
  • Yksi Extreme-ohjelmoinnin keskeisistä ominaisuuksista, pariohjelmointi ei toimi monissa tapauksissa hyvin . Monimutkainen koodaus voi vaatia kahta päätä, mutta kaikki tehtävät eivät välttämättä edellytä kahta henkilöä, toisen henkilön ollessa paino. Itse asiassa pariohjelmointi, jos yksi jäsenistä ei ole tahdissa toisen kanssa, on yksi tärkeimmistä syistä, miksi Extreme-ohjelmointi epäonnistuu monissa tapauksissa.
  • Riippuvuus asiakkaasta siihen pisteeseen, että se ehdottaa paikan päällä olevaa resurssia asiakkaan puolelta, voi olla syventävä. Se voi myös johtaa häiriöihin, niin todellisiin kuin kuviteltuihin, kehityksen aikana.
  • Ääriohjelmoinnin keskittyminen yksinkertaisuuteen voi vaikeuttaa nykyiseen projektiin lisäämistä, mikä tarkoittaa suurempaa budjettia jopa yksinkertaisiin muutoksiin, jotka eivät enää jää yksinkertaisiksi.
  • Tasainen hierarkkinen rakenne tarkoittaa, että joukkueen tulisi aina olla keskittynyt, ja jos johtajaa ei ole olemassa eroavaisiin ihmisryhmiin, Extreme-ohjelmointiryhmä on täysin riippuvainen kaikkien joukkueen jäsenten emotionaalisesta kypsyydestä, tekijä, joka ei ole aina luotettava .

Näissäkin tekijöissä Extreme-ohjelmointi on edelleen tehokas työkalu oikeaan projektiin käytettäväksi. Yritykset ilmoittavat tehokkuudensa moninkertaistuneesta käytöstä äärimmäisen ohjelmointiprosessin jälkeen. Kehittäjälähtöinen järjestelmä, toisin kuin Scrum, joka on enemmän prosessiohjattua järjestelmää, Extreme Programming-ohjelmaa tai ainakin sen osia, voi johtaa vallankumoukseen äärimmäisten ohjelmointiohjelmistojen kehittämisessä.

Luokka:

Yrittäjyyden kehittäminen