Agila metoder i programvaruutveckling

Vägledning till läsaren

Denna berättelse handlar om hur man har kunnat effektivisera arbetet med att utveckla programvara. Här kan man läsa om de krav som man måste ta hänsyn till vid utveckling av programvara, som skall användas i stridsflygplan där programvaran är klassad som säkerhetskritisk.

Genom att använda agila arbetssätt kan man kraftigt öka prestanda, kvalitet och leveransprecision. I denna text exemplifieras detta med ett utvecklingsarbete, som bedrevs på traditionellt sätt och fick diverse svåra problem. När man sedan övergick till agila metoder fick man en enastående förbättring.

Utvecklingen gick från 0 % leveransprecision och kvalitet till 100 %! Man hade i stort samma bemanning men man ändrade arbetssätt och inställning till arbetet.

Bakgrund

Det är inte helt trivialt att utveckla programvara i komplexa inbyggda realtidsmiljöer, med krav på flygsäkerhet och kvalitet. I den här texten beskrivs de hänsynstaganden som man har att hantera när man utvecklar programvara för avancerade system.

Rekommendation

Författaren rekommenderar nedanstående texter som har koppling till denna berättelse: Under Kundvärde, läs gärna Utveckling av Teknikdemonstratorer, under Livscykelkostnad, läs gärna Systems Engineering och under Utvecklingskompetens, läs gärna Systemintegration - en unik kompetens.

Texten berör markerade områden inom förändringsresan i flygindustrin

Sammanfattning

Att utveckla programvara är en del av utvecklingen av ett flygsystem. Det innebär att den är en del av hanteringen av ett informationsflöde.

Detta informationsflöde startar med en kunds beställning som är baserade på krav och förväntningar och slutar med en levererad produkt.

Att hantera ett informationsflöde för att utveckla programvara innebär att man måste dela upp informationen. Med hjälp av metodik och verktyg skall man kunna hantera spårbarhet av kundkrav till produktleverans. Att utveckla programvara innebär alltså att hantera mycket information.

Utveckling av programvara är inte en fristående aktivitet utan en del av en produktutveckling, vilket innebär en samordning med övriga deltagande processer, en samordning som behöver stöd genom metodik och verktyg. Information måste kunna flöda mellan de olika processerna.

För att hantera de problem det innebär att driva utvecklingsprojekt för programvara, så har det blivit vanligt att använda agila metoder. Exempel på sådana metoder är Scrum, ”parprogrammering” och Kanban.

Syftet med metoderna är att göra succesiva anpassningar av programvaran mot en kravbild som inte alltid är klar från början, exempelvis där en kund från början inte vet exakt hur en produkt skall se ut när den är klar.

Beskrivning av innehåll

  • Vid utveckling av programvara är det oftast inte problem med att hantera funktionen i sig som skapar svårigheter.
  • Det arbete som oftast fordrar mycket tid är att hantera process, informationsflöde, metodik, teknik och utvecklingsmiljö.
  • Det är inte ovanligt att arbetet med att hantera process, informationsflöde, metodik, teknik och utvecklingsmiljöer är det som skapar problemen som leder till förseningar och fördyringar.
  • ”Continuous Integration” innebär att programvara som utvecklas, kontrolleras via byggsteg, testas och görs tillgänglig för alla andra som behöver den.
  • Det är en väsentlig skillnad att utveckla kod för ett inbyggt flygande system med krav på hantering av flygsäkerhetskritisk programvara och på att hantera utveckling av exempelvis ett system för hantering av taktisk loop eller för ett testsystem.

Programvara i realtidsmiljöer

Det är inte helt trivialt att utveckla programvara i komplexa inbyggda realtidsmiljöer, med krav på flygsäkerhet och kvalitet. I denna text beskrivs de hänsynstaganden som man har att hantera när man utvecklar programvara för avancerade system. Exempel på områden som berörs är följande:

  • System som ingår i flygplanet.
  • System för test.
  • Riggar och underhållsutrustning som behövs vid framtagning av ett flygande system.
  • Utprovningssystem.
  • Teknisk loop med analys av ett flygplans tekniska funktionalitet och hantering av underhåll.
  • Taktiska loopen, d.v.s. planering utförande och analys av uppdrag.
  • Operativ analys och träning.
  • Teknisk pilotträning.

Fokus vid utveckling av programvara skall ligga på att hantera kundens förväntningar och utveckling av funktionalitet. Det är inte själva programvarukoden i sig som är primär, koden är ett resultat av utvecklingsarbetet.

Vid utveckling av programvara är det oftast inte problem med att hantera funktionen i sig som skapar svårigheter. Det arbete som oftast fordrar mycket tid är att hantera process, informationsflöde, metodik, teknik och utvecklingsmiljö. Det är inte ovanligt att dessa områden är de som skapar problemen som leder till förseningar, fördyringar och att kundens förväntningar inte kan uppfyllas.

Utvecklingsprocessen för programvara

Saab har under 2000-talet strävat mot att samordna hela företagets processer. Det gäller inte minst utvecklingsprocessen för programvara. Denna är en del av företagets utvecklingsprocess med gränssnitt mot andra processer.

Även om gränssnitten är klarlagda, så är det inte alltid som det inses att informationsflödet mellan dem behöver hanteras i ett utvecklingsprojekt. Man kan ibland behöva utreda hur informationsflöden behöver förändras.

Utveckling av programvara är inte en fristående aktivitet utan en del av en produktutveckling. Utveckling av programvara innebär en samordning med övriga deltagande processer. En samordning som behöver stöd genom metodik och verktyg. Information måste kunna flöda mellan de olika processerna

I figuren nedan visas utvecklingsprocessen illustrerad i form av ett "utvecklings-V". Alla steg som beskrivs i detta utvecklings-V, inkluderar flera processer, inte bara utvecklingsprocess för programvara utan också processer för utveckling av system, hårdvara, verifiering och validering.

I detta "utvecklings-V" för utvecklingsprocessen kan man principiellt följa vägen från krav på ett system, via kravnedbrytning, design, test och leverans. Man kan se det i figuren genom att läsa från övre vänstra hörnet ner till ”V:ts” botten och upp till högra hörnet.

Utveckling av flygsäkerhetskritisk programvara

En utvecklingsprocess skall stå för ordning och reda, d.v.s. se till att hantera kundens krav och förväntningar. Den skall resultera i en produkt som kunden är nöjd med. Det är inget unikt för en flygindustri, det gäller för alla företag som utvecklar programvara.

Det som gör det mer komplicerat för en flygindustri som Saab är att processen som skall borga för kvalitet och effektivitet, också måste kompletteras med ett regelverk för att hantera utvecklingen av flygsäkerhetskritisk programvara.

Exempel på flygsäkerhetskritisk programvara är programvara för styrsystemet i ett flygplan. För att få den att bli tillåten att användas, så krävs det en spårbarhet av funktioner från krav, via implementation och test till produkt. Det ställer också krav på att verktyg, exempelvis en kompilator är godkänd för användning.

De regler som behöver uppfyllas för utvecklingen beskrivs i regelverket RTCA/DO 178C som berör mjukvarubaserade flygsystem. I det regelverket delas programvara in i flera klasser, från A till E, där klass A står för den högsta säkerhetsnivån.

Klasserna A till C räknas i första hand som kritiska för flygsäkerheten, medan klass D och E är programvara som inte är påverkar flygsäkerheten.

I dessa regler beskrivs olika typer av krav enligt följande:

  • Hur krav på programvara skall hanteras för att kunna spåras i den utvecklade programvaran.
  • Hur verktyg för programvaruutveckling skall vara kvalificerade.
  • Hur programvara skall granskas och testas.
  • Hur programvara skall hanteras vid och efter leverans, för att säkerställa att den är så säker som är möjligt, för att få användas operativt i ett flygplan.

Även om den flygsäkerhetskritiska programvaran endast utgör en liten del av all den programvara som utvecklas för de olika systemen, så innebär det att om det blir otydligheter om vad som gäller för olika programvaror, så bäddar det för en ökad komplexitet vid utvecklingen.

Informationsflöde

Att utveckla programvara är alltså endast en del av utvecklingen av ett flygsystem. Det innebär att den är en del av hanteringen av ett informationsflöde.

Detta informationsflöde startar med en kunds beställning som är baserad på krav och förväntningar och slutar med en levererad produkt.

Man behöver för programvaror ha exakt kontroll på vad som är levererat i form av testad kod.

Att hantera ett informationsflöde för att utveckla programvara innebär att man måste dela upp informationen. Med hjälp av metodik och verktyg skall man kunna hantera spårbarhet av kundkrav till produktleverans. Man har stora krav på att hantera information för att säkerställa säkerhetskritisk funktionalitet. Det finns också stora krav på att säkerställa hantering av sekretessbelagd information och information som behöver hanteras avseende exportrestriktioner.

Att utveckla programvara innebär alltså att hantera mycket information. Vid start av ett utvecklingsprojekt, så har man information om att projektet skall leverera vid en önskad tidpunkt. Önskemålen är ofta krav, där man ansätter överenskomna acceptanskriterier, dessa skall vara hanterade och godkända vid leverans.

Det innebär att det är mycket viktigt att redan från början ha en väl utvecklad metodik och erforderliga verktyg som stödjer design av en produkt.

Ett exempel på hantering av information i ett värdeflöde är utveckling av träningssystem för piloter, Mission Training System. Det är ett system där en pilot kan träna att flyga olika versioner av Gripen. Träningssystemet innehåller olika system i form av sensorer, vapen, kommunikation, etc. som de olika versionerna av Gripen består av.

Träningssystemet är uppbyggt av programvara som simulerar alla dessa delar, genom att det finns modeller beskrivna i programvara för alla system. Det innebär att man under utvecklingen behöver hantera modeller som är olika för olika kunder.

System- och programutvecklarna har tillgång till vissa modeller, men inte alla, eftersom de olika systemen har olika försvarssekretess vilket innebär att modellerna också har det. Det kräver att programvaran är uppdelad i skilda delar och att informationen och modellerna hanteras med verktyg som säkerställer åtkomst och skydd.

Produkten i sig är utformad för att ge kunderna tillgång till de modeller som de behöver och har rätt att hantera, men tillåter också kunderna att lägga in egna modeller av exempelvis sensorer, som man vill prova under träning.

Man måste ha en design av ett programvarusystem, som ger möjlighet att lägga till och ta bort modeller av olika delsystem. Det gör att en kund kan få fördel av att ta fram egna modeller av delsystem som denne vill prova ut, utan att leverantören vet hur dessa ser ut.

Det ökar nyttan för kunden, men ger också ett förenklat förfarande vid utveckling och underhåll i form av ett modulärt programvarusystem, med tydliga avgränsningar mellan olika delar av programvaran. Det vill säga om metodiken finns beskriven så att programvaran som tas fram är modulärt uppbyggd, så underlättar det både vid utveckling, vid framtida underhåll av produkten och gör det också möjligt att skilja på programvara av olika försvarssekretess.

Metodik

För att utföra ett utvecklingsarbete enligt utvecklingsprocessen så behöver denna process omsättas i metodik, som sedan behöver anpassas för olika uppgifter.

Vid utveckling av programvara kan man använda "Continuous integration", som innebär att alla utvecklares olika delresultat av kod, kan testas kontinuerligt mot en större kodbas för ett helt system och en hel funktion. Man får därmed snabb återmatning kring funktion och ökad kvalitet på den kod som utvecklats.

”Continuous Integration" används sedan några år i ett antal projekt inom bl.a. utveckling av stödsystem och träningssystem till Gripen. ”Continuous Integration" kommer också att användas vid utveckling av programvara som finns i flygplanet.

För design av system och utveckling av programvara används "Model Based System Engineering" (MBSE). MBSE är ett modelldrivet arbetssätt för att utveckla programvara. Där fokuserar man på att skapa och utnyttja abstrakta representationer av kunskap och aktiviteter för att styra en viss funktion eller system.

Vid denna typ av utveckling används t.ex. modeller för grafisk presentation av ett system. Det innebär att man får en enklare förståelse av ett systems funktion eller effekt. Man vill också använda modeller för att kunna beskriva hur olika system eller delar av ett system fungerar tillsammans. Modeller kan användas för att vara beskrivande, för hur ett tänkt system skall användas eller kan modeller vara definierande och generera exekverbar programkod.

Agil utveckling

För att hantera de problem det innebär att driva utvecklingsprojekt för programvara, så har det under senare år blivit vanligt att använda agila metoder. Exempel på sådana är Scrum, ”parprogramering” och Kanban.

Syftet med metoderna är att göra succesiva anpassningar av programvaran mot en kravbild som inte alltid är klar från början, exempelvis där en kund från början inte vet exakt hur en produkt skall se ut när den är klar. Man skall alltså vara agil, d.v.s. anpassningsbar och lättrörlig under utvecklingen för att stegvis utveckla och förändra en produkt under utvecklingsarbetet.

Arbetet bedrivs då inkrementellt genom succesiv tillväxt av funktionalitet och med ett iterativt arbetssätt. Det innebär att regelbundna mindre leveranser sker och att olika frågor kan utvärderas löpande och ändras för att möta nya krav och önskemål.

Beroende på vilken arbetsuppgift och vilket sammanhang, så är det tillåtet för olika team att själva välja någon av dessa metoder beroende på de förutsättningar som man har. Olika team har också olika mognadsgrad vilket är en annan anledning till att man är fri att välja metod så att man stegvis kan utvecklas och förbättra sitt arbetssätt.

Det är en styrka att programvaruutveckling ger möjligheten att förändra en produkt utan mekaniska omkonstruktioner, men också en svaghet som måste hanteras. Ibland kan det från en kunds sida finnas en uppfattning att det väl ”bara att ändra i några rader kod”. Svaret är, att det oftast inte är så enkelt.

Ett exempel är ändring av kod i en programvara som är flygsäkerhetskritisk. Vilken ändring som helst är omfattande då den innebär en hantering av dokumentation, granskning av kod, testning av funktion och hantering av en ny leverans av kod.

Men även för programvara som inte är flygsäkerhetskritisk, så kan en förändring baserad på nya önskemål innebära större eller mindre förändringar av programvaran. Att införa en ny modell i Mission Trainer, som nämndes ovan, innebär en mindre förändring.

Användning av ett agilt arbetssätt ger stora möjligheter att succesivt i samarbete med en kund vid utveckling av en produkt som uppfyller dennes förväntningar. Det sker under en kontrollerad kravhantering och kostnadsbild.

Att införa agila metoder för styrning av programvaruprojekt är därför något av det viktigaste som hänt på Saab under senare år. Även om Saab i jämförelse med andra tillverkare av flygplan är ett litet företag, så är produkterna komplexa och blir ännu mer komplexa när de skall samordnas med varandra.

Det är lätt att en enskild programvaruutvecklare inte ser sin egen roll i detta, utan att denne kan känna att den egna insatsen inte har så stor betydelse.

Ett exempel är arbetet som gjordes inom MSS för Gripen C/D avseende att hantera bränsleberäkningar, i samband med planering av ett flyguppdrag. Där var endast ett mycket begränsat antal personer inblandade som gjorde ett viktigt arbete för att införa funktionen.

Varje utvecklare betyder mycket för utvecklingen av produkterna. Rätt användning av agila metoder visar på det ansvar som ligger på var och en, vad som skall göras och till när, samt visar var denna ”bit passar i det stora pusslet”.

Agila metoder tillämpas idag av väldigt många olika team i olika projekt på Saab. Införandet startade runt år 2008 med att ta tillvara erfarenheter som gjordes, vid utvecklingen av ett system för uppdragsplanering, inför flygning med transportplan 84 (TP84) för svenska försvarsmakten, vid Saabs dåvarande kontor i Örebro.

Användningen av SCRUM i projektet TP84 gav så positiva effekter, att dåvarande utvecklingsledning utarbetade instruktioner för att införa dem vid arbete med nya produkter. Användandet av Scrum spred sig under 2009, då fler och fler projekt började använda sig av agil utveckling som metodik. Då anordnades också ett flertal workshops där projekt- och utvecklingsteam delade med sig av sina erfarenheter och givetvis även bakslag.

Agila metoder har kommit att sätta fokus på behovet av ett mer flexibelt och lättrörligt arbetssätt för system- och programvaruutveckling. De under många år använda varianterna av vattenfallsmodellen för system och programvaruutveckling har sina begräsningar i strikt planering, styrning och ordningsföljd på de olika faserna i ett utvecklingsprojekt. Med ett sekventiellt arbetssätt får man ofta långa ledtider och mindre flexibilitet för erfarenhetsutbyte och möjlighet att hantera behov av förändringar.

I figuren ser man ett arbetssätt som bygger på vattenfallsprincipen.

Agila metoder har som styrka att använda arbetssätt som sätter den som är kund (intern eller extern) i centrum genom att regelbundet leverera värdeskapande resultat under ett utvecklingsprojekt.

I figuren ser man ett arbetssätt som bygger på agil metodik.

Förändrade krav och förutsättningar är snarare legio än undantag i stora utvecklingsprojekt. Det är då viktigt att kunna hantera förändringar så att de skapar nytta för kunden.

Det agila arbetssättet bygger på att det team som arbetar med en uppgift, själva får ta ansvaret för att planera genomförandet. Det ger oftast bra motivation för att kunna uppnå det mål och de resultat som kunden specificerat. Det blir därmed lättare att kunna leverera bra projektresultat.

I agila metoder är nära samarbete inom teamet en grundsten för genomförande av varje uppdrag. Ett inbyggt och lärande arbetssätt är nödvändigt för att kunna dra lärdomar, som kan användas för nästa eller kommande utvecklingsuppdrag under ett utvecklingsprojekts genomförande. Särskilt viktigt är att teamet får reflektera på hur man presterar och vad som kan göras för att förbättra arbetssättet och öka sin effektivitet.

SCRUM

Inom Saab startade användandet av agila metoder inom programvaruutveckling för ett antal år sedan i samband med uppdateringar av tidigare Gripen-versioner. SCRUM-metodiken blev ryggraden i det agila arbetssättet. SCRUM-metodiken har därefter förfinats och anpassats.

SCRUM är ett iterativt och inkrementellt ramverk för att hantera produktutveckling, särskilt väl anpassat för agil programvaruutveckling. Ramverket i SCRUM definierar "en flexibel, holistisk strategi” för produktutveckling, där ett utvecklingsteam arbetar som en enhet för att nå ett gemensamt mål.

Utvecklingsteamet har ett nära samarbete genom fysisk samlokalisering eller ett nära samarbete via olika ”verktyg” för kommunikation mellan gruppmedlemmarna. Dessutom har man daglig samverkan mellan alla gruppmedlemmar och berörda teknikdiscipliner i det aktuella projektet.

Grundtanken med SCRUM är att minimera riskerna i programvaruutvecklingen genom att utveckla programvara under korta tidsperioder, så kallade iterationer, som vanligtvis håller på mellan två till sex veckor. I slutet på varje iteration finns ett leveransbart resultat av arbetet. Detta resultat utgör då en delmängd av det slutliga resultatet.

I varje iteration ingår att granska arbetssätt och resultat för att kunna förbättra både arbetssätt och det utvecklingsarbete som man arbetar med, detta kallas för retrospective.

Metodiken omfattar ett antal roller och ett antal beståndsdelar i form av obligatoriska möten och dokument.

I figuren visas arbetsmetodiken principiellt i SCRUM, med en sprintcykel. Figuren utgår från arbetssättet enligt SCRUM med en mindre Saab-anpassning.

En väsentlig del i SCRUM-metodiken är det nära samarbetet mellan den interna kunden/beställaren av arbetet och SCRUM -teamet.

För att det skall fungera så måste kunden vara delaktig. Det sker genom avstämningar under utvecklingsarbetets gång, exempelvis kan avstämning ske vid möten efter att en sprint är klar, d.v.s. enligt efter 30 dagars arbete.

Arbetssätt i SCRUM

Att utveckla enligt agila metoder kräver ett engagemang från enskilda individer och utvecklingsteam. SCRUM-metodiken utgår från överenskommelse mellan beställare och SCRUM-teamet.

Det som utvecklingsteamet har överenskommet att genomföra under en sprint, skall också hanteras under sprinten och resultatet skall också kunna levereras.

Definitioner avseende arbetssätt i SCRUM

  • En sprint är en uppdelning av arbetet i lämpliga delar. Planeringen sköts via stories. En story beskriver på ett enkelt och kortfattat sätt uppgiften som skall utföras och varför.
  • Efter prioritering och tidsuppskattning läggs stories i en backlog som ett utvecklingsteam tar till sig av, för att utföra under varje sprint.
  • En backlog är en samlingsplats för alla önskemål om förändringar av produkten. Går uppgiften av någon anledning inte att utföra, så säger man till i god tid och planerar om storyn.

Figuren visar den statusboard som ett SCRUM-team använder. Här publiceras där de ärenden som hanteras under en sprint. 

Arbetsflöde

Nedan beskrivs de moment som ett SCRUM-team hanterar och som publiceras på ett statusboard.

  1. Ärenden som teamet skall arbeta med hämtas från projektets backlog av prioriterade ärenden vid sprintplaneringen. De uppgifter som teamet har åtagit sig att klara av ligger först som ”Not Checked Out”.
  2. Under rubriken ”Checked Out” ligger ärenden som teamets medlemmar arbetar med.
  3. Under rubriken ”Done” ligger alla avklarade ärenden.
  4. I diagrammet ”Burn down” visas hur mycket tid som återstår av sprinten, hur mycket tid som lagts på avklarade ärenden och vad som återstår.
  5. Den blå kurvan i diagrammet ”Burn down” skall i en perfekt planerad och utförd sprint, vara nere på noll när sprinten är klar.
  6. Under rubriken ”Unplanned Items” ligger ärenden som har tillkommit under sprinten. Dessa måste hanteras var för sig. Anser man att man hinner dem under sprinten, så genomför man dem. Annars behövs det en omplanering av sprinten, alternativt så får dessa ärenden göras vid en senare sprint. Teamet hanterar detta vid statusboard och håller projektledaren informerad.
  7. Under rubriken ”Next” finns ärenden som upptäckts under arbetet och som behöver hanteras vid planering och uppdatering av projektets Backlog.

Förutsättningar

Arbetet med ett statusboard tydliggör för en projektledare vad ett utvecklingsteam orkar med. Det går kanske inte att ”pressa” in mer och mer arbete under en viss tid. Det krävs att projektledaren har ordning på den backlog av ärenden, som skall utföras och att dessa är tidsatta och prioriterade. Är detta uppfyllt kan ett utvecklingsteam sedan ”plocka åt sig” de olika uppgifterna som skall utföras under en sprint.

Agil utveckling när den fungerar bra, gör att projektledare vet vad som kommer att utföras av respektive utvecklingsteam och när det blir klart. Utvecklingsteamen har själva tagit detta åtagande. Det ger projektledaren en möjlighet att prioritera verksamhet, plocka bort sådant som kan göras senare, eller aldrig behöver göras.

I SCRUM-metodiken är återmatning (retrospective) en hörnsten i arbetssättet, denna görs vid avslut av varje sprint. Här är varje enskild teammedlems synpunkter på vad som fungerar bra och vad som fungerar mindre bra, viktiga att lyfta fram, för att ett kontinuerligt förbättringsarbete skall kunna ske.

Svårigheter med SCRUM är bland annat att sätta ihop fungerande utvecklingsteam, med den kompetens som utvecklingsteamet behöver. Utvecklingsteamen och varje utvecklare behöver träna på att bedöma vad man hinner med och se till att detta också blir utfört.

Om det är stora projekt så kan det vara svårt att samordna alla utvecklingsteams arbetsinsatser. Genom att alla se till att alla utvecklingsteam använder samma tidslängd för varje sprint underlättas samordningen.

Det måste också finnas en övergripande planering, som styr projektets backlog av ärenden och ger deras prioritering. Denna måste alla utvecklare känna till. Det är oerhört viktigt att alla är delaktiga i val och beslut om vad som skall göras under varje sprint. Alla behövs och är viktiga. Detta är styrkan vid användning av SCRUM, men blir en svaghet om kunskapen saknas.

Användning

SCRUM används inom merparten av de projekt som arbetar med systemutveckling och programvara avseende Gripen. Den används exempelvis både vid utveckling programvara i systemdator för Gripen, träningssystem, tekniska och taktiska markstödssystem.

Många programvaruutvecklingsprojekt använder SCRUM med en sprintlängd på tre veckor. Det verkar vara en sprintlängd som ger en bra anpassning till behovet av fokusering på uppgiften och behovet av att hantera prioriterade stories.

Det är också viktigt att kunna genomföra demonstrationer av resultat från en sprint vid avslut av denna. Dessutom är det nödvändigt att hantera behov av omplanering och omprioritering med andra utvecklingsteam.

I samband med att man startade utveckling av Gripen NG infördes agila metoder på alla nivåer inom disciplinerna, för utveckling av programvara, hårdvara och design av grundflygplanssystem.

Exempel på resultat som kommit ut av projekt som har använt SCRUM under en längre tid är följande:

Vid utveckling av planerings- och utvärderingssystem för Gripen C/D och numera för Gripen E (Mission Support System - MSS C/D och MSS E) har SCRUM-metodik bidragit till följande:

  • Ett strukturerat arbetssätt, där produktkraven överförs till ”toppstories”, som sedan bryts ner i mindre arbetspaket/stories, prioriteras i backlog och hanteras av teamen. Teamens effektivitet mäts via ”burn-down”.
  • Att man i projekt MSS-C/D fått kontroll över leveranser och kostnader.
  • Att man i MSS-E har bra progress för framtagandet av programvara som skall levereras. Man har fått ”koll på” sitt arbete.

Exempel - framgång med hjälp av agila metoder

Inom teknikområdet Grundflygplansystem hade man i början av 2010-talet stora problem med att få färdigt ett av de mer centrala systemen kallat AIU. Man hade en tid arbetat på ett traditionellt sätt med att utveckla programvaran.

Arbetet karakteriserades då av, att man var positivt inställd till att göra alla arbetsuppgifter som påfördes utvecklingsteamet. I utvecklingsteamet fanns några mycket erfarna nyckelpersoner, vilka gjorde individuella bedömningar av tidsåtgång för olika arbetsuppgifter utifrån personliga erfarenheter.

Det fanns många kravställare på utvecklingsteamets uppgift. Utvecklingsteamet hade däremot ingen specifik metod för att analysera vilka krav som var mest angelägna att prioritera vare sig efter ordningsföljd eller efter angelägenhetsgrad. Det berodde på att det inte fanns någon fastställd plan på leveransordning. I positiv anda tog man sig an alla nya uppgifter.

I utvecklingsteamet blev de mest erfarna nyckelpersonerna snart en trång resurs, vilket ledde till en begränsad kommunikation med kravställare och andra utvecklingsteam som var intressenter. Genom att nyckelpersonerna var hårt belastade blev utvecklingsarbetet ett mer individuellt arbete.

Arbetsbelastningen på utvecklingsteamet blev mycket stor, så man hade inte tid med ett systematiskt förbättringsarbete av sitt arbetssätt. Genom den stora arbetsbelastningen blev man tvungen att sätta in mycket övertid för att klara sin uppgift. Trots detta blev förseningsläget allt värre. Kravställarna som inte fick sina leveranser i tid blev mycket missnöjda, vilket ledde till dålig stämning. Hög arbetsbelastning gjorde att man inte hade haft tid att ta reda på de interna krav som fanns och som skulle ha underlättat en prioritering.

Mätning av prestanda

Initialt innan någon förändring skedde genomfördes en mätning av trivseln i utvecklingsteamet. På en skala 1-5 så blev betyget 2,8. Man mätte också prestanda på tid, teknik, kvalitet och leveransprecision. Det visade sig att dessa värden var helt oacceptabla med 0 %. Resultaten var en konsekvens hög arbetsbelastning. Man kunde inte leverera i tid.

Åtgärder

Efter detta startade ett förändringsarbete. I detta bekymmersamma läge tillsattes en ny projektledare, som införde ett agilt angreppssätt på uppgiften och utvecklingsteamets arbetssätt. Man såg till så att man lärde känna varandra i teamet och hade ett nära samarbete med systemutvecklarna.

Man gjorde en genomgång med samtliga kravställare och man gjorde då en prioritetsordning mellan alla aktiviteter. Genom det kunde man tydligt se vilka konsekvenser detta fick för andra utvecklingsteam.

Utvecklingsteamet gjorde upp en plan för att klara detta åtagande. Resultatet av planeringsarbetet gav stort engagemang då teamet kunde få en överenskommelse med kravställarna. Man gjorde sedan formella överenskommelser om en leveransplan med alla berörda intressenter, kravställare och utvecklingsteam.

Detta resulterade i att andra utvecklingsteam kunde planera sitt arbete så att man fick kontroll av hela värdeflödet. Det gällde både inleveranser till utveckling av AIU och utleveranser från detta team.

Man införde också agila metoder som ”parprogrammering” och SCRUM-metodik. Detta arbetssätt är lämpligt för att få en effektiv kunskapsöverföring mellan teammedlemmar.

Man såg till så att man kunde visualisera arbetet på en finmaskig nivå. Därigenom kunde man enkelt följa arbetet. Man hade nu möjligt att optimera arbetet på ”dagnivå” och hade hela tiden den kritiska linjen tydligt synliggjord för hela projektet.

Nu fanns en prioritetsordning. Man hade klassat vilken programvara som var av säkerhetskritisk typ. Man hade en detaljerad plan för hur man skulle leverera ny kod, för att kunna bli klara inom 18 månader, vilket var helt nödvändigt.

Leverans av ny kod skulle nu ske vid fastställda tillfällen, totalt 6 gånger under projektet. Genom att utvecklingsteamet nu kunde hålla sin plan och kunde leverera i tid så fick man beröm, vilket gav positiv påverkan på stämningen i teamet. Man arbetade också mycket med att kommunicera med kravställarna och med andra utvecklingsteam i värdeflödet.

För att få bättre balans av arbetsuppgifter i teamet fick nyckelpersonerna agera som coacher för att stödja och lära övriga i teamet.

Man införde ett systematiskt förbättringsarbete för att effektivisera många arbetsuppgifter som var repetitiva. Man gjorde många och effektiva förbättringar både av de verktyg man använde och av de metoder som styrde arbetet. Man arbetade efter SCRUM-metodik och hade alltid en retrospektiv översyn vid varje sprintavslut.

Mätning av prestanda efter åtgärder

Vid mätning av trivseln i utvecklingsteamet i slutet av projektet blev resultatet på en skala 1-5 betyget 4,7. Man mätte också prestanda på tid, teknik, kvalitet och leveransprecision. Det visade sig att man hade 100 % uppfyllnad!

Framgångsfaktorer i projektet var följande:

  1. Man arbetade med en behovsnära styrning, alltså levererade i tid och med rätt kvalitet.
  2. Man organiserade projektet så att man på vardagsbasis kunde ge ett praktiskt och konkret stöd till deltagarna.
  3. Projektägaren tog ansvar för att säkra kontakt och kontinuerlig kommunikation med kravställare och andra intressenter.
  4. Man arbetade med kommunikation och kunskapsöverföring i hela värdeflödet.
  5. Man delade upp arbetet i mindre och överskådliga delar som gick att styra.

Lärdomar från agila metoder

Det är mycket viktigt att utvecklingsteamen själva får satsa sitt engagemang, utifrån det åtagande man själva gör, för att utvecklingsarbetet skall bli effektivt. För att få ett effektivt utvecklingsarbete är det nödvändigt att de olika utvecklingsteamen förstår, både sin egen del i utvecklingsarbetet men också helheten i värdeflödet.

Man måste förstå förutsättningarna både uppströms och nedströms i värdeflödet. Förstår man detta är det väsentligt mycket enklare att kommunicera och överenskomma, med sin interna kund, om förväntade projektresultat. Därmed kan teamet planera arbetet så att man utvecklar rätt funktionalitet, levererar vid rätt tid och med rätt kvalitet.

Engagemang behövs både på individ- och teamnivå, det vill säga engagemang för projektet, i processen, och till varandra inom ett utvecklingsteam. En viktig faktor för att får rätt engagemang och ansvarstagande är att teamen får delaktighet både i beslut avseende teknik och arbetssätt.

Självklart finns en hierarkisk struktur inom linjeorganisationen för hur man fattar tekniska beslut. Det är dock viktigt att teamen förstår den tekniska designen och blir delaktiga, för att kunna realisera de tekniska lösningarna på ett effektivt sätt.

En nyckelroll för arbetet med agila metoder och specifikt SCRUM är den som är produktägare. Denne har en nyckelroll för att samla ihop alla typer av krav och inkludera de som är härledda från överordnade kundkrav.

Alla krav måste omvandlas till konkreta utvecklingsuppdrag. Man måste också fastställa värdet av de funktioner som skall utvecklas och ge tydliga planeringsförutsättningar för dem. En produktägare skall både säkra realisering av nya tekniska funktioner, definiera och minimera risker samt planera för kommande tekniska utvecklingssteg.

Utvecklingen av Gripen NG är ett mycket komplext projekt. Det finns mer än 1000 ingenjörer grupperade i över 100 utvecklingsteam inom 14 teknikområden.

I detta utvecklingsarbete används SCRUM och agila metoder för att utveckla olika funktioner och system. Att integrera många system i en komplex produkt ställer stora krav på arbetssätt och styrning av arbetet. Genom användande av SCRUM och agila metoder kan man kontinuerligt få bra överblick hur utvecklingsarbetet fortgår och man kan dessutom hantera avvikelser och problem snabbt och regelbundet.

Continuous integration

”Continuous Integration” innebär att programvara som utvecklas, kontrolleras via byggsteg, testas och görs tillgänglig för alla andra som behöver den. Är metodik och utvecklingsmiljö fullt utvecklad för ”Continuous Integration”, så ger varje ny tillförd programvara en produkt som är byggd och testad till en given kvalitetsnivå.

En fungerande ”Continuous Integration” är en process som innebär att det hela tiden finns en produkt som fungerar, där man vet vilken funktion denna har samt vilka ärenden och krav som den hanterar.

Integration och tillväxt av funktionalitet sker stegvis, inte i stora integrationssteg. Tester kan utföras kontinuerligt när funktionstillväxten sker. Fel återmatas tidigt till utvecklare och gränssnitt provas ständigt. Om ”Continuous Integration” är fullt utbyggd i ett projekt, så ger denna en effektiv utveckling som bidrar som en framgångsfaktor i ett projekt.

I figuren visas de olika processtegen i ”Continuous Integration”.

För ett större projekt med många team och många funktioner är ”Continuous Integration” komplext att införa och arbeta efter.

För att ”Continuous Integration” skall fungera så kräver det ett genomtänkt informationsflöde, stöttad av en genomtänkt och fungerande CM metodik. Man behöver också en genomtänkt byggmiljö, med möjlighet till ”dagliga- och nattliga byggen”. Dessutom är det nödvändigt att integrations- och systembyggen är automatiserade i hög grad.

Det krävs också en genomtänkt teststrategi med automatiserade tester. Man måste dessutom stötta och säkerställa att den programvara som ständigt tillförs projektet, fungerar tillsammans med övriga delar av programvaran.

Figuren ovan visar stegen i ”Continuous Integration” men är förenklad bild av processen. Det behövs exempelvis också en metodik för att se till att varje programvaruutvecklare får tillgång till de funktioner som behövs för att kunna utveckla sina egna delar. Det behövs utvecklingsverktyg (programvara) och en utvecklingsmiljö (lagring och maskiner) som stödjer detta.

Ett sätt att ge varje utvecklare tillgång till den färdiga produkten är i form av ”Prebuilts” som är kontrollerade utgåvor av produkten och som kan användas som en bas för att utveckla en enskild del av en funktionalitet, d.v.s. den kod som en enskild programvaruutvecklare behöver för att förändra. Varje ”Prebuilts” status beskrivs avseende innehåll, i form av funktioner och vilka gränssnitt som gäller för den.

Erfarenheter och användningsområden

Det finns ett flertal exempel på projekt där man har fått ”Continuous Integration” att fungera i olika grad, men tyvärr så tenderar resultat och erfarenheter att inte föras vidare mellan projekt och när nya projekt startas.

Att få ”Continuous Integration” att fungera utan att ha egen erfarenhet av detta arbetssätt är inte lätt. Erfarenheter måste föras vidare från projekt till projekt.

Några exempel på lyckade projekt som använt ”Continuous Integration” är:

  • Utvecklingen av styrsystem till Gripen var det projekt som var först ut med att tillämpa ”Continuous Integration”.
  • Olika projekt inom stödsystem till Gripen.
  • Mission trainer och MSS för Gripen C/D och MSS för Gripen E.
  • Mission Support System för Gripen C/D.

Utvecklingen av styrsystemet till Gripen genomfördes genom bygge och test av programvaran till styrsystemet, enligt det flöde som har likhet med processen för ”Continuous Integration”.

Tidigare nämnda ”Mission trainer” och MSS för Gripen C/D och MSS för Gripen E är projekt som använt och använder ”Continuous Integration” i utvecklingen av programvara. I dessa projekt så kan man via en sida i projektens ”Wiki”, ständigt se hur bygge och integration fungerar i de olika programvarudelar som projektet består av. Varje incheckad kod byggs och testas automatiskt.

Resultatet presenteras med hjälp av färger för varje programvarudel. Om en incheckning misslyckas i någon del, så kan varje utvecklare se detta och ofta får den utvecklare som gjorde incheckningen en notifiering om resultatet. Det är lätt att inse hur värdefullt det här är i ett projekt med många utvecklare.

Arbetssätt

För utveckling av taktiskt stödsystem för planering och utvärdering av uppdrag, kallat Mission Support System för Gripen C/D, används ”Continuous Integration” enligt följande:

  • En utvecklare av en funktionalitet får tillgång till den senaste programvaran i form av ”Prebuilts” som är kontrollerade utgåvor av MSS C/D. Denna ”Prebuilts” kan användas som en bas för att utveckla en enskild del av en funktionalitet, d.v.s. den kod som en enskild programvaruutvecklare behöver förändra.
  • Tillsammans med en datamiljö, exempelvis kartdata, vapendata etc., så finns allt som behövs tillgängligt.
  • ”Prebuilts” utgår från den produkt som (nästan) alltid finns fungerande. ”Prebuilts” paketeras vid planlagda tillfällen och görs tillgängliga i projektet.

När en utvecklare är klar med sin funktionalitet, så testas den i ramverket (programvara och hårdvara) för att dagligt kunna bygga ”systemet/produkten”. Detta kallas ”daily build”.

  • Man kan då visa att den går att använda i projektet.
  • Man kan också visa att gränssnitt etc. fungerar och att den inte förstör andra utvecklares arbete med koden.

Funktionen läggs sedan in en ”byggmiljö” och körs som nattligt bygge. Vid denna körning görs olika automatiska teststeg etc., detta kallas ” Nightly build”.

  • För varje steg så får programvaruutvecklaren notering om allt går rätt eller om det finns fel att ta om hand.
  • Det ger en snabb återmatning till en utvecklare och låter denne stegvis testa och hantera upptäckta fel.

Att ha en fungerande ”Continuous Integration” funktionalitet i ett projekt ger alltså en mycket stor effektivitet.

Ökad automatisering

Det kan gå att nå ytterligare ett steg vidare från” Continuous Integration” till ”Continuous Deployment”, vilket innebär att slutresultatet är en produkt som är klar för leverans.

Det innebär att varje nytillförd funktionalitet skall resultera i en produkt, testad och klar för leverans. Att nå nivån ”Continuous Deployment” för en ”programvara som skall flyga”, kräver dock en analys av hur långt det går att automatisera alla de formella steg som behövs innan en programvara blir godkänd för flygning.

Även om man för närvarande har en bit kvar innan detta är genomförbart, så är det värt att studera hur långt det går att driva processen. Även andra processer än utvecklingsprocessen för programvara blir inblandade, exempelvis systemutveckling, verifiering och validering.

Hantera befintliga och framtida krav

Hantering av problem vid programvaruutveckling är till stor del förmågan att tillämpa metodik, exempelvis agil utveckling och ”Continuous Integration”.

Men man får inte glömma bort att se det behov av teknik och teknikutveckling som också behövs inom området agil utveckling och ”Continuous Integration”. De teknikområden som skulle ha stor nytta av bättre metodik i utvecklingsarbetet är programvaruarkitektur, d.v.s. hur krav översätts till en design, teknik för att hantera byggandet av programvaruprodukter, hantering av test, teststrategi och hantering av realtidssystem samt informationshantering och programvarusäkerhet.

Här pågår samarbete med landets högskolor för att studera till exempel hantering av teknisk skuld. Det sker genom att definiera vad som menas med teknisk skuld och applicera teknik för att mäta och hantera den. Andra exempel är teknik för att utveckla ”Continuous Integration” och teknik för att hantera programvara i Multicore processorer i flygande system.

Valet av MBSE är lika mycket ett val av metodik som val av en teknik. Att lyckas med att införa MBSE vid programvaruutveckling ger möjligheter att hantera arkitektur, design och underhåll av komplex funktionalitet.

Men det finns även andra områden som är lika viktiga, som exempelvis teknik för att hantera inbyggda realtidssystem, säkerhetskritisk programvara i system med multiprocessor, test och omvärldspresentation i realtidssimulatorer.

Det är viktigt att de erfarenheter som görs, överförs och blir kända för nya eller pågående projektteam. Överföring av erfarenheter tycks alltid vara en utmaning, oaktat vilket årtionde man avser.

Krav på programvara

Det är en väsentlig skillnad att utveckla kod för ett inbyggt flygande system med krav på hantering av flygsäkerhetskritisk programvara och på att hantera utveckling av exempelvis ett system för hantering av taktisk loop eller för ett testsystem.

Inbyggda system med krav på realtid innebär exempelvis att man har tillgång till begränsat med minne, mindre lagringsmedia och krav på prestanda för att upprätthålla tidskrav. Flygsäkerhetskritiska delar får inte ”krascha”, d.v.s. sluta exekveras utan att det finns kontroll på hur kraschen skall hanteras. För programvara som används vid ett skrivbord i en icke kritisk användning är det irriterande om ett program upphör att fungera, men där kan man hantera det genom att starta om programmet, eller i många fall starta om datorn.

Krav på systemutvecklingsmiljö

Ofta är det lätt att hamna i en situation där man gör ett verktygsval, exempelvis ”en häftig” kompilator, utan att ha tänkt igenom den metodik och de regelverk som behöver följas innan valet görs. Verktygen skall vara just verktyg, som hjälper till att utveckla produkter snabbt och effektivt.

Det är också viktigt att ha kontroll över inlåsningseffekter, d.v.s. om man väljer ett visst verktyg vad det innebär i arbete och övrig kostnad att byta det mot ett annat verktyg.

Det är ändå inte antalet verktyg som behöver förvaltas som är väsentligt. De kan vara många. Det viktiga är att ha kontroll över att verktygen ger möjlighet att realisera vald metodik.

Strategi för systemutvecklingsmiljöer

Eftersom det är skillnader i utveckling av de olika produkterna och antalet verktyg är stort och behöver vara stort, så behövs det en strategi för att hantera verktygen.

  • En strategi är att beskriva behovet av verktyg i de förmågor som behövs för att utföra utveckling av produkt.
  • Förmågor är exempelvis behov av verktyg för agil utveckling, byggmiljö, testmiljö, hantering av krav etc.
  • Det är väsentligt att dela in utvecklingen i förmågebehov och se över vilka verktyg som behövs för att realisera förmågorna.

Strategin skall också se till att det går att utveckla både inbyggda realtidssystem och system för ”skrivbordet”. Här används olika operativsystem, vilket innebär att olika verktyg passar bäst för utveckling för en viss produkt. Det innebär att en förmåga innehåller flera olika verktyg som uppfyller denna. Det kan till och med vara en styrka för ett större företag att ha flera olika val. Det ger en möjlighet att hantera exempelvis kunders önskemål om programvara som skall kunna användas på en viss plattform (Linux, Windows, Android etc.). Det minskar också beroendet av en given verktygsleverantör och ger möjlighet att jämföra funktionalitet i olika verktyg.

Systemutveckling och produktåtagande

Här är det också viktigt att förstå att en utvecklingsmiljö och en metodik är kopplade till en produkt, snarare än till ett projekt. Projektets uppgift är att hantera utveckling och leverans av en given version av en produkt. Sedan är projektet oftast slut. Produkten lever ju dock vidare i form av nya projekt som hanterar garantiåtagande, vidareutveckling etc. Utvecklingsmiljön behövs då för att hantera nya projekt för produkten.

Nedan ges några exempel på olika verktyg som behövs för utveckling av en produkt. Man behöver då bland annat verktyg för:

  • Configuration Management (CM).
  • Utveckling (kompilatorer, editorer).
  • Bygge av produkten.
  • Hantering av ärenden.
  • Framtagning av HMI.
  • Leverans av produkten.
  • Hantering av säkerhet (exempelvis virusskydd).

Rekommendationer

Det är väsentligt att ett projekt för att skapa en effektiv systemutvecklingsmiljö kopplas till en produkts livscykel, snarare än till ett enskilt systemutvecklingsprojekt.

Det är ett projekt i sig, att sätta upp alla de verktyg och tillhörande anpassningar av dem, för att hantera metodik, förmågor och kraven på informationsflöde.

Ett projekt som kommer att leva som en del i en produkts utvecklingsprojekt under hela dess livstid och ibland längre.

Projektet att hantera utvecklingsmiljö har åtminstone tre faser:

  • Sätta upp och ta i drift utvecklingsmiljön.
  • Kontinuerligt vidmakthålla utvecklingsmiljön vid projektavslut.
  • Paketera utvecklingsmiljön för framtiden.

Författarens reflektioner