Alai

Jos tietäisimme, mitä olemme tekemässä, sitä ei kutsuttaisi tutkimukseksi.

-Albert Einstein

Spikes ovat eräänlainen exploration Enabler Story SAFessa. Ne määriteltiin alun perin Extreme Programmingissa (XP), ja ne edustavat toimintoja, kuten tutkimusta, suunnittelua, tutkintaa, eksploraatiota ja prototyyppien luomista. Niiden tarkoituksena on hankkia tietoa, jota tarvitaan teknisen lähestymistavan riskien pienentämiseen, vaatimuksen parempaan ymmärtämiseen tai tarina-arvion luotettavuuden lisäämiseen.

Kuten muutkin tarinat, piikit arvioidaan ja demonstroidaan sitten iteraation lopussa. Ne tarjoavat myös sovitun protokollan ja työnkulun, jota Agile Release Trains (ART) käyttää apuna epikoiden elinkelpoisuuden määrittämisessä.

Agile ja Lean arvostavat faktoja spekulaatioiden sijaan. Kun ketterät tiimit kohtaavat kysymyksen, riskin tai epävarmuuden, ne tekevät pieniä kokeiluja ennen toteutukseen siirtymistä sen sijaan, että spekuloisivat lopputulosta tai hyppäisivät ratkaisuun. Tiimit voivat käyttää piikkejä erilaisissa tilanteissa:

• Arvioidakseen uusia ominaisuuksia ja kyvykkyyksiä analysoidakseen niiden implisiittistä käyttäytymistä ja antaakseen tietoa lähestymistavasta, jolla ne voidaan jakaa pienempiin, mitattavissa oleviin osiin
• Toteuttaakseen toteutettavuusanalyysejä ja muita toimintoja, jotka auttavat määrittelemään eepoksen elinkelpoisuutta
• Toteuttaakseen perustutkimusta, jolla ne voivat perehtyä uuteen tekniikkaan tai toimialueeseen
• Luottamuksen hankkiminen teknistä tai toiminnallista lähestymistapaa kohtaan, vähentää riskiä ja epävarmuutta

Piikkeihin liittyy pienen ohjelman, tutkimustoiminnan tai testin luominen, joka demonstroi jonkin uuden toiminnallisuuden näkökohdan.

Tekniset ja toiminnalliset piikit

Piikkejä on pääasiassa kahdessa muodossa: teknisiä ja toiminnallisia.

Toiminnalliset piikit – Niitä käytetään ratkaisun kokonaiskäyttäytymisen analysointiin ja sen määrittämiseen:

• Miten se hajotetaan
• Miten työ organisoidaan
• Missä on riskejä ja monimutkaisuutta
• Miten oivalluksia käytetään vaikuttamaan toteutuspäätöksiin

Tekniset piikit – Niitä käytetään erilaisten lähestymistapojen tutkimiseen ratkaisun toimialueella. Esimerkiksi:

• Kehitä build-versus-buy-päätös
• Arvioi uuden käyttäjätarinan mahdollisia suorituskyky- tai kuormitusvaikutuksia
• Arvioi tiettyjä teknisiä toteutuslähestymistapoja
• Kehitä luottamusta haluttuun ratkaisupolkuun

Joidenkin ominaisuuksien ja käyttäjätarinoiden kohdalla saatetaan tarvita molempien tyyppisiä piikkejä. Tässä on esimerkki:

”Kuluttajana haluan nähdä päivittäisen energiankulutukseni histogrammina, jotta voin nopeasti ymmärtää menneen, nykyisen ja ennustetun energiankulutukseni.”

Tässä tapauksessa ryhmä saattaa luoda molempien tyyppisiä piikkejä:

• Tekninen piikki, jolla tutkitaan, kuinka kauan kestää päivittää asiakasnäyttö nykyiseen kulutukseen, määritetään viestintävaatimukset, kaistanleveys ja se, työnnetäänkö vai vedetäänkö tiedot
• Toiminnallinen piikki – Prototyypitäkää histogrammi verkkoportaalissa ja hankkikaa käyttäjäpalautetta esitystavan koosta, tyylistä ja kaaviokuvasta

Ohjeita piikkejä varten

Koska piikit eivät tuota suoraa lisäarvoa käyttäjälle, käyttäkää niitä niukasti. Sovelletaan seuraavia ohjeita.

Kvantifioitavissa, osoitettavissa ja hyväksyttävissä

Kuten muutkin tarinat, piikit laitetaan tiimin Backlogiin, arvioidaan ja mitoitetaan siten, että ne mahtuvat iteraatioon. Piikkien tulokset eroavat tarinasta, koska piikit tuottavat tyypillisesti pikemminkin tietoa kuin toimivaa koodia. Niiden pitäisi kehittää vain tarvittava tieto, jotta sitä ajavat tarinat voidaan tunnistaa ja mitoittaa luotettavasti.

Piikin tuotos on osoitettavissa sekä tiimille että muille sidosryhmille, mikä tuo näkyvyyttä tutkimus- ja arkkitehtuuripyrkimyksille ja auttaa myös rakentamaan kollektiivista omistajuutta ja jaettua vastuuta päätöksenteosta. Tuoteomistaja hyväksyy piikit, jotka on demonstroitu ja jotka täyttävät sen hyväksymiskriteerit.

Piikkien ajoitus

Koska piikit edustavat epävarmuutta yhdessä tai useammassa mahdollisessa tarinassa, sekä piikin että sen tuloksena syntyvien tarinoiden suunnittelu samassa iteraatiossa on joskus riskialtista. Jos kyseessä on kuitenkin pieni ja suoraviivainen tarina, johon todennäköisesti löytyy nopea ratkaisu, voi olla varsin tehokasta tehdä molemmat samassa iteraatiossa.

Poikkeus, ei sääntö

Jokaiseen käyttäjätarinaan liittyy epävarmuutta ja riskejä; se on ketterän kehityksen luonne. Tiimi löytää oikean ratkaisun keskustelun, yhteistyön, kokeilujen ja neuvottelujen kautta. Näin ollen tietyssä mielessä jokainen käyttäjätarina sisältää piikkimäisiä toimintoja teknisten ja toiminnallisten riskien tunnistamiseksi. Ketterän tiimin tavoitteena on oppia käsittelemään epävarmuutta jokaisessa iteraatiossa. Piikit ovat kriittisiä, kun epävarmuutta on paljon tai tuntemattomia on paljon.

Learn More

Leffingwell, Dean. Ketterät ohjelmistovaatimukset: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison Wesley, 2011.

Viimeisin päivitys: 10.2.2021