SCRUM Værktøjer

Tjah, efter at have brugt noget tid på OnTime fra Axosoft, er der to ting om det produkt som jeg gerne vil dele med jer:

1) Der er et ret fedt produkt, der er ret modent

2) Det understøtter ikke SCRUM, og tro ikke på sælgerne

Så hvis du står og skal kørt et nyt system ind, så vælg et andet en OnTime 8.1

Se også dette indlæg.

Agile tool - task management...

Har gennem de sidste uger tænkt meget over at anskaffe et værktøj til styring af opgaver i organisationen, lige fra projekter, designopgaver, helpdesksager og til ideoplæg. Det må gerne understøtte vores Scrum-proces og dermed gerne have mulighed for både at kunne håndtere product backlogs og sprint backlogs. Jeg har kigget på flere forskellige, men savner egentlig råd fra folk med praktisk erfaring. Vi har tidligere brugt MS TFS, som jeg på ingen måde ønsker at bruge. Alt for datacentrisk og simpelt - eks. kunne man ikke på nogen nem måde få overblik over stories og de underliggende subtasks til dem.

I øjeblikket kredser mine tanker meget omkring to vidt forskellige systemer:

Mingle - et fuldt udbygget agile management tool med subversion integration

JIRA - et generisk issuetracking system.

Begge har rig mulighed for opsætning af felter, lister og flows. Har du praktisk erfaring med et af disse? Kan du give nogle gode råd? Eller har du erfaring med andre, som du ønsker at anbefale, så skriv gerne en kommentar.

Årsags/Effekt diagram

Et af de værktøjer jeg, engang imellem, finder frem fra min værktøjskasse er et "årsags-effektdiagram".

Se en beskrivelse her: http://en.wikipedia.org/wiki/Ishikawa_diagram

Det er et super værktøj til at brainstorme over et problem på - forleden brugte jeg og en anden chef kollega på dba.dk værktøjet til at identificere en række årsager til store udfordringer vi har lige nu.

Den store udfordring med værktøjet er at det giver lidt et sortsyn på situationen - du får en rigtig god liste over årsager til problemer, og viser typisk hvor komplekt situationen er.

Har du nogle erfaringer med dette eller andre værktøjer?

------

Jeg har ikke selv brugt det, men her har du et online tool:

http://www.pptmagic.com/downloads/ProjectMgm/Fishbone.swf

Continuous Integration

Bøvler I også med at få lavet et fornuftigt CI setup? Hvordan kommer man igang, hvor er faldgruberne, hvad er de gode ting at gøre? Der er mange spørgsmål i den forbindelse. Her på Den Blå Avis har vi brugt det sidste år på at få fornuftige miljøer op at stå, og det er ikke altid helt enkelt.

Martin Fowler har skrevet en god artikel, man kan starte ud med, hvis man ønsker at hjælpe til med den proces (husk dog at det er udviklerne selv som skal drive det, da de ved bedst...). Jeg synes selv den giver et godt overblik over de problemstillinger man vil støde på i, og ja jeg synes det er sundt for en projektleder eller Scrum Master at have en holdning til og forståelse for den slags.

God linksamling

Jeg fandt denne linksamling med artikler, ressourcer, websites og meget andet vedrørende agile udvikling og ledelser. Smider den i vores liste af links også. God læsning!

Domain modeling with color

Et stærkt værktøj, når det kommer til domænemodellering, er Peter Coad's modeling with color. Hans pragmatiske tilgang til domænemodellering er baseret på ideen om, at domænet består af en række (tekniske) arketyper: party, place, thing og moment-interval. Hver af disse har deres egen farve, og hele domænemodellen farvekodes efter dens indholds arketypiske værdi. Dette skaber en super godt overblik, men endnu vigtigere også et forum, hvori domænet kan diskuteres, analyseres og tilrettes... og ikke kun af teknikere, men også forretningsfolk. Hvis du vil læse mere om modeling with color, så læs pdf'en jeg linker til ovenfor. Denne post handler nemlig om, hvordan man undgår at ende i "farvediskussioner", fordi man ikke forstår værktøjet til fulde. Jeg læste en kort artikel om det her til morgen, og jeg synes den er meget sigende for de problemer man kan støde på med modeling with color, og samtidig god som inspiration for, hvordan man overkommer disse problemer. Det vigtigste i artiklen er argumentet om, at hvis man ender i farvediskussioner, så bør man erkende at diskussionen ikke er forkert, men oftest symptomatisk for noget andet... noget der mangler, eller ikke er defineret præcist nok...