Ketterät terminologiat ja määritelmät

Hyväksyntätestaus

Muodollinen testaus sen selvittämiseksi, täyttääkö järjestelmä hyväksymiskriteerinsä, ja jotta asiakas voi päättää, hyväksyykö se järjestelmän vai ei.

Ketterä ohjelmistokehitysmenetelmä


Ketterä ohjelmistokehitys painottaa voimakkaasti yhteistyötä, muutokseen reagoimista ja jätteen vähentämistä koko kehitysjakson ajan. Ketterä ohjelmistokehitys keskittyy pitämään koodi yksinkertaisena, testaamaan usein ja toimittamaan sovelluksen toiminnalliset bitit heti, kun ne ovat valmiita.

Tärkeä ketterä periaate on toimittaa (mahdollisesti) irrotettavat ohjelmistot jokaisen iteraation jälkeen.


Takautuva hoito

Tilauskannan hoito on prosessi, jolla lisätään uusia käyttäjäkertomuksia myöhästymiseen, priorisoidaan olemassa olevat tarinat uudelleen tarpeen mukaan, luodaan arvioita ja puretaan suuremmat tarinat pienemmiksi tarinoiksi tai tehtäviksi. Sen sijaan, että tiimi hoitaisi tilannetta satunnaisesti koko iteraation ajan, joukkue voi pitää virheenkorjausistunnon kerran iteraatiota kohti.

Rakenteen rikkominen

Kun kehittäjä lisää lähdekoodivarastoon muutoksia, jotka johtavat myöhemmän rakennusprosessin epäonnistumiseen, kehittäjä on 'rikkonut koontiversion'.


Sen pitäisi olla joukkueen sitoutuminen välttämään rakenteen rikkomista, koska se hidastaa kehitystä ja voi olla pullonkaula muille kehittäjille. Kun koontiversio on rikki, kehitystiimin on ryhdyttävä välittömästi korjaamaan koontiversio.

Koontiversio on rikki, jos rakennusprosessia ei voida suorittaa loppuun monista syistä, mukaan lukien (mutta ei rajoittuen) kääntämisen epäonnistuminen, kelpaamattomat varoitukset tai mikä tahansa automaattisten testien epäonnistuminen.

Rakennusprosessi / putkilinjan rakentaminen

Rakennusprosessi tai rakenneputki on prosessi, jossa tarina kulkee alusta tuotantoon, yleensä läpi eri vaiheiden ja tarkastusten laadun varmistamiseksi.


Koontiputki määrittelee ohjelmiston toimituksen työnkulun ja sen, mitä kussakin vaiheessa tapahtuu.

Palovuokaavio

Kaavio, joka näyttää päivässä jäljellä olevien tehtävien kokonaismäärän. Se osoittaa, missä joukkue seisoo sprintille sitoutuneiden tehtävien suorittamisessa. X-akseli edustaa päiviä sprintissä, kun taas Y-akseli on jäljellä vaivaa.

Kana


Kana on slangin sana, jota käytetään projektista kiinnostuneelle henkilölle, jolla ei ole vastuuta työstämisestä aktiivisessa iteraatiossa. He voivat tarkkailla ryhmän kokouksia, mutta eivät voi äänestää tai puhua.

Jatkuva integraatio

Jatkuva integraatio (CI) on eXtreme Programming (XP) -käytäntö, jossa toimitusryhmän jäsenet integroivat työnsä usein (esim. Tunneittain tai vähintään kerran päivässä).

Jokainen integraatio tarkistetaan automatisoidulla koontiversiolla, joka suorittaa myös testauksen, jotta voidaan havaita kaikki integraatiovirheet nopeasti ja automaattisesti. CI: n päätavoitteena on välttää sitä, mitä yleisesti kutsutaan integraatioksi, tai yhdistää helvetti.


Monialainen ryhmä

Tiimi koostuu jäsenistä, joilla on kaikki toiminnalliset taidot ja erikoisuudet (usein kutsutaan monitaitoisiksi), jotka ovat tarpeen projektin suorittamiseksi alusta loppuun.

Asiakas

Asiakas määritellään yleensä tuotteen vastaanottajaksi tai käyttäjäksi. Asiakkaat voivat olla organisaation sisäisiä tai ulkopuolisia. Asiakas voi olla yksi henkilö, osasto tai suuri ryhmä.

Sisäisiä asiakkaita kutsutaan joskus 'liiketoiminnaksi'.

Päivittäinen valmiustila

Päivittäinen tiimikokous pidettiin yleensä aamulla ensimmäisenä tarjotakseen tilapäivityksen tiimin jäsenille. Kokoukset ovat yleensä 5-15 minuutin aikarajoituksia, ja ne pidetään seisomaan muistuttaen ihmisiä pitämään kokous lyhyenä ja asiaankuuluvana.

Määritelmä Valmis (DoD)

Kriteerit työn hyväksymiseksi valmiiksi. Näiden kriteerien määrittäminen on koko tiimin, myös yrityksen, vastuulla. Yleensä on kolme tasoa 'Valmis' (tunnetaan myös nimellä Valmis-Valmis-Valmis):

  • Valmis: Kehitetty, toimii kehittäjän laatikossa
  • Valmis: Vahvistettu suorittamalla yksikötestit, koodin tarkistus jne.
  • Valmis: Vahvistettu toimitettavaksi laadulliseksi toiminnallisilla testeillä, arvosteluilla jne.

Tehtyjen tarkat kriteerit vaihtelevat eri organisaatioiden ja aloitteiden erityistarpeiden mukaan.

Eeppinen

Erittäin suuri käyttäjäkertomus, joka lopulta jaetaan pienempiin tarinoihin. Eepoja käytetään usein paikkamiehinä uusille ideoille ja niihin liittyville tarinoille, jotka kehitetään myöhemmissä sprintteissä.

Eeppiset tarinat auttavat ketteriä kehitystiimejä tehokkaasti hallitsemaan ja hoitamaan tuotekannan.

Arvio

Tuoteportissa olevien tarinoiden tai tehtävien koonmittauksesta sopiminen. Ketterissä projekteissa arviointi tehdään työstä vastuussa olevalla tiimillä, yleensä käyttämällä suunnittelupeliä tai pokeria.

Äärimmäinen ohjelmointi

Ketterä ohjelmistokehitysmenetelmä, jonka tarkoituksena on parantaa ohjelmistojen laatua ja reagointikykyä asiakkaiden muuttuviin vaatimuksiin.

XP kannattaa usein tapahtuvia julkaisuja lyhyissä kehitysjaksoissa, joiden tarkoituksena on parantaa tuottavuutta ja ottaa käyttöön tarkistuspisteitä, joissa voidaan ottaa käyttöön uusia asiakkaiden vaatimuksia.

Muita äärimmäisen ohjelmoinnin elementtejä ovat: pariohjelmointi, laajat koodiarvostelut, yksikötestaus, jatkuva integraatio muutamaksi.

Ominaisuus

Johdonmukainen yritystoiminto tai ohjelmistotuotteen tai -järjestelmän attribuutti. Ominaisuudet sisältävät yleensä monia yksityiskohtaisia ​​vaatimuksia. Yksi ominaisuus toteutetaan tyypillisesti monien tarinoiden kautta.

Ominaisuudet voivat olla toiminnallisia tai ei-toiminnallisia; ne tarjoavat perustan tarinoiden järjestämiselle.

Fibonacci-sekvenssi

Numerosarja, jossa seuraava luku on johdettu lisäämällä kaksi edellistä (esim. 1, 2, 3, 5, 8, 13, 21, 34…). Sarjaa käytetään koon arviointiin ketterissä arviointitekniikoissa, kuten pokerin suunnittelussa.

Esteettömyys

Kaikki, mikä estää tiimin jäsentä suorittamasta työtä mahdollisimman tehokkaasti, on este. Jokaisella tiimin jäsenellä on mahdollisuus ilmoittaa esteistä päivittäisen standup-kokouksen aikana.

ScrumMasterin tehtävänä on varmistaa esteiden poistaminen mahdollisimman pian, jotta tiimi voi jatkaa tuottavuutta.

Toisto

Aika (1 viikosta 2 kuukauteen), jonka aikana ketterä kehitystiimi tuottaa valmiiden ohjelmistojen lisäykset. Kaikki järjestelmät elinkaaren vaiheet (vaatimukset, suunnittelu, koodi ja testi) on suoritettava iteraation aikana ja osoitettava sitten, että iterointi hyväksytään onnistuneesti.

Iteraation alussa yritys tai tuotteen omistaja yksilöi seuraavan (tärkeimmän prioriteetin) työryhmän suorittaman työn. Kehitystiimi arvioi sitten työn tason ja sitoutuu suorittamaan osan työstä iteroinnin aikana.

Kanban

Kanban on vähärasvaisesta valmistuksesta johdettu työkalu, joka liittyy ketterien käytäntöjen haaraan, jota kutsutaan löyhästi nimellä Lean Software Development. Kanban rajoittaa käynnissä olevan työn sallimista tapahtua samanaikaisesti.

Suurin ero Kanbanin ja Scrumin välillä on, että Scrum rajoittaa keskeneräisiä töitä sprinttien kautta ja Kanban rajoittaa keskeneräisiä töitä rajoittamalla kuinka paljon työtä voi tapahtua kerralla (esim. N tehtävää tai N tarinaa).

Lean-ohjelmistokehitys

Lean-ohjelmistokehitys tai vain Lean keskittyy jätteiden vähentämiseen ja ohjelmistojen tuotannon arvovirran optimointiin.

Pienin kannattava tuote (MVP)

Pienin toimiva tuote, joka voidaan rakentaa ja testata ja toimittaa tietyssä ajassa, joka tarjoaa käyttäjille lisäarvoa.

Parin ohjelmointi

Ketterä ohjelmistokehitystekniikka, jossa kaksi ohjelmoijaa työskentelee yhdessä yhdessä työasemassa. Yksi kirjoittaa koodin, kun taas toinen tarkistaa jokaisen koodirivin kirjoitettaessa. Kirjoittajaa kutsutaan ohjaimeksi. ja koodia tarkistavaa henkilöä kutsutaan tarkkailijaksi tai navigaattoriksi. Kaksi ohjelmoijaa vaihtaa roolia usein.

Sika

Joku, joka on vastuussa tehtävän suorittamisesta aktiivisella iteraatiolla. Se on päinvastainen kuin Chicken. Siat ovat aktiivisesti mukana projektissa.

Suunnittelu Pokeri

Planning Poker on konsensukseen perustuva arviointitekniikka, jota käytetään enimmäkseen ohjelmistokehityksen vaivojen tai tehtävien suhteellisen koon arvioimiseen. Joukkue käyttää fibonacci-sarjan tai T-paidan mitoitusta arvioidakseen tarinoita pokeripelin suunnittelun aikana.

Tuote

Yleisesti ottaen tuote viittaa kokoelmaan ominaisuuksia, jotka on integroitu ja pakattu ohjelmistojulkaisuihin, jotka tarjoavat arvoa asiakkaalle tai markkinoille.

Tuotteen omistaja

Tuotteen omistaja on yksi Scrumin avainrooleista. Tuotteen omistajan velvollisuuksiin kuuluu:

  • Tuotevision luominen, vaaliminen ja välittäminen
  • Kehittäjäryhmän luominen ja johtaminen asiakkaan parhaaksi tuottamiseksi
  • Projektin seuranta suhteessa ROI-tavoitteisiin ja investointivisioon
  • Päätösten tekeminen siitä, milloin virallinen julkaisu luodaan

Tuotteiden viivästyminen

Tuotekanta on kuin toivelista ominaisuuksista, jotka yritykset haluavat tarjota pitkällä aikavälillä. Se on kokoelma tarinoita ja tehtäviä, joiden kanssa tiimi työskentelee jossain vaiheessa tulevaisuudessa.

Tuotteen omistaja ylläpitää tätä luetteloa tuotekannasta liiketoiminnan prioriteettien ja tarpeiden mukaisesti. Tilauskannassa olevien kohteiden tulisi heijastaa liiketoimintasuunnitelmaa.

Refactoring

Olemassa olevan ohjelmistokoodin muuttaminen yleisen suunnittelun parantamiseksi. Refactoring ei yleensä muuta ohjelmiston havaittavaa käyttäytymistä; se parantaa sisäistä rakennettaan.

Vapautussuunnitelma

Julkaisusuunnitelma on aikataulu ohjelmistojen julkaisemiseen tuotantoon. Tyypilliset julkaisusuunnitelmat sisältävät toimitettavat keskeiset ominaisuudet sekä vastaavat julkaisupäivät.

Retrospektiivinen

Sprintin lopussa pidetty aikakokoinen kokous, jossa joukkue tutkii prosessejaan selvittääkseen, mikä onnistui ja mitä voitaisiin parantaa. Retrospektiivi on avain jatkuvaan parantamiseen.

Positiivinen tulos retrospektiiville on tunnistaa yksi tai kaksi tärkeätä toimintokohtaa, joiden kanssa tiimi haluaa työskennellä seuraavalla iteraatiolla tai julkaisulla.

Scrum

Scrum on kehys monimutkaisten ohjelmistotuotteiden kehittämiseksi iteratiivisesti ja inkrementaalisesti, ja se on tunnetuin ketterä kehys.

Scrum koostuu sarjasta lyhyitä iteraatioita - ns. Sprinttejä - joista jokainen päättyy toimivan ohjelmiston lisäyksen toimittamiseen.

Scrum-tiimi

Scrum-tiimi on monitoiminen ja itseorganisoituva ryhmä, joka vastaa ohjelmiston toimittamisesta.

Tutkimusryhmään kuuluu monitaitoisia ihmisiä, jotka ymmärtävät asiakkaiden vaatimukset ja suorittavat ohjelmistosuunnittelua, koodausta ja testausta. Lisätaitoja (esim. Käyttöliittymän suunnittelu, käytettävyys jne.) Voidaan myös sisällyttää.

Rummutiimi on vastuussa kaikista työhön liittyvistä sitoumuksista ja tuloksista.

ScrumMaster

ScrumMaster vastaa Scrum-prosessin ja tiimin yleisen terveyden ylläpidosta. ScrumMaster varmistaa, että joukkue on täysin toimiva ja tuottava poistamalla kaikki esteet, jotka saattavat estää tiimin etenemistä. ScrumMaster järjestää myös Scrum-seremoniat.

Piikki

Tarina tai tehtävä, jonka tarkoituksena on vastata kysymykseen tai kerätä tietoja tuotteen ominaisuuksien, käyttäjäkertomusten tai vaatimusten toteuttamisen sijaan.

Joskus syntyy käyttäjäkertomus, jota ei voida arvioida, ennen kuin kehitystiimi tekee todellisen työn teknisen kysymyksen tai suunnitteluongelman ratkaisemiseksi. Ratkaisu on luoda 'piikki', joka on tarina, jonka tarkoituksena on antaa vastaus tai ratkaisu.

Sprintti

Tuotekehityksessä sprintti on asetettu ajanjakso, jonka aikana tietty työ on saatava päätökseen ja tehtävä tarkasteltavaksi. Tyypillinen sprintin pituus on yleensä 2 viikkoa ja yleensä enintään 4 viikkoa.

Sprint Backlog

Luettelo ominaisuuksista, käyttäjäkertomuksista tai tehtävistä, jotka vedetään tuoteraportista harkittavaksi loppuun saattamista varten tulevan sprintin aikana. Tuotteiden myöhästymisominaisuudet ja käyttäjäkertomukset on jaoteltu tehtäviin muodostaakseen sprintitilanteen sprintin suunnittelukokouksen aikana.

Tarinan hoito

Tarinoiden hoitotilaisuuksissa käyttäjäkertomusten yksityiskohdat täsmennetään. Hyväksymiskriteerit kirjoitetaan ja laaditaan. Tarinoita arvioidaan myös tässä vaiheessa.

Tämän istunnon tarkoituksena on varmistaa, että kaikilla tarinoiden kehittämiseen ja testaamiseen osallistuvilla on yhteinen käsitys tarinoiden kontekstista ennen tarinoiden kehittämisen aloittamista.

Tarinanhoitoharjoitukset pidetään yleensä seuraavan sprintin sprintin puolivälissä, jotta joukkue on tietoinen seuraavan sprintin työmäärästä.

Osallistujat ovat scrum-tiimi, scrum master ja tuotteen omistaja.

Sprintin suunnittelu

Sprintin suunnitteluistunnot pidetään juuri ennen uuden sprintin alkua. Tässä istunnossa joukkue tunnistaa tehtävät, jotka on tehtävä, ja päättää, kuinka monelle tarinapisteelle he voivat sitoutua tulevaa sprinttiä varten.

Ennen sprintinsuunnittelun tarinoita olisi pitänyt kehittää ja arvioida tarinojen hoitoharjoitusten aikana, jotta sprintin suunnittelussa ei hukata aikaa.

Osallistujat ovat scrum master ja scrum team.

Käyttäjän tarina

Käyttäjätarinan (alias tarina) voidaan ajatella olevan vaatimus, ominaisuus, jolla on jonkin verran liiketoiminnallista arvoa.

Tarinat kuvaavat työtä, joka on suoritettava tuotteen ominaisuuden toimittamiseksi. Tarinat ovat Scrum-tiimin, yritysomistajien ja tuotteen omistajan välisen viestinnän, suunnittelun ja neuvottelujen perusyksikkö.

Tarinat koostuvat seuraavista osista:

  • Kuvaus, yleensä liiketoiminnallisesti
  • Karkeaa arviointia varten koko, joka ilmaistaan ​​yleensä tarinapisteinä (kuten 1, 2, 3, 5)
  • Yksi tai useampi hyväksymiskriteeri, jossa on lyhyt kuvaus tarinan validoinnista

Tehtävä

Tehtävät ovat kuvauksia varsinaisesta työstä, jonka henkilö tai pari tekee tarinan täydentämiseksi. Ne ovat hallittavia, toteutettavissa olevia ja seurattavia työyksiköitä. Tarinaa kohti on tyypillisesti useita tehtäviä.

Tekninen velka

Termi, jonka on keksinyt Ward Cunningham kuvaamaan velvollisuutta, joka ohjelmisto-organisaatiolla on, kun se valitsee suunnittelun tai rakentamisen lähestymistavan, joka on tarkoituksenmukaista lyhyellä aikavälillä, mutta lisää monimutkaisuutta ja on kalliimpaa pitkällä aikavälillä.

T-paidan mitoitus

Menetelmä tarinan loppuun saattamiseksi tarvittavan työn arvioimiseksi T-paitakokoina, eli Pieni (S), Keskikokoinen (M), Suuri (L) tai X-Suuri (XL)

Aikataulu

Aikataulu on kiinteän pituinen aikajakso, joka on varattu jonkin tavoitteen saavuttamiseksi. Ketterässä kehityksessä iteraatiot ja sprintit ovat esimerkkejä aikalaatikoista, jotka rajoittavat työtä prosessissa ja vaiheittaista etenemistä.

Nopeus

Nopeus mittaa kuinka paljon työtä joukkue voi suorittaa iteraatiossa. Nopeus mitataan usein tarinoissa tai tarinapisteissä. Nopeus voi myös mitata tehtäviä tunteina tai vastaavana yksikkönä.

Nopeutta käytetään mittaamaan, kuinka kauan tietyllä tiimillä kestää tulevaisuuden tulokset ekstrapoloimalla sen aikaisemman suorituskyvyn perusteella.

Työn alla

Kaikki työt, joita ei ole saatu päätökseen, mutta joille on jo aiheutunut pääomakustannuksia organisaatiolle. Kaikkia ohjelmistoja, jotka on kehitetty mutta joita ei ole otettu tuotantoon, voidaan pitää käynnissä olevina töinä.