Embed Size (px)
Citation preview
Reload! A/S
Om Reload og procesPræsentation af Reload
Vi er specialister i Drupal
Vi er pt. 16 faste folk
Reload startede i 2010.
Vi bor på Frederiksberg
• 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
DR.dk
DR.dk på DrupalVi har arbejdet på at lave en helt ny webplatform for
DR sammen med Peytz siden 2012. Vi har i juni 2015
rundet 11.000 timer for Reload alene på dette projekt,
og projektet bliver færdig ved udgangen af året.
IDA.dk
Københavns Biblioteker
bibliotek.kk.dk
Vi har arbejdet på at lave en
helt ny hjemmeside for
Københavns Biblioteker,
baseret på open source
systemet DDB CMS - som
vi også har en stor del af
æren for.
Københavns Biblioteker er
den største
bibliotekshjemmeside i DK,
og vi har haft dem som
kunde siden 2008.
stofa.dk
samvirke.dk
Mød Reload
• Se video online på https://vimeo.com/
112038104 eller reload.dk
• 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
Vælger i os, så vælger i også en proces
Vi kan jo ikke bare udskrive en blanko-check?!- Typisk reaktion fra kunde, sagt i vantro…
• 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!
En agil udviklingsproces handler om at give mest
mulig forretningsværdi for pengene
Det handler om at finde symbiosen mellem
forretningsviden og teknisk viden
Viden stiger over tid - fordrer JIT planlægning
Plan
Plan
Plan
Plan
Plan
"JUST-IN-TIME" PLANLÆGNING
Plan Analyse TestKodeDesign 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?
• 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)
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
Fast scope Agil
Projekt fokus Udfør opgaver med mindst mulig indsats
Maksimering af forretningsværdi og TCO
Ændringer Dyre Gratis
Scope FastLøbende forbedret med de
erfaringer der er gjort i projektet
Fast scope vs agil
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
• 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
(Quality)
Scope (functionality, features)
Time (deadline)
Resources (cost, budget)
• 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
• 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
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
