Dba.dk har fået en blog....

Endelig er det sket, at vi er gået i luften med vores egen blog på dba.dk. På bloggen kan du både læse om nye features inden de lanceres, spændende statistik, inside-viden og om jobmuligheder.

Tag et kig på: http://blog.dba.dk og husk at tilmelde rss feedet til din foretrukne rss-reader (http://blog.dba.dk/atom.xml).

Downfall of Agile Hitler

Den her er lidt på kanten, men alligevel er det svært at lade være med at trække på smilebåndet.

http://www.youtube.com/watch?v=l1wKO3rID9g&eurl=http://www.agile-software-development.com/2009/05/downfall-of-agile-hitler.html&feature=player_embedded

Retrospective Anti-patterns

En essentiel del af Scrum er retrospectivet. Det er her man finder frem til, hvad der kører, og hvad der skal forbedres i forhold til proces, teambuilding, programmering osv.

Mødet er måske det sværeste af de møder, man støder på i Scrum. Det kan meget let ende med at være "formålsløs" stirren tilbage på alt det som ikke duede og så bliver det sjældent en konstruktiv affære.

Jeg stødte på en kort og præcis artikel omkring nogle af de ting man helst ikke skal gøre og hvordan man undgår dem:
http://radio.javaranch.com/ilja/2009/03/25/1237998972110.html

QA Manager med Agilt fokus søges til Den Blå Avis!

Er du knaldhård til tests af high performance web sites både hvad angår automatiseringstests og testing knyttet til vores scrum projekter. Er du den der kan sikre et rent site, hvor "sundheden" løbende kan monitoreres? Har du arbejdet med testing i en del år, har du ledelseserfaring og kunne du nu tænke dig at prøve at bygge en QA afdeling op fra bunden af? 

Så læs lige her: http://www.dba.dk/info/qaman.asp

Fantastisk citat...

Et vigtigt aspekt ved agil udvikling er at sikre en kodebase, der kører næsten uden bugs. Dette er selvfølgelig vigtigt (1)  for at kunne leve op til princippet om, at hver sprint/iteration leverer release-bar funktionalitet og (2) for at undgå en death march periode inden noget skal releases. Jeg læste fornyligt en artikel fra Mike Cohn omkring naturen af nye funktioner i et softwareprojekt (artiklen stiller et interessant spørgsmål, så læs den...) og her stødte jeg på følgende citat:

Take one step at a time up the slippery mountainside, and make absolutely sure that each hoof is on solid ground before you take the next step.

Tænk lige over det. Ville du nogen sinde bestige et bjerg uden at sikre hvert skridt? Overfør så det til dit daglige arbejde med softwareudvikling... Selvfølgelig kan man altid invende, at softwareudvikling ikke er en disciplin man dør af, hvis man træder forkert, men så igen, hvis man ser bjergbestigning som en disciplin hvis målsætnings success er betinget af, at man ikke træder ved siden af (uanset om man dør eller ej), så er vi jo tilbage til at muligheden for at nå trygt i mål afhænger af kvaliteten af ens arbejde undervejs.

Krav - hvordan og hvem gør hvad...

Vi har brugt en del tid på at optimere kravsprocessen her i huset, og vi blev i den forbindelse klar over, at vi med Scrum og fokus på roller og deres funktion måske var endt i en grøft, hvor forventninger til Product Owneren var for store. Vores PO skrev krav og overleverede disse til teamet under Estimeringsmødet op til en sprint. Dette er problematisk, da kravene ofte ikke var modne nok. Det er som citatet nedenfor også pointerer svært for en person alene at stå for dette arbejde.

"It is not necessarily the remit of one person, like the Business Analyst in more traditional projects, to gather the requirements independently and write them all down; it’s a joint activity of the team that allows everyone to contribute, challenge and understand what’s needed. And just as importantly, why."

Alle på teamet deltager i dette arbejde. Det er en kollaborativ proces. Man kunne spørge sig selv: hvorfor? Er det ikke spild og skal vi ikke lige netop fokusere på at eliminere spild i processen??

Jo lige netop! Ved at gøre det til en kollaborativ proces så sikrer man også den bedste vidensdeling og at udviklerne har et "godt" forhold til de krav, som står i backloggen, og som skal estimeres på et tidspunkt. Vi anvender user stories, som jo pr. natur er tænkt som værende et kommunikationsredskab, og derfor giver det endnu mere mening at samarbejde om modningen af disse, så hver user story fungerer som en effektiv placeholder for kommunikation. Ved at gøre kravsmodning til en kollaborativ proces tidligt i projektforløbet kan man opnå følgende gode fordele:

• Øget kommunikation imellem PO og team
• Bedre forståelse af user stories og deres boundaries
• Hurtigere og mere præcise estimeringssessioner (sprint planning 1)
• Bedre og mere præcise velocity-forudsigelser
• Bedre krav 
• En velfungerende backlog, som teamet stoler på
• En PO som teamet stoler på
• etc.

Hvilke erfaringer har i gjort jer på området? Hvordan faciliterer i kravsmodning?

Mike Cohn om User stories og estimering..

To videoer som virkelig er værd at bruge lidt tid på...

Del 1:



Del 2:

Brænder du for webudvikling i et agilt miljø?

Vi søger pt. en webudvikler som føler sig naturligt hjemme i objektorienteret design og udvikling, og som behersker både ASP.NET og C#. Er det dig? Eller kender du en? Læs vores stillingsopslag her:

http://www.it-jobbank.dk/ShowProfile.aspx?ProfileId=50177277

Derfor holder budgetterne ikke, når projekter skal realiseres

"Mennesket ser for lyst på fremtiden – bevidst og ubevist - og derfor holder budgetterne ikke, når store byggeprojekter skal realiseres." Oprindelig artikel fra Ingeniøren af Bjørn Kock Sørensen

Jeg faldt over dette citat i denne artikel og selv om den går på byggeprojekter, og uden at have nærmere på Bent Flyvbjergs arbejde, eller på Daniel Kahnemans for den sags skyld, mener stadig jeg det holder på de projekter jeg har været tæt på.

Skal man budgettere ud fra hvad man ud fra hvad man ved, det vil sige ikke se spøgelser?
Skal man være pessimistisk?
Skal man gøre det nedefra-op eller oppefra-ned?
Eller hvad med Planning Game?

---

Kender du Bent Flyvbjerg og Daniel Kahnemans arbejde? Er du enig med deres perspektiv?

Hvordan estimere i arbejdet ved jer?

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.