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

Lean from the Trenches

Har precis läst ut boken ”Lean from the Trenches” av Henrik Kniberg. En lättläst bok om hur de jobbade i ett stort projekt med 60 projektmedlemmar på Rikspolisstyrelsen.

Henrik beskriver hur de kombinerade XP, Scrum och Kanban. Boken tar upp vad som fungerade, vad som inte gjorde det, varför och hur processen utvecklades.

Det beskrivs hur de arbetade praktiskt genom hela utvecklingsprocessen. Jag tycker boken blir levande genom verkliga exempel och massor av  foton på t.ex. deras fysiska Agila tavlor.

Jag blir så glad över att läsa om ett projekt där man tillsammans arbetar fram ett sätt att jobba effektivt ihop. Hur man gör stora förändringar genom att låta små förändringar i samma riktning ske ofta.

Samtidigt funderar jag på om hur det känts om jag hade varit med i projektet. Henrik var inne i projektet ett halvår och det är det halvåret som boken beskriver. Det måste ha varit mycket stimulerande och intensivt att vara med och förändra projektet tillsammans.

Men vad händer sedan.

Fortsätt läsa Lean from the Trenches

Hur få kvalitet i kravgranskning?

Jag tror att alla är överens om att det är viktigt att kvalitetssäkra kravspecifikationer. En felaktig eller inkomplett kravspecifikation kan få katastrofala följder. Som kravansvarig har man gjort sin kravplan och punkten ”kravgranskning” låter ju tämligen enkel att genomföra. Men är det så i verkligheten? I många fall inte tyvärr. Fortsätt läsa Hur få kvalitet i kravgranskning?

Krav, lösning eller mittemellan

Jag satt nyligen i ett mötesrum fullt av människor med lite olika roller; systemarkitekter, kravledare, produktägare, säkerhetsspecialister, dokumentatörer… Syftet med mötet var att gå igenom ett antal produktinitiativ som hade samlats in för en tid sedan, och att följa upp vårt gemensamma arbete med att bryta ned dessa till mer konkreta features. Utkast till funktionella business-features varvades under diskussionen med arkitekturella features (eller enablers som de nuförtiden kallas enligt SAFe-ramverket som projektet ifråga hämtar inspiration ifrån).

Stämningen i rummet var inte direkt dålig, men jag kände ändå i maggropen att två läger höll på att utkristalliseras. Fortsätt läsa Krav, lösning eller mittemellan

Nyårslöften…

Ett nytt år ligger nästan orört framför oss. Kanske är det lite ute att ge nyårslöften, men någonstans under ytan brukar man ändå uttala lite förhoppningar om det nya året. Vi som arbetar med kravhantering grunnar säkert på hur vi ska kunna bli bättre på att lägga grunden för framgångsrika projekt och ta fram rätt produkter. Inventerar jag mitt 2015 hittar jag ett par riktigt grundläggande ”low hanging fruits” att polera lite på, som kanske du också känner igen…

2016 tänker jag nämligen bli ännu bättre på … att dokumentera motivering och källa till ett krav.

Fortsätt läsa Nyårslöften…

Vad är ingenjörsmässigt?

En gång när jag för hundratusende gången hos en kund tjatade om att vi måste göra kraven otvetydiga, och helst mätbara, fick jag en raljerande kommentar av en annan konsult i projektet. Han himlade med ögonen och sa nåt i stil med ”Ja, ja. Det låter ju bra men det fungerar inte så i praktiken. Det vet jag, för jag har faktiskt jobbat med det här i många år”. Vid tillfället kom jag givetvis inte på någon dräpande kommentar men igår kom jag att tänka på händelsen igen, trots att det är ganska många år sedan.

civilingenjor580

Det som slog mig är att det är en ganska vanlig inställning till specifikationsarbetet. Alltså att det inte är nödvändigt, eller ens önskvärt, att vara tydlig i sina krav. Iallafall när det gäller krav i textform…

Fortsätt läsa Vad är ingenjörsmässigt?

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