Metoder och funktionell dumhet

Något jag tycker mig se som ett återkommande mönster i många av de IT-projekt jag arbetar som kravare i, är vilken extrem tilltro vi tillskriver metoden. Använder vi oss bara av de vedertagna och framförallt moderna metoderna så kan det ju inte gå fel. Men används metoderna för att gynna vårt sätt att arbeta och ta beslut på eller för att det helt enkelt ”är så man gör”? Klart vi inte skulle erkänna att vi bara följer strömmen, men ibland får jag känslan av att vi ändå är rätt dåliga på att utvärdera det arbetssätt vi använder. Några exempel nedan.

Fortsätt läsa Metoder och funktionell dumhet

När processer och metoder krockar med verkligheten

På de flesta företag finns processer för hur kravarbetet ska utföras. Vad som ska göras, när och på vilket sätt. Ofta används en agil approach och ibland kombineras det med en projektstyrningsmodell. Som ”kravare” har man också ofta flera arbetssätt i sin verktygslåda. Allt från det klassiska upplägget med Elicitation, Analysis, Specification och Validation, till User Stories, Use Cases 2.0 och Volere. Det finns med andra ord gott om arbetssätt och metoder beskrivna, och som kravare vet man vad som är viktigt för att resultatet ska bli bra.

Det var bara det där med verkligheten.

Fortsätt läsa När processer och metoder krockar med verkligheten

”Utreda krav? Jaha, då ska det vara workshops!”

För några år sedan gjorde jag en oväntad upptäckt: Utvecklarna på företaget jag arbetade för var mycket bättre på workshopteknik än projektledarna och kravhanterarna. Detta trots att det var vi som satt i flest workshops. Hur kunde det bli så?

Fortsätt läsa ”Utreda krav? Jaha, då ska det vara workshops!”

Vi införde Scrum – varför löste sig inte kravhanteringen?

De senaste åren har Scrum varit i ropet inom IT-branschen. Allt fler företag prövar det och överger byråkratiska och fyrkantiga sätt att bedriva utveckling. Ibland beskrivs Scrum som något som löser alla tänkbara problem. Många företag har också stor nytta av det, även om det inte passar alla.

Det finns dock en hake med Scrum. Ofta rullas det ut på utvecklingsavdelningen, och det är här entusiasmen finns. Nu ska utvecklingen ske enligt Scrummetodiken! Lappar sätts upp på tavlor och sprintar införs. Nu ska företaget arbeta agilt! Även test rycks med, det ingår ju numera i sprintarna.

Men vart tog kravhanteringen vägen? Fortsätt läsa Vi införde Scrum – varför löste sig inte kravhanteringen?

Felet med RUP

Rational Unified Process, eller RUP som det ofta kallas, är knappast något nytt. Det är en mjukvaruutvecklingsapproach som är tänkt att vara iterativ och väldigt use case-fokuserad. Den går att beskriva på en mängd andra sätt också och frågar du två personer vad RUP är får du antagligen inte samma svar. Att använda sig av en strukturerad process är alltid bra och det finns många fördelar med RUP, vilket troligen är anledningen till att så många företag fortfarande stödjer sig på RUP i sin utvecklingsprocess. Men det finns en sak som jag verkligen stör mig på.

Fortsätt läsa Felet med RUP

Använd modeller!

En sak jag märkt är att många företag vid både kravinsamling och utveckling är alldeles för dåliga på att använda modeller. Istället produceras alldeles för långa kravspecifikationer med mer text än någon skulle vilja läsa och definitivt mer än vad som är lätt att förstå.

Jag tänker inte ens gå in på hur fel jag tycker det är med tusensidiga kravspecifikationer, det är ett helt annat blogginlägg. Däremot vill jag slå ett slag för att använda modeller oftare för att förtydliga krav. Vi människor har ett väldigt högt visuellt lärande och det borde utnyttjas för att lättare komma överens om krav med projektets intressenter. Fortsätt läsa Använd modeller!