Udviklingsmetode

Tags:    projektstyring

<< < 12 > >>
Hej udviklere!

Jeg er lige begyndt på et nyt projekt som skal køre frem mod jul. Projektets formål er at afklare hvor vidt en løsningsmodel holder i den virkelige verden, og min fornemste opgave er som programmør at udvikle proof of concept / prototype.

Jeg er vant til at udvikle i teams, og familiær med metoder som SCRUM, XP, UP, og andre agile metoder. Men fælles for dem alle er at de henvender sig til teams - selvfølgelig fordi udvikling fungerer bedst i teams. Men jeg er altså alene om dette projekt, og skal derfor formå at have en iterativ tilgang til udviklingen, reaktiv i forhold til ændringer undervejs.

Af ovenstående grunde hælder jeg mest til at arbejde med XP(Extreme Programming), hvor productowner kan komme med ændringer anytime, og jeg ikke skal dokumentere andet end kommentarer i koden. Men XPs hovedpunkt er pairprogramming hvilke bliver en smule svært.

Derfor vil jeg virkelig gerne høre om jeres erfaring med systemudvikling som 1-man teams!

På forhånd tak!









Indlæg senest redigeret d. 22.10.2014 22:29 af Bruger #16325
Martin bach - Jeg er ikke interesseret i at diskutere Scrum. Det er desuden ikke jeg, men skaberne af Scrum som siger dig imod, men lad det nu ligge. Jeg ville gerne høre konkrete erfaringer fra et konkret projekt hvor man har måtte arbejde alene efter en kendt konkret procesmodel. Hvad du har lært og ikke lært på et srum kursus og hvilke dele af det du så vælger at implementere, er jeg ikke interesseret i :)




Indlæg senest redigeret d. 22.10.2014 15:12 af Bruger #17368
Mikkel -
Jeg tror en del her har erfaringer med SCRUM og andre agile metoder.
Jeg tror en hel del her har erfaringer med at være alene om et projekt.

Jeg tror IKKE at ret mange her har erfaringer med at köre efter en formelt agil metode i et alene projekt - nok simpelhen fordi bare det faktum at man er alene gör jo at man er super agil, der er et meget lille gruppe overhead (intet), man er tæt paa ledelse, udförelse og andre roller i projektet fordi man er alle paa en gang ... saa mange vil tænke "hvorfor smide det overhead paa projektet med en metode til en gruppe som bl.a. pröver at fjerne stivhed og overhead ved udvikling i grupper ... naar der ingen gruppe er?"

At du maaske rent faktisk har en god grund til at göre alt dette - f.eks. fordi du gerne vil dokumentere processen og forberede til at gruppen bliver bemannet med mange engang, det skal jeg ikke modsige dig i fornuften af.

Forvent blot ikke at ret mange andre har erfaring i lige netop den övelse - specielt da det virker meget som et gaa over aaen for at faa vand.





@Michael Larsen - det er ganske fint hvis man er en lille startup eller des lige. Men når du arbejder i kocernvirksomhed er der krav og rammer som skal overholdes og politik med i spillet. Du får ikke bare en mørk kælder og en pc og nøglen smides væk. Der kræves visning af fremgang og inddragelse af brugere.

Jeg er ganske udemærket klar over hvordan Scrum/XP/UP/(vandfald) fungerer, men jeg håbede på nogle som havde erfaringer med dette, og ikke belæring om hvad en procesmodel er....


Men så er du ikke længere productowner? :)

At følge en bestemt arbejdsmetode ender med at du administrerer dig ihjel. Dit mål er at have en plan, som du kan følge og fremvise efter.



Jeg har for nylig afsluttet et næsten 10 måneder langt udviklingsprojekt, hvor jeg var eneste mand om opgaven. Så jeg kan sagtens følge dig i, at en form for metode eller system er vigtig.

Jeg har tidligere arbejdet med forskellige metoder, og SCRUM er nok min favorit. Men jeg valgte ikke at følge en bestemt metode eller proces i mit eget projekt. Jeg ville ikke have for meget tidsmæssigt overhead pga. metoder, som alligevel ikke rigtigt passede på et enkeltmandsprojekt.

Jeg havde istedet lavet en specifikation af hvad der skulle laves, så detaljeret som muligt, og defineret nogle milestones.

Hver mandag morgen havde jeg så et møde med mig selv, hvor jeg besluttede hvad der skulle laves denne uge. Hver morgen brugte jeg iøvrigt lige 5 min. på at se på om jeg stadig var på sporet. Alle bugs blev registreret i en To Do app, da jeg ikke nødvendigvis mener, at det er fordelagtigt at løse bugs efterhånden som man finder dem.

Som ene mand kan bugfixes nemt ødelægge produktiviteten. Jeg vil hellere kode løs og få en feature færdig, eller nå en milestone, og så derefter rykke en dag eller to ud på at fixe bugs som jeg må have opsamlet løbende.

Det virkede fint for mig, og jeg formåede at blive på sporet, selvom der er mange fristelser løbende for at tage en anden kurs. Jeg er stor tilhænger af ikke at gøre ting mere komplicerede end højest nødvendigt.



Jeg arbejder altid alene (og har gjort det i 10 år i samme firma), og min metode er at tænke lidt over problemet, finde på en løsning på abstrakt plan og så ellers kode skidtet...processer er for teams.



Tak Carsten Jacobsen, det var lige præcis den type indlæg jeg søgte efter.

Antaget at du skulle orientere andre(ledere), og brugere, hvordan sørgede du for kommunikationen til stakeholders, og inddragelse af dem? Brugte du en form for retrospective og demos og i givet fald hvor meget/lidt?

@Jonatan Hertel, planen er at forsætte projektet da jeg mener min case er stærk. Derfor synes jeg det mest optimale er at starte projektet efter en procesmodel - så man ikke en gang til skal bruge tid på kickoff - selvfølgelig vil der være noget ensretning af teamet osv. som ikke kan undgås. Og jeg forventer skam ikke at alle har oplevet dette, men det var dog en forhåbning, som Carsten påviste var begrundet.



Jeg sidder i en gruppe med 4 produkter og jeg er pt. eneste udvikler på et af produkterne. De tre andre produkter har 10-15 udviklere og kører derud af med Scrum, sprintmøder og alt andet som følger med.

Jeg arbejder ud fra et regneark med opgaver og nogle konsulenter + chefer prioriterer opgaverne som skal udvikles. Jeg ville sgu gerne være en del af Scrum-gruppen, da jeg ikke synes min måde at arbejde på er optimalt for processen/produktet/mig selv. Overvej evt. bare at bruge kanbanize.com til at oprette alle dine tasks og der igennem have lidt overblik.



Jeg er stødt på dette blogindlæg om personal scrum - eller individuel scrum. Det er spændende læsning, og måske kan andre få gavn er netop dette:

http://blog.jgpruitt.com/tag/personal-scrum/



<< < 12 > >>
t