Specification by Example by Gojko Adzic

Specification by Example seminar Proeksperdis

1. novembril toimus Proeksperdis inspireeriva Gojko Adzic-i poolt läbi viidud seminar Winning big with Specification by Example (SBE). SBE on oma olemuselt kollaboratiivne lähenemine nõuete defineerimisele – fookus on kommunikatsioonil ja reaalsetel näidetel, et kõigil osapooltel tekiks ühine arusaam loodava süsteemi funktsionaalsusest. Positiivse lisana muutuvad SBE “õigel” rakendamisel nõuded ka automaatselt valideeritavateks – teatud tööriistade abil saab kõigile loetavas formaadis kirja pandud nõuded automaat-testideks muuta.

 

Enne edasi minekut on ilmselt paslik mõne lausega ka Gojko tausta puudutada:

Ühesõnaga, väga aktiivne ja mõjukas mees, kes on tegus väga mitmel erineval rindel.

Gojko Proeksperdis koolitamas

Kuna seminarist olid huvitatud rohkem kui pooled Proeksperdi töötajad, siis kontori nõupidamisruumidesse oleks nad vaid püstijalu ära mahtunud. Seega kogunes pea 70 huvilist igast Proeksperdi valdkonnast hoopis Cafe Gustavisse ning ootused paistsid kõigil kõrged olevat.

 

Edulood

Gojko alustas peibutistega – edulood tiimidest, kes SBE olid kasutusele võtnud, tundusid mõnikord peaaegu nagu muinasjutust. Mõned näited:

  • suur süsteem pangas, mis on juba 5 aastat major incident’ideta töötanud (BNP Paribas).
  • meeskond, kes 9 kuud pärast SBEga alustamist loobus bugtracking süsteemist üleüldse, sest seda polnud lihtsalt enam vaja (Weyerhaeuser)
  • projekt läks live’sse ilma probleemideta, äripoole inimesed raporteerisid nõukogule, et tegu oli parima user acceptance testing kogemusega nende ajaloos (JP Morgan).

 

Sammud paremate nõueteni

Edasi pani ta inimesed mõtlema protsesside ja mustrite peale, mis võiksid viia elava dokumentatsioonini (näidetega nõuded koos võimalusega neid kiiresti ja automaatselt valideerida).

  1. Kõige alus on tihe koostööst erinevate osapoolte vahel – arendajad, juhid, analüütikud, testijad ja mistahes kliendi esindajad tuleb omavahel rääkima panna. Kui tellija ei leia kohtumisteks aega, peaks talt küsima, et kas see on üldse piisavalt tähtis projekt või saab meeskond ehk millegi prioriteetsemaga tegeleda.
  2. “Ühe tõe allikas” pole vähem olulisem – nõuded ei  tohiks olla laiali wikis, koodis, emailides, postititel, inimeste peades jne.
  3. Reaalsed (ja relevantsed!) näited nõuetes (ümmarguse jutu asemel) on paljude tiimide jaoks see koht, kust enam edasi ei minda – juba sinnani jõudmine on väga palju kasu toonud.
  4. Edukamad tiimid teevad veel paar sammu kaugemale, automatiseerides nõuete valideerimise mõne tehnilise vahendi abil.

 

Väga hästi illustreerib tema mõtteviisi järgmine skeem:

Key Process Patterns of Spec-by Example
Pärineb Gojko raamatu “Specification by Example” 2. peatükist.

 

Mida see kõik täpsemalt tähendab? Seminaril sai sellest hea ettekujutuse Gojko toodud näidete ja ka grupitööde raames. Kes seal ei osalenud, saab lugeda väikest ülevaadet :)

 

Skoobi tuletamine eesmärkidest

  • Klassikaline mudel, et tellija defineerib nõuded/skoobi ja meeskond implementeerib need töötavaks süsteemiks, ei pruugi kõige parem olla.
  • Lastest äriinimestel nõuded defineerida, disainivad nad selle käigus lahenduse oma probleemile. Aga nad ei ole tarkvara disainerid ja see võib hädasid tekitada.
  • Klassikaline lähenemine võib viia küll tarkvarani, mida klient soovis, aga mis ei tee seda, mida ta tegelikult tahab.
  • Alustada tuleks ärilisest eesmärgist ja koos meeskonnaga sobiv disain välja töötada.

 

Kollaboratiivselt nõuete spetsifitseerimine

  • Kui ei arendajaid ega testijaid pole spekkimise juures, tuleb kulutada lisa-aega nende kurssi viimisele ja suureneb valesti tõlgendamise oht.
  • Erineva taustaga inimesed mõtlevad erinevalt ja nii saab spekk täielikum.
  • Koos töötades tekib ühisomandi tunne ning suureneb vastutus.

 

Näidetega illustreerimine

  • Inimkeel on mitmetähenduslik ja kontekstist sõltuv – see jätab ruumi valesti tõlgendamiseks.
  • Tavaliselt muutuvad nõuded konkreetseks alles koodis – edukad meeskonnad konkretiseerivad need näidete abil juba varem.
  • Näited defineerivad, mida tarkvara tegema peab ning on ühtlasi ka vastuvõtukriteeriumeiks pärast arendust – nendega võib teoorias asendada kogu speki.

 

Nõuete rafineerimine

  • Sageli tekib koostöö käigus liiga palju näiteid – see raskendab olulise hoomamist.
  • Äri poole inimesed võivad keskenduda liialt sellele, kuidas süsteem asju teeb, mitte mida see teeb.
  • Puhastatud ja üksnes relevantsed näited on üheskoos nii spekk, acceptance testid kui ka funktsionaalsed regressiooni-testid (tulevikus, kui nad on automatiseeritud).

 

Nõuete automaatne valideerimine (ilma nende muutmiseta)

  • Manuaalne testimine on aeglane – tagasiside aeg pikeneb.
  • Tavapärasel testide automatiseerimisel (nt unitja Seleniumi testide abil) on miinuseid:
    • Nad loovad “uue tõe” – tõlkes võib üht-teist kaduma minna.
    • Nad muutuvad äriinimestele loetamatuks (ja on sageli “peidetud”).
    • Nende päevakohasena hoidmine nõuab suurt pingutust.
  • Tööriistade nagu Concordion, Fitnesse jt abil on võimalik inimloetavad näited otse testideks tõlgendada – see lahendus vähendab oluliselt eelnevalt välja toodud miinuseid.
Executable spec, automated with Fitnesse
Automaatselt valideeritava spetsifikatsiooni näide Fitnesse-s (SBE raamatu 2. peatükist).

 

Tihti valideerimine

  • Sageli on ainus tõe allikas kood – dokumentatsioon on sageli juba projekti üle andmisel tellijale aegunud.
  • Automaatselt valideeritavad nõuded annavad kindluse, et kood teeb endiselt seda, mida ta peaks tegema.
  • Tihti valideerides muutub spetsifikatsioon sama usaldusväärseks nagu kood.

 

Elav dokumentatsioon

  • Lisaks kõigele eelnevale peaksid nõuded olema hästi organiseeritud, kergelt leitavad ja ligipääsetavad ning ühtses stiilis.
  • Edukad tiimid uuendavad nõudeid ka vastavalt nende teadmiste muutumisele domeenist või turuolukorrast.
  • Elav dokumentatsioon on “koodi tõlge”, mida saavad edukalt kasutada kõik seotud osapooled – tehnilise toe spetsialistid, arendajad, testijad, äri-analüütikud jne.

 

Kes tahab veidi pikemalt lugeda, siis raamatu Specification by Example 2. peatükk on vabalt kättesaadav.

 

Kuidas elava dokumentatsioonini jõuda?

Tuleb teha näiliselt lihtsaid asju:

  • Alusta meeskonna kultuuri muutmisest:
    • Koostöö spekkimisel (jah, see on võtmetähtsusega!).
    • Ehita üles usaldus tellija ja meeskonna vahel.
    • Deliver features, not functionality.
  • Eemalda töö-protsessidest kõik üleliigne:
    • Muuda nõuded varakult konkreetseks.
    • Pane paika selge definitsioon, millal on ülesanne valmis (definition of done).
    • Muuda deployment ja testimine usaldusväärseks.
    • Kehtesta ainsa tõe allikas (source of single truth).
  • Kergenda (edaspidiseid) muutusi:
    • Dokumenteeri äriprotsessid.
    • Joonda äri-, tarkvara- ja testimise mudelid.
    • Muuda dokumentatsioon korrektseks, asjakohaseks ja kergelt ligipääsetavaks.

 

Strateegiad

Loomulikult andis Gojko ka mõned ideed strateegiatest, kuidas täpsemalt oma meeskonnas SBE juurutamisega algust teha. Valikuid, millest alustada, on laias laastus kolm:

  1. Kvaliteedile keskendumine (meeskonna ühine vastutustunne kvaliteedi ja protsessi ees);
  2. Automatiseerimine (“peibutiseks” on uute huvitavate tööriistade kasutuselevõtt);
  3. Vana hea šokiteraapia (“homsest teeme nii”, sobib nt siis, kui niikuinii on muutused käsil).

 

Ei ole olemas ainuõiget teed või viisi kuuldu rakendamiseks, kõik sõltub konkreetsest olukorrast – projekti domeen/iseloom/ärikriitilisus, meeskonna suurus/geograafiline jaotus/hetkel kasutatavad töömeetodid, kliendi nõuded, ajagraafik jne.

 

Kokkuvõte

Gojko väited said paljuski illustreeritud näidetega päris elust ja tema kogemustest arendusmeeskondadega üle maailma (mida muud oodatagi mehest, kes levitab näidete usku!). Ka ei olnud tal raskusi küsimustele vastamisega ega nalja viskamisega. Elav esitlusstiil, paeluv kõnemaneer, parajas koguses lühikesi pause ning mini-grupitööd hoidsid rahva kaasatuna viimaste minutiteni.

Terane Proeksperdi pere

Kel huvi SBE vastu kasvas, tasub karismaatilist Gojkot kindlasti mõnele konverentsile või koolitusele kuulama-vaatama minna. Kui seda võimalust pole, siis SBE rakendamise kohta saab rohkem infot Specification by Example raamatust, samanimelisest Google grupist ja ka Vimeo on täis kuldaväärt presentatsioone Gojkolt.

 

Lõpetuseks sobib väga hästi meie oma mehe Terry Londoni mini-arvustus antud seminari kohta:

Isiklikult pean kõige olulisemaks, et nii suur hulk arendajaid-testijaid-juhte said korraga valgustuslaksu. Kõik tõed ja kogemused, mis taolistel koolitustel jagatakse on alati olnud suhteliselt lihtsad ja elementaarsed ning rõhunud kastist väljapoole vaatamisele ja mugavustsoonist väljumisele. 

Seni on minu meelest olnud probleem, et isegi, kui üks inimene projektimeeskonnast käib koolitusel ära ja saab valgustatud, siis tal pole piisavalt oskusi ja sarmi, et enda kogetut ülejäänud meeskonnale edasi anda. Praegu ma usun, et kui meeskonnad tahavad oma töös midagi muuta, ei pea nad enam maailmavaadete sünkroniseerimiseks nii palju energiat raiskama, vaid saavad jätkata Gojko räägitu pinnalt.

Äge!“.

 

Leave a Reply

Your email address will not be published. Required fields are marked *