Fra myter og moter til evidensbasert IT-utvikling"

Transkript

1 Fra myter og moter til evidensbasert IT-utvikling Magne Jørgensen Simula Research Laboratory Evidens-basert systemutvikling er sunn fornuft satt i system 1. Forstå hva du skal finne ut av. Vær tilstrekkelig presis til at det går an å besvare spørsmålet. 2. Søk etter relevant og pålitelig kunnskap: Forskning (strukturert, kritisk innhenting)! Praksisbaserte erfaringer (strukturert, kritisk innhenting)! Empiri i egen organisasjon (pilotstudier, eksperimenter, datainnsamling)! 3. Evaluer relevansen og påliteligheten til kunnskapen. 4. Anvend kunnskapen. 5. Evaluer effekten. 1

2 Bindersen er en norsk oppfinnelse Misforståelse Dekker et behov Gjentagelse Sjekker ikke en god historie Napoleon-komplekset (korte menn er mer aggressive) Misforståelse Aktiv mytedannelse? Lett å forestille seg Bekreftelsestendens 2

3 Vi mister vi det meste av varmen gjennom hodet Uklart hva som menes Ingen sjekker kildene og hva de egentlig sier Det meste av kommunikasjon er ikke-verbal Uklart hva som menes Ingen sjekker kildene og hva de egentlig sier 3

4 Barn blir hyperaktive av sukker Vi ser det når vi tror det Gjentagelse Når vi først har bestemt oss, vil ting sjelden gå tilbake til normalen 4

5 Hvordan jeg skapte myten om at Risikovillige programmere er bedre 1. Påvirkning: Gruppe A mottar informasjon om et forskningsstudie i favør av de risikovillige, samt blir bedt om å angi et argument i favør av hvorfor det kan være slik. Gruppe B mottar og gjør det samme, men i favør av de risikouvillige. 2. Spørsmål: Basert på din erfaring, tror du at risikovillige programmerere er bedre enn de risikouvillige? è 1 (helt enig) 5 (ingen forskjell) - 10 (helt uenig) 3. Evaluering 1: è Grupe A: 3,3 - Gruppe B: 5,4 4. Evaluering 2: Begge gruppene mottar informasjonen om at studien var der for å villede og ikke var reell. Oppdatering av evaluering. è Gruppe A: 3,5 - Gruppe B: 5,0 5. Evaluation 3: To uker senere. è Gruppe A: 3,5 - Gruppe B: 4,9 Hvordan bli en evidensbasert myth buster? 1. Finn ut hva som menes med påstanden a) Har den noe presist innhold? b) Hvis den ikke lar den seg falsifisere, hvilken funksjon har den? 2. Vær kritisk til din egen tendens til å akseptere påstander uten evidens eller med ikke-nøytral evidens, særlig når du er enig a) Hvorfor høres dette riktig ut? Er det av gode grunner? b) Hvem kommer med påstanden? Aksepterer du den pga kilden, ikke pga argumentasjonen? c) Husk at du glemmer fortere kilden enn innholdet Påstander fra kilder med lav kvalitet kan dermed virke sterkere med tiden! Dette kalles the sleeper effect. 3. Hva finnes av nøytral, pålitelig kunnskap (evidens)? a) Finnes nøytrale og relevante studier eller erfaringer som støtter dette? Erfaringer fra en som selger kurs i samme metode er for eksempel neppe nøytrale. b) Hva sier totaliteten av evidens? c) Når gjelder påstanden? 5

6 Software crisis : Reell eller Standish-skapt? 200 % 180 % 160 % Misforståelse/dårlig studie Gjentagelse Nytte av at det er slik Ingen sjekker kildens kvalitet Lett å forestille seg 140 % 120 % 100 % 80 % 60 % 40 % 20 % Average percent cost overrun 0 % (page 13 of their 1994-report): We then called and mailed a number of confidential surveys to a random sample of top IT executives, asking them to share failure stories. Ikke lett å fjerne myter... Har kanskje hatt en viss effekt (the CHAOS Report 2013): 6

7 The Standish Group - igjen 45% av funksjonaliteten (ved bruk av tradisjonelle utviklingsmetoder) brukes aldri Henvisning til en keynote av Jim Johnson på XP Flere som etterspør hvordan studien er gjort får ingen svar. Ingen dokumentasjon tilgjengelig. Hva betyr det at 45% av funksjonalitetet aldri brukes? (Aldri av noen? Hvem har de spurt?) Er dette for et bestemt system, eller en survey? Er det noen grunn til å tro at det er bruken av tradisjonelle metoder som er årsaken? Ville en annen metode (smidig) endret tilstanden? Er dette bruk av COTS hvor du får mye ekstra funksjonalitet gratis, produktutvikling der markedet er ukjent, eller for annen type utvikling. Hvordan stemmer dette med det vi ellers vet? Strategien synes å være: Ekstreme påstander noen har nytte av gir oppmerksomhet og økt salg Sucess = On time, on schedule and with specified functionality Finn minst én åpenbar feil i undersøkelsen! 7

8 The Standish Group er ikke alene... Hvordan bør vi forholde oss til spektakulære funn? Overforenklinger er vanligere enn rene myter, men like farlige! Faktor 10 økning i feilrettingskostnader per fase Dersom det koster 1000 kr å rette en feil i analysefasen, så koster det 1000 * 10 * 10 * 10 = kr å rette den i testfasen. Påstanden finnes i mange varianter. Den mildeste er at det koster ALLTID mer å rette en feil i en senere fase. Hva betyr påstanden om x10? Lønner det seg å finne ALLE feil så tidlig som mulig? Hvor kommer x10 fra? Betyr det at smidige metoder tar feil når det legges mindre vekt på å ha en fullstendig og korrekt spesifikasjon? 8

9 Flere overforenklinger Adding manpower to a late software project makes it later The Mythical Man-Month (Brook s lov) Beskrives av Brook selv som en: outrageous oversimplification. Forskjellen mellom dårligste og beste programmerer er 1:10. Studie fra 1968 på med erfarne utviklere på en konkret problemstilling. Forholdet kan åpenbart variere så mye vi vil avhengig av oppgaven. Brainstorming bør gjøres i grupper Vanligvis er vi er mer innovative alene, ikke i grupper MEN, informasjon bør deles og ideer bør diskuteres i grupper Duplisering av programvarekode bør alltid unngås Number one in the stink parade (Martin Fowler agile guru) Duplisert kode er typisk av høyere kvalitet enn ikke-duplisert kode. Det er helt klart situasjoner der man ikke bør duplisere kode. Når slike finnes, gå til systematisk gjennomganger Eksempel: Hva er effekten av smidig utvikling? Dybå med flere oppsummerer nøytrale kvalitetsstudier om smidig utvikling (hovedsakelig XP) i Information and Software Technology og konkluderer med at: The evidence also suggests that agile methods not necessarily are the best choice for large projects. Thus, consistent with recommendations provided by others [11,12,15], we suggest that practitioners carefully study their projects characteristics and compare them with the relevant agile methods required characteristics.! Due to the limited number and relatively poor quality of the primary studies in this review, it is impossible to offer more definitive and detailed advice. Med andre ord: Ingen klare funn på at vi blir så mye bedre med smidig og det litt mer kjedelige resultatet Det kommer an på... 9

10 Det uavklarte rundt smidige metoder illustrerer hvor viktig det er med et presist spørsmål Spørsmålet som stilles: Lønner smidige metoder seg? Er spørsmålet riktig stilt? JA: Det er det vi ønsker å vite noe om. NEI: Spørsmålet er for upresist til å la seg besvare meningsfullt! Hva mener vi med smidige metoder? Hele XP, Lean, Kanban, Scrum, inkrementell leveranser,...? Er vi smidige selv om vi kun bruker deler av en smidig metode? Forutsetter det riktig bruk av XP, Scrum,...? Forutsetter det egnede prosjekter? Hva mener vi med lønner seg? Utviklingskostnader? Totalkostnader kunde? Nytte-effekt av systemet (riktig funksjonalitet) Moter og systemutviklingsmetoder 10

11 De fleste av disse utviklingsmetodene har vært in i en periode Waterfall model, sashimi model, agile development, rapid application development (RAD), unified process (UP), lean development, modified waterfall model, spiral model development, iterative and incremental development, evolutionary development (EVO), feature driven development (FDD), design to cost, 4 cycle of control (4CC) framework, design to tools, re-used based development, rapid prototyping, timebox development, joint application development (JAD), adaptive software development, dynamic systems development method (DSDM), extreme programming (XP), pragmatic programming, scrum, test driven development (TDD), model-driven development, agile unified process, behavior driven development, code and fix, design driven development, V-modelbased development, solution delivery, cleanroom development, vis av firmaspesifikke metoder. Retorisk bruk av begreper er vesentlig for å skape en mote Vil du være moderne, fleksibel, rask, smidig, løsningsdrevet, aktiv og slank eller vil du heller være tradisjonell, ufleksibel, omstendelig og dokumentdrevet? 11

12 De 10 Bud for å skape en systemutviklingsmote Inspirert av Rhetoric and Myth in Management Fashion av Alfred Kieser 1. BUD Presenter minst en nøkkelfaktor som i følge guruene har blitt neglisjert i tidligere metoder, f eks mulighet for læring underveis vha del-leveranser. Dersom nøkkelfaktoren er velbrukt, finn nye begreper for denne slik at dette likevel virker nytt og neglisjert. 12

13 2. BUD Beskriv hvordan de tidligere metodene er dømt til å mislykkes fordi de ikke følger prinsippene i den nye metoden, f eks hvordan de tradisjonelle metodene fører til systemer med mye funksjonalitet som kunden ikke trenger. 3. BUD Koble den nye metoden til viktige, positivt ladede verdier, som kommunikasjon, fleksibilitet, brukernytte og kontinuerlig læring. 13

14 4. BUD La gode fortellere presenter historier om store suksesser forbundet med å bruke metoden. Presenter historiene på industrikonferanser, i lettleste bøker med direkte tale og i så mange fora som mulig. Advarsel: Ikke reflekter omkring årsak-virkning mellom metode og suksess. 5. BUD Unngå for all del å bidra til en oppfattelse av at metoden er laget ved et universitet eller basert på akademisk forskning. Vektlegg i stedet at metoden er basert på svært erfarne utvikleres kunnskap og læring. Et skrekkens eksempel: Spiralmodellen 14

15 6. BUD Presenter pionerene som særdeles begavede utviklere. Gi dem guru-status. 7. BUD Baser fremstillingen av metoden på en blanding av enkelhet, sunn fornuft og vaghet. Bruk dette til å demonstrere overlegenheten til metoden. Si for eksempel at metoden bygger på at samarbeid er bedre enn kontraktsforhandlinger. 15

16 8. BUD Påpek at metoden kan være vanskelig å få til. Feilslåtte prosjekter er dermed mulig å forklare som dårlig implementasjon av metoden. 9. BUD Av og til bør metodens fortreffelighet kobles til vitenskapelige studier. Studier med lav kvalitet og svært skjev tolkning av data er ikke noe stort problem. Det er neppe noen som vil sjekke kilden. 16

17 10. BUD Sørg for å time introduksjonen av metoden godt. Hver ny generasjon av utviklere ønsker sin egen metode for å skille seg fra de etablert og å være de mest kunnskapsrike. I denne mote-lignenede mekanismen ligger dessverre også enhver suksessfull metodes undergang ved at den blir tradisjonell. Tiden er trolig inne for en erstatter til smidig utvikling. Har dere hørt om ELASTIC? ELASTIC Development Together with some of the most experienced developers in the world Simula has developed a new best-practice method: ELASTIC. More and more experienced developers found that they SOMETIMES needed more design/architecture, more planning and more documentation. They could not anymore stand and look at failed projects due to religious beliefs in ONE method. We need to be flexible. We need to be more elastic! Manifesto of ELASTIC: Software projects vary, so should their development methods 17

18 ELASTIC Development Key principle: ELASTIC has a phase where the developers together with their clients (based on project characteristics such as expected requirement stability, client maturity and technical complexity) agree on the development process design. This tailoring method is unique and not part of any other development method. There is nothing fundamentally wrong with the traditional methods, such as agile, scrum, RUP and waterfall. They lack however: The flexibility to deal with today s variation in clients and types of projects Support on how to tailor a development method. ELASTIC development The main values of ELASTIC are Communicate, Analyze, Reflect and Educate in close collaboration with the client (the CARE values). ELASTIC has so far been a great success! We have so many times been disappointed by the lack of professionalism and low ability of adapting the development method to our needs and maturity levels. Most software developers seem to be more concerned about their own religious belief in a method than creating value for the client. ELASTIC development takes us the client seriously. We will never again choose a software provider that does not follow ELASTIC development. Stein Mathisen, CEO Norwegian Hydropower. 18

19 ELASTIC development The client went from 50% to 0% failed projects and a 200% increase in profitability by selecting a software provider which followed the ELASTIC method. Other studies also show great benefit from use of the ELASTIC method. The Johnson Group have studied more than 200 projects and found that ELASTIC gave the highest ROI (return on investment). ELASTIC development 6 ROI = (Benefit - Cost)/Cost Elastic XP Scrum RUP 19

20 Fra Myter og Moter til Evidens-basert praksis Det positive i det hele er at vi for første gang i historien har all verdens mulighet til å skaffe oss god informasjon om hva som virker. All ære til scholar.google.com for mye av dette Dette krever: Riktig spørsmålstillinger Kunnskap om innhenting og evne til kritisk evaluering av evidens Vi trenger evidens-basert systemtuvikling for å. Gå fra myte og mote-basert til kunnskapsbasert praksiser Motvirke vår velutviklede evne til å se mønstre hvor det ikke er noen Motvirke bekretelsestendensen Fremskaffe kunnskap som ikke kan hentes fra erfaring alene Bedre evnen til å fremskaffe kunnskap, inkludert praksisbasert kunnskap 20

21 Evidens-basert systemutvikling er sunn fornuft i system 1. Forstå hva du skal finne ut av. Vær tilstrekkelig presis til at det går an å besvare spørsmålet. 2. Søk etter relevant og pålitelig kunnskap. Forskning (strukturert, kritisk innhenting)! Praksisbaserte erfaringer (strukturert, kritisk innhenting)! Empiri i egen organisasjon (pilotstudier, eksperimenter, datainnsamling)! 3. Evaluer relevansen og påliteligheten til kunnskapen 4. Anvend kunnskapen 5. Evaluer effekten 21