mboost-dp1
Agile projektstyrings-værktøj
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Hejsa, jeg har fået et spørgsmål på den interne mail, som jeg er sikker på også interesserer andre. Jeg tillader mig derfor lige at poste det:
-----------------------------------------
Emilm skrev d. 26-10-2010:
---
Hej faldt over dit indlæg på
http://newz.dk/forum/programmering/agile-projektst...
Er selv ved at udvikle en gratis projektstyringsløsning, det er dog ikke for at gøre reklame for den, men jeg ville høre om du kunne sige kort, hvilke ting der mangler ved de fleste, der har en som du siger svaghed med at man skal taste ting ind i databasen? :)
-----------------------------------------
Emilm skrev d. 26-10-2010:
---
Hej faldt over dit indlæg på
http://newz.dk/forum/programmering/agile-projektst...
Er selv ved at udvikle en gratis projektstyringsløsning, det er dog ikke for at gøre reklame for den, men jeg ville høre om du kunne sige kort, hvilke ting der mangler ved de fleste, der har en som du siger svaghed med at man skal taste ting ind i databasen? :)
Hvis du har et test-site, så kommer jeg gerne med løbende kommentarer. Men ellers så får du lige et resumé her:
Ofte sete svagheder:
1. Dato-fiksering.
Mange projektstyringsværktøjer er tankeløst henvendt til "Dato-projekter". Altså opgaver der starter på én dato, slutter på en anden og fylder min. et par dage. I disse dage kan der derefter ikke laves andre opgaver samtidigt. Dette koncept er kun brugbart i store virksomheder og allerbedst er det, hvis de driver deres projekter efter SPU-lignende modeller.
Mange små og mellemstore virksomheder og R&D-afdelinger kører derimod med et opgave-system, der lyder som følger: "Opgave A skal laves og påbegyndes så hurtigt som muligt. Det afsluttes når kravspecifikationen er opfyldt. Opgave B som der ikke er en fuldtidsopgave, har dog større prioritet end Opgave A og skal derfor laves samtidigt."
2. Opgave-fleksibilitet.
Lidt som en forlængelse af 1, så har mange systemer meget svært ved at håndtere ændringer i deres skemalægning (læs: det er besværligt!). Rigtig mange virksomheder (små og mellemstore) har dog en tendens til at udføre investerings-projekter, som lav-prioritet, som der afbrydes ved indtræf af forudbetalte kunde-projekter. (Konsulent-virksomheder ofte.) (Eller det også være, gud forbyde det, Ad Hoc-opgaver. HRRRR)
3. Estimerede timer på kalender.
Ofte bliver projekter defineret i estimeret timeantal i stedet for de regide datoer. Det er der også mange systemer der understøtter, men jeg har endnu ikke set et der også kan finde ud af at placere disse "estimeret time"-opgaver på kalenderen. Blot fordi at man arbejder i timer og ikke i datoer, så betyder det ikke, at man ikke er interesseret i hvornår noget er færdigt.
4. Default værdier.
Mange projektstyringsværktøjer kræver at man indtaster en stor bunke data, når man opretter et projekt. Dette fungerer fint hvis man har dedikerede folk, der ikke laver andet end at oprette projekter. Eller hvis man ikke opretter projekter så tit. I agile miljøer derimod, er gruppe-lederen derimod ikke dedikeret projekt-leder og der oprettes ofte mange (opgaver), meget tit. Oprettelse af opgaverne bliver derfor hurtigt til en byrde i stedet for en hjælp. Som jeg ser det, så er en oprettet (registret) opgave fyldt med default-værdier, bedre end ingen (registreret) opgave.
5. GUI og look.
Der er rigtig mange (især gratis) projektstyringsværktøjer, som der ligner noget der burde været kommet i toilettet og som der har brugervenlighed på højde med den DOS-basede Wordperfect. Når man skal bruge et program hver dag, som der ikke direkte har noget at gøre med ens arbejdsfunktion, så er det vigtigt at det er behageligt at bruge og at kigge på.
6. Localization.
Dette er mest relevant for udenlandske værktøjer, men projektstyringsværktøjer skal også bruges af n00bs. Det er derfor vigtigt at interfacet også er på eg. dansk.
Ofte sete svagheder:
1. Dato-fiksering.
Mange projektstyringsværktøjer er tankeløst henvendt til "Dato-projekter". Altså opgaver der starter på én dato, slutter på en anden og fylder min. et par dage. I disse dage kan der derefter ikke laves andre opgaver samtidigt. Dette koncept er kun brugbart i store virksomheder og allerbedst er det, hvis de driver deres projekter efter SPU-lignende modeller.
Mange små og mellemstore virksomheder og R&D-afdelinger kører derimod med et opgave-system, der lyder som følger: "Opgave A skal laves og påbegyndes så hurtigt som muligt. Det afsluttes når kravspecifikationen er opfyldt. Opgave B som der ikke er en fuldtidsopgave, har dog større prioritet end Opgave A og skal derfor laves samtidigt."
2. Opgave-fleksibilitet.
Lidt som en forlængelse af 1, så har mange systemer meget svært ved at håndtere ændringer i deres skemalægning (læs: det er besværligt!). Rigtig mange virksomheder (små og mellemstore) har dog en tendens til at udføre investerings-projekter, som lav-prioritet, som der afbrydes ved indtræf af forudbetalte kunde-projekter. (Konsulent-virksomheder ofte.) (Eller det også være, gud forbyde det, Ad Hoc-opgaver. HRRRR)
3. Estimerede timer på kalender.
Ofte bliver projekter defineret i estimeret timeantal i stedet for de regide datoer. Det er der også mange systemer der understøtter, men jeg har endnu ikke set et der også kan finde ud af at placere disse "estimeret time"-opgaver på kalenderen. Blot fordi at man arbejder i timer og ikke i datoer, så betyder det ikke, at man ikke er interesseret i hvornår noget er færdigt.
4. Default værdier.
Mange projektstyringsværktøjer kræver at man indtaster en stor bunke data, når man opretter et projekt. Dette fungerer fint hvis man har dedikerede folk, der ikke laver andet end at oprette projekter. Eller hvis man ikke opretter projekter så tit. I agile miljøer derimod, er gruppe-lederen derimod ikke dedikeret projekt-leder og der oprettes ofte mange (opgaver), meget tit. Oprettelse af opgaverne bliver derfor hurtigt til en byrde i stedet for en hjælp. Som jeg ser det, så er en oprettet (registret) opgave fyldt med default-værdier, bedre end ingen (registreret) opgave.
5. GUI og look.
Der er rigtig mange (især gratis) projektstyringsværktøjer, som der ligner noget der burde været kommet i toilettet og som der har brugervenlighed på højde med den DOS-basede Wordperfect. Når man skal bruge et program hver dag, som der ikke direkte har noget at gøre med ens arbejdsfunktion, så er det vigtigt at det er behageligt at bruge og at kigge på.
6. Localization.
Dette er mest relevant for udenlandske værktøjer, men projektstyringsværktøjer skal også bruges af n00bs. Det er derfor vigtigt at interfacet også er på eg. dansk.
7. Agile
Hvis vi taler om et decideret Agile projekt-styringssystem. Eg. SCRUM, så kunne det være rart, hvis hele systemet var opbygget omkring de indholdte koncepter. Eks. til at understøtte og hjælpe med udførslen. Det kunne eks. være udtrykt i navngivning og data, således at hver projekt har en projekt-leder, en projekt-ejer, styre-gruppe, konceptet om Pigs and Chickens, hjælper til at lave de korte kravspecifikationer, uddeling af roller, oprettelse af iterationer, delmål, påmindelse om tests o.s.v.
Sådan et system har jeg heller ikke set endnu. (Jo, men kun i de store systemer, som der har så meget bloat, så det drukner.)
Hvis vi taler om et decideret Agile projekt-styringssystem. Eg. SCRUM, så kunne det være rart, hvis hele systemet var opbygget omkring de indholdte koncepter. Eks. til at understøtte og hjælpe med udførslen. Det kunne eks. være udtrykt i navngivning og data, således at hver projekt har en projekt-leder, en projekt-ejer, styre-gruppe, konceptet om Pigs and Chickens, hjælper til at lave de korte kravspecifikationer, uddeling af roller, oprettelse af iterationer, delmål, påmindelse om tests o.s.v.
Sådan et system har jeg heller ikke set endnu. (Jo, men kun i de store systemer, som der har så meget bloat, så det drukner.)
8. Arbejdsmæssig effekt.
Der er mange projektstyringværktøjer som der mere eller mindre bare er store dataindtastnings-programmer. Eg. skærmbilleder til en database. Der skal lidt mere til end det. Det skal være givtigt for den enkelte udvikler, at opdatere de registrerede opgaver. Det skal give effektive absolutte overblik for lederne. Det skal decideret komme med mere effektivitet, bedre tidsplan-forudseelse, nedbringelse af fejlrate ... whatever, for at det ikke bare er spild af tid.
Der er mange projektstyringværktøjer som der mere eller mindre bare er store dataindtastnings-programmer. Eg. skærmbilleder til en database. Der skal lidt mere til end det. Det skal være givtigt for den enkelte udvikler, at opdatere de registrerede opgaver. Det skal give effektive absolutte overblik for lederne. Det skal decideret komme med mere effektivitet, bedre tidsplan-forudseelse, nedbringelse af fejlrate ... whatever, for at det ikke bare er spild af tid.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.