mboost-dp1
Study finds 268% higher failure rates for Agile software projects
Agile og Scrum's idé med en "dynamisk kravspec" at man bare går igang og lader kravene krystalisere sig efterhånden som tingene falder på plads, synes jeg ikke er helt tosset. Problemet er vel at sammenligne et projekt med en knivskarp kravspec med et projekt der ikke har, fordi ingen ved præcis hvad der skal stå i den. Det er ikke en fair sammenligning. Det tager tid og viden at skrive en skarp kravspec. Måske ligefrem et forprojekt. Er den tid mon med i sammenligningen i #1.
Ellers tænker jeg at de fleste teams vel kommer frem til deres egen foretrukne udviklingsprocess med nogle elementer fra Agile og nogle fra andre metodikker. Der er masser af godt i Agile men også uheldige ting. Er det virkelig nødvendigt med daglige stand op møder, f.eks.
Ellers tænker jeg at de fleste teams vel kommer frem til deres egen foretrukne udviklingsprocess med nogle elementer fra Agile og nogle fra andre metodikker. Der er masser af godt i Agile men også uheldige ting. Er det virkelig nødvendigt med daglige stand op møder, f.eks.
larsp (2) skrev:Det tager tid og viden at skrive en skarp kravspec. Måske ligefrem et forprojekt. Er den tid mon med i sammenligningen i #1.
Det vil jeg formode.
Vurderingen af projekterne er vel actual vs estimated for både duration og cost.
Og jeg vil tro at der er betydelig mindre usikkerhed på udarbejdelsen af kravspec end de senere faser.
#2
Effektiviteten af agile afhænger en del projektets type.
Skal man udvikle et web interface til en business applikation så er det ret effektivt at arbejde i tæt dialog med dem der skal bruge den web applikation. Brugerne siger hvad de ønsker. Udviklerne laver et udkast. Brugerne giver feedback. Udviklerne tilretter udfra feedback. Det virker. Det virker meget bedre end en 200 siders kravspec der beskriver alle skærmbilleder udfærdiget af en BA som aldrig har arbejdet med den applikation.
Skal man udvikle software til et pilotløst passagerfly så vil man gerne have en meget præcis kravspecifikation. Man sender ikke bare nogen op og flyve med en tidlig udgave og ser om de kommer frem i live eller flyet styrtet og all dør.
For små teams med 2-10 deltagere i samme bygning er det meget mere effektivt at tale sammen end at udfærdige og distribuere projekt status rapporter.
Men hvis man har et projekt med 500 deltagere fordelt på 3 kontinenter, så er det svært med den direkte verbale kommunikation. SAFe, LeSS og andre er kun workarounds for et fundamentalt problem.
Effektiviteten af agile afhænger en del projektets type.
Skal man udvikle et web interface til en business applikation så er det ret effektivt at arbejde i tæt dialog med dem der skal bruge den web applikation. Brugerne siger hvad de ønsker. Udviklerne laver et udkast. Brugerne giver feedback. Udviklerne tilretter udfra feedback. Det virker. Det virker meget bedre end en 200 siders kravspec der beskriver alle skærmbilleder udfærdiget af en BA som aldrig har arbejdet med den applikation.
Skal man udvikle software til et pilotløst passagerfly så vil man gerne have en meget præcis kravspecifikation. Man sender ikke bare nogen op og flyve med en tidlig udgave og ser om de kommer frem i live eller flyet styrtet og all dør.
For små teams med 2-10 deltagere i samme bygning er det meget mere effektivt at tale sammen end at udfærdige og distribuere projekt status rapporter.
Men hvis man har et projekt med 500 deltagere fordelt på 3 kontinenter, så er det svært med den direkte verbale kommunikation. SAFe, LeSS og andre er kun workarounds for et fundamentalt problem.
Jeg har iøvrigt været en stor fan af UP i 22 år.
For de mere komplekse projekter mener jeg at UP er bedre end XP/Scrum/Kanban/whatever agile.
Agile fokuserer på at få noget leveret til brugerne som de kan komme igang me dog give feedback på. Rent praktisk betyder det ofte fokus på brugergrænseflade og at få nogle enkelte operationer i backend til at virke mere eller mindre virkelighedsnært. Og det skaffer feedback som man ønsker. Problemet er at det sjældent er der hvor projekt risikoen er. Der er ingen projekter som totalfejler fordi man ikke kan få GUI til at virker. Projekter kan totalfejle fordi kernen er for langsom og ikke skalerer.
UP fokuserer på at få de vanskeligste og mest risikable del af projektet lavet først. Er der nogle kritiske performance og skaleringsproblemer så starter man med at løse dem. Når man ser fremskridt på dem, så kan man begynde med de nemme 90% af arbejdet.
For de mere komplekse projekter mener jeg at UP er bedre end XP/Scrum/Kanban/whatever agile.
Agile fokuserer på at få noget leveret til brugerne som de kan komme igang me dog give feedback på. Rent praktisk betyder det ofte fokus på brugergrænseflade og at få nogle enkelte operationer i backend til at virke mere eller mindre virkelighedsnært. Og det skaffer feedback som man ønsker. Problemet er at det sjældent er der hvor projekt risikoen er. Der er ingen projekter som totalfejler fordi man ikke kan få GUI til at virker. Projekter kan totalfejle fordi kernen er for langsom og ikke skalerer.
UP fokuserer på at få de vanskeligste og mest risikable del af projektet lavet først. Er der nogle kritiske performance og skaleringsproblemer så starter man med at løse dem. Når man ser fremskridt på dem, så kan man begynde med de nemme 90% af arbejdet.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund