Dette er vores standard-præsentation omkring Reload og vores proces. Det handler om, hvem vi er, hvordan vi arbejder og hvorfor vi synes, at det giver mening.
Det handler om hvorfor en agil tilgang og en proces omkring fast pris og et minimumsscope (MVP) giver mening.
Læs mere på https://reload.dk/proces
2. Vi er specialister i Drupal
Vi er pt. 16 faste folk
Reload startede i 2010.
Vi bor på Frederiksberg
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
5. DR.dk på Drupal
Vi 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.
8. 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.
11. Mød Reload
• Se video online på https://vimeo.com/
112038104 eller reload.dk
12. • 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
14. Vi kan jo ikke bare udskrive
en blanko-check?!
- Typisk reaktion fra kunde, sagt i vantro…
15.
16. • 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!
20. Plan
Plan
Plan
PlanPlan
"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?
21. • 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)
22. 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)
Fastscopevsagil
23. 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
Fastscopevsagil
24. 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
Fastscopevsagil
25. • 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
27. • 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
28. • 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
29. 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
30. Suomisvej 2, 2. sal
1927 Frederiksberg
reload.dk
kontakt@reload.dk