[A20] Kick off document and process description. 1 of 5

Transkript

1 [A20] Kick off document and process description 1 of 5

2 kick off document Huge Lawn Projekt Kick-Off Alle projekter og ideer er forskellige. For at vi kan give et reelt bud på dit/jeres projekt eller idé ift. tid, økonomi og omfang vi vi bede dig/jer udfylde dette skema med så megen information som muligt. Informationer givet i dette dokument behandles fortroligt. Om dig/din virksomhed Beskriv målgruppen for projektet: Dit navn, evt. titel og kontaktoplysninger: Konkurrenterne: Beskriv konkurrenterne på markedet og evt. styrker/svagheder Fortæl lidt om organisationen og jeres formål. Hvilke varer/services tilbydes? Forefindes der evt. et website eller anden offentlig kommunikationsmateriale? Projekt realisering Projekt-idé Indhold og setup: Er indholdet til projektet allerede fastlagt og produceret i en digital version? Er det tekniske setup klar? Fortæl om dit projekt i én sætning: Målet for projektet er: Prøv at beskrive den vigtigste målsætning for projektets succes design, brugervenlighed og effekt taget i betragtning Deadline Findes der en deadline for projektet, eller er det fleksibelt? 2 of 5

3 Process description Processen bag en god app Budget Ved at kende budgettet på projektet kan vi nemmere anskueliggøre, hvilke features der bør udelades i den første version ell afgøre, om det hele skal rulles ud på én gang (et estimat er nødvendigt) Hos Huge Lawn - Miracle Apps arbejder vi ud fra en scrum-baseret proces, der både sikrer jer en hurtig, gennemsigtig og resultatorienteret udviklingsproces, som samtidig giver vores udviklere de bedst mulige arbejdsvilkår, så vi undervejs og til slut kan levere et produkt, der afspejler jeres ønsker og behov i forhold til app en. For at give jer et bedre indblik i arbejdet omkring en app finder I herunder en gennemgang af scrum-processens forskellige trin hos Huge Lawn - Miracle Apps. Noget vi glemte? Anden information der er vigtigt for dette projekt Mange tak for din tid. Vi vender tilbage med et tilbud. Send Indsend aldrig adgangskoder via Google Analyse. Leveret af Google Docs Rapportér misbrug - Servicevilkår - Yderligere vilkår Kick off dokument til opstart af processen Som opstart på processen i forhold til udvikling af en app får I tilsendt vores Projekt Kick off til udfyldelse. (jf. Dette udgør sammen med det indledende møde basis for Huge Lawn - Miracle Apps efterfølgende analysearbejde. Indledende møde med fokus på idéudvikling Ved dette møde sætter vi sammen de nærmere rammer for og klargør jeres ønsker til app en for eksempel i forhold til: konteksten for projektet idé og formål funktionaliteter visuelt udtryk deadline og økonomi Afklarende analyse Efter mødet afklarer og analyserer Huge Lawn - Miracle Apps internt processen for udviklingen nærmere. Det er vigtigt for hele projektets resultat og jer, at analysearbejdet gøres grundigt, så vi sikrer, at slutproduktet af analysen, der består af systembeskrivelse med estimater og tilbud på udvikling af app en, er bedst muligt. Systembeskrivelsen indeholder: en beskrivelse af, hvilke funktioner og strukturer app en vil have for at kunne opfylde dens formål til den/de ønskede målgrupper bedst muligt et storyboard over app ens struktur og wireframe design af de enkelte skærme i app en baseret på vores erfaringer med best practice for usability info om, hvilke devices app en skal udvikles til at køre på, og hvilke eventuelle administrationssystemer og integrationer med eksisterende systemer, der skal udvikles estimater for udvikling af de forskellige komponenter, så vi sammen kan vurdere om prisen for udvikling af en feature står mål med den værdi, I som kunde får af den enkelte feature beskrivelse af forudsætninger og afhængigheder af evt. leverancer fra jer til Huge Lawn - Miracle Apps i forbindelse med udviklingen. 3 of 5

4 Analysearbejdet omkring app en bliver faktureret på timebasis. Betalingen for analysearbejdet indregnes i det endelige tilbud. Accept af tilbud og projekt Når I modtager tilbuddet omkring udviklingen af app en, vil der være en deadline for accept af tilbuddet. Hvis I accepterer tilbuddet, faktureres I som udgangspunkt 50% af den estimerede pris ved start. Hvis tilbuddet ikke accepteres, vil I blive faktureret for den første del af processen (analysearbejdet) jvf. ovenstående. Kontrakt I vil sammen med ovenstående tilbud få tilsendt en kontrakt på udviklingsarbejdet. I har mulighed for at vælge mellem to former for kontrakt: Funktionskontrakt Med en funktionskontrakt vil I få et fast og styret udviklingsforløb. Som indledning vil vi afholde idéudviklingsmøde, hvor vi fastsætter rammer for og indhold i app en. Derefter går Huge Lawn - Miracle Apps i gang med at designe, kode og teste app en. I vil få app en til test og korrektur, og når alt er som aftalt i kontrakten, og I kan godkende app en, sender vi den til review i App Store eller uploader direkte til Google Play (tidligere kendt som Android Market). En funktionskontrakt er tilrettet efter en fra starten fastsat pris og indeholder som udgangspunkt kun en milepæl, hvor I har mulighed for at komme med rettelser og kommentarer til app en. I har mulighed for undervejs i processen at indsætte yderligere milepæle mod en merpris. Dynamisk kontrakt I modsætning til en funktionskontrakt vil I med en dynamisk kontrakt have større mulighed for at tage del i processen og dermed også have mulighed for undervejs, som udviklingen skrider frem, at komme med nye ideer til indhold i app en til sikring af det bedst mulige slutprodukt for jer. Med en dynamisk kontrakt vil I med andre ord i større grad have mulighed for at være en del af udviklingsprocessen. Processen vil overordnet indeholde følgende: Produkt Backlog: Sammen laver vi indledende en prioriteret liste over de udviklingsdele, som app en skal indeholde. Alle ideer til udvikling og indhold vil blive registeret i en prioriteret produkt backlog. Planlægningsmøde hver uge: Hver uge holder vi med jer et enten online eller fysisk møde, hvor vi sammen planlægger den kommende uges prioriterede udviklingsopgaver. Den ugentlige periode hedder i Scrum terminologi en Sprint. Det første møde af denne slags bruges på at oparbejde og definere den ovennævnte produkt backlog. Planlægningsmøderne indeholder følgende dele: Godkendelse af ugens udvikling: En gang ugentlig vil I modtage en demo af den sidste uges udvikling til godkendelse. I har på mødet mulighed for at komme med rettelser og nye ideer Estimering ugentlig: Ud fra produkt backloggen laver udviklingsteamet hos Huge Lawn - Miracle Apps en estimering af den kommende uges opgaver og sprint Sprint backlog: De højest prioriterede opgaver fra produkt backloggen, som teamet comitter sig til, at de kan nå at udvikle i denne uges sprint, kommer i ugens sprint backlog. Hvis ugens prioriterede udviklingsopgaver er overstået før tid, vil vores udviklere tage hul på den højest prioriterede opgave i produkt backloggen, der er tid til inden sprintens afslutning. På denne måde vil udviklingen af jeres app aldrig være stillestående, og der vil altid blive arbejdet på de højest prioriterede opgaver først. Intern daglig opsamling: Dagligt mødes udviklingsteamet hos Huge Lawn - Miracle Apps kort for at lave status på opgaverne og sammen løse eventuelle udfordringer App-store submit: Når app en er færdigudviklet i overensstemmelse med jer, sender vi den til godkendelse i app-store. I den forbindelse vil vi fra jer have brug for forskellige oplysninger. I kan læse mere om kravene for app-store submit her: link til hjemmeside-page hvor liste med eksempler og beskrivelser ligger En dynamisk kontrakt er et godt værktøj i forhold til at sikre jer, at I ender med præcis den app, som I og jeres brugere har brug for. Fordele og forskelle på kontraktformerne Dynamisk kontrakt: I betaler præcis for den tid Huge Lawn - Miracle Apps bruger på udvikling af app en. Det vil sige, at i denne kontraktform fjernes risikoen for merbetaling for ekstra tid, da betalingen slutter ved app ens færdiggørelse. I den dynamiske proces arbejdes der altid på det vigtigste jvf. ovenstående. Det vil sige, at efter afslutning af hvert sprint kan I vælge at sige, at app en er færdig og ønske den udgivet. Hvis I vælger at afrunde projektet med app en efter 3 sprint, vil de 3 sprint være brugt på de vigtigste features, og I vil dermed være sikret dem som indhold i app en. I har i denne kontraktform mulighed for uden merbetaling løbende at ændre produkt backloggen, som udviklingen skrider frem. Det vil sige, at der altid er plads til nye ideer til udvikling undervejs i processen. Funktionskontrakt: Prisen for projektet aftales forud. I er sikret en fast pris på app en, men ved denne kontraktform er der derved også risiko for, at I betaler for mere tid end den, vi faktisk kommer til at bruge på udviklingen. Ønsker I at ændre kravene til app ens funktioner og muligheder undervejs i udviklingen, vil det altid medføre en merpris. App-launch 4 of 5

5 For at få en applikation på App Storen skal den godkendes af Apple. Der er ingen mulighed for at få forhåndsgodkendelse fra Apple, og godkendelsen (eller besked om afvisning) kan tage fra 4 dage til 4-5 uger! I gennemsnit bliver 98% af nye indsendte apps og indsendte opdateringer vurderet i løbet af 6-8 dage. Det er muligt at tilbageholde en godkendt applikation fra App Store efter Apples godkendelse, så launch kan koordineres med markedsføringskampagner. Godkendelse af efterfølgende versioner af applikationer følger samme proces som første version. Der er ingen review process for Google Play apps. De kan offentliggøres, så snart de er uploadet. Kvalitetssikring Kvaliteten af vores apps sikrer vi på en række måder: Dygtige medarbejdere, der konstant udvikler sig og hinanden ved at reviewe hinandens kode, stille udfordrende spørgsmål og påpege forbedringsmuligheder. Dygtige softwaretestere der uafhængigt af vores udviklere tester vores apps på relevante devices. Agil scrum-baseret proces der sikrer fokus på den højeste værdi for kunden. Sporbarhed: alle kodeændringer linkes til brugerkrav eller fejlrapporter og omvendt. Herved kan vi altid finde ud af, hvordan en fejl er løst, og hvorfor en kodeændring er lavet. Manuelle eller automatiske tests på relevante devices, der nemt og hurtigt kan verificere, om kodeændringer har løst kendte problemer, og sikre, at nye bliver fundet hurtigst muligt. Continuous Integration system med mulighed for automatisk eksekvering af unit og system tests, samt direkte adgang for kunder til tidlige versioner af apps. Automatisk opsamling af app crashes, til analyse og fejlretning. Effektiv brug af checklister med områder af tests og specifikke test cases, der tidligere har voldt os eller andre problemer. Fuld synlighed: Kunder kan få direkte adgang til at følge med i alle vores systemer. 5 of 5