![Agenda Bra verktyg för produktägare ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (12)
Similar a Bra verktyg för produktägare som vidareutvecklar scrum - André Ekespong
Similar a Bra verktyg för produktägare som vidareutvecklar scrum - André Ekespong (20)
Más de manssandstrom
Más de manssandstrom (20)
Bra verktyg för produktägare som vidareutvecklar scrum - André Ekespong
- 1. Bra verktyg för produktägare som vidareutvecklar Scrum? Agila Sverige 2009 Tisdag 9.00 André Ekespong, IRM
- 4. Nedlagd tid de senaste 12 mån Jag är absolut ingen ”High Tower”-arkitekt !
- 5. Projekt: Stöd för aktieanalytiker -98
- 6. Projektteam Stöd för aktieanalytiker -98 Projektledare (Product Owner) Chef för analys- verksamheten (> 20 milj lön/år)
- 13. Value Optimization av raffinaderier (projekterfarenhet 2008/09) Utmaning: Hur optimera utfall/resultat från vald råoljemix?
- 18. Verksamhetsarkitekturens hörnstenar Processer Information Processernas informationsbehov Lagrad information Informations- försörjning Varför? Hur? Vad? Vem? När? System och tjänster Var? 13107
- 19. Verksamhetsarkitektur 13151 Utveckla processkarta Identifiera tjänster Analysera IRM-matriser Utforma tjänstestruktur Utforma kravspecifikation Utforma gränssnitt Prioritera processtjänster Utveckla tjänster och system Förvalta tjänster och system Utveckla övergripande objektmodell Identifiera strategiska processer Initiera projekt Identifiera berörda tjänster
- 20. Arkitekturrollerna enl Dataföreningen Värde-nätverk Affär och strategi Affärs-modell Processer Information Applikation Infrastruktur Teknologi Tjänster Affärsarkitekt Verksamhets-arkitekt IT-Arkitekt
- 22. Struktur via abstraktion till 25-35 objektgrupper 13153 Objektgrupper kan användas för att bringa ordning på verksamhetsregler och tjänster exempelvis
- 23. Mål: Överbrygga klyftan mellan verksamhet och IT Vision Verksamhet IT WHY HOW WHAT Process & Architecture Matrix Requirement Matrix System Matrix Perspektiv enligt Zachmans ramverk
- 27. SOA-specialistens roll Affärsarkitekt Verksamhetsarkitekt IT-arkitekt
- 28. Identifiera tjänster - grundläggande synsätt Stabilitet Organisation Process vem? hur? Information vad?
- 29. Verksamhetsarkitektur 13151 Utveckla processkarta Identifiera tjänster Analysera IRM-matriser Utforma tjänstestruktur Utforma kravspecifikation Utforma gränssnitt Prioritera processtjänster Utveckla tjänster och system Förvalta tjänster och system Utveckla övergripande objektmodell Identifiera strategiska processer Initiera projekt Identifiera berörda tjänster
- 31. Processarkitektur Operativ process Utvecklingsprocess Infrastrukturprocess Supportprocesser
- 32. Vad vill vi åstadkomma? Processägare Flexibilitet och vighet genom utveckling av verksamhetens processer både horisontellt och vertikalt För att möta omvärldens ständigt ökade krav på förändring Kund Kund
- 37. Tjänstekarta
- 39. Identifiera tjänster en del i verksamhetsarkitektur
- 40. Objektgrupp - detaljmodell 12305 En detaljmodell för en objektgrupp har relationer till objekt i andra objektgrupper.
Notas del editor
- Jag är definitivt kvar i utvecklarkulturen också och det är ett medvetet val. Jag är definitivt ingen ”high tower” arkitekt – vilket är en rädsla i Agilekretsar.
- Systemet ersatte Excel-lösningar. Genom att använda databas istället för Excelark kunde man visa upp data ur alla ledder från webben
- Uppgiften är att Hitta bra verktyg för produktägare som vidareutvecklar Scrum Produktägarens roll(PO) är viktig för att Scrum skall fungera. Idag har många svårigheter att hitta bra PO och de som finns saknar bra etablerade verktyg för sin roll. Inom verksamhetsarkitekur-kulturen finns processmodeller, informationsmodeller och matriser som etablerade artefakter. Dessa kan tas fram på några veckor. Jag tänker visa att de modellerna kan användas på ett agilt sätt och hjälpa PO att fånga behov och att kommunicera med verksamhetens experter och chefer. Det kan ge organisationer med agila ambitioner ett bra stöd och högre kvalitet inom det svåra gränslandet mellan verksamhet och IT.
- Ser det inte ofta ut så här i alla Agile-projekt?
- Inledning Verksamhetsarkitekturens hörnstenar är processer, information och system och hur dessa samverkar – det är vad VA handlar om i grund och botten. Processer I VA så beskriver vi processerna på en övergripande nivå. Normalt så har vi en processkarta för hela verksamheten med 6-8 processer och som vi sen detaljerar så att vi hr en processkarta per process, dvs 6-8 st. Om vi relaterar den här hörnstenen till Zachman så svarar processerna på frågan hur arbetet bedrivs, vi kopplar processerna till vision, mål och strategi och får då koppling till varför vi beskriver även händelser som initierar processerna som ger oss en koppling till när och till sist så anger vilka aktörer som utför processerna och får kopplingen till vem. Information Den andra hörnstenen är informationen och vi använder objektmodellen som verktyg för att beskriva vilken information som verksamheten hanterar och hur den är strukturerad. Och informationen svarar på frågan vad i Zachman framework System Den tredje hörnstenen är system, databaser, applikationer där informationen lagras och hanteras. Matriser För att det ska bli en arkitektur av dett så analyserar vi hur dessa hörnstenar hänger ihop med hjälp av matriser. Process- och informationsmatris – beskriver vilken info som en process behöver och vilken information som processen skapar. Vi analyserar vilka system som stödjer vilka processer och till sist så har vi en matris för att analysera var och hur vi har lagrat informationen. Detta tillsammans bildar som sagt var hörnstenarna i arkitekturen. Nuläge/framtid Vi använder dessa modeller och matriser för att dels kartlägga nuläget men framför allt så tar vi fram en framtida version av hur vi vill att dessa hörnstenar ska se ut. System – service komponenter Det som vi har kompletterat dessa hörnstenar med är att systemen numera är kompletterade med service komponenter. Övergång Det var en kort beskrivning av vad verksamhetsarkitekturen består av låt oss nu gå vidare och se hur vi använder den för att ta fram en SOA-baserad arkitektur. Customer Value To be prepared for change ; IT shall support changes and development of Business Processes. High Quality; to provide the business processes with high quality SOA Services. This includes high quality of data/information, functions and business rules. Low cost; every SOA Service is unique and there are no duplicates regarding data, function and business rules. This reduces the cost compared to the legacy with more than 50 % in many businesses.
- Exempel på helhetsperspektiv. Används för att förenkla kommunikation.
- Inledning Vi använder objektgruppsmodell som verktyg för att beskriva hörnstenen information på en övergripande nivå för en verksamhet . Objektgruppsmodell Vi tar först fram en övergripande objektmodell för hela verksamheten med de mest centrala begreppen och relationerna. Utifrån den objektmodellen identifierar vi grupper av objekt. Vi grupperar genom att utgå från ett viktigt objekt i verksamheten – ett sk kärnobjekt och analyserar vilka kringliggande objekt har samma livscykel som det aktuella objektet – utifrån det får vi fram objektgrupperna. Identifiera När den här väl är klar är det enkelt att identifiera objekt servicekomponenterna – det är nämligen 1:1 så har man identifierat en objektgrupp så har man identifierat en objekt servicekomponent Övergång Men vi behöver mer kunskap om objektgrupperna för den fortsatta analysen så därför tar vi fram detaljmodeller…
- Matriser och modeller används för att överbrygga gapet mellan IT och verksamhet. Perspektiven är från Zachmans ramverk. Målet för IRM är att överbrygga klyftan mellan verksamhet och IT genom att ha en fot i bägge världarna
- Hos Toyota har man chefsingenjören (och hans team). Vid husbyggnad har man arkitekten (eller teamet av arkitekter). Vid filmproduktion har man filmregissören. (Vid teaterproduktion teaterregissören). Och i vår bransch arbetar till exempel IASA för att arkitektrollen skall utvecklas åt detta håll. Vilket den också gör. Hela it-arkitektcommunityn är på väg åt detta håll.
- Du får delta om du vill.
- Här finns fyra ord som särskilt ska understrykas: händelse , aktiviteter , resultat och kunden Definition av en process: Här finns fyra ord som särskilt ska understrykas: händelse , aktiviteter , resultat och kunden Definitionen är användbar när vi analyserar processer. Har vi fångat de viktiga attributen (dvs de fyra orden ovan)? Bildens budskap Att definiera vad en process är. Presentation Betona följande ord i definitionen: Händelse, ofta kopplad till en kund Aktiviteter, det arbete som utförs till följd av en händelse Resultat, det som ”kommer ut ur processen” Kund, processer syftar till att öka fokuseringen på kunden Övergång till nästa bild Det här är en nedskriven, sammanfattad definition på en process, men vad kännetecknar en process?
- Processägaren likt en dirigent orkestrerar sina processer Obs – prattext till orkestrering av Eskil Focusing on critical business process Develope a new process instant for a specific customer, product, contry, event … Orchestrator is a new role supporting the process owner Working closely together with ”service owners” This role is created by John Hagel in ”out of the Box” Bild som visar flexibilitet och orkestrering Vilka värden skapas (white paper) Det här är vad alla talar om men hur skapar vi förutsättningar för att nå dit? Lista med förutsättningar (slå in öppen dörr..) PAUL ALLEN Constant business change New business areas, products, channels, technologies … Silo systems and processes Duplication Inconsistency High cost Time to market IT is critical path Quality Repeatable processes Consistent outcomes Satisfied customers Cost of change
- Lagra Information efter behov Okej en förutsättning för att upphandla morgondagens krav var att vi beskriver och förmedlar våra krav i modeller att vi bygger på information som är den mest stabila så nu är utmaningen att hitta metoder för att kombinera det här för att jag tror att Ni minsann är nyfikna och håller med om det jag sagt frågan är bara hur gör vi det här. Ja vi måste ju ta reda på vad vi ska lagra och då gör vi som kocken. Om vi nu vill ha system som kan klara av en förändring i morgon utan att få hicka. Så kan vi inte lagra informationen på ett flertal ställen. Ponera att vi jobbar på restaturang och har en kyl där vi lagrar ingridienserna. Vi skulle kunna lagra dom efter recept det går då bra och snabbt att ta fram ingrideinseran men nackdelen är att vi inte vet. Hur mycket vi har av till exempel vetemjöl eller ägg. Så ett annat sätt att lagra Ingridienserna skulle ju vara efter råvaror på så sätt kan vi ju kombinera och göra nya recept allteftersom vad vi känner för och även de rätter vi inte har på menyn idag kan ju tas fram och lagas av det som finns. Vi vet också när det är slut och vi behöver beställa mera Och om varje råvara lagras på ett och samma ställe är det lättare att hitta och använda sig av. Vi slipper utgågna varar eller det är åtminstone lättare att hålla ordning och genom att inte ha pastan på hundra ställen spar vi också utrymme. Begrepp
- Inledning Vi använder objektgruppsmodell som verktyg för att beskriva hörnstenen information på en övergripande nivå för en verksamhet . Objektgruppsmodell Vi tar först fram en övergripande objektmodell för hela verksamheten med de mest centrala begreppen och relationerna. Utifrån den objektmodellen identifierar vi grupper av objekt. Vi grupperar genom att utgå från ett viktigt objekt i verksamheten – ett sk kärnobjekt och analyserar vilka kringliggande objekt har samma livscykel som det aktuella objektet – utifrån det får vi fram objektgrupperna. Identifiera När den här väl är klar är det enkelt att identifiera objekt servicekomponenterna – det är nämligen 1:1 så har man identifierat en objektgrupp så har man identifierat en objekt servicekomponent Övergång Men vi behöver mer kunskap om objektgrupperna för den fortsatta analysen så därför tar vi fram detaljmodeller…
- Nu har vi gått igenom att vi ident
- När vi gör detaljerade objektgruppsmodeller fattar vi beslut om vilka objekt som ska vara innanför resp utanför avgränsningen för den aktuella objektgruppen. Vi gör det utifrån…- beskriv principerna Det ger oss objektgrupper som har ett litet beroende till andra objektgrupper – dvs utmärkt underlag för att identifiera servicekomponenter Rita inte ut relationerna mellan objekten i andra grupper, t ex leverantör och leverantörsavtal. Låt istället dessa framgå i resp objektgrupp Utgå från ett kärnobjekt 1:M relation ingår på M-sidan M:M måste bedömas När föds informationen? Kontrollera mot ramobjektet så att objektgruppen blir tillräckligt stor Bättre kvalité OBS Objektgruppshierarki Ger oss möjlighet att utveckla stegvis eftersom vi har en karta att utgå ifrån
- Analys av arkitektur och ”matrisen” Titta på kvarteren – ett kvarter kan motsvara en aktivitetstjänst men i många fall kan endast en rad motsvara en aktivitetsservicekomponent Vad skiljer en SOA-matris från en IRM-matris?