Ken Schwabers guide till Scrum

Link: http://www.scrumalliance.org/resources

Hos ScrumAlliance kan den intresserade hitta en kort (12 sidor) introduktion till Scrum (på engelska). Den är läsvärd.

Glömde säga en sak… Jag har också skrivit en scrum-introduktion, fast på svenska. Den finns påhttp://www.systemvaruhuset.se/kunskapsbank/introduktion-till-scrum.aspx. Jag har också gjort en topp-10 lista som ni hittar påhttp://www.systemvaruhuset.se/kunskapsbank/scrum-topp-10.aspx.

Domain driven design, or no domain?

Link: http://domaindrivendesign.org/resources/what_is_ddd

Eric Evans har under de senaste 5 åren populariserat domänmodellering med sitt koncept – domain driven design. Som så många andra har han tagit angreppssätt som till stora delar är vedertagna, etablerade och beprövade, blandat ihop och döpt om dessa och sedan lanserat dem på nytt.

Fördelen med detta är att han lyckats skapa ett intresse för en enormt kraftfull kravteknik; informationsmodellering. En väl genomförd informationsmodellering ger nämligen otroligt tydliga strukturella krav på systemet och är dessutom ett väldigt bra underlag för design.

Det som stör mig lite är att man på svenska prompt måste kalla det för domänmodellering (domain modeling). Detta eftersom ordet domän inte säger något. Med risk för att visa min okunskap så tolkar jag ordet som att det betyder område. Några exempel;

  • problemdomänen = problemområdet
  • verksamhetsdomänen = verksamhetsområdet
  • systemdomänen = systemet och dess tillhörande områden
  • kunskapsdomänen = ung. det jag känner till om saken

Om man då pratar om en domänmodell, vad menar man egentligen? En modell som inte beskriver ett område finns väl inte. Eller gör det?

Mitt råd är att istället för domän prata om vad ni modellerar, datamodeller, informationsmodeller, begreppsmodeller, databasmodeller, verksamhetsmodeller, systemmodeller m.m. Att modellen tillhör en domän är så självklart att det förvirrar mer än förklarar om man säger det.

Missförstå mig rätt bara, jag är en stor fan av domain driven design, rätt applicerat hjälper det oss att bygga bättre, mer robusta och förändringsbara system.

Agil systemutveckling ökar effektiviteten

Kanske inte något ovanligt uttalande idag… Scott Ambler har dock gjort en intressant enkät till ca 650 personer med följande resultat.

1. Nästan 80% av agila projekt lyckas
2. Dryft 80% har iterationslängder mellan 1 och 4 veckor.
3. Drygt 80% av projekten upplevde lite eller mycket högre effektivitet
4. Nästan 80% av projekten levererade system av lite eller mycket högre kvalitet.
5. Drygt 70% av projekten kostade lite eller mycket mindre.
6. Nästan 80% av projekten resulterade i lite eller mycket mer nöjda verksamhetsintressenter

Läs mer på http://www.ambysoft.com/surveys/agileFebruary2008.html

Alla borde vara metod-nissar (och framförallt alla projektledare)!

Link: http://alistair.cockburn.us/Everyone+should+be+a+methodologist

Alistair cockburn definierar en gång för alla vad en metod är på sin blog:

A methodology is the conventions the team agrees to follow.

Det kan inte sägas enklare. Det kan inte sägas tydligare. Som projektledare är man ansvarig för hur gruppen arbetar, alltså är man metodansvarig…

Redan de gamla Romarna…

Nu är vi på konferens i Rom! En otroligt faschinerande stad. Det känns som att det finns ett konstverk bakom varje hörn. I dag var vi på guidad visning av bl.a. Colloseum och Forum Romanum och jag måste säga att de var duktiga på kravställning i antikens Rom!

Colloseum kunde fyllas resp. tömmas på folk på 15 minuter! Det fanns avlopp, serveringar, sjukvårdsplatser m.m. som var dimensionerade efter antalet möjliga gäster. När man går runt och tittar så känns det som att de tänkt på allt.

Varför kan vi inte kravställa och bygga våra IT-system idag lika bra som Romarna kunde kravställa och bygga sina arenor? Ett svar är säkert att Colloseum inte var något helt nytt i sitt slag, utan man tog bara något befintligt och gjorde det större. Tyvärr hjälper den förklaringen inte i jämförelsen med IT-systemen. Många projekt går faktiskt ut på att man ska ta ett befintligt system och skala upp det, men ändå brister det i kravställning och genomförande. Så vad beror det då på?

Ingen aning, men i mina mörkaste stunder tror jag att man lägger för lite tid på att fundera igenom vad man vill åstadkomma och hur man vill använda systemet. Dessutom kanske man ibland lyssnar för mycket på användarna och misslyckas med att skapa incitament för projektgruppen att faktiskt lyckas med uppgiften. Tittar man på Romarnas projekt så tror jag att man var tydlig med arenans syfte till arkitekten, jag tror inte att man frågade särskilt många gladiatorer och/eller besökare vad de ville ha och jag misstänker att arkitekten riskerade livhanken om han inte levererade…

Inget av ovanstående är väl något vi kan införa rakt av i våra projekt, men kanske kan vi hitta nya/bättre sätt

  1. att tydliggöra projektets syfte på,
  2. att lyssna på användarna tillräckligt mycket men inte för mycket,
  3. att motivera projektgruppen på .

än vad vi normalt gör

Det tror jag är ett framgångsrecept så gott som något…

Scrum = 2000-talets RUP?

Alla områden har sina religioner och alla religioner har sina fanatiker. Kanske hade Marx rätt i det att utvecklingen drivs genom ”tes, antites och synteser”. I IT-branschen trodde vi en gång i tiden på vattenfallsmodellen. Den växte fram som en antites till ostrukturerat arbete och kaotiska krav. RUP blev syntesen av detta. Nu har RUP blivit en tes och XP och Scrum växt fram som antiteser till RUP. Frågan är vad nästa syntes blir? Vad kommer att komma när scrum blivit tes, hur ser då antitesen ut?

Personligen tror jag stenhårt på agil systemutveckling, även om jag kanske inte är någon fanatiker. Jag anser till exempel också att RUP har otroligt mycket bra att bidra med.

Min poäng är i alla fall att vi alla behöver något att klaga på, och av naturliga skäl så är det enklast att klaga på den/det som dominerar. I dag är det RUP, i morgon kanske det är scrum.