Bra verktyg för produktägare som vidareutvecklar scrum - André Ekespong
Upcoming SlideShare
Loading in...5
×
 

Bra verktyg för produktägare som vidareutvecklar scrum - André Ekespong

on

  • 3,077 views

 

Statistics

Views

Total Views
3,077
Views on SlideShare
3,068
Embed Views
9

Actions

Likes
0
Downloads
26
Comments
0

1 Embed 9

http://www.slideshare.net 9

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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?

Bra verktyg för produktägare som vidareutvecklar scrum - André Ekespong Bra verktyg för produktägare som vidareutvecklar scrum - André Ekespong Presentation Transcript

  • Bra verktyg för produktägare som vidareutvecklar Scrum? Agila Sverige 2009 Tisdag 9.00 André Ekespong, IRM
  • Agenda Bra verktyg för produktägare
    • Exempel på bra produktägare
    • Uppgift
      • Utveckla processägar-rollen(PO) i Scrum
    • Problem
      • Svårt att hitta PO idag som klarar rollen
      • Svårt för PO att lyckas
      • Medför (oförtjänt?) kritik mot Scrum/Agile
    • Hypotes på möjlig lösning
    • Inbjudan att delta
  • André Ekespong
    • Sedan 1985 i IT-branschen
    • Konsult sedan 1990 (generalist/T-profil)
        • Certifierad verksamhetsarkitekt
        • Certifierad .NET-arkitekt(2xSundblad och Microsoft Sverige)
        • Certified Scrum Master hos Crisp
        • Skriver kod fortfarande…
    • Agile Sweden medlem sedan 2002
    • IRM sedan nov 2008 som konsult
    • Bloggar sedan 2 år: http://ekespong.wordpress.com
    • Twittrar sedan 3 mån id: ekespong
  • Nedlagd tid de senaste 12 mån Jag är absolut ingen ”High Tower”-arkitekt !
  • Projekt: Stöd för aktieanalytiker -98
  • Projektteam Stöd för aktieanalytiker -98 Projektledare (Product Owner) Chef för analys- verksamheten (> 20 milj lön/år)
  • Framgångfaktorer aktieanalytiker -98
    • Tillit
      • Stöd från högsta ledningen
      • Förtroende inom teamet och med PO
    • Prestigelöst arbete
      • Max 20 min eget funderande innan man måste fråga om hjälp av någon annan
    • Mycket bra/kunnig produktägare(PO)
      • Sa oftast nej (80% av alla förslag/idéer sågades)
      • Kunde verkligen verksamheten/kraven
      • Skrev även SQL-koden för nyckeltalsberäkningen
  • Vad vi tillämpade i Agile/XP i projektet för aktieanalytiker 1998
    • Agile Manifesto (innan det skrevs)
      • Individer och interaktion framför metoder, processer och verktyg.
      • Fungerande programvara framför omfattande dokumentation.
      • Kundsamarbete framför kontraktsförhandlingar.
      • Anpassning till förändring framför att följa en plan.
    • XP practices
      • Viss parprogrammering
      • Morgonmöte
  • Resultat projektet för aktieanalys -98
    • Ovanligt stor kundnytta
      • 5 miljoner initial kostnad, flera hundratals miljoner i nytta
      • Företaget fick marknadens bästa verktygsstöd och det hjälpte till vid bl.a. rekrytering av stjärnanalytiker
      • Framställa en 25-sidig rapport gick ner från 6 timmars arbete till 2-3 minuters
    • En orsak: Bästa produktägaren (PO) någonsin
  • Uppgift – utveckla PO-rollen i Scrum
    • Bra verktyg för produktägare(PO) som vidareutvecklar Scrum
    • Bakgrund
      • Viktiga roller i Scrum idag
        • Scrum Master
        • Product Owner(PO)
      • Trend
        • Product owner team
  • Problem idag för PO
    • Svårt att hitta bra PO idag som klarar rollen
      • och fyller hela kravbilden:
        • Kunnig på verksamhetens krav
        • Har tid att avsätta för projektet
        • Tar hand om allt som ingen annan gör
    • Svårt för PO att lyckas
      • Vilka verktyg/modeller skall PO använda egentligen?
      • Är de verktygen/modellerna lättrörliga? Passar de in?
  • Problem med arkitektur – (medelstort företag med ca 500 anställda)
    • > 200 applikationer/system
    • > 300 viktiga informationsobjekt
    • Många kopior av samma information
      • Normalt 5-10 olika kundregister
      • Idag kräver de integration(meningslöst arbete) för att hålla acceptabel datakvalitet
    • Låg återanvändning av information
  • Value Optimization av raffinaderier (projekterfarenhet 2008/09) Utmaning: Hur optimera utfall/resultat från vald råoljemix?
  • Value Optimization av raffinaderier (resultat av projekt 2008/09)
    • Nöjda användare/beställare
        • Ersatte 2 misslyckade interna projekt
        • Gav hög datakvalitet för systemet
    • Men också:
      • Ytterligare 1 databas med 25 nya tabeller som inte var integrerad med resten
    • Inte bra för företaget på arkitekt/helhetsnivån => bristande arkitektur-tänk ?
  • Förslag till lösning på problemet
    • Verksamhetsarkitektur blir PO’s verktyg
      • Process- och informationsmodeller tas fram på kort tid ca 6-8 veckor
      • Nyttja erfarenheter från 25 år inom IRM – verksamhetens perspektiv, vikten av helhetsperspektiv
      • Använda seminarieteknik med folk från verksamheten, väggplast, få och enkla symboler i modeller
  • Hypotes: Conceptual Modelling för Scrum-rollen Product Owner
    • 80 % existerande verksamhetsarkitektur(VA) går att använda om det anpassas
      • Utgå från en mix av IRM idéer och annan beprövad kunskap om VA
    • Lägg till 20 % nytt material
    • Döp om till ”Conceptual Modelling” som kanske fungerar i Agile-världen eftersom arkitektur associeras negativt bland Agile-folk (stämmer det?)
  • Vad är då verksamhetsarkitektur?
    • Mycket kort beskrivning av vad verksamhetsarkitektur är
      • Kräver idag minst 12 dagars utbildning
      • Baserad på >25 års erfarenhet
      • Idag >900 certifierade via Dataföreningen Kompetens
  • 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
  • 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
  • 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
  • Exempel övergripande informationsmodell
  • Struktur via abstraktion till 25-35 objektgrupper 13153 Objektgrupper kan användas för att bringa ordning på verksamhetsregler och tjänster exempelvis
  • 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
  • Mål för höst/vinter 2009/10
    • Bättre stöd för PO i Scrum
      • Bättre anpassade modeller
      • Större kunskap om hur man fångar krav/behov
    • Större förståelse och acceptans för arkitektens helhetsperspektiv inom Agile Rollen finns redan i andra branscher:
        • 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)
  • Inbjudan att delta för intresserade
    • Alla intresserade är välkomna att delta
      • Bidrar du får du möjlighet att påverka och möjlighet att använda resultatet
    • Kom ihåg min hypotes
      • 80% kvar i anpassad form, 20% nytt
    • Mejla intresse av att delta till andre@irm.se
  • Sammanfattning
    • Helhetsperspektiv/arkitekturperspektivet
    • Modelldriven utveckling är effektiv
    • Utnyttja goda erfarenheter från verksamhets-arkitektur i Scrum
    • Se systemutveckling/IT som en del av verksamhetsutvecklingen
    • Undvik överlämningar mellan smala specialister
    • Delta i arbetet – ge ditt bidrag, din tid
  • SOA-specialistens roll Affärsarkitekt Verksamhetsarkitekt IT-arkitekt
  • Identifiera tjänster - grundläggande synsätt Stabilitet Organisation Process vem? hur? Information vad?
  • 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
    • En process initieras av en händelse och består av en samling aktiviteter som tillsammans skapar ett resultat som utgör ett mervärde för kunden .
    Vad är en process? 9015/10668
  • Processarkitektur Operativ process Utvecklingsprocess Infrastrukturprocess Supportprocesser
  • 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
  • Objektmodellering
    • En enkel och säker metod för beskrivning av information i en verksamhet
    7069/5125
    • Smartast lagra enligt behoven?
    8546
  • Exempel övergripande datamodell
  • Identifiera objekttjänster
    • Identifiera objekttjänster genom analys av objektgrupper
    En objektgrupp (subject area) = en datatjänst (data centric service) 13153
  • Tjänstekarta
  • Top-down arkitektur
    • CIO/IT
    • Processägare
    VA-process
  • Identifiera tjänster en del i verksamhetsarkitektur
  • Objektgrupp - detaljmodell 12305 En detaljmodell för en objektgrupp har relationer till objekt i andra objektgrupper.
  • Identifiera tjänster och struktur
    • Identifieras genom analys av IRM-matrisen