Net ir Agile projektuose klientai reikalauja pasirašyti detaliąją funkcinę specifikaciją ir iš pirmo žvilgsnio gali atrodyti, kad tai atitinka klientų interesus, kadangi detaliosios funkcinės specifikacijos naudojimas (formaliai ar neformaliai), padeda pagerinti projekto rezultatus ir sudaro sąlygas įvertinti projekto progresą bei pasiektus rezultatus.
Kita vertus, tai paremta klaidingomis prielaidomis, kad reikalavimai gali būti suprantami iš anksto. Remiantis patirtimi galima pastebėti, kad klientai yra labiau linkę turėti funkcinių reikalavimų dokumentą, tačiau nevykdyti pokyčių kontrolės procedūrų, kai eigoje nustatomi nauji reikalavimai.
Galimas dvejopas šios problemos vertinamas. Pirma, tai neefektyvu, kadangi pokyčių valdymo procedūros, kurių aprašymai dažniausiai yra didelės apimties ir sudaro apie kelis šimtus puslapių teksto, yra reikšmingos. Be to šiuo atveju funkcinė specifikacija tampa iliuzine procedūra, kadangi dokumentas tampa tokiu sudėtingu, kad vienas žmogus tiesiog nepajėgia užtikrinti adekvataus dokumento nuoseklumo ir išsamumo.
Antra, tai lemia ilgą išankstinių reikalavimų analizės etapą ir įprastai veda prie didesnio kiekio projektavimo, vystymo ir testavimo procedūrų.
Agile projektų pradžioje įprastai praleidžiame 2-6 savaites, kad pasitvirtintume projekto apimtį ir numatytume plėtrą. Šiuo laikotarpiu kuriame tai, ką vadiname „funkcinėmis gairėmis“ – trumpą dokumentą (10-15 psl.), kuris apibūdina aukšto lygmens projekto strateginius tikslus ir šių tikslų vertę, kurią klientas tikisi gauti. Taip pat aprašome aukšto lygio verslo procesus ir kitas svarbias aplinkybes.
Tada mes gaminame pirminį reikalavimų katalogą, kurį sudaro pagrindiniai reikalavimai ir ‚kliento kelionės‘ (angl. user stories/ user journeys), kurie vėliau būtų tobulinami.
Bendradarbiaudami su klientu įvertiname besikeičiančius verslo reikalavimus ir imame skaidyti, jungti, keisti bei iš naujo prioretizuoti kai kuriuos elementus, esančius reikalavimų kataloge. Būtent tokie ir yra Agile principai: mes įvertiname grįžtamąjį ryšį ir nuolat mokomės vis geriau suprasti sprendimus ir jų rezultatus.
Klientai, atsisakydami detalios funkcinės specifikacijos, susiduria su keliais nemaloniais klausimais: kaip mes galime žinoti, už ką mokame pinigus, jeigu raštu to neaptariame?
Kitaip tariant – jeigu nesuderiname apimties, kaip galime žinoti, kad nemokame už kažką, ko nenorime?
Tiesa yra ta, kad apimtis niekada nėra suderinama. Mūsų bendras supratimas apie apimtį vystosi projekto metu. Jeigu raštu sutarsime apimtį, kuri bus neteisinga, tai neleis mus teisingai nustatyti, kokią vertę bus galima gauti už sutartą pinigų sumą.
Priešingai – aukšti ir detalūs reikalavimai projekto pradžioje lemia didesnės apimties pokyčius projekto metu, o tai sumažina galutinę vertę.
Tikras kokybės ir kainos santykis gali būti nustatytas tada, kai klientui yra pristatoma sukurta vertė. Būtent tai yra viena iš priežasčių, kodėl geriau klientui pristatyti kuriamą produktą laipsniškai. Jeigu klientas per pirmuosius projekto mėnesius pamato kuriamą produktą, įvertina jo kokybę ir toliau reguliariai stebi kūrimo procesą, tokiu atveju gali sukaupti reikiamos informacijos siekiant įvertinti tikrąjį kainos ir kokybės santykį.
Laikui bėgant tai pereina nuo mokėjimo už tam tikras paslaugas, iki mokėjimo už tai, kad komanda sugebėtų teikti sutartą vertę už sutartą kainą, net ir reikšmingai besikeičiant reikalavimams. Dėl šios priežasties įprastai rengiame sutartis, kurių pagrindu klientas gali mažinti projekto apimtis po kiekvienos vystymo iteracijos ir taip potencialiai sutaupyti pirminio biudžeto atžvilgiu.
Kaip mes galime turėti efektyvią pokyčių kontrolę, neturėdami bazinio atspirties taško?
Fiksuotos kainos ar fiksuotos apimties projektams yra reikalinga griežta pokyčių valdymo ir kontrolės sistema. Jeigu originalioje projekto apimtyje nebuvo numatyta tam tikra ypatybė, kuri gali būti kritinė, klientui gali tekti mokėti papildomą kainą. Iš kliento perspektyvos, dėl šio niuanso kyla tam tikros problemos.
Be konteksto gali būti sunku įvertinti vieną siūlomą pakeitimą. Galima pastebėti, kad klientas dažnai atmeta pasiūlymus dėl supratimo stokos ar noro sumažinti išlaidas ir tai dažnai nutinka projekto baigiamosiose stadijose. Formalios pokyčių valdymo ir kontrolės procedūros yra brangios. Nėra įprasta, kad būtų mokami tūkstančiai dėl pokyčių poveikio vertinimo, jeigu tas pokytis galų gale būna atmestas.
Tiekėjai dažniausiai taria lemiamą žodį, ar kažkoks pokytis yra reikšmingas ir ar tai lems papildomas išlaidas.
Visa tai nereiškia, kad nereikia fiksuoti pokyčių. Sprendimai, kurie gali daryti didelę įtaką, turėtų būti aptarti bei atnaujinami atitinkamuose dokumentuose. Visą šią procedūrą siekiame padaryti kuo efektyvesne, kad daugiau dėmesio galėtume skirti tikrą vertę kuriančioms veikloms. Visgi, svarbiausia yra produkto kokybė ir veiksmingumas, o ne jo atitikimas tam tikram formaliam dokumentui.
Kaip galime pasiruošti testavimui?
Dauguma mūsų klientų pageidauja atlikti formalų ir nepriklausomą produkto testavimą, nepaisant to, kad mes patys atliekame pirminę kokybės užtikrinimo procedūrą. Šiame etape klientai dažnai įtraukia testavimo specialistus, kurie atlieka griežtus, metodiškai pagrįstus testavimus.
Problema iškyla tuomet, kai testuotojas mano, kad jo darbas yra įvertinti, ką sistema šiuo metu daro ir ką ji turėtų daryti, remiantis funkcine specifikacija, o tai reikalauja absoliučiai detalios funkcinės specifikacijos. Taip pat, testuotojams reikia laiko, per kurį specifikacija verčiama į detalius testavimo scenarijus.
Mūsų sprendimas yra atlikti dalį testuotojų darbo už juos.
Mes rengiame aukšto lygio funkcinį vadovą ir pirminių reikalavimų katalogą, siekiant sukurti pradinį projekto konteksto ir apimties vaizdą, kurį tobuliname viso projekto metu.
Kiekviena reikalavimų kataloge esanti vartotojo kelionė (angl. user story/ user journey) yra aprašoma pagal rezultatą, o ne sistemos veikimo mechanizmą. Pavyzdžiui, „Kaip vartotojas aš galiu prisijungti naudodamas savo įmonės vartotojo vardą ir slaptažodį, todėl neturiu įsiminti atskiro vartotojo vardo ir slaptažodžio“.
Kai pabaigiame „vartotojo kelionę“, paruošiame konkretų aprašymą, kaip sistema turėtų veikti ir kokį rezultatą generuoti. Tai įgauna šio scenarijaus formą: „kompanijos serveryje „Active Directory“ egzistuoja vartotojas ‚j.simth‘ bei slaptažodis ‚secret‘. Kai vartotojas suveda šį vartotojo vardą bei slaptažodį jam pavyksta sėkmingai prisijungti ir jo ekrane atsiranda sveikinimo pranešimas“.
Mes prašome klientų patvirtinimo. Jeigu komanda gali pademonstruoti, kad sistema veikia taip, kaip nurodyta, tai yra vertinama kaip atitikimas reikalavimams.
Jeigu neatliktume šio žingsnio, tai reikštų, kad mes patys vertiname savo darbus. Kai kuriuose projektuose klientai įsitraukia ir padeda mums sukurti „vartotojų keliones“ bei suformuoti atitikimų reikalavimus, nors dažniau tai darome mes.
Mes naudojame bet kurį reikiamą programinį kodą, kad atitiktume reikalavimus bei automatizuotume atitikimo testus. Tai yra žinoma kaip „Behaviour Driven Development“ (BDD) arba „Acceptance Test Driven Development“ (ATDD). Šiuos testus atliekame kiekvieną kartą, kai programoje įtvirtiname pokyčius.
Kaip mūsų testavimo pagrindą mes naudojame sutartus patvirtinimo kriterijus, taigi testuotojai gauna tokio detalumo informaciją, kokia pateikiama funkcinėje specifikacijoje. Prašydami klientų pasirašyti suderintus patvirtinimo kriterijus, galima viso projekto eigoje gerinti reikalavimų kokybę ir tikslumą.
Kaip būsimi projektai gali padėti suprasti sistemos galimybes?
Kadangi sistemos yra techniškai prižiūrimos, plečiamos, integruojamos, naikinamos ir pakeičiamos, dažnai yra pageidaujama turėti vieną dokumentą, kuriame būtų pateikiamas visas sistemos aprašymas. Tokiu būdu būtų išvengiami papildomi bandymai suvokti, kaip ji veikia. Išbaigta funkcinė specifikacija galėtų puikiai pasitarnauti šiam tikslui.
Tačiau kyla klausimas, ar tikrai? Funkcinė specifikacija dažniausiai nėra kuriama minėtam tikslui, taigi ji ne visada pasižymi tinkama struktūra. Be to, sistema gali kisti nuo to laiko, kai yra rašoma funkcinė specifikacija, taigi tokiu atveju dokumentas būna neišbaigtas ir jame būtų pateikiamos nuorodos į atskirus pokyčių kontrolės dokumentus.
Mūsų požiūriu, reikalavimų katalogą reikia naudoti kaip pirminį sistemos dokumentą. Jis turėtų būti tikslus ir išbaigtas, kadangi detali dokumentacija (patvirtinimo kriterijai) yra apibrėžiami kaip tik prieš pradedant kurti programą. Automatizuoti kriterijai kūrimo momentu nedelsiant informuoja apie aptiktus neatitikimus tarp sistemos ir reikalavimo. Jeigu reikia daugiau dokumentų, jie gali būti kuriami atskirai ir prioretizuojami remiantis jau esama dokumentacija.
Martinas Aspeli yra Deloitte Digital UK programavimo departamento vadovas, vadovaujantis daugiau kaip 100 programuotojų komandai, taikant Agile (LEAN IT) metodiką.
