Mina produkter

Logga in för att följa kategorier och för att få genvägar i denna meny
avbryt
Visar resultat för 
Sök istället efter 
Menade du: 
SannaLin
  • 0 Svar
  • 9 gilla
  • 14 Visningar
Hej! 

Vi får många frågor på hur vår utvecklingsprocess ser ut och hur vi jobbar med test och kvalitetssäkring av Visma eEkonomi. 
Så här kommer information om hur vi jobbar på utvecklingsavdelningen med Visma eEkonomi: 

Våra utvecklingsteam: 

Vi har fyra team som jobbar med en specifik process eller programdel av Visma eEkonomi: 
  • Försäljning och Lön 
  • Leverantörsfaktura, Kassa/bank och Bokföring 
  • Visma eEkonomi-appen 
  • Externt API 
I varje team finns det en produktägare som är ansvarig för prioriteringar i teamet och den listan kallas för backlog.  
En backlog är alltid prioriterad vilket innebär att vi startar med att utveckla den aktivitet som står högst upp på listan och fortsätter sedan neråt. För att undvika att ha för många saker pågående samtidigt kör vi en utvecklingsprocess som kallas för Kanban vilket är en välkänd utvecklingsprocess. 

Alla team ansvarar för utveckling av nya funktioner, förbättringar i existerande funktionalitet och att fixa buggar samt hjälpa till med kundärenden som inte vår support kan lösa själva. I varje team finns det dedikerade utvecklare både för förbättringar och buggar. Om ett team har problem med kvalitet och har många kritiska buggar har vi tydliga prioriteringar att det alltid är kvalitet som är första prioritet. 

Hur beslutar produktägaren i teamet vad som ska utvecklas? 

Produktägaren får input och feedback från flera olika kanaler och baserat på mål för produkten gör vi roadmaps som diskuteras i flera omgångar med alla intressenter. Nedan följer några exempel på kanaler som ger produktägaren värdefull input till prioriteringar: 
  • Lagar och regler när myndigheter inför nya rutiner och processer eller nya lagkrav så är det första prioritet att införa så fort som möjligt. 
  • Produktägaren på utveckling har ett nära samarbete med både försäljning, marknad och vår supportavdelning. Det finns två utsedda personer på support och marknad som hjälper utveckling med prioriteringar och feedback från våra kunder.  Ett exempel är att vi varje månad får en rapport från supportansvarig med information om hur många supportärende vi haft, vilka frågor har varit vanligast och vilka ärenden har tagit längst tid att lösa. 
  • Nya ideer och förslag till förbättringar från våra kunder i vårt forum. 
  • Referensgrupper - i vissa större projekt har vi satt upp en grupp av kunder som vi kallar referensgrupp. Normalt brukar gruppen vara mellan 5-10 kunder som ger oss bra synpunkter både vad det gäller vad vi ska utveckla och vi får också värdefull feedback från dessa kunder under införandet av större funktioner eller förbättringar i programmet.
  • Icke funktionella krav som t ex säkerhetsåtgärder. Att vi måste hålla våra tekniska plattform uppdaterad är ofta krav som kommer ifrån våra systemarkitekter och utvecklare. 
  • Kundundersökningar och kundnöjdhet, varje månad mäter vi kundnöjdheten och ett par gånger om året gör vi mer detaljerade kundundersökningar och där får vi väldigt mycket input till både vad som funkar bra och vad vi behöver förbättra. 
  • När kunder väljer att avsluta Visma eEkonomi så frågar vi alltid vad som är orsaken t ex om det är så att de saknar en funktion eller växt ur programmet, detta ger oss ett bra underlag till framtida prioriteringar.
  • Användartester, vi har flera UX designers på vår utvecklingsavdelning i teamet som hjälper till med research, användartester och intervjuer med kunder.  
  • Såklart håller vi även lite koll på vad våra konkurrenter erbjuder samt även vad andra internationella företag utvecklar som ger oss inspiration till förbättringar och lite nytänkande.

Liveteam, våra “firefighters”  

Vi har även ett team som kallas för Liveteamet vi ser dem som Visma eEkonomis “firefighters”. I Liveteamet har vi både utvecklare och produktspecialister. Liveteamet hanterar incidenter, övervakar våra driftsmiljöer, analyserar loggar, prioriterar och klassificerar buggar samt hjälper support att lösa kluriga supportärenden. Detta teamet har ett nära samarbete med vår supportavdelning. Det är också detta team som koordinerar våra releaser. 


Test och kvalitetsarbete: 

Nedan finns en kort beskrivning kring hur vi jobbar med att kvalitetssäkra funktionalitet innan release till kunder: 
  1. Alla ändringar ska testas lokalt på utvecklares dator 
  2. Innan utvecklaren checkar in kod (ändringar) måste alltid en annan utvecklare göra en kodgranskning för att verifiera att det ser bra ut och godkänna ändringarna. 
  3. Alla ändringar i koden blir först byggda på en intern testmiljö där vi kör alla automattester. 
  4. Alla ändringar verifieras och testas sedan manuellt av en Business analyst (kravställare) för att säkerställa att ändringen fungerar som förväntat. 
  5. Om de manuella och automatiserade testerna är godkända flyttar vi över ändringarna till nästa miljö (stage) som är identisk med vår produktionsmiljö. Även här kör vi återigen igenom utvalda automattester. 
  6. När alla stegen ovan är godkända så är vi klara för en release till våra kunder. 

För att säkerställa att vi testar på olika webbläsare så genomförs både manuella och automatiserade tester på de mest använda webbläsarna. Vi följer statistik på vilka webbläsare som faktiskt används av våra kunder och fokuserar på dessa webbläsare. 

Kvalitet, testautomatisering 

I Visma använder vi en modell och de guidelines som är definierade i Test Automation Pyramid.
Test Automation Pyramid innebär kortfattat att vi kör flera olika av typ av testautomatisering: enhetstester, integrationstester samt gränssnittstestning.



Inom produktutveckling pratar vi ofta om ett begrepp som kallas för “Definition of Done” vilket innebär att vi satt upp kriterier för när vi definierar en uppgift som klar. 

För Visma eEkonomi innebär det att vi inte anser att en aktivitet är klar förrän en utvecklare också har gjort enhets- och integrationstester. För automatisering av gränssnittstester (UI) har vi två dedikerade utvecklare som jobbar med att se till att vi har en bra täckning.  Alla automatiserade tester körs på våra interna testmiljöer varje natt och vi får en status varje morgon på vilka tester som har gått igenom. Vi har över 600 automatiserade integrationstester och ca 80 automatiserade gränssnittstester som automatiskt klickar igenom produkten. Innan vi släpper en release till våra kunder ska alla våra automatiserade tester vara gröna och genomförda. 

Nedan visar ett exempel på ett av våra dashboards som hjälper oss att bevaka status på våra automatiserade tester: 



Våra releaser: 

Major release: 
En gång i månaden har vi en planlagd större release av nya funktioner eller större förbättringar.  
Tillsammans med produktägare och teamet gör vi ett grovt estimat vad vi tror att vi kan leverera kommande månad. 

Minor release: 
Varje onsdag har vi en planlagd mindre release där vi levererar mindre förbättringar och buggfixar som inte är kritiska. 

Bug fix: 
Om vi har kritiska buggar har vi normalt sätt möjlighet att rätta och släppa en release inom ett par timmar. 
Ibland har vi buggar som är mer komplexa och kräver längre tid för felsökning. Men vi strävar alltid efter att fixa kritiska 
buggar inom ett par timmar och har en process för det. 

Hantering av incidenter                                                                                                                                        

Alla incidenter som vi har på Visma eEkonomi publiceras på  https://status.visma.com/ så fort vi har identifierat dem. 
Vår definition av en incident är när Visma eEkonomi är helt nere (major outage), tillfällen då vi har problem med prestanda (degraded performance)eller när delar av programmet inte går att använda (partial outage). 

Alla incidenter följs upp på ett incident möte som genomförs 1-2 dagar efter incidenten. Alla involverade medarbetare deltar på mötet samt produktägare och och driftsansvariga. Vi identifierar grundorsaken samt följer upp hur processer och information har följts under incidenten. Vi specificerar en lista på förbättringar och tilldelar dem till rätt personer för att undvika att det sker igen. 
Ibland handlar det om förbättringar i våra interna processer, att larm och övervakning varit bristfällig eller att vi måste förbättra loggning i våra program. Alla ärenden registreras i ett centralt system och följs upp. 

Vill du läsa mer om hur Visma hanterar säkerhet, personuppgifter och incidenthantering läs gärna mer på Visma Trust Center  https://www.visma.com/trust-centre/
Hantering av buggar                                                                                                                                            

Alla kritiska buggar kommuniceras ut genom vår supportavdelning i vårt användarforum så snart vi bekräftat felet. 
På supporten finns ett dedikerat Knowledge team för Visma eEkonomi som utvecklingsteamen samarbetar dagligen med. 
Sedan februari har vi i Visma eEkonomi även infört samma process som vi har för incidenter när det gäller uppföljning av kritiska buggar. Både utvecklaren, business analyst (kravställaren), produktägaren samt utvecklaren som genomfört kodgranskningen kör ett incidentmöte. Syftet med detta möte är att identifiera grundorsaken till buggen, lära sig och försöka undvika liknande buggar i framtiden. Efter mötet specificeras en lista på förbättringar och tilldelas till rätt personer. Ett exempel skulle kunna vara att det saknas automatiserade tester. Alla ärenden registreras i ett centralt system och följs upp. 


Continuous Delivery och MVP (Minimal viable product) 

Visma eEkonomi och Visma Spcs har som många många andra företag som utvecklar webbaserade tjänster ändrat processer när det gäller hur vi utvecklar och levererar våra produkter. Inom produktutveckling kallas det för “Continuous Delivery” som ställer högre krav till automatisering i våra team. Fördelen för våra kunder är att vi kan släppa mindre förbättringar och nya funktioner snabbare, jämfört mot tidigare då vi hade 1-3 releaser om året. 
Detta ger oss möjlighet att få feedback från våra användare tidigare vilket hjälper oss att prioritera nästa steg (=bygga rätter saker). Vi har också upplevt att om vi sitter och bygger en funktion lite för länge så riskerar vi att bygga fel funktioner samt att vi vet att våra användare ofta tycker att stora förändringar och nyheter är tidskrävande och inte alltid positiva.   
För att säkerställa att vi levererar kundvärde så försöker vi utveckla Visma eEkonomi utifrån  principerna i Lean StartUp och MVP (Minimum Viable Product). 

Lean Start Up -  har inspirerats av ”lean produc­tion”, ett indu­stri­ellt pro­duk­tions­sätt som har utveck­lats på Toyota och bygger på att du tar en ide, bygger och leverera den, testar och följer upp och tar lärdom.

MVP - Minimum Viable Product - innebär att vi identifierar det allra minsta vi kan leverera som kan ge ett kundvärde och testar det på ett mindre antal kunder och lyssnar på feedback för att göra eventuella förbättringar innan vi släpper till alla kunder. 

Spotify som många känner till har valt att visualisera deras utvecklingsprocess med följande bild: 



Sedan i början av 2017 har vi testat detta arbetssätt på leverantörsfaktura processen i Visma eEkonomi där vi gjort flera förbättringar. 
Första steget har varit att testa ideerna/förbättringarna på en referensgrupp på ca 10 kunder där vi fått feedback . Det andra steget har varit att vi släppt det till ett större antal kunder ca 1000 st och följt upp vad de tycker om förbättringarna genom en fråga inne i programmet. Baserat på feedback från den gruppen har vi gjort vissa justeringar och när vi bedömer att våra användare är övervägande positiva har vi släppt de nya förbättringen till alla kunder.  För dig som användare som väntar på fler förbättringar kan jag förstå att det upplevs som du inte tycker funktionen är riktigt klar när vi utvecklar Visma eEkonomi på detta sättet. Men vi ser det som en stor möjlighet att utveckla kontinuerliga mindre förbättringar med möjlighet till feedback från våra användare tidigare, vilket gör att vi får en bättre produkt. 

Syftet med "Continuous Delivery" och vår utvecklingsprocess är inte inte att släppa ut funktioner snabbt med dålig kvalité (buggar) de utmaningar vi haft med en del buggar sista veckorna beror på brister i våra processer och nödvändiga åtgärder är tagna för att undvika detta i framtiden.

Hoppas denna information gett lite mer insikt hur vi jobbar med utvecklingen av Visma eEkonomi. 

Ha en fin dag! 





 
Medverkande