Försäkringskassan borde skippa RUP

21 August 2008 | agile, försäkringkassan, programmering, scrum | Markus Härnvi | Inga kommentarer

Försäkringskassans nya datasystem har dragit över budget med 420 miljoner! Det är mycket pengar…

Låter som ett klassiskt exempel på ett IT-projekt som drabbats av byråkratisjukan. Ett annat tecken på det är att de använder RUP som utvecklingsmetod. RUP (Rational Unified Process) är som julafton för byråkrater.

I ett typiskt RUP-projekt sitter det en “arkitekt” - oftast en senior utvecklare som inte orkar hålla på att koda längre - i sin ensamhet (eller ännu värre - i en grupp med andra “arkitekter”). De gör fina diagram och dokument som behandlas på ändlösa möten med beställarna.

Beställarna saknar förmågan att förstå de fina diagrammen (varför i hela friden skall en avdelningschef på Föräkringskassan förstå UML?) och kan inte annat än nicka och säga ja och amen.

Sen, efter månader av möten och ritande, är designen “fryst”. “Fryst” är ett viktigt begrepp. Det tar ju evigheter att få igenom en ändring. Det finns speciella dokument och det skall hållas ändlösa möten om minsta ändringsförslag. Nu får utvecklarna några megabyte med PDF- och Visiodokument som de skall “implementera”. Arkitekten ser framför sig hur hans fina dokument görs om till källkod som går att kompilera och köra. Arkitekten tycker nog egentligen att det vore bättre om man kunde göra detta steg maskinellt. Utvecklarna tenderar att dra upp en massa problem med designen och det är ju inte skoj. All design fungerar ju nämligen alltid perfekt på papper. Verkligheten och koden är mest i vägen.

Om utvecklarna har vett och stake nog så kommer de snart att strunta i arkitektens papper. De får helt enkelt försöka fixa något som funkar så gott de kan.

Spola fram sex månader. En del av systemet har levererats till beställaren som säger “Que?!”. De inser att det mesta är fel och missförstånden är många. Nu inträder kaos-och-stressmonstret och man gräver skyttegravar och börjar skjuta på varandra. Chefer på underchefer, arkitekterna på utvecklare och tvärtom.

Antingen läggs projektet ner, eller, om pengarna finns, kickas några syndabockar och så startar hela karusellen igen.

Jag har inget skvaller (nån som kan bidra?) om att det är så här det gått till på Försäkringskassan, men jag har egen erfarenhet av hur illa det kan se ut.

Numera strävar de flesta efter att använda agila metoder som t.ex. Scrum. Här står verksamhetsnyttan i fokus. Man skall minimera byråkratin. Användare och utvecklare jobbar tätt tillsammans, med koden i centrum. Ingen är “arkitekt”, utan att samtidigt vara programmerare. Det byggs inga luftslott och dokumenthysteri är förbjuden. Ingen “fryst” design. Projektet levererar fungerande och testade program till beställaren varje eller varannan vecka. Lite i taget. Beställaren utvärderar och prioriterar vad som skall implementeras i nästa iteration.

Det går att leverera fungerande, användbara lösningar i tid och under budget. Men jag undrar om det går med en byråkratisk process?