Hvis din plan var at lave en komplet project beskrivelse og saa sende den viderer til en udvikler, er min eneste kommentar. LAD VAERE! Den form for udvikling fungerer kun hvis alle deltagerne har mange aars erfaring med udvikling af lignende systemer. (Denne form for udvikling er kendt som waterfall antipattern*). Det er en god ide at have en overordnet beskrivelse af hvilke dele projectet bestaar af, og hvilke features dissse dele skal have. Saa lad mig gaette paa at dit project nok skal have "Bruger system","Forum","Foto galleri","Facebook integration",... For hver del skal du saa beskrive alle vaesentlige features. For dit "Foto galleri" kunne dette vaere noget med: "Brugeren skal kunne uploade billeder" "Mulighed for at kategorisere billeder efter deres type" "Mulighed for at andre brugerer kan stemme paa dine billeder" "Sikkert ogsaa mere" Det vigtige i denne beskrivelse er at du kun beskriver hvad du oensker, ikke hvordan det helt specifikt skal laves. Faktisk skal din beskrivelse helst laves saadan at man kunne lave den ved at hyre 1000 kineserer og uden at bruge computerer :} Naar du saa har denne meget overordnede beskrivelse af dit project er det tid til at bruge denne beskrivelse til at finde en udvikler/firma som er interesseret i at udvikle din loesnnig(Saa ok, det bliver nok lidt mere end 5 linier som jeg skrev ovenfor :} Naar du saa har fundet din udvikler, holder i moeder hvor du helt konkret beskriver hvordan du havde taenkt dig at dine features skal realiseres. Din udvikler kommer saa sikkert ogsaa med noget input(Og ting du ikke har taenkt paa, og der er sikkert mange). Dette skulle gerne give alle deltagerer i projectet en forstaaelse af hvad der ca skal laves, og saa begynder i at lave et grafisk design, og implementere det. Det vil ofte vaere en god ide at starte med en central del af systemet. Du skal ogsaa meget overveje din egen rolle i projectet. Har du taenkt dig at du skal vaere med til at skrive koden? Note 1: For et se eksempler paa hvordan du laver en udvidet funktionel description, proev at se http://www.joelonsoftware.com/articles/fog0000000035.html hvor han gennemgaar hvad en functional specification kan vaere og hvordan man laver den. ps: Det alternativ til php/mysql jeg havde taenkt mig, var Java+PostgreSQL da jeg personligt har daarlige erfaringer med mysqls query optimizer. Men da jeg ikke har den store tid til at udvikle projectet betyder det ikke noget :} *Ikke mange ved det, men waterfall udvkilingsmetoden blev faktisk lavet som en beskrivelse af hvordan man ikke skulle udvikle software. |
Google SCRUM eller Unified Process er de mest brugte
Afhængig af størrelsen -
MEGA projekter brug Unified Process. Der er argumenter for og imod, men sæt dig ind i metoden, så giver tingene lidt sig selv. Nogle virksomheder har det som krav, at udviklingsmetoden er udviklet under UP eller (R)UP - hvor R er en variation af metoden, som man selv beskriver, men som man samtidig forpligter sig til at overholde.
Scrum kan bruges til alt, men de gange hvor jeg har udviklet under den, har det været projekter af en overskuelig størrelse. - Jeg er stor fan af SCRUM
Scrum - er i sin enkelthed 3 trin.
Trin 1) Opdel opgaven i problemstillinger som kan prioriteres - start med den vigtigste
Trin 2) Knus problemet og implementer løsningen (et scrum) - Et scrum er normalt en bestemt tid 1-4 uger
Trin 3) Aflevering til kunden - Når et scrum er overstået, skal programmet "virke".
Scrum kan sammenlignes med dagligdagen. Du får en række opgaver fra konen om morgnen - du prioriterer lyn hurtigt rækkefølgen. I løbet af dagen får du så handlet, støvsuget osv. og hver gang siger du til konen at "jeg er færdig", som udløser et kys og du er klar til at løse næste opgave.
Scrum kan bruges på forskellig måde til forskellige opgaver. Der er i virkeligheden ikke så meget forskel på om det er et hardware projekt, software projekt eller at tjene kys hos konen. Uden at kunne bekræfte det, så har jeg hørt rygter om at SCRUM er den mest udbredte agile udviklings-metode.
Det fede ved SCRUM (og derfor jeg er fan) er at det er forholdsvis let at lave tids-estimater over projektet som helhed, da man bare skal gange antallet af opgaver med den tid som er afsat til et SCRUM.
En anden god ide for dig kunne være at lave et gantt-kort, som beskriver sammenhængene og afhængigheder og lade dette være indput til prioriteringen af opgaverne.
Man kan godt have et varelager og en online betalingsservice, men hvis webshoppen mangler, så er det ikke meget ved. Prioriteringen skulle derfor gerne hede - 0)Vi har et varelager 1) laver webshoppen, 2) vi skaffer en bankkonto 3) vi bestiller betalingsservice 4)vi markedsføre vores produkter
Håber det kan bruges
Dennis