Mjukvaruprocesser och Planering. 1DV404 HT14 Jesper Andersson



Relevanta dokument
Agil mjukvaruutveckling. 1DV404, Jesper Andersson

Mjukvaruprojekt Inception-fasen. 1DV404, HT14 Jesper Andersson Kap 5, 6, 7

Iterativ mjukvaruutveckling. 1DV404 HT14 Jesper Andersson

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

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget % misslyckades!

Roller i mjukvaruprojekt. Åke Liljenberg ake.liljenberg@volvo.com

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.

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

RUP - Rational Unified Process

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

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

Inspel till dagens diskussioner

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

CREATING VALUE BY SHARING KNOWLEDGE

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

Agil testning i SCRUM

Agil Projektledning. En introduktion

Agil programutveckling

Linköpings universitet 1

Agil Projektledning. En introduktion

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions

Arbeta i projekt. Anders Hessel ITP-projekt Uppsala Universitet

Symptom på problemen vid programvaruutveckling

ALM Live: Scrum + VSTS

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

Scrum Scrum. en beskrivning. a description. V Scrum Alliance,Inc 1

Agil Projektledning. En introduktion

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel

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

Informationssystem och databasteknik, 2I-1100

RUP Rational Unified Process. 17 november 2004

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

Kanban är inte din process. (låt mig berätta varför) #DevLin Mars 2012

QC i en organisation SAST

Projectbase en generell projektmodell

Roller i mjukvaruprojekt. Åke Liljenberg. Volvo Group, Corporate Process & IT ake.liljenberg@volvo.com

ALM Live. April 2008 Effektivare projektarbete med Visual Studio 2008

Att fatta rätt beslut vid komplexa tekniska upphandlingar

Användarcentrerad systemdesign

Användarcentrerad systemdesign

Kurser och seminarier från AddQ Consulting

AGIL KRAVHANTERING. Hitta behoven bakom kraven!! Thomas Nilsson! Agile Coach & Mentor! CTO, Responsive

Testbara krav. SAST Syd Ställ gärna frågor under presentationen eller efteråt Åhörarkopior distribueras efteråt

Agile-metoder, XP och ACSD

Configuration Management

CM FORUM. Introduktion till. Configuration Management (CM) / Konfigurationsledning. Tobias Ljungkvist

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

Scaled Agile Framework

ISO STATUS. Prof. dr Vidosav D. MAJSTOROVIĆ 1/14. Mašinski fakultet u Beogradu - PM. Tuesday, December 09,

12 principer of agile practice (rörlig)

Sara Skärhem Martin Jansson Dalarna Science Park

Kvalitetssäkra ditt projekt med kontinuerlig integration

Agila Metoder. Nils Ehrenberg

SCRUM och mycket mer

Projektarbete. Grunder

SCRUM. Marcus Bendtsen Institutionen för datavetenskap

Kurser och seminarier från AddQ Consulting

Platina och kvalité. Rasmus Staberg, Teknisk direktör,

Projektmetodik. Översikt. Lektion 1: Metodiker. Metodiker.

Filhanterare med AngularJS

Användbarhet i sitt sammanhang

Projekt? 1DV420 Nätverksprojekt Kalmar, Lars Karlsson +46(0)

Software Engineering. Agneta Nilsson, PhD MPA Software Engineering Master s Programme

Alla rättigheter till materialet reserverade Easec

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

Att arbeta agilt. En arbetsgång

Meter to cash - og prosess effektivitet med toveiskommunikasjon.

SCRUM. på fem minuter

Övning / handledning Användningsfall

Tillgång till alla globala delar i systemet styrs av denna profil, som i sin tur kopplas till respektive användare.

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

Kurser och seminarier från AddQ Consulting

Design för användbarhet

Hur lyckas med förändring?

BESKRIVNING AV PROCESSMETODEN SCRUM

App analytics TDP028

IT-projektledning - introduktion 725G62

Föreläsning 11, Planera utvärdering. Att planera utvärdering. Vetenskapliga experiment. Kapitel i kursboken

PROJEKTLEDNING. Vad är ett PROJEKT? Ett projekt:

LUNDS UNIVERSITET. Projektledning

En snabbare väg till framgång Ett agilt angreppssätt för BI Johan Petersson

Agenda. Plats och magkänsla. Presentation. - en pedagogisk fråga?

Datavetenskap. Beteendevetenskap MDI. Design

Hjälpmedel: Hjälpmedel som finns på plats: Valda artiklar del 1 och del 2 (gäller för del 2 av tentan) Inga övriga hjälpmedel

Vad är agilt? Agile Islands Andreas Björk

FMV användning av ISO/IEC för ledningssystem implementering. Harold Bud Lawson Styrelsemedlem och Consulting Partner

Faster time to action and more accurate pre-studies using Agile tooling

Viktigt! Glöm inte att skriva Tentamenskod eller namn på alla blad du lämnar in.

Swedbank CI Cross Functional Team

Implementationsstrategier för PLCS

Tentamen, delkurs Projektstyrning Webbutvecklare SU13, Malmö

KURSER OCH WORKSHOPS 2017

PRODUCT MANAGEMENT. Klicka här för att ändra format. Klicka här för att ändra format på underrubrik i bakgrunden

agil projektledning CE E86C7B9BE4BB2FD43E7A902 Agil Projektledning 1 / 6

Main headline. Affärsvärde till Perstorp AB Headline. mha appar SAPSA IMPULS

CHANGE WITH THE BRAIN IN MIND. Frukostseminarium 11 oktober 2018

Produktens väg från idé till grav

Lyckade projekt - finns det?

Transkript:

Mjukvaruprocesser och Planering 1DV404 HT14 Jesper Andersson

Mål Utvecklare Kostnad Vinst Maximera! WinWin! Träning Tid Tjänster Kvalitet Säljare Användare Köpare

Och vi behöver en process? ü För att I ett företag måste alla resurser arbeta mot samma mål. Arbetet måste vara möjligt att kontrollera. Arbetet måste kunna upprepas. Resultaten från olika projekt måste vara i nivå med varandra. Organisera arbetet

Mjukvaruprocesser är mallar för att skapa en ü vägbeskrivning för framgångsrika mjukvaruprojekt. ü Framgång kräver att vi besvarar följande frågor. Vad skall göras? När skall det utföras? Vem skall göra det? Hur skall det göras? (Varför ingår tom ibland!)

Hur organiserar vi arbetet? ü Roller Resurser Mantimmar ü Aktiviteter ü WorkProducts Artifakter ü Styrande faktorer Tid Resurser Beroenden ü è Processmodell

Processmodeller Många smaker Unified Process Kanban SCRUM normativ

Exempel Roller och några Artifakter i UP Role Name User Inter Soft Proj ware ect Dev Can didat Phy DesiRUP face Desi gn Deli elop GANStat e Objesical gn Wor Spe vera men NT us Issu Use Archct Data Guidker Test cific ble t CharRep e Risk GlosCas itect Mod Mod elinematrcas Test ation List Plan t ort Log List sary es ure el el s ix es Plan s Analyst Worker Set Business-Process Analyst Business Designer Business-Model Reviewer Requirements Reviewer C C C System Analyst C C C Use-Case Specifier R User-Interface Designer R Individual Name Developer Worker Set Architect C C C C R R C Architect Reviewer C C Capsule Designer Code Reviewer Database Designer C C R C Design Reviewer Designer C C C Implementer C C C C Integrator C C C Tester Worker Set Test Designer Tester C C C Manager Worker Set Change Control Manager Configuration Manager Deployment Manager Process Engineer Project Manager R R R R R C Project Reviewer C C C Additional Worker Set Any Worker Course Developer Graphic Artist Stakeholder System Administrator Technical Writer Tool Specialist

SCRUM Roller och Aktiviteter ü Roller Product Owner ägare av produktvisionen Scrum Master hjälper utvecklingsteamet att på bästa sätt använda SCRUM för att bygga produkten Development team bygger produkten ü Artifakter Product increment en färdigställd delmängd av en produkt. Product backlog en prioriterad idélista för ett projekt Sprint backlog en detaljerad plan för utvecklingen under nästa sprint.

Aktiviteter i mjukvaruutvecklingsprojekt ü Kravhantering ü Kravanalys ü Design ü Implementation ü Testning ü Integration ü Evolution

Iterationer & Inkrement ü Enklare att planera (!?) Mindre steg Kortare tid Enklare att verifiera och validera Snabbare återhämtning om vi gjort fel eller gått fel väg.

Iterativ vs. inkrementell ansats Tid Komplett Tid Komplett Källa: http://www.applitude.se/

Hur hanterar vi Iterationer och Inkrement Open UP Source: http://epf.eclipse.org/wikis/openup/

Riskhantering ü Proaktiva aktiviteter för att minimera osäkerheter och eventuell skada kopplat till ett utvecklingsprojekt. ü Beslut baserade på fakta och kunskap inte gissningslekar! ü Genomförs kontinuerligt under systemets livslängd! Från dag 1!! ü Risker orsakas ofta av osäkerheter! risk värde

Osäkerhet och osäkerhetstyper <Osäkerhet> orsakar <Risk> hanteras av <åtgärd> åstadkommer <Resultat> ü Komplexitet och Heterogenitet är primära faktorer för osäkerhet ü Osäkerhetstyper Brist på kunskap Fakta som inte är känd eller bara delvis känd och som måste finnas för att färdigställa produkten. Bristande definition Systemaspekter som inte specificerats eller beslutats. Statistiska variabler Oprecis kunskap, statistiskt säkerställd eller i alla fall avgränsad.. Known Unknowns Saker som vi vet att vi inte vet. Unknown Unknowns Oooups, saker vi inte vet. Source: Hastings and McManus, A Framework for Understanding Uncertainty and its Mitigation and Exploitation in Complex Systems. 2004, INCOSE

Osäkerhet: Risker/Möjligheter och Åtgärder ü Risker Fel Degradering. Förändringar på marknaden. Förändringar av behov. ü Åtgärder Marginaler Verifiering Generalisering Uppgraderingsbarhet

Risker and Risktyper ü ü ü ü ü ü Teknik Databasen som används kan inte behandla så många transaktioner per sekund som förväntat. Programvarukomponenter som ska återanvändas innehåller brister i funktionalitet. Människor Det är omöjligt att rekrytera personal med den kompetens som krävs. Nyckelpersonal är sjuk och otillgänglig vid kritiska tidpunkter. Nödvändig utbildning för personalen finns inte tillgänglig. Organisatoriska Omorganisationer har medfört att olika avdelningar är ansvariga för projektet. Ekonomiska problem framtvingar minskningar av projektbudgeten. Verktyg Den kod som genereras av ett CASE-verktyg är ineffektiv. CASE-verktyg kan inte integreras. Krav Det görs ändringar av krav som kräver större omarbetningar. Kunderna förstår inte konsekvenserna av krav ändras. Uppskattningar Den tid som krävs för att utveckla programvaran är underskattad. Takten med vilken nya defekter upptäcks har underskattas. Storleken av programvaran är underskattat.

Risker som driver projektet ü Projektrisker och produktrisker ü Risker är inte nödvändigtvis negativa. Analysen driver utveckling Ger alternativ Och möjlighet till Trade-off analys ü Planera varje möjlig (kritisk) händelse i förväg.

Hur organiserar vi arbetet? ü Roller Resurser Mantimmar ü Aktiviteter ü WorkProducts Artifakter ü Styrande faktorer Tid Resurser Beroenden ü è Processmodell

Några Processmodeller ü Vattenfall (sekventiell) ü Evolutionary Upptäckande Prototyping ü Iterativa Spiraler ü Agila Iterative

Vad är ett projekt? ü Ett projekt har ett mål som nås genom att slutföra uppgifter som är unika och inbördes beroende av varandra. ü Projekt genomförs genom att man använder och förbrukar resurser ü Projekten har en omfattning, scheman och kostnader och är genomförda inom vissa tidsramar, budgetar, och enligt specifikation 20

Mjukvaruprojekt, några kännetecken ü Stora projekt ü Distribuerade ü Osynlig produkt ü Alltid första gången?!

Tecken på misslyckande (eller fara för) Projektledningen förstår inte användarnas behov. Projektets omfattning är dåligt definierad. Projektförändringar hanteras dåligt. Den valda tekniken förändras. Affärsidéen behöver förändras. Deadlines är orealistiska. Användarna är motsträviga. Stöd förloras. Projektet saknar folk med rätt kompetens. Chefer ignorerar best practices och erfarenhet. Reel, J.S., IEEE Software, May/June1999

Fem viktiga framgångsfaktorer ü Kom igång direkt. ü Behåll drivkraften. ü Mät framstegen. ü Fatta smarta beslut. ü Genomför alltid post-mortem analyser.

Principer för planering ü Planering på kort sikt är lättare än att planera på lång sikt! Okända risker Resurser och mål ü Gårdagens väder är den bästa prognosen ü Planera med slack - ett förändrat startdatum är ett förändrat slutdatum ü Mongoliska hjordens strategi - Antagandet att lägga till folk påskyndar genomförandet av en uppgift är inte sant!. ü Matcha kompetens och erfarenhet med uppgiftens egenskaper ü Balansera grupperna

Planering ü Två strategier Top-down, traditionell ansats Bottom up, en agil ansats ü Top down Använd en existerande processmodell och matcha projektet med den. Instantiera processen! Allokera resurser till processens aktiviteter. Definiera projektspecifika milstolpar. ü Bottom up Planeringsspelet Planera releases Planera iterationer

Planera att lösa ett komplext problem! ü Divide and conquer Bryt ned projektets uppgifter ü Bryt ned närtid i i fler detaljer! ü Behåll framtiden mer oskarp/oprecis Förbered, granska, anpassa Identifiera beroenden och uppskatta tid Avgör resursbehov Dokumentera

Work Breakdown Structures (WBS) ü En hierarkisk representation av aktiviteter och uppgifter ü Börjar med de viktigaste milstolparna ü Förfinar milstolpar till aktiviteter och uppgifter med egna milstolpar. ü Detta är en kontinuerlig process, en WBS är ett aktivt dokument som kommer att förändras under projektets gång. Main Sub 1 Sub 2 Sub 1.1 Sub 1.2 Sub 2.1 Sub 2.2 Sub 2.3 Reproduced with permission 27 from BESTEAMS 2004

UP Översikt

UP - Planering ü Grovkorning - Långsiktig Vision Projektplan Iterationsplanering ü Finkorning - kortsiktigt Iterationsplan

Inception ü Mål Få igång projektet ü Fokus Ta fram en mängd artifakter som man kan arbeta vidare med. Kund Projekt Risker ü Milstolpar Definiera viktiga systemfunktioner Definiera en kandidat mjukvaruarkitektur Etablera projektomgivningen

Elaboration ü Mål Konstruera en fungerande körbar arkitekturbas En detaljerad konstruktionsplan ü Fokus Analys av kraven Implementation av en arkitekturbas ü Milstolpar En körbar arkitekturbas

Construction ü Mål Utveckla arkitekturbasen till ett fullständigt mjukvarusystem ü Fokus Implementation Testning av komponenter ü Milstolpar Fruset mjukvarusystem

Transition ü Mål Rätta fel/defekter ü Fokus Genomför kundspecifika Underhåll av design och implementation Acceptans & Beta tester ü Milstolpar RELEASE PARTY!

UP planering SDP Fas-plan Iterationsplanering (per fas) FAS Iteration # 1 «En tidsordnad sekvens av «aktiviteter «och uppgifter, «med tilldelade resurser, «med beroenden,

Bottom-up (mer agilt) ü Agila principer Självorganiserade grupper Fungerande mjukvara istället för dokument Kundsamarbete framför kontraktsförhandlingarna Reaktion på förändringar istället för att följa en plan ü Två nivåer Releaseplanering (med kunder) Iterationsplanering (med utvecklare)

Releaseplanering ü Definiera milstolpar i form av releaser ü Del av att definiera projektets omfattning ü Genomförs tillsammans med kunden ü Förbered krav (användarberättelser) som ingår i kommande releaser (närtid) ü Faser Explorativa fasen: Kunden ger en lista på krav med stort värde (användarberättelser). Åtagandefasen: Bestäm åtagandet, dvs vilken funktionalitet som ska ingå i nästa version och releasedatum. Genomförandefasen: Justera planen om det behövs. Till exempel kan krav sättas / ändras / tas bort

Iterationsplanning ü Planera utvecklarnas aktiviteter och uppgifter ü Allokera resurser till uppgifter ü Uppskatta resursåtgång. ü Faser Explorativa fasen: Översätt krav till uppgifter. Åtagandefas: Uppskatta när uppgifterna skall vara klara och dela ut dem till utvecklarna. Kontrollfas: Genomför uppgifterna och kontrollera resultatet mot det förväntade.

Ten Golden Rules of Project Management 1. Figure out what business you are in, and then mind your own business 2. Understand the customer s requirements and put them under version control. 3. Prepare a reasonable plan. 4. Build a good team with clear ownership. 5. Track project status and give it wide visibility. 6. Use Baseline Controls. 7. Write Important Stuff Down, Share it, and Save it. 8. If it hasn't been tested, it doesn't work. 9. Ensure Customer Satisfaction. 10. Be relentlessly pro-active. James Chapman, http://www.hyperthot.com/