Systemutveckling innebär flera saker. Vanligtvis tar man emot en beställning på ett datorsystem, skriver en strukturerad kravspecifikation på systemet, genomför systemering av det, programmerar, testar och driftsätter det. Arbetet sker traditionellt enligt olika metodiker, var och en med sina för- och nackdelar.
Systemutveckling med Vattenfallsmodellen
Vattenfallsmodellen går ut på att man bygger ett datorsystem i strikta steg som
vart och ett avslutas innan man påbörjar nästa. Typiska steg är att man börjar med kravinsamling och kravspecifikation och när dessa är på plats följer implementering av kraven, dvs programmeringen. När allt är färdigprogrammerat genomgår programmet grundliga tester för att därefter paketeras och driftsättas. Denna process liknar man ofta vid en serie av vattenfall. När man tagit sig genom ett fall (ett steg) är det väldigt svårt att gå tillbaka och göra om. Om man hittar brister i kraven under testerna krävs det stora resurser att rätta till filen. Det finns risk för att stora delar av systemet måste skrivas om för att komma tillrätta med feltänket. Dessutom är vattenfallsmodellen okänslig mot förändringar i omvärlden som oundvikligen sker under projektets gång.
Agil systemutveckling
Agil systemutveckling innebär att man under intensiv kunddialog och inkrementell programutveckling parallellt och i dialog med kunden bedriver systemutveckling. Den ses ofta som en vidareutveckling av Vattenfallsmetoden.
Agil systemutveckling är ett samlingsnamn för ett antal systemutvecklingsmetoder som kan användas vid mjukvaruutveckling, även kallade lättrörliga metoder. Metoderna följer i stort sett samma värderingar, principer och synsätt. Jämfört med tidigare vattenfallsmodeller representerar de
mer flexibla sätt att arbeta. Agile är engelska och betyder smidig, vig, lättrörlig.
Grundtankarna bakom agile bygger på att göra kunden/användaren nöjd med det som utvecklas genom ett mycket nära samarbete under hela utvecklingstiden med täta och regelbundna möten mellan utvecklare och beställare/mottagare. Arbetet bedrivs inkrementellt och iterativt vilket innebär att regelbundna mindre leveranser sker och att saker löpande utvärderas och kan ändras för att möta nya krav och önskemål. Det agila synsättet anser att det oftare är människor och kommunikation än verktyg och formella dokument som löser problem under utvecklingsarbetet.
En annan central grundtanke är att minimera risken för att en stor del av ett system befinner sig i ett halvfärdigt läge och inte kan leverera nytta. Detta gör det möjligt för beslutsfattare att få ett bättre underlag inför beslut om att tillföra ytterligare resurser till ett projekt. Inom agil systemutveckling finns flera metoder och tekniker, till exempel RUP (Rational Unified Process).
Exempel på ett antal "lättrörliga metoder":
- Feature Driven Development (FDD)
- Adaptive Software Development
- Dynamic Systems Development Method (DSDM)
- Scrum
- Extrem programmering (XP)
- Lean Software Development
- Crystal
- Nightly build
Systemutveckling med Scrum
Scrum är en metodik för systemutveckling skapad av Jeff Sutherland och Ken 
Schwaber. Ordet "scrum" kommer från rugbyn och är där ett moment när bollen sätts i spel. Rugby användes som en liknelse av de japanska managementforskarna Hirotaka Takeuchi och Ikujiro Nonaka för att beskriva en speciell stil av utveckling. I rugbyliknande utveckling samarbetar ett tvärfunktionellt team för att göra klart produkten på samma sätt som ett rugbylag spelar tillsammans för att föra bollen uppför planen. Denna typ av arbetsform kontrasterade Nonaka och Takeuchi med mer stafettliknande processer. I dessa färdigställs arbetet i funktionella faser med tydliga överlämningar mellan grupper när arbetet går från en fas till en annan.
Scrum har tillämpats sedan tidigt 1990-tal och formaliserades 1995. Scrum är
ett sätt att fördela arbetsuppgifter i tiden med bibehållet fokus på levererad affärsnytta.
Roller i Scrum
- Product owner (produktägare)
Tar emot, hanterar och prioriterar önskemål om tillägg och ändringar för en produkt. Produktägaren måste vara en fysisk person.
Fungerar som coach för teamet. Säkerställer efterlevnad av processen, synkroniserar mellan aktörer samt avlägsnar hinder för utvecklargruppen.
Utvecklargruppen är självorganiserande. Det är bra om den täcker så mycket som möjligt av kompetensbehovet. Gruppen bör bestå av 5-9 personer.
Beståndsdelar 
En samlingsplats för alla önskemål om förändringar av produkten. Ägs och hanteras av produktägaren. Det finns ingen begränsning på antal önskemål. I stället används prioritering. Ju högre prioriterad, desto bättre specificerad ska ändringsönskemålet vara.
Den delen av en product backlog som scrum-gruppen åtar sig att implementera under den kommande sprinten.
Arbetet delas in i sprintar. Varje sprint, som är mellan 3 till 30 dagar lång, inleds med en planeringssession (Sprint planning) och avslutas med en granskning av de utlovade ändringarna (Sprint review). Under sprinten sker dagligen Daily scrums. Som sista punkt i en sprint äger en förbättringsaktivitet rum (Sprint retrospective).
Ett kort statusmöte där endast scrum-gruppens deltagare får prata.
Scrum master går igenom alla personer i gruppen, som i tur och ordning
besvarar tre frågor:
Vad har jag gjort sedan igår?
Vad ska jag åstadkomma tills i morgon?
Vad hindrar mig?
Sprint review
På svenska: sprintgranskning. En från dag ett inplanerad granskning av det arbete som genomförts i sprinten. Under granskningen redovisas först status för de i sprinten inplanerade sakerna, därefter demonstreras klar funktionalitet för produktägare, kunder och andra inbjudna intressenter. Syftet med granskningen är att alla inblandade ska få bästa möjliga förståelse för dagsläget. Fokus är på att visa upp ny och ändrad funktionalitet genom att faktiskt köra produkten.
På svenska: återblick. Alla gruppmedlemmar samt scrum master och produktägare arbetar tillsammans för att lära sig från sprinten som gått. Förbättringar i arbetssättet identifieras, och ett antal saker väljs ut och åtgärdas i kommande sprint.
En heldag under vilken alla ändringsönskemål gås igenom av produktägaren för hela scrum-gruppen. Gruppen bryter ned kraven och estimerar sedan alla aktiviterna. Slutligen vägs tidsestimaten mot tillgänglig tid och de ändringsönskemål, prioriterade av produktägaren, som gruppen åtar sig att införa under sprinten fastställs och benämns sprint backlog.
>>Här hittar du utbildningar i systemutveckling
