Vilken projektmetodik är bäst? Det är en relevant fråga. Finns det en one-size-fits-all-version som passar alla typer av företag och uppgifter? Och är en traditionell projektmodell à la vattenfall, som innebär utveckling i sju steg, bättre eller sämre än att köra agilt?
Nej, en enda modell som passar för allt finns inte. Däremot är det viktigt att ha en gemensam projektmetod i botten – det är sekundärt vilken man väljer. Projektmodellen ger stadga, struktur, ett gemensamt språk och alla vet vad som gäller. Vi får en bra checklista som hjälper oss med att säkra att inget väsentligt faller mellan stolarna. Vi vet vad som förväntas av oss. Vi får hjälp med att strukturerat och metodiskt lösa den uppgift vi har. Steg för steg. Ordning och reda. Vilket i sin tur underlättar det kreativa lösningsarbetet.
Om valet står mellan vattenfall och agil utveckling, väljer jag det seenare. För att vara ärlig: vattenfall suger. Ofta. Det är en fantastiskt fin teori som visat sig svår att få fungera i praktiken. Systemutveckling går mer och mer från att vara baserad på detaljerade kravspecifikationer till att handla om kortare releaser där systemutvecklare och användare har täta avstämningar.
Visst behövs dokumentation – absolut. Den ska vara tillräcklig och tydlig – men den kan aldrig ersätta kommunikation och samarbete. En bra dokumentation är kort och koncis. Pang på rödbetan. Vi har alla ont om tid. Kortfattat premieras framför långfattat. Kom till saken! Direkt! Smid järnet bums. Gör det, och det blir gjort.
Agil utveckling innebär inte ett paradigmskifte, utan är en förbättring av de mer tungrodda och byråkratiska projektmetoderna. I sin bästa form kombinerar metoden russinen ur kakan från de mer traditionella metoderna och kravspecifikationsdriven utveckling med lättrörlighet.
När jag för ett tag sedan höll föredraget ”Agile – Konsten att överleva”, konstaterade en av åhörarna att agil utveckling handlar om att byta ut byråkrati mot tillit. Det är en bra sammanfattning.
Tilltro till individen. Tilltro till sig själv och sin förmåga. Att ge, ta och få ansvar, som Citymail uttrycker det.
Nej, en enda modell som passar för allt finns inte. Däremot är det viktigt att ha en gemensam projektmetod i botten – det är sekundärt vilken man väljer. Projektmodellen ger stadga, struktur, ett gemensamt språk och alla vet vad som gäller. Vi får en bra checklista som hjälper oss med att säkra att inget väsentligt faller mellan stolarna. Vi vet vad som förväntas av oss. Vi får hjälp med att strukturerat och metodiskt lösa den uppgift vi har. Steg för steg. Ordning och reda. Vilket i sin tur underlättar det kreativa lösningsarbetet.
Om valet står mellan vattenfall och agil utveckling, väljer jag det seenare. För att vara ärlig: vattenfall suger. Ofta. Det är en fantastiskt fin teori som visat sig svår att få fungera i praktiken. Systemutveckling går mer och mer från att vara baserad på detaljerade kravspecifikationer till att handla om kortare releaser där systemutvecklare och användare har täta avstämningar.
Visst behövs dokumentation – absolut. Den ska vara tillräcklig och tydlig – men den kan aldrig ersätta kommunikation och samarbete. En bra dokumentation är kort och koncis. Pang på rödbetan. Vi har alla ont om tid. Kortfattat premieras framför långfattat. Kom till saken! Direkt! Smid järnet bums. Gör det, och det blir gjort.
Agil utveckling innebär inte ett paradigmskifte, utan är en förbättring av de mer tungrodda och byråkratiska projektmetoderna. I sin bästa form kombinerar metoden russinen ur kakan från de mer traditionella metoderna och kravspecifikationsdriven utveckling med lättrörlighet.
När jag för ett tag sedan höll föredraget ”Agile – Konsten att överleva”, konstaterade en av åhörarna att agil utveckling handlar om att byta ut byråkrati mot tillit. Det är en bra sammanfattning.
Tilltro till individen. Tilltro till sig själv och sin förmåga. Att ge, ta och få ansvar, som Citymail uttrycker det.
Den här artikeln har 0 kommentarer:
E_angled_view_active_display_and_interior_light_and_open.jpg)
