CREATING VALUE BY SHARING KNOWLEDGE

Relevanta dokument
Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg

SCRUM och mycket mer

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

Vad är agilt? Agile Islands Andreas Björk

Agil Projektledning. En introduktion

Att arbeta agilt. En arbetsgång

Agil Projektledning. En introduktion

SCRUM. Marcus Bendtsen Institutionen för datavetenskap

BESKRIVNING AV PROCESSMETODEN SCRUM

Projektledning Introduktion. Version Juha Söderqvist

Chaos om datorprojekt..

Agila Metoder. Nils Ehrenberg

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech

Linköpings universitet 1

Så här gör du. om du vill genomföra en framgångsrik innovationstävling

SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell.

SCRUM på Riksarkivet. Magnus Welander /

Användarcentrerad Systemutveckling

Linköpings universitet 1 TDP029. Systemutveckling. Systemutveckling. Vanliga faser. Fler faser. Systemutvecklingsmetod

Chaos om IT-projekt..

Föreläsning 4: Designprocessen

Skrivtolkad version av telefonintervju med Daniel Antonsson, avdelningschef, Myndigheten för digital förvaltning

Agila metoder. Idag skall vi vända på steken... Agil Ledning av IT-projekt

Introduktion - Metodik i Produktutveckling

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

12 principer of agile practice (rörlig)

Fungerar Agila principer i alla typer av projekt?

Deluppgift 2 Kravhantering a) (2p) När man diskuterar krav brukar man ange två olika typer av krav. Beskriv dessa och ge exempel.

Processbeskrivning Systemutveckling

ALM Live: Scrum + VSTS

Presentation. Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban

Agila Organisationer

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete

Utveckling för dig som är handledare.

Inspel till dagens diskussioner

Agil testning i SCRUM

Agil Projektledning. En introduktion

FEMSTEGSMODELLEN: ÖVNING & CHECKLISTA FÖR UTBILDNING OCH ARRANGEMANG

Processbeskrivning Systemutveckling

Vårt nya sätt att möta kunden

Ramverk för projekt och uppdrag

Agil mjukvaruutveckling. 1DV404, Jesper Andersson

Samarbetsstrukturer för att självorganisera inom givna ramar.

Expertgruppen för digitala investeringar. Framgångsfaktorer för ett agilt arbetssätt

Martin Völcker, SLL & Suit

SCRUM. på fem minuter

Arbeta med resultatet Steg 3: Åtgärder. En guide om hur du går vidare från insikt till handling

Projektbeskrivning: Ny hemsida

Agila arbetsformer. Gemensamma värderingar

FEMSTEGSMODELLEN: ÖVNING & CHECKLISTA FÖR EN ÖPPEN OCH TILLGÄNGLIG VERKSAMHET

Agila metoder och motivation

Metoder för Interaktionsdesign

Hur kan man uppnå tillståndet där Lean/Verksamhetsutveckling är en naturlig del av tillvaron?

Agil utveckling ställer nya krav på upphandling. Roland Bäcklin, Jaybis Konsult AB

Intervjuguide - förberedelser

De Mjuka Faktorerna Bakom Kontinuerlig Integration. SAST Q Alexander Tarnowski

ALM Live. April 2008 Effektivare projektarbete med Visual Studio 2008

Rapport för Andrew Jones


Produktägarens roll i Scrumprojekt

Smakprov ur 4 råd, utgiven på Fantasi & Fakta, fantasifakta.se

Möte med kommunen. att tänka på före, under och efter besöket

Engagerade medarbetare skapar resultat!

Ansvarsområden och utmaningar för produktägare och Scrum-mästare En fallstudie på ett svenskt IT-företag

SCRUM. på fem minuter

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

Participatory Design III

Projektprocessen. Projektprocess

- Det effekthöjande ledarskapet -

Agilt arbetssätt i komplexa organisationer. Välkomna! Anna Picetti, IT-HUSET

KAM Processen. Henrik Mannerstråle

Slutrapport. Innovativt utbildnings- och forskningsmaterial användning av 3D visualisering och animering för att bemöta pedagogiska utmaningar

PLANERING AV PROJEKTET

Resultat, avslut och uppföljning

XLPM 2.5 UPPDATERINGAR RELEASE: BESKRIVNING AV VAD SOM ÄR NYTT OCH ÄNDRAT

FEMSTEGSMODELLEN: ÖVNING & CHECKLISTA FÖR EN ÖPPEN OCH TILLGÄNGLIG VERKSAMHET

Tema: Underhållning Teknikspanarna

TRE STEG TILL ETT LYCKAT HÅLLBARHETSARBETE

SUNETs Projektmodell. Syfte. Processer. Version:

AGILA METODER. (för oss som inte kodar) Nina Berlin

Filhanterare med AngularJS

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions

Affärsplan. Produkten. Affärsidén. Marknaden. Kunder. Konkurrenter

LATHUND FÖR FRAMGANGSRIKT PAVERKANSARBETE. 2. Möte med. att tänka på före, under och efter besöket

Översikt. Fö: Projekt: Interaktivt system. Projekt. Mål. Coachning. Praktiker att använda

EN GUIDE AV. Så matchar du kandidat med företagskultur!

Förslag på intervjufrågor:

Business Model Canvas

LUNDS UNIVERSITET. Projektledning

INTERAKTIVA WORKSHOPÖVNINGAR

Så säkerställer du affärsnyttan för dina produkter

Rapport. Utökad projektmodell. Företaget AB. Skriven av: Jens Ahlgren-Norin Thomas Nilsson. Datum:

Slutrapport YUNSIT.se Portfolio/blogg

FEMSTEGSMODELLEN: ÖVNING & CHECKLISTA FÖR EN ÖPPEN OCH TILLGÄNGLIG SCOUTKÅR

Astrakan Strategisk Utbildning AB

Etablering av Lean inom logistik / distribution

Öka effekten av DR med QR! Sju inspirerande exempel på hur du kan använda QR-koder i dina DR-kampanjer

Beställarorganisation och e-tjänster

Tips och råd för uthållig och lönsam tillväxt

Transkript:

CREATING VALUE BY SHARING KNOWLEDGE

PROJEKTLEDNING 101 Nidzara Dellien, Lund September 2017

PROJEKT En formell definition på projekt är följande (enligt Wikipedia): En temporär satsning för att framställa en unik vara eller tjänst. Temporär avser att projektet har en viss varaktighet med en start och ett slut. Satsning innebär att någon tilldelar projektet resurser av något slag. Unik är att projektet avser att ta fram någonting som inte gjorts tidigare. Vara eller tjänst innebär att projektet syftar till att ta fram någonting, att det ska producera ett slutresultat.

PROJEKT INTE PROJEKT Utveckla en ny mobiltelefon Fixa buggar på mobiltelefons mjukvaran Införa ett nytt verktyg (tex Visma) på en arbetsplats Dra ut data från Visma för att betala ut löner till anställda Omorganisera ett företag för att det ska passa bättre med företagets verksamhet Vara chef på en av avdelningar på företaget Laga mat till familjen varje kväll Renovera kök Utveckla och rulla ut en mobil app tex Swish Kundsupport for Swish Öppna en ny HM butik Sälja kläder på HM

PROJEKTFASER Tips: Atlassian.com har en väldigt bra introduktion till projekt och projektledning. Använd den gärna för referens längre fram, när ni kör egna projekt.

Initiera Input: En idé En vision Ett problem

Vad ska vi bygga? Detta kan kännas som den viktigaste frågan när man ska starta ett projekt. Men det är det inte. Det viktigaste frågan är varför vi ska bygga det! Vilken problem försöker vi lösa och vad är värdet av att lösa det? Innan man hoppar in i problemlösnings mode, det är viktigt att förstå problemet vi försöker lösa, så att vi är överens att vi löser rätt problem. Vem löser vi det för? Behöver de det? Vad kommer de kunna göra efter vi är klara, som de inte kan göra idag? Kommer de vilja betala för det?

Vem behöver vi? Har vi en tydlig beställare för vår projekt? Har vi en projektledare? Vilka olika kompetenser behöver vi för att kunna planera och genomföra projektet? Vilka personer känner vi som besitter dessa? Är de tillgängliga att arbeta i vårt projekt? Tips: Har man möjlighet, så ska man välja ett team som består av personer som kommer från olika bakgrund och som har olika problemlösnings strategier. Team med hög diversitet tenderar att vara mer innovativa och produktiva än homogena team.

När har vi lyckats? Definiera (mätbara) mål som ska nås för att projektet ska ha lyckats Definiera mätningar som kan användas för att följa upp om projektet är på rätt väg (detta kan ibland vara svårt) Ett företag har ofta en större målsättning och vision, och meningen är att projekt som bedrivs inom företaget ska hjälpa företaget att komma närmre de målen. Dubbelkolla att målet med projektet ligger i linje med företagets övergripande mål.

Klara, färdiga hitta lösningar! Nu har vi bra förståelse av problemet vi försöker lösa och vi förstår personer som ska använda projektets resultat. Vi har också ett team som har kompetenser som behövs för att lösa uppgiften. Det är dags (ÄNTLIGEN!) att börja med att ta fram lösningar. Ta fram (om möjligt) flera olika lösningsförslag och jämför de mot varandra. Vi håller oss fortfarande till idéer, ritningar och beskrivningar. Vi har inte börjat bygga än. Fundera på hur de ska implementeras i verkligheten. Finns det teknologi för det eller beror vår lösning på att det finns fungerande ljushastighetsdrift? Kommer det att vara för dyrt, kommer det att ta orimligt lång tid, etc Hur kommer användarna att interagera med slutprodukten? Hur passar den i deras arbetsflöde?

Gör en prototyp och testa! Om det är möjligt, borde man nu göra en prototyp av det som projektet ska ta fram, och testa prototypen med de personerna som är tänkta att använda den sen. Genom att göra detta så får man tidig feedback om projektets resultat: Löser rätt problem Hur lätt/svårt är det att använda den Nu är det perfekt läge att upptäcka om man har tänkt fel, innan en massa tid, pengar och engagemang har investerats i projektet. Kommer man fram till att det inte funkar som det ska, får man gå tillbaka till ritbordet.

Planera Input: Problemdefinition Kriterier för att projektet bedöms som lyckat Ett lösningsförslag Ett embryo till projektteam med rätt kompetenser

Bestäm scope (omfattning)! Fram till nu har vi jobbat med att förstå vad det är vi ska bygga. Den enda begränsning vi har tagit hänsyn till är om det är praktiskt möjligt att bygga det som vi försöker bygga. Nu är det dags att ta hänsyn till de begränsningar projektet har: Funktionalitet som absolut måste finnas med (MVP) Tid (när måste det vara klart) Budget (hur mycket det får kosta) Kvalitet (tex: produkten måste följa någon statlig föreskrift)

Projekttriangeln Kvalitet av projektets resultat är begränsad av projektet budget, tid och scope Projektledaren behöver ofta kohandla mellan de olika begränsningar. Om en av begränsningar förändras, tex tiden blir kortare, så får man antigen minska innehållet eller lägga till mer folk till projektet (budgeten ökar). Annars kan kvalitet på slutprodukten komma att äventyras

Planera Så, nu vet vi vilken funktionalitet som önskas, vi vet vad den önskade slutdatumet är och vad budgeten är. Nu är det dags att planera: Hur bryter vi uppgiften till logiska delar? Vad ska vi börja med och vad kommer sen? Vilka beroende finns mellan delarna? Hur lång tid tar det att göra de olika delarna (grov uppskattning)? Hur långt tid gör det för oss att göra hela jobbet om vi har obegränsat med folk? Givet budgeten (dvs antal personer vi har att tillgå), hur lång tid tar det då? Fråga beställaren vad som är viktigast för hen? Tid, pengar eller innehåll. Oftast är det någon av första två. Utifrån svaret, anpassa planen. Detta görs bäst med en teknik som heter Work Breakdown Structure Skapa en backlog och en release plan

Kommunikation Kommunikation, eller brist på det, är en av de största anledningar för projekt att bli sena eller misslyckas Tänk igenom vem kommer behöva vilken information, och hur ska de få det (mail, möte, annat) och hur ofta Ju fler stående möte man har desto mindre tid har man för att jobba. Att ha en bra mötesplan är guld värt

Exekvera Input: Backlog och grov release plan Ett komplett projektteam En riskmatris Ett kommunikationsplan

Vattenfall vs. Agile Vattenfallsmodellen är en sekventiell systemutvecklingsprocess där man ser framstegen som ett flöde nedåt genom olika faser: förberedelse, etablering, analys, design, konstruktion, test, produktionssättning och underhåll. Agile systemutveckling är ett samlingsnamn för ett antal utvecklings metoder som oftast användas vid utveckling av mjukvaran. Grundtanken är att arbetet bedrivs inkrementellt och iterativt.

Iterativ modell När man har kommit så långt att man ska börja sprinta, så bestämmer man vilken längd på iterationen (2-4 veckor) man vill börja med. Kommer man fram till att just den längden inte är optimal, så ändrar man det under projektets gång. Ta de högst prioriterade arbetet från backloggen och gör en sprint plan Utveckla och testa. Kolla om man går framåt enligt plan (burndown chart, gant chart) I slutet av iterationen, visa ett demo av det som har blivit gjort och samla feedback Reflektera över hur det har gått. Vad var bra, och vad kan vi göra bättre? Uppdatera releaseplanen om nödvändigt Gå tillbaka till steg 1. Det som är väldigt viktigt här är att man hela tiden aktivt jobbar med att prioritera backlogen, så att vi hela tiden jobbar med det viktigaste funktionalitet som är kvar. Så när vi kommer till slutet av projektet, så kommer de viktigaste delarna att ha kommit med.

Leverera Input: Minimum Viable Product

Överlämnande Vid detta laget, så har vi byggt en MVP (Minimum Viable Product) och det är dags att lämna resultatet över till kunden/beställaren. Om vi har kommunicerat bra under tiden projektet pågick, så bör det inte komma några överraskningar nu. Träffa beställaren och gå igenom vad som har blivit gjort, och det som inte kom med (beroende på projekt så är detta mer eller mindre formel steg) Stäng budgeten Gör retrospektiv som täcker hela projektet Fira att jobbet har blivit gjort!

Förbättra Input: Minimum viable product Backlog av saker som ska förbättras

Ny release Efter att produkten/tjänsten har används ett tag, så brukar man komma på några saker som man kan lösa på ett bättre sätt, saker som saknas, eller saker som inte funkar alls. Då bestämmer man sig ofta att släppa en ny, förbättrad version av produkten/tjänsten. Det är i regel ett nytt projekt, men ofta mindre än den ursprungliga.