Za oblikovanje metode je bila organizirana fokusna delavnica, katere namen je bil oblikovati metodo iz predlaganih elementov, ki bi ˇcim bolj ustrezala specifiˇcnemu podjetju, v povezavi z naˇcinom dela podjetja in projekti, pred-vsem pa v konsenzu z pred-vsemi skupinami. Na delavnici je bilo prisotno celotno vodstvo, tehniˇcni del in del razvojne ekipe. Delavnica je bila bolj debatnega znaˇcaja z dvema ciljema – predstavitev rezultatov in oblikovanje metode.
Poleg predstavitve rezultatov je bila tukaj konstantna spodbuda k priso-stvovanju in izraˇzanju svojega mnenja. S tem smo dosegli vkljuˇcenost vseh interesnih skupin.
Rezultati so predstavljeni po fazah razvoja. Za vsako fazo posebej so bili preko pogovora in skupnega konsenza izbrani elementi z najveˇcjo podporo.
4.3.1 Zajem zahtev
Vse tri skupine so bile v anketi soglasne, da se brez vodenih delavnic in do-kumenta opredelitve zahtev programske opreme ne more izvesti faze zajema zahtev. Potrditev je bila dana tudi na delavnici. Ta dva elementa izhajate sicer ˇze iz prakse.
Pri vodenih delavnicah je bilo izpostavljeno, kako je pomembno, kdo je prisoten na teh delavnicah. Iz predstavljenih izkuˇsenj je sledilo, da je naj-boljˇsa praksa, da je na strani podjetja poleg vodje projekta obvezno prisoten tudi vodja razvojne ekipe in/ali arhitekt. Na strani stranke se po navadi stvari malo zapletenejˇse. Poleg vodje projekta na strani stranke morajo biti prisotni tudi kljuˇcni uporabniki. Slednji morajo poznati delovne procese in jih objektivno predstaviti. Nemalokrat se zgodi, da vsak uporabnik svoje zahteve podaja individualistiˇcno in ne vidi ˇsirˇse slike. Izbor kljuˇcnih uporab-nikov se lahko iz tega razloga tudi veˇckrat spremeni tekom procesa razvoja programske opreme.
Pri oblikovanju zahtev pa pomaga tudi prototip, ki je tudi eden izmed
iz-branih elementov za fazo zajema zahtev, vendar z doloˇcenimi prilagoditvami.
Stranki je v veˇcino primerih dobrodoˇslo, da ˇcimprej vidi, kako pribliˇzno bo izgledal konˇcni produkt. Specifiˇcnemu podjetju ni sprejemljivo, da bi pora-bili preveˇc ˇcasa za prototip, ki na koncu ne bi bil uporaben. Predlagan pa je bil t. i. ˇziˇcni model (angl. wireframe) z doloˇceno mero interaktivnosti. To pomeni, da niso samo slike, ampak npr. klik na gumb, kar pomeni premik na drugo okno aplikacije.
Popis vseh zahtev mora biti obvezno v Dokumentu opredelitve zahtev programske opreme. S potrditvijo tega dokumenta se naroˇcnik strinja, da je bil proces v celoti opredeljen in da dokument vsebuje vse zahteve s strani naroˇcnika. Pogosto tekom projekta pride do sprememb, dopolnitev ali nespo-razumov in ravno ta dokument je potem podlaga za ugotavljanje in pisanje morebitnih dopolnitev ali ugotavljanje napak.
S strani razvoja so bili dobro ocenjeni tudi intervjuji in uporabniˇske zgodbe. Vseeno pa so vse skupine priˇsle do skupnega zakljuˇcka, da bi in-tervjuji vzeli preveˇc ˇcasa in resursov. Pri uporabniˇskih zgodbah bi bilo potrebno trenutno vloˇziti preveˇc truda za vpeljavo. Mogoˇce bi pa o tem elementu razmiˇsljali v prihodnosti.
4.3.2 Arhitektura in oblikovanje
Arhitekturen del te faze je kompleksen in veˇcplasten. Zelo je tudi preple-ten s fazo zajema zahtev. Pri produktih po navadi stranka v doloˇceni meri definira arhitekturo sistema s svojimi zahtevami po operacijskem sistemu in podatkovni bazi.
Vse tri skupine so bile zelo naklonjene elementu Planiranje po funkcional-nost, ki je bil takoj dodan na seznam elementov metode razvoja programske opreme. Drugaˇcna zgodba pa je bila pri elementu Agilno atributno voden razvoj. Zelo visoko je bil ocenjen s strani vseh treh vlog. Preko pogovora in razlage je bilo ugotovljeno, da gre tukaj za celotno metodo. Absolutno je bil koncept zanimiv vsem, vendar trenutno predstavlja preveˇc dela za vpeljavo, zato je bil zaenkrat postavljen na stranski tir in ni bil izbran v metodo.
Na drugi strani pa je bil izpostavljen element Poenoteni jezik modeliranja.
Tehniˇcni del mu je dal visoko oceno. Bilo pa je predlagano, da bi bil delno vkljuˇcen, kar pomeni, da bi bil model UML vkljuˇcen v smislu diagramov, brez generacije kode.
4.3.3 Razvoj
Razvoj je najobˇsirnejˇsa faza in ima poslediˇcno najveˇc predlaganih elementov.
Tudi na fokusni delavnici smo se najdlje ustavili pri tej fazi. Ob gledanju zgolj na rezultate, je zanimivo to, da noben izmed elementov razvojnega cikla ni priˇsel v ˇcetrti kvadrant pri grafih primerjav med enim in drugim delom.
In prav s tem se je zaˇcela debata pri fazi razvoja.
Vodstvo je ocenilo enotedensko iteracijo kot najboljˇso, tehniˇcni del pa ji ni bil naklonjen. Na koncu so vsi ugotovili in potrdili, da je za specifiˇcno podjetje in trenuten naˇcin delovanja najprimernejˇsi element Neprekinjena dostava, zato enotedenska iteracija ni izbrana. Poudarjeno pa je bilo, da je potrebno delati na izboljˇsavi avtomatizacije dostave.
Sestanki so pomemben del vsakega razvoja programske opreme. V pri-meru tega podjetja je veˇckrat tako, da nekdo ne dela ekskluzivno samo na enem projektu. Iz tega dejstva je sledila izbira elementa Dnevni sestanek na nogah po posameznem oddelku, ki tudi vkljuˇcuje prvine dnevnega Scrum sestanka. Na sestanku tako vsak pove, kaj je delal prejˇsnji dan, ˇce so kje kakˇsne teˇzave in kaj je plan za danaˇsnji dan. Ni pa nujno, da je dnevni sestanek sestavljen samo iz tega dela, vendar naj bo karseda kratek. Poleg tega pa je bil dodan tudi sestanek za doloˇcanje prioritet, ki je bil zelo visoko ocenjen. Le-ta naj se izvaja enkrat na teden.
Metodi je bil dodan tudi element Skupno lastniˇstvo nad kodo, ki bo pri-pomoglo k kvalitetnejˇsi kodi. Vodstvo ni bilo najbolj naklonjeno elementu Pregled kode zaradi morebitne ˇcasovne potratnosti. Razvoj in tehniˇcni del je izbiro tega elementa oznaˇcil za nepogreˇsljivega. Tudi ˇce v doloˇceni meri podaljˇsa ˇcas razvoja, v ˇcasu vzdrˇzevanja zmanjˇsa ˇcas in pripomore k zado-voljstvu stranke zaradi manj napak. Vodstvo se je na koncu strinjalo, zato
je bil dodan tudi element Pregled kode. Omenjen je bil tudi element Pro-gramiranje v paru, ki je bil visoko ocenjen s strani razvoja in tehniˇcnega dela, vodstvo pa ga je ocenilo zelo slabo. Tudi na delavnici je bilo vodstvo enotno, da se ta element ne more uvrstiti v seznam elementov metode, ker pri manjˇsem podjetju to ne bi bilo profitabilno.
4.3.4 Testiranje
Raziskovalno testiranje je bilo od vseh elementov v fazi testiranja na prvem mestu. Za to testiranje ni potrebno vnaprej doloˇcenih scenarijev in priprave, hkrati pa je dober naˇcin odkrivanje napak in omejitev produkta.
Tako vodstvu kot razvoj je na drugo mesto postavil element Testiranje uporabnosti. Velikokrat se premalo ˇcasa posveˇca testiranju enostavnosti in logiˇcnosti uporabe samega produkta. Glede na to, da je eno izmed vodil specifiˇcnega podjetja poenostaviti strankam vsakdanje delo, je ta element dobil pomembno mesto v metodi.
Debata je na fokusni delavnici tekla tudi o elementu Enotsko testiranje.
Razvoj je temu elementu dal dobro oceno. Trenutno ni dovolj pomemben, da bi ga uvrstili v konˇcni seznam metode. Je pa bil podan predlog, da bi se v bliˇznji prihodnosti delalo na vpeljavi avtomatiziranega enotskega testiranja.
Udeleˇzenci so tudi izpostavili, da je potrebno dodati manjkajoˇce elemente.
Manjkati ne smeta testiranje obremenitve (angl. stress test) in integracijska testiranja (angl. integration testing).
4.3.5 Implementacija
Pri implementaciji so bili vsi naklonjeni izobraˇzevanju kljuˇcnih uporabnikov in je bil ta element brez dvoma takoj potrjen. To pomeni, da peˇsˇcico upo-rabnikov, ki so bili v veˇcini primerov prisotni tudi na vodenih delavnicah, izobrazimo. Ti uporabniki dobro poznajo produkt in vse procese do te mere, da lahko izobrazijo svoje sodelavce.
Izbrano je bilo tudi raˇcunalniˇsko izobraˇzevanje. Na tem elementu bi bilo
potrebno bolj delati in ga v prihodnosti razˇsiriti, predvsem v smislu uporab-niku prijazne dokumentacije in video vadnic.