Detta är ett scenario som visar skillnaden före och efter en introduktion av robotar, för ett företag som utvecklar en applikation som sedan säljs och levereras till kund i form av färdiga program och nedladdningsbara appar.
Ingående roller och komponenter
Ett gemensamt repository där all kod lagras, både specifikationer och källkod till alla program och appar. Det är versionshanterat via GIT och kan därför användas för automatiska process-steg.
Datorn här får representera den automatiska byggprocessen som kontinuerligt läser i repositoryt och skapar färdiga installerbara program och appar. Det betyder att en ny version av applikationen är färdig att testas strax efter att ny kod är tillgänglig. Då kan automatisk testning ta vid och verifiera att allt är korrekt.
Lisa har rollen Business Analyst (BA) och är ansvarig för funktionaliteten i den programvara som levereras. Hon kan verksamhetsområdet och vet vad kunderna behöver. Hon har en del insikt i programmering, men inga detaljkunskaper inom området.
Tom har rollen System Engineer (SE) och är expert på programmering av mobilappar och applikationsservrar. Han vet på ett ungefär vad verksamhetsområdet gäller, men har ingen detaljkunskap som Lisa har. Däremot är han full koll på de programmeringsspråk och utvecklingsmetoder som används i företaget..
Tillsammans utgör de att team som har ansvarar för utvecklingen inom ett visst område.
Nuvarande arbetssätt
Det hela startar med att en idé om förbättrad eller ny funktionalitet ska implementeras. Lisa och Tom samarbetar med problemet och deras arbetsrätt kan illustreras med följande diagram.
Arbetsgången för detta exempel är:
- Lisa tar till sig den nya idén och skriver en specifikation som beskriver vad som ska göras och vilka egenskaper den nya funktionaliteten ska ha. Den färdiga specifikationen lagrar hon i repositoryt och notifierar Tom att det finns en ny uppgift.
- Tom läser så småningom meddelandet och planerar in när han har tid att utföra programmeringen.
- När det sedan är dags för Tom att programmera enligt Lisas specifikation, så finns det några oklarheter som de reder ut tillsammans.
- När Tom är klar med programmet så sparar han det till repositoryt.
- Den automatiska byggprocessen registrerar att det finns ny kod och bygger den nya versionen av applikation och appar.
- Nu först kan Lisa prova om hennes idé och det verkliga programmet stämmer överens. Om inte så startar processen om igen …
Arbetssätt med robotar
För att introducera robotar så krävs det ett visst förarbete. En robot är ju ett program i sig och behöver skapas för att den ska kunna användas.
Tom analyserar i förväg vad roboten behöver veta för att kunna utföra sin uppgift. Det består dels i att bestämma vilken typ av information som måste finnas i specifikationen och dels vilka mallar och algoritmer som roboten behöver implementera. Observera att Tom inte behöver veta exakt vad Lisa vill få utfört. Han kan i stället fokusera helt på tekniken.
När han är klar så blir roboten en integrerad del i den automatiska byggprocessen.
Nu blir arbetsgången i stället:
- Lisa tar till sig den nya idén och skriver en specifikation som beskriver vad som ska göras och vilka egenskaper den nya funktionaliteten ska ha. Den färdiga specifikationen sparar hon till repositoryt. I och med det så startar en helautomatiskt process.
- Roboten registrerar att det finns ny kod och skriver ny programkod utgående från specifikationen och sina fördefinierade mallar. Den nya koden sparar roboten till repositoryt.
- Den automatiska byggprocessen registrerar att det finns ny kod och bygger den nya versionen av applikation och appar.
- Nu kan Lisa prova om hennes idé och det verkliga programmet stämmer överens. Om inte, så skriver Lisa om sin specifikation och processen startar om igen.
Vad blir det för skillnad?
En viktig skillnad här är tiden det tar från att Lisa registrerar sin specifikation i repositoryt tills dess att hon kan prova sin idé i verkligheten. Om byggprocessen och roboten är tillräckligt snabba så kan det ske inom några minuter i stället för dagar eller veckor.
En annan skillnad är att roboten gör lika varje gång. Det betyder del högre kvalitet eftersom roboten inte gör slarvfel. Den kan naturligtvis ändå göra fel, men det yttrar sig i systematiska fel som är lättare att upptäcka och rätta.
Kostnaden för att prova och att göra prototyper på framtida funktionalitet minskar också drastiskt eftersom det går snabbare för Lisa att prova sig fram i stället för att behöva veta alla detaljer från början.
Lisa och Tom kan fokusera bättre på sina respektive expertområden. Idag behöver de båda veta ganska mycket om den andres område. Det kritiska delen är kommunikationen dem emellan. Om någon nyanställd skulle ta över Toms roll så skulle Lisa behöva skriva mycket noggrannare instruktioner än om Tom ska utföra dem. Det är ett problem i team där medlemmarna har olika erfarenhet.
Att kunna leverera program och appar på nya plattformar eller versioner blir enklare i och med att bara Tom blir inblandad. Han kan i lugn och ro anpassa ytterligare en uppsättning robotar som skapar den nya koden som behövs.
Det affärsmässiga innehållet i programmet blir lagrat i repositoryt och därmed spårbart till vilka levererade versioner det ingår i. Före roboten infördes kunde specifikationen i och för sig också lagras, men det som egentligen bestämde applikationens innehåll var Toms program, inte Lisas specifikation. De kan nu versionshanteras, vilket medför att det är enkelt att se skillnader mellan versioner och dessutom utgå från den förra i stället för att skriva en ny.
Lisa måste lära sig ett nytt sätt att skriva specifikationer, eftersom de måste vara så stringenta i syntax att en robot kan läsa dem. De kan naturligtvis ha vilka regler som helst, men en lämplig väg är att använda sig av domänspecifika modellspråk (DSM). De konstrueras så att det blir så naturligt och enkelt som möjligt att använda. (Andra alternativ är XML, JSON eller Excel, som kan passa för enkla applikationer.)
Låter det intressant? Kontakta Oss för att få veta mer!