Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Reload præsentation

Reload præsentation

Dette er seneste version af vores standard præsentation af Reload - lidt om os og vores metoder.

Rasmus Luckow-Nielsen

May 11, 2016
Tweet

More Decks by Rasmus Luckow-Nielsen

Other Decks in Business

Transcript

  1. Reload! A/S
    Om Reload og proces
    Præsentation af Reload

    View Slide

  2. Vi er specialister i Drupal
    Vi er pt. 18 faste folk
    Reload startede i 2010.
    Vi bor på Frederiksberg

    View Slide

  3. • Vi er et teknisk konsulenthus, og har de
    dygtigste Drupal udviklere i DK
    • Vi outsourcer ikke, idet vi fokuserer på et
    tæt samarbejde med kunden
    • Vi har høj faglighed stolthed og en god
    sjat idealisme
    Kort om Reload

    View Slide

  4. DR.dk

    View Slide

  5. DR.dk på Drupal
    Vi har arbejdet på at lave en helt ny webplatform for
    DR sammen med Peytz (og senere Netcompany) i
    perioden april 2012 til december 2015. Vi har rundet
    de 12.000 timer for Reload alene på dette projekt.
    Langt størstedelen af projektet har vi ageret
    hovedarkitekter og senior ressourcer.

    View Slide

  6. IDA.dk “Den agile proces fungerer
    skide godt. Det giver ro i maven,
    at der er løbende leveringer”
    Kim Elmose, Digital udviklingsredaktør, IDA

    View Slide

  7. samvirke.dk
    “Vi er så glade for at arbejde
    sammen med dem - også selv
    når projektlederen og jeg
    diskuterer som et gammelt
    ægtepar”.
    “Der findes ikke et Drupal-
    udviklingshus som er mere
    kompetent end Reload.”
    Lotte Malmgren, digital redaktør,
    Samvirke

    View Slide

  8. “Ret tidligt i forløbet havde vi noget
    visuelt, som kunne fungere teknisk,
    hvilket var super fedt.”

    Birgitte Olesen, IT-projektkoordinator, DKT
    “Det at have designere og udviklere i
    samme rum og med det samme finde ud
    af, hvorvidt designet kan
    implementeres, var fantastisk”

    Anne Tønnes Jessen, systemkoordinator, DKT
    Det Kongelige Teater - Intranet

    View Slide

  9. Københavns Biblioteker

    View Slide

  10. stofa.dk

    View Slide

  11. desuden
    TV2, Bonnier, Unicef, Læger uden Grænser,
    Det Kongelige Teater, De Danske Spejdere,
    Novasol, Region Sjælland, Kulturstyrelsen
    og mange andre…

    View Slide

  12. Mød Reload
    • Se video online på https://vimeo.com/
    112038104 eller reload.dk

    View Slide

  13. Many companies face the paradox of wanting
    to build a delightful product without
    knowing if people actually want the product
    until it’s released.
    – Chris Bank, UXPin

    View Slide

  14. • Antager at man på forhånd kan regne ud,
    hvad der skal bygges, og i hvilken
    rækkefølge, det bedst giver mening
    • Fungerer derfor fint til simple eller
    overskuelige opgaver
    • Har et meget langt feedback loop, og er
    derfor ikke optimalt til innovative eller
    komplekse projekter med mange
    antagelser og ubekendte
    Den klassiske vandfaldsmodel

    View Slide

  15. • Et godt projekt er ét vi ikke ved hvordan vi
    skal løse når vi går igang
    • Et godt projekt bliver vi klogere af
    • Vi kommer ofte tidligt ind i projekterne og
    bruger meget energi på at afklare de
    reelle forretningsbehov, inden vi prøver
    at løse dem
    Hvis virkeligheden er simpel, så
    har I nok ikke brug for Reload!
    Reloads typiske projektrum

    View Slide

  16. Start with why
    Vi bruger metoden Impact
    Mapping for at identificere
    forretningsmål, aktører,
    hvordan og hvad der skal
    laves.
    Og så bruger vi agile
    metoder for at levere dette
    efterfølgende.
    Vi arbejder altså i højere
    grad efter forretningsmål
    end funktionaliteter.

    View Slide

  17. Vælger i os, så vælger i også en proces

    View Slide

  18. View Slide

  19. Vi kan jo ikke bare udskrive
    en blanko-check?!
    - Typisk reaktion fra kunde, sagt i vantro…

    View Slide

  20. • Feedback loop, kommunikation og
    ansvarsfordeling
    • Giver gennemskuelighed og
    transparens
    Overskrift i en linie
    • Det giver mening at være agil når
    man arbejder inden for komplekse
    problemområder
    • Løbende forventningsafstemning
    Hvorfor arbejder vi agilt? Fantastisk video - se den!

    View Slide

  21. En agil udviklingsproces
    handler om at give mest
    mulig forretningsværdi for
    pengene

    View Slide

  22. Det handler om at finde
    symbiosen mellem
    forretningsviden og
    teknisk viden

    View Slide

  23. Viden stiger over tid - fordrer JIT planlægning

    View Slide

  24. Plan
    Plan
    Plan
    Plan
    Plan
    "JUST-IN-TIME" PLANLÆGNING
    Plan Analyse Test
    Kode
    Design Release
    Traditionel (prædiktiv):
    Planlæg hele projektet på forhånd
    Scrum (empirisk):
    Planlæg lidt før projektet og lidt før hvert sprint
    Analyse
    Design
    Kode
    Test
    Release
    Analyse
    Design
    Kode
    Test
    Release
    Analyse
    Design
    Kode
    Test
    Release
    Analyse
    Design
    Kode
    Test
    Release
    Hvad hvis projektet
    stopper her?
    Plan
    Plan
    Plan
    Plan
    Plan

    View Slide

  25. • Fokusér på forretningsværdi
    • Lav leverancer der kan afprøves i
    virkeligheden og hurtigst muligt
    • Prototyping!
    • Løbende forbedringer i stedet for "løs det
    hele på en gang"
    • Lagkagen skal skæres vertikalt og ikke
    horisontalt
    Fokus på forretningsværdi, time-
    to-market og minimumsprodukt
    (MVP)

    View Slide

  26. Fast scope Agil
    Transparens "95% færdig" Reel fremdrift er synlig
    Time to market Langsommere, alt skal designes
    først
    Hurtigere, færdiggør ting med
    størst forretningsværdi først
    Kvalitet Mindst muligt der opfylder
    kontrakten
    Fokus på Total Cost of Ownership
    (TCO)
    Fast scope vs agil

    View Slide

  27. Fast scope Agil
    Projekt fokus Udfør opgaver med mindst mulig
    indsats
    Maksimering af forretningsværdi
    og TCO
    Ændringer Dyre Gratis
    Scope Fast
    Løbende forbedret med de
    erfaringer der er gjort i projektet
    Fast scope vs agil

    View Slide

  28. Fast scope Agil
    Kundeinvolvering Stor indsats i starten og
    slutningen af projektet
    Stabil indsats gennem hele
    projektet
    Typiske risici Dyrt pga. ændringer, manglende
    kvalitet
    Uerfarent team
    "misbruger" den agile praksis
    Pris Fast + ændringsønsker Betal kun for udført arbejde
    Fast scope vs agil

    View Slide

  29. (Quality)
    Scope
    (functionality, features)
    Time
    (deadline)
    Resources
    (cost, budget)

    View Slide

  30. • At have en effektiv agil udviklingsproces
    stiller en masse krav til resten af
    organisationen og de omkringliggende
    beslutningsprocesser
    • At fordre en agil mentalitet og
    arbejdsproces kræver stor opbakning i
    organisationen og specielt i ledelsen
    • At indføre og køre et scrumforløb som en
    ekstern konsulentpart har sine helt egne
    udfordringer - men vi kender dem.
    At arbejde agilt stiller en masse
    krav til jeres organisation

    View Slide

  31. • I skal turde at gå efter overordnede mål -
    og ikke tro at alt kan skrives ned i en
    kontrakt fra starten
    • Det kræver kompetente teams,
    uddelegering af beslutningsmandat og
    klare mål
    • Transparens i proces og hurtig feedback
    giver mulighed for - og kræver - løbende
    reprioriteringer af de planlagte opgaver
    At arbejde agilt stiller en masse
    krav til jeres organisation

    View Slide

  32. • Vi starter med fokus på hvilken reel forretningsværdi
    vi jagter - og hvordan det er prioriteret. Her er Impact
    Mapping et godt værktøj.
    • Vi arbejder langt mere med prototyping - endnu mere
    iterativt og meget tæt med kunde, udvikler, ux og
    design. På den måde slipper vi for at kæmpe mod
    forudintagede forventninger omkring det endelige
    design. I stedet bruger vi style guides og eksempler.
    • Endnu større fokus på at lave fremskrivning. Hvad når
    vi af funktionalitet for pengene? Hvornår er vi
    færdige?
    • Risici. Klassisk risiko log i fht. projektet giver ro i
    maven.
    Agile projekter hos Reload

    View Slide

  33. • Vi kræver at kundens Product Owner er
    beslutningsdygtig og sammen med
    teamet 1-2 dage om ugen
    • Faste rutiner - typisk 2 ugers sprint,
    løbende backlog grooming, sprint-
    planning, -demo og -retrospektiv samt
    daily scrums
    • Gode værktøjer - vi sværger til Jira Agile,
    og vores kunder arbejder også her.
    • Gode afrapporteringsskabeloner med
    fokus på MVP
    Agile projekter i Reload

    View Slide

  34. Lige meget hvor godt et
    projekt vi laver, så vil det af
    kunden blive betragtet som
    en fiasko, hvis vi ikke møder
    deres forventninger.
    – Rasmus Luckow-Nielsen, adm. direktør, Reload

    View Slide

  35. Suomisvej 2, 2. sal

    1927 Frederiksberg
    reload.dk
    [email protected]

    View Slide