Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Empfohlen
Empfohlen (20)
Smidige prosjekter på dypt vann (Smidig 2012)
- 1. Smidige prosjekter på dypt vann Risikohåndtering av IT-prosjekter i en smidig verden Svein-Magnus Sørensen @SveinMagnus Photo by SteelCityHobbies (CC-BY) - http://www.flickr.com/photos/steelcityhobbies/1084133585/ @SveinMagnus Smidig 2012
- 2. Tradisjonell risikohåndtering Faste kontrollrutiner Statiske styringsparametre Kontraktsbasert oppfølging Photo by Adam Modlin (CC-BY-NC) - http://www.flickr.com/photos/adam-modlin/2742297035/ @SveinMagnus Smidig 2012
- 3. Effekten av smidig Metoder for prosjektgjennomføring har gjennomgått en revolusjon! Risikoprofilen og organisasjonen er endret, men utnytter vi mulighetene? Photo by Wodgie (CC-BY) - http://www.flickr.com/photos/nevillewootton/6800341205/ @SveinMagnus Smidig 2012
- 4. En parallell: Sportsdykking Nødvendig utstyr ble utviklet på 30-tallet og sporten ble popularisert etter 2. verdenskrig med militært overskuddsmateriell. De fleste risikomomenter var kjente, men måtte håndteres statisk på forhånd: – Dykketid/dybde måtte planlegges etter tabeller, ingen individuell tilpasning var mulig. – Ingen luftmåler på tanken – kun liten reserve – Ved uforutsette hendelser var det vanskelig å korrigere planen da man lett kunne risikere trykkfallssyke eller å gå tom for luft. Slik gjøres også tradisjonell risikohåndtering! Illustration from WikiMedia Commons | Photo by Archibald (CC-BY-NC) - http://www.flickr.com/photos/archi-bald/5964026174/ @SveinMagnus Smidig 2012
- 5. Smidig sportsdykking Oppdriftskontroll Lufttrykksmåler Dykkecomputer Photo by DocJelly (CC-BY-NC) - http://www.flickr.com/photos/docjelly/173949072/ @SveinMagnus Smidig 2012
- 6. Generelle prinsipper Sanntidsinformasjon Kontinuerlig evaluering Intelligent feedback Løpende modifisering Photo by Mal B (CC-BY-ND) - http://www.flickr.com/photos/mal-b/6834639908/ @SveinMagnus Smidig 2012
- 7. Organisasjonelle utfordringer Mennesker underestimerer risiko Kan ikke bytte prosjektdeltakere Helheten er vanskelig å forstå Photo by Saspotato (CC-BY-NC-SA) - http://www.flickr.com/photos/saspotato/4449735215/ @SveinMagnus Smidig 2012
- 8. Forutsetninger Testdrevet utvikling Kontinuerlig byggemiljø Automatisk analyse av kodekvalitet Aktiv planlegging og registrering av oppgaver Photo by hankplank (CC-BY-NC-ND) - http://www.flickr.com/photos/theactionitems/3575062874/ @SveinMagnus Smidig 2012
- 9. Smidig risikohåndtering i praksis Automatisk måling av ferdigstatus på oppgaver Kan synliggjøre faktisk leveransekapasitet Analyse kan vise om oppgaver leveres på tid Dynamisk evaluering av måleparametre Implementert funksjonalitet kan måles mot plan Tettere oppfølging av kostnader vs. måloppnåelse Photo by Derek Keats (CC-BY) - http://www.flickr.com/photos/dkeats/6336991333/ @SveinMagnus Smidig 2012
- 10. Bruk mulighetene! Photo by Hani Amir (CC-BY-NC-ND) - http://www.flickr.com/photos/haniamir/4157806397/ @SveinMagnus Smidig 2012
- 11. Takk for meg! Spørsmål? Photo by Frank Kehren (CC-BY-NC) - http://www.flickr.com/photos/fkehren/4217138338/ @SveinMagnus Smidig 2012
Hinweis der Redaktion
- Risikoanalyse, risikohåndtering og risikoledelse er store områder.Tenker her primært rundt håndtering av utviklingsteknisk risiko i IT-prosjekter.
- Risiko består av produktet av to elementer:1 sannsynlighet for at hendelsen inntrer2 konsekvens når den inntrerStatkonsult Rapport 1998:7 – Risikohåndtering av IT-prosjekterTyper risiko:2 Urealistiske mål og for høyt ambisjonsnivå – for lite fokus på gjennomføringsevne.4 For store og omfattende systemer – leveransene ikke nok splittet opp mht. oppgaveløsning og ferdigstillelsestidspunkt.7 Planer og estimater baseres på mangelfullt grunnlag.11 Neglisjering av endringer i krav og nye forutsetninger for prosjektet underveis.
- Det har skjedd en revolusjon i prosesser slik som kravspesifisering, kundedeltakelse og ferdigstilling av leveranser.Risikoprofilen i mange prosjekter har dermed blitt endret, men utnytter vi mulighetene dette gir?Deler av risikoen har blitt mindre (f.eks. at det man utvikler ikke dekker behovet) mens annen risiko har vokst (f.eks. avveining mellom budsjett og funksjonalitet).Risikohåndtering og risikostyring gjøres allikevel stort sett på samme måte som før! F.eks. fast % krav til testdekning, oppfølging av leveransefunksjonalitet, etc.Dette kan være i konflikt med resten av prosjektmetodikken som søker å tilpasse seg behov i endring.
- Sportsdykking utviklet seg i mellomkrigstiden med svømmeføtter, masker, pusteapparater, dybdemåler, klokke og dykketabeller. Ble populært etter krigen basert på overskuddsmateriell fra froskemannsstyrkene de fleste land hadde utviklet.
- På 70-tallet fikk man Submersible Pressure Gauges på lufttanken og Buoyancy Control Devices for å kontrollere oppdriftUtover 90-tallet ble det også populært med dykkecomputere som gav sanntids nitrogenestimering og dekompresjonstid.Dette tillot mer dynamisk og individuelt tilpasset dykking på varierende dybder.Ikke lenger like risikabelt å gå noen meter dypere for å utforske noe spennende.
- Fortsatt viktig med grundig planlegging, riktig trening og lang erfaring.Sanntidsinformasjon om kritiske parametere gjør at man kan kontinuerlig evaluere og modifisere plan og retning etter faktiske forhold.Ved å bruke intelligent feedback som styringsparametre kan man tidlig oppdage forsinkelser og risiko, og agere deretter.
- Fridykking har helt andre typer risiko og ferdighetskrav enn instrumentdykking, men det er ikke nødvendigvis åpenbart siden det ‘nesten’ er det samme.Folk flest underestimerer risikosannsynlighet, særlig når det komplekse sammenhenger med ting andre personer holder på med.Fortsatt de samme menneskene som skal gjøre prosjektet. Kan ikke bare be dem endre sin atferd, slik tar tid. Utviklere og andre prosjektdeltakere ser ikke konsekvenser av sine valg, f.eks.effekten av en liten forsinkelse på resten av det store bildet, så slikt rapporteres ikke oppover.Smidig risikohåndtering bør derfor begynne med tekniske løsninger, likt kodekvalitet og testing.
- Forutsetter TDD, Kontinuerlig byggesystem, Automatisk analyse av kodekvalitet.
- Klarer vi å måle opp mot antatt ferdig-mengde av løsningen. Trenger gode indikatorer som faktisk gir informasjon om leveransekapasitet -> risiko for prosjektet.Leveranse på tid (Ferdigstiller man ting i backlogg eller skyves de framover?)Funksjonalitet (Måles mot krav, og planlagt i sprint)Kvalitet (Sikkerhet, Feil i løsningen, Brukerkvalitet)Kost (Evaluering av kost mot hva som faktisk blir levert)
- Bruk mulighetene som ligger i sanntidsevaluering av relevante prosjektparametere!Kan gi spennende forbedringer i prosjektgjennomføring!