All posts in Application Lifecycle

SharePoint! När jag nämner detta ord är det med spänning jag inväntar reaktion… detta för att det finns starka känslor kring vilken upplevelse man har haft i samband med SharePoint. Reaktionen kan ha en närmast traumatisk återkoppling och andra reagerar euforiskt över tillfället att berätta om alla framgångssagor… varför har det blivit så och hur ser SharePoint ut idag?

SharePoint har en lång historia av att vara en ledande plattform för att bygga intranät och hantera företagsrelaterat innehåll. Enligt Nielsen Norman Group’s Top 10 intranets så är 70-80% av topp 10 intranäteten byggda på SharePoint. Det verkar dock inte lika vanligt att man skryter med det, nästan tvärt om och det händer att kunder frågar om man kan få det att se ut som något annat än ”SharePoint”.

Det klassiska (Classic) SharePoint lanserades redan 2002 och har genomgått flera upplyft genom åren. Eftersom det finns många olika lösningar av varierande kvalitet och flera olika versioner så är det nästan omöjligt att fullt förstå hur användare har mottagit lösningen. Microsoft behövde fatta ett beslut: översyn av den åldrande produkten, eller se SharePoint dö en långsam och smärtsam död. Resultatet fick vi se i fjol med införandet av den nya ”moderna” SharePoint upplevelsen (Modern).

På kort tid så har Microsoft lyckats koordinera flera parallella initiativ på flera olika nivåer och resultatet pratar för sig själv om man vill se efter. Några av de saker jag tycker sticker ut med detta nya tänkt kring SharePoint och Office 365:

  • Tilltalande sidor, listor och bibliotek – både för redaktörer och konsumenter av innehåll, påminner inte det alls om klassiska SharePoint
  • Responsivitet – Det är inte längre en fråga om sidorna fungerar på mobiltelefoner
  • Hastighet – Större del av koden körs på klienten, moderna webdelar och smartare indexeringsfunktioner
  • SharePoint Framework (SPfX) – Helt ny utvecklarupplevelse med nya moderna verktyg och process
  • Office 365 – bra integration till andra moduler (Outlook, Planner, Forms m.fl.) och nya grupper i Office 365 för att hantera användare och rättigheter
  • Hubbsidor – En platt struktur istället för mängder med undersidor, gemensamma funktioner och navigering
  • Flow – Automation och arbetsflöden som fungerar även utanför SharePoint, kan exporteras och utvecklas vidare som Azure Logic Apps
  • Teams – nytt samarbetssätt med allt som behövs i samma kontext
  • Agile/DevOps – nya kvalitetssäkrade funktioner snabbare, mer öppenhet och transparens

Enligt Gartner så är nu SharePoint rankad #1 på förmågan att exekvera innehållstjänster.

According to Gartner, “Content services platforms are the next stage of enterprise content management, representing a shift from self-contained systems and repositories to open services.” To truly deliver on the promise of content services, you must balance manageability with ease of use to unlock productivity gains around your critical business information.

Jag kan inte göra annat än att hålla med och hoppas att fler användare kan tänka sig ge SharePoint en ny chans. Kontakta gärna din favorit expert och boka in en demo på det nya moderna tänket kring SharePoint/Office365 och framtidens digitala arbetsplats.

:=)

 


Att bygga mjukvaror är svårt, att räkna på investeringar i mjukvaror är svårt, att möta investeringen med rätt byggkvalitet är jättesvårt. Vi vet oftast för lite kring vilken skuld vi har ackumulerat genom de beslut vi tar längs resan och vi fokusera inte ofta på att amortera skulder.

Total ägandekostnad (eng. Total Cost of Ownership, TCO) är något som investerare kalkylerar på för att se vad den totala kostnaden är för en mjukvara inför ett investeringsbeslut. Den totala ägandekostnaden omfattar såväl anskaffningskostnad som driftskostnad men i många fall så räknar man inte med ackumulerade skulder som en del av den totala kostnaden för ägande, kanske för att det inte finns bra modeller för detta eller för att man helt enkelt inte förstår att det kan kalkyleras.

Under en applikationslivscykel så skiftar investeringen från en kapitalinvestering (CAPEX) till en operativ kostnad (OPEX), vanligtvis från ett projekt till en förvaltning. Inkluderat i denna övergång är de skulder som ackumulerats vilket kan leda till oförutsedda kostnader och ytterligare investeringsbehov för att möta effektmål. Det är en stor risk att inte veta vilken skuld man äger och vilka mått av kvalitet man mäter på, detta kanske är än mer viktigt när det kommer till mjukvaror då det kommer strida strömmar av inkrementella förbättringar och de positiva riskerna (vinster) kan kontinuerligt värderas därefter. Det är trots allt idéer som blir till affärsapplikationer, som sparar pengar eller ökar omsättningen.

För några veckor sedan var jag med som talare på en konferens kring systemförvaltning och passade även på att lyssna på övriga talares framträdanden. Ett mycket intressant framträdande var från Johan Magnusson, forskare från Chalmers kring Teknikskuld (eng. Technology debt) och Teknisk skuld (eng. Technical debt). Det bredare begreppet kring teknikskuld som innefattar såväl personal (ideologi, kompetens, arbetsmiljö), användare (nöjdhet, rykte) och system (infrastruktur, skugg-it, teknisk, styrning) kan även ackumulera skuld på samma sätt som teknisk skuld gör vid exempelvis bristande kvalitet i konstruktion av programvara. Väldigt användbart för att hantera såväl risker som nyttorealisering och skuldsanering, ser fram emot mer insikt i denna forskning.

Att automatisera, optimera och integrera leveransprocessen är utmanande, men om inte snabbt införande prioriteras kommer det inte heller att gå snabbt, likaså är avsaknad av inbyggd kvalitetshantering det säkraste sättet att erhålla dålig kvalitet och en stor dold skuld med ockerränta. Genom att kontinuerligt värdera nya insikter och vikta dessa mot baslinjen så kan man istället undvika onödiga problem och säkerställa bra och friska nyckeltal.


Då var det dags att solidifiera min inriktning och nu går jag all-in på livscykelhantering och optimering av utvecklingsprocesser. Jag ansluter mig stolt till Nordeuropas vassaste gruppering av experter inom applikationslivscykelhantering – www.solidify.se.

Det handlar om passion. Ett outtröttligt engagemang, förtroende och närhet till kund, en delad vision, att i en värld där mjukvaruutveckling blir alltmer avgörande för företags framgång, möjliggöra och aktivera organisationer att nyttja integrerade och optimerade processer för applikationslivscykler.

Känslan att se människor förändra och förbättra i takt med nya insikter, kunskaper och samtidigt vara trygga med att tidigare leveranser inte påverkas. För mig handlar det om min passion, att våga ta nya vägar, se nya möjligheter och att kontinuerligt utveckla system, processer och människor.


Tittar man på ett historiskt perspektiv kring systemutveckling så ser man att det har hänt mycket kring antalet roller och verktyg som är involverade under hela livscykeln. Mängden kommunikationsvägar  har samtidigt ökat radikalt, det är betydligt fler specialister med i utvecklingsprojekten än tidigare och det blir därmed svårare att avläsa status då det behövs aggregeras data från fler källor än tidigare.

kommunikationsvägar systemutveckling alm

Det är kanske inte så ovanlig att specialister vill ha de bästa verktygen för just den specialiseringen man nischat in sig på, som exempel så vill ju gärna testproffs använda sig av Test Management verktyg och programmerare vill ju gärna ha effektiva källkodshanteringssystem. Börjar man lista dessa specialist system så blir det snart en gedigen lista och det är inte alltid så lätt att få dessa system att kommunicera med varandra utan manuell handpåläggning.

Det finns en formel för att räka ut hur många kommunikationsvägar som finns givet antalet kommunikatörer, formeln är n*(n-1)/2 och används ofta inom projektledning för att räkan på hur många kommunikationsvägar som måste hanteras. Som exempel så kan vi tänka att ett systemutvecklingsprojekt består av 10 personer så blir kommunikationsvägarna mellan dessa 10*9/2=45, alltså kan kommunikationen färdas på 45 olika vägar.

Denna formel går även att applicera på verktyg som systemutvecklare behöver använda för att bedriva effektiv systemutveckling. Om vi tänker oss att det finns 10 olika verktyg för systemutveckling (så som verktyg för programmering, källkodshantering, dokumentation, rapportering, krav, test, arkitektur, tidsrapportering, bygghantering och drifthantering) då blir även detta 45 olika vägar som information kan tänkas behöva flyta för att få effektivitet i flödet. Enligt min erfarenhet så är det inte så många organisationer som lägger samma vikt vid denna typ av kommunikationsvägar som i projekten, men det borde man för det minimerar waste (se Lean) och förbättrar kvalitet på resultatet. Detta argument är centralt i ALM (Application Lifcecycle Management) verktyg, där fokus är att länka samman alla verktyg och underlätta för hela systemutvecklingsflödet både mellan människor i sociala relationer och mellan verktyg och informationsflöden däremellan.

Är man ansvarig projektledare för ett större systemutvecklingsprojekt och får den vanliga frågan ”Hur går det?” så blir ju svaret ofta ett konsultsvar – Det beror på…
Det är ju så många olika saker som väger in och det är ofta svårt att få insikt om hur det faktiskt går vid en given tidpunkt och ibland kan det faktiskt vara så illa att man inte ens har möjligheten att införskaffa sig insikt då det är för många kommunikationsvägar som saknas eller inte är kompatibla.

 
Vi vill ju ofta arbeta mer agilt och i många kortare iterationer vilket är bra då man efter varje cykel kan avgöra om man behöver ändra riktning. För att denna process skall fungera optimalt så behöver även verktygen samspela effektivt över hela applikationen så det inte uppstår köbildning i någon instans där informationsflödet kan komma ur synk. Genom att samordna verktyg och processer för att aktivt hantera alla kommunikationsvägar över hela applikationslivscykeln så faciliteters även de sociala kommunikationsvägarna.


De flesta företag strävar efter mål och strategier som ger dem unika fördelar mot sina konkurrenter.

Förvånansvärt få av dessa företag har etablerade strategier för att skapa egenutvecklade fördelar med hjälpa av skräddarsydda applikationer och IT-lösningar, vilket jag nu tänkte redogöra varför jag anser att dessa företag borde tänka om.

Finns resultatet att köpa så bör man kanske inte utveckla det själv… det ger ju inga strategiska fördelar då konkurrenter kan köpa samma lösning. Köp då istället in den färdiga lösningen och investera istället där det faktiskt går att få en unik fördel. Genom att tänka på hur en IT-lösning kan erbjuda direkta fördelar för verksamheten genom att driva egenutveckling av applikationer, vi kallar detta begreppet – ”Strategisk IT”, den andra typen av IT kallar vi här för ”Nytto IT” och det är allt annat som inte är av strategisk vikt, se nedan:

blog.yllemo.com_stratit

Då Strategisk-IT erbjuder unika fördelar och Nytto-IT mestadels erbjuder verksamhetsstödjande IT så kan alla former av IT underminera verksamheten och försvåra för verksamhetens nyttjandegrad av IT-stöd. Genom att aktivt analysera hur verksamheten kan konsumera kunskap och leverera insikt och beslutsunderlag tillbaka till strategiska råd så får man se tidiga indikatorer på att något borde ändras. Precis som en kvalitetsprocess bör även en IT-strategisk process finnas på plats då nästan alla idag arbetar med hjälp av IT-stöd i någon form.

Det man skall värdera när man investerar i egenutvecklade lösningar är långsiktigheten, man borde tänka hela livscykeln och räkna in både projektresultat och de långsiktiga effektmål som man utvecklar för. Tänker man på detta redan tidigt i projektet så får man en förvaltningsbarhet kring lösningen som kortar ner vidareutvecklingstider och kunskapsöverföringstider.

Det är först till kvarn som får mala när det gäller strategisk-IT, den som först har sin lösning på plats vinner det största övertaget, nästa företag som försöker nå samma fördel får en betydande nackdel och över tid så blir nya innovationer ofta ett tvång för alla andra företag. Ett företag som inte har varit med på banan kan få en rejäl kalldusch och krampaktigt tvingas försöka komma ikapp, vilket kan vara en utmaning även för den bästa på den snabbrörliga informationsarenan.

Jag får ofta riskrelaterade frågor kring reaktivt beteende, vad gör vi om… något händer… vilket i sig själv är bra då risker skall tas seriöst. Men även positiva risker skall värderas högt… hur kan vi skapa IT relaterade fördelar från… något händer… När det kommer till risker så finns det mycket att göra även på informationsarenan.

Det gäller att veta vilka applikationer och processer man skall investera i för att nå de långsiktiga visionerna. Jag tror inte det är en bra strategi att tänka för brett och säga att allt är viktigt, då man då förlorar sitt fokus på det som faktiskt är av högsta prioritet. Vill man öka insikten i den egna organisationens it-flora så kan man söka IT-strategiskt rådgivning. Lämpligtvis från seriösa leverantörer som förstår samtid och verksamhetsbehov i relations till IT-behovet. Genom en kartläggning av existerande IT-stöd och samrådande dialog med verksamheten så kan en IT-rådgivning ändra riktning helt, det är inte helt ovanligt att man blir hemmablind.

Att tänka på IT från ett strategiskt verksamhetsperspektiv är nyckeln till framgång på informationsarenan. Inget kommer skapas automagiskt varken strategisk-it eller kunskapshantering utan det måste styras och aktivt drivas från toppen av organisationen och med fokus på rätt områden och av rätt anledning.


Det pratas en hel del om vikten av en aktiv systemförvaltning och det forskas en hel del kring just detta i Sverige idag. Det verkar dock som det är stora skillnader på hur man internationellt ser på system- och applikationsförvaltning gentemot de populära svenska modellerna som t. ex. pm3 (www.pm3.se).

Den stora internationella draken inom systemförvaltning heter ITIL (www.itil-officialsite.com) och är ett ramverk som har många godbitar, men har sitt ursprung av mer tekniska och infrastrukturrelaterade tankegångar. Bara att försöka översätta ordet systemförvaltning till engelska är ju svårt, ord som System/Application Management, Software Maintainance, och IT Governance känns inte som det matchar det svenska ordet vidare bra. De moderna förvaltningsmodeller som vi ser i Sverige idag är mer samspelade med verksamheten och är mer i linje med de agila tankegångarna från systemutvecklingsprojekt.

Systemförvaltning utgör runt 80 procent av den totala kostnaden över en applikationslivscykel.

 

applikationslivscykel

Jag har försökt visualisera detta genom att måla upp en Applikationslivscykel ovan med de tre vanliga huvudkomponenterna Ledning, Systemutveckling, Systemförvaltning baserat på ALM (Application Lifecycle Management).

Enligt Pareto principen (80-20 regeln) så skapar ju 20 procent av orsakerna 80 procent av verkan, vilket även verkar stämma in på applikationslivscykler. Svensk forskning visar att genom att ha en bra ordning på systemförvaltningen så kan man få 20-40 procent högre avkastning på investeringen, vilket är riktigt tunga argument att lyfta fram, inte minst mot systemutvecklingsprojekten så det produceras förvaltningsbara resultat.

Den kanske mest kritiska fasen i hela livscykeln är när det utvecklade resultatet skall omvandlas till nytta för verksamheten. Jag kallar detta område för överlämningsarenan på skissen ovan. Det är här som projektledaren byter namn till förvaltningsledare och systemutveckling går över till systemförvaltning. Även det idag så populär uttrycket DevOps har sin kärna i dessa trakter, när utveckling (Development) möter förvaltning och drift (Operations), sammanfogas till ett ord DevOps. Vissa organisationer inser att det minst kostsamma sättet att lösa en bugg är att låta den som skapade den även lösa den, så man låter utvecklare få följa med en bra bit in i förvaltning. Det är heller inte helt ovanligt att man driver nya uppdrag i förvaltningen, en så kallad aktiv förvaltning som även har budget för vidareutveckling för att möta framtiden på ett bra sätt.

Kunskapsöverföring över hela livscykeln är en springande punkt för mig, att säkerställa att transaktionstiden blir så kort som möjligt för utveckling, förvaltning och användare i form av konsumtion av dokumentation och insikt på bästa sätt över hela livscykeln. Det finns mycket att läsa från universitet runt om i landet och många forum och dialoger kring aktiv systemförvaltning. Jag tycker de svenska forskningen kring systemförvaltning är en förebild som andra mer internationella modeller borde kunna lära sig mycket från.


Dokumentation är något som vi utvecklare ofta ser som något negativt och inte sällan prioriterar ner till att icke göra listan. I vattenfall liknande projekt så lägger man ofta dokumentationen sist och dokumenterar vanligen endast den färdiga produkten. Resan dit finns då inte med i någon dokumentation och varför man kom fram till lösningar försvinner då i tomma intet.  För mig som värderar spårbarhet och erfarenhetsåtervinning så känns det som man går miste om väldigt mycket om man inte kontinuerligt dokumenterar på ett sätt som växer med lösningen.

Organisationer med hög personalrotation skulle tjäna mycket på att utvärdera metoder för kunskapshantering och kanske tillsätta roller för att administrera och styra processerna för att säkerställa att kunskapen blir till visdom och inte bara blir data som ligger. Intellektuellt kapital kan bli till strukturkapital som går att omsätta till direkt nytta, men det krävs en del omställningar och processarbete vilket kanske prioriteras bort till förmån för något mer greppbart. Kunskapshantering händer inte av sig själv och om det inte finns processer som hanterar dessa flöden i organisationen så kanske man går miste om värdefull insikt och förbättringspotential.

För många år sedan arbetade jag som MIS (Management Information Systems) utvecklare att jobbade med att skapa olika rapporter och beslutsunderlag. Uppdraget var då att omvandla data till ett format som beslutsfattare kunde värdera och använda som underlag i beslutsprocessen. Mina rapporter var endast skapade från data och den långa vägen för att omvandla data till underlag var till stor del manuell och krävde en hel del från organisationen. Dessa manuella processer gick inte att skynda på och krävde specifika personers input. En mer mogen process skulle förfina och förbättra genom att hela tiden söka bättringar i varje led och sträva efter att ta bort alla onödiga moment. För att fatta rätt och bra beslut så tycker jag även att man skall försöka hämta input från så många personer som möjlig som har något att tillföra. Den kollektiva erfarenheten brukar alltid vara bättre än den enskilda individens.

Att en organisation satsar stort på CRM system är idag självklart, men hur är det med att lägga samma kraft och energi på att förstå hur man gör saker och varför man fattar vissa beslut och hur kunskap söks och tillförs till organisationen är inte lika moget.  Det finns idag många bra verktyg för att hantera kunskap och erfarenhetsåtervinning genom att alla kan samarbeta kring information och kompetens blir mer tillgängligt, kontinuerligt växande, demokratiskt värderad information kan erhållas utan att det tar mer tid i anspråk, man kan arbeta smartare inte nödvändigtvis mer och få många positiva synergier bara genom att våga lita på sina anställdas kompetens.


Det Agila manifestet förespråkar ”Working software over comprehensive documentation” och de flesta Agila metoder indikerar att man skall fokusera på fungerande funktioner högre än dokumentationen. Att man bara skall skapa precis så mycket som man behöver tycker jag kan vara missvisande. Det finns vissa fall då Agila utövare inte fokuserar alls på dokumentation och detta kan resultera i att resultatet inte blir kvalitativt och svårt att förvalta över tid.

Enligt min mening så borde man tänka mer Agilt kring dokumentation och även tänka varje segment av dokumentation som en potentiell byggsten i en större kontext så man kan återanvända enskilda fragment av dokumentation i olika sammanhang och med olika ingångar.

När man skriver sin kod så borde man även skriva förklaringar som går att återanvända även dessa från olika ställen, detta kan göras i Visual Studio med hjälp av XML kommentarer genom verktyg som GhostDoc för att stubba ut och delvis automatisera denna process. Dessa kommentarer kan sedan användas i andra delar av koden när man kallar på den i form av tooltips och man kan även exportera den och skapa automatiserad systemdokumentation som hjälper till att synliggöra och förklara hur koden och tester är uppbyggt.

Genom att använda en fullfjädrad Wiki för sin dokumentation så kan man även bygga dokumentation från alla delar av projektet och från olika vinklar där alla som bidrar fyller på med små byggstenar som är ämnade för återanvändning. Detta skiljer sig rejält från den traditionella formen av dokumentation där man ofta fyller i en förformaterad mall i exempelvis Microsoft Word och det blir mer av ett race för att fylla i innehåll runt ett skelett som tyvärr inte är så enkelt att återanvända och svårt att ens söka reda på.

En viktig faktor att tänka på att sökbarheten i dokumentationen, det måste gå att hitta rätt och ju snabbare man kan hitta ju mindre meningslöst letande blir det. Om man har dokumentation på flera ställen så kan man tjäna mycket på att bygga upp sökindex som söker på alla ställen och fronta detta med ett sökfönster. Genom att bygga upp dokumentation med logiska namnrymder (namespace) så borde man kunna söka i delar av dokumentationen och få upp endast relevant information.

Lägger man samman dessa två former av dokumentations rutiner tillsammans med en Team Foundation Server (TFS) som alla deltagare samarbetar kring så kan man få till ett stort dokumentationsvärde tillsammans med kommunikationskraften från TFS. Detta erbjuder en åtråvärd transparens kring hela livscykeln med många Agila fördelar. Genom att ha minimalt med ”waste”, långsiktighet och modultänk i dokumentationen så minimerar man tiden för nya projektmedlemmar att komma in i projektet och dokumenten blir en naturlig del av utvecklingsarbetet.

Att ha för lite dokumentation kan vara väldigt kostsamt då det tar längre tid för nya att sätta sig in och riskerna med att det intellektuella kapitalet sitter inne i huvet på deltagarna och finns då inte tillgängligt om personer inte är på plats. Dessa mjuka argument är svåra att räkna på men om man tänker hela applikationers livscykler så blir det viktiga faktorer att vikta in för att få rätt kvalitet på det man eftersträvar.

Det svåra i kråksången är ju att få till rutiner och systemstöd som underlättar insamling och transparens kring meta informationen i utvecklingsarbetet. Microsoft är den ledande leverantören på ALM lösningar men samtidigt den ledande leverantören av det traditionella dokumentations plattform i form Office (Word, Excel, Powerpoint). En tankegång kring detta är ju om Microsoft krigar på två fronter. Nya element i Office som OneNote och Storyboarding i PowerPoint indikerar ju att Microsoft försöker integrera Office med vinkling åt det Agila tänket. Samtidigt som den gamla skolan lever kvar parallellt i Office så kanske det blir någon form av identitetskris kring användandet av Office för dokumentationsarbete. Ser man till helheten i Microsoft lösningar med SharePoint, Team Foundation, Visual Studio och Office så har man en riktigt solid plattform för att leverera just Agilt värde. Arvet kring traditionell dokumentens metodiker i dessa verktyg kan dock visa sig vara hinder för att övertyga på värdet att använda just dessa verktyg.


Vad är då ALM (Application Lifecycle Management) och varför är det värt att titta närmare på det? Om man tar några minuter och surfar runt på nätet för att få en bild på vad ALM är för något så hittar man många olika definitioner av vad det är och hur det bör implementeras och det är inte så konstigt då det rör sig om hela applikationer livslängd. Väl genomfört så erbjuder ALM en kontinuerlig affärsnytta genom kontrollerad investering i mjukvaror med en avvägd balans mellan kvalitet och tid.

För några månader sedan köpte jag en bok på Internet kring ALM som egentligen inte är en egenskriven bok utan en samling wikipedia artiklar som är lite omarbetade (Application Lifecycle Management – Activities, Methodologies, Disciplines, Tools, Benefits, ALM Tools and Products, ISBN: 9781742446646). Tar man en titt i innehållsförteckningen i denna bok så inser man hur mycket som faktiskt ingår i ALM tänket, i stora drag så kan man säga att ALM är allt som har att göra med applikationer i hela dess livslängd. Det går att jämföras med PLM (Product Lifecycle Management) som beskrivs som en filosofi för hur man hanterar en produkt och information om produkten under produktens hela livscykel och har funnits med länge i affärsutvecklingssammanhang.

En av fördelarna med ALM är att team samarbetar bättre vilket leder till snabbare och bättre leveranser, förbättrad kvalitet, smidigare informationsflöden.

Att bygga mjukvaruapplikationer är ett hantverk och det krävs många olika kunskaper för att leverera de krav och förväntningar som marknaden förväntar sig idag. Ofta så har man flera personer med olika expertområden och olika team för olika faser för att se till att arbete kan fortgå enligt de planerade aktivisterna och stegen man tar. Det kan röra sig om kravställning, arkitektur, konstruktion, design, test, debugging, distribution eller ren programmering.

När man planerar hur man skall bygga applikationer så brukar man prata metodiker och det är ofta någon form av projektmetodik såsom Vattenfall, RAD, Scrum, RUP, TDD m.fl. En metodik brukar definiera hur teamen leds och varierar mycket även om det står samma namn på etiketten.

Utöver roller och metodiker så tittar även ALM på vilka supporterade discipliner som behövs för att få maximal nytta av applikationer och det röra sig ofta om konfiguration, dokumentation, kvalitetssäkring, användbarhet, förvaltning och projektledning.

För att fullborda ALM matrisen så behöver man se över vilka verktyg som alla roller, metodiker och discipliner behöver för att fungera bra tillsammans och det kan en lång rad olika verktyg såsom kompilatorer, utvecklingsmiljöer, grafiska verktyg, moduleringsverktyg, källkodshantering, bygghantering, releasehantering m.fl. Men det finns även färdiga produkter som t.ex. Microsoft Team Foundation Server som har många av dessa element redo att börja användas direkt i egen regi eller på kran via molnet. Genom att centralt samla data så kan flera team och individer kontinuerligt samarbeta med samma ”arbetspaket” och information lagras genom hela livslängden och alla faser som applikationen går igenom vilket ger en mer komplett och sanningsenligt bild och det blir lättare att faciliteter processer och flöden i olika stadier.

Man kan sammanställa detta och säga att ALM är helt enkelt är konsten att optimera applikationsutveckling i alla dess stadier och få alla element att samspela genom att optimera aktiviteter, metodiker, roller och verktyg så att relationer mellan system, processer och människor kontinuerligt förbättras. En väl fungerande ALM implementation kan jämföras med en bra fungerande motor där man kan öka hastigheten och få nytta snabbare genom att se till att alla element fungerar bra i sig och i relation med helheten samt med transparent spårbarhet genom hela livscykeln.


När man leder och ansvarar för systemutvecklingsprojekt så är det viktigt att förstå vilken kvalitet som efterfrågas för att kunna facilitera därefter, det är därför viktigt för projektledare att förstå olika aspekter av kvalitet och att kvalitet betyder olika saker baserat på vem man frågar i projektet.

Jag har ibland hört sponsorer använder orden ”good enough” i kvalitetskontext vilket jag har svårt att relatera till då min utgångspunkt är att alla i projektet gör det bästa man kan för att leverera så hög kvalitet man kan. Genom att utvärdera kvalitet så utvärderar man värde, högre kvalitet är samma sak som högre värde. Direktivet man hör är ju således att man skall leverera tillräckligt högt värde genom att levererar tillräckligt bra kvalitet, frågan blir istället till vem skall man leverera värde till?

Funktionell kvalitet är den vanligaste mätningen av kvalitet och syftar till specifika krav man har på en mjukvara som ofta finns listade i user stories och i form av en backlog. Genom att skapa en applikation som har få buggar och levererar enligt specifikation så uppnår man hög funktionell kvalitet. Eftersom det är förhållandevis enkelt att testa och utvärdera denna form av kvalitet så blir det oftast här man fokuserar när man värderar kvalitet.

Strukturell kvalitet är en form av kvalitet som utvecklingsgruppen värderar högt och ofta ser som ett stort värde. Genom att ha en bra struktur i koden och följer ”best practices” så kan man återanvända och undvika att gå in i samma problemgränd som andra professionella utvecklare av erfarenhet rekommenderar att man inte repeterar samma mönster. Kvalitet i struktur är svårt att utvärdera och har ofta en väldigt komplex struktur i sig och kräver stor insikt för att värdera vilket kan leda till att detta felaktigt förbises som en kvalitet som inte ger värde.

Process kvaliteten är hela kvaliteten kring utvecklingscykeln och hur bra man mötet budget och leveranstider.  Genom att optimera denna kvalitet så ökar kvaliteten implicit även på andra kvaliteter.

Det går inte att säga vilken form av kvalitet som är viktigast. Det är människor i team som utvecklar mjukvaror och individer ser på kvalitet från olika aspekter. Min aspekt är att människor är det viktigaste och för att uppnå maximal kvalitet så görs det genom människor som samarbetar och inte genom funktioner, strukturer eller processer.