Software-procesforbedring mislykkes igen og igen

Når ledelsen indfører CMMI eller andre metoder til at forbedre software-udviklingen, går det galt hver anden gang. Et nyt manifest skal være værktøjet, der gør det nemmere at finde fælles fodfæste, når udviklingsarbejdet skal modnes.

Software-udviklingen skal sættes i system. Sådan tænker mange små som store virksomheder med udviklere i huset, men det er med vekslende held, at værktøjer som CMMI, ISO 15504 og ITIL bliver brugt til at lægge faste rammer om arbejdet.

»50 procent af de virksomheder, der går i gang med procesforbedring af softwareudvikling, lykkes ikke med det,« forklarer Jørn Johansen, leder af Delta Axiom, der har specialiseret sig i rådgivning om softwareudviklings-processer, og er en del af DELTA.

Og et af problemerne er, at der sjældent er bred enighed om, hvad forbedringsprocessen skal føre frem til, udover at man skal have en certificering eller rykke et niveau op i CMMI-hierarkiet.

Derfor har han sammen med professor Jan Pries-Heje fra Roskilde Universitet stået for et nyt manifest for procesforbedring, der skal skabe klarhed og fælles fodslag hos ledelse og kodekarle.

»Ligesom man har et manifest for agil udvikling, syntes vi, at der skulle være et for software-procesforbedring. Der har manglet en klar, fælles forståelse,« siger han.

Derudover er den slags projekter heller ikke altid nemme at 'sælge' til udviklerne. Den typiske reaktion er skepsis blandt de ansatte, når en virksomhed går i gang med procesforbedringer.

»I et firma med lavt modenhedsniveau mener udviklerne tit, at det blot vil føre til ekstra bureaukrati. Det er besværligt, og de er ikke interesserede. Men i virksomheder med et højt modenhedsniveau er svaret anderledes. Her oplever de, at mange trælse opgaver er forsvundet, fordi de er sat i system og nærmest løser sig selv. Så er der mere tid til at være innovativ,« forklarer Jørn Johansen.

Når et procesforbedrings-projekt sættes i gang, er et andet typisk problem, at der ikke bliver fokuseret ret meget på, hvordan det skal sættes i værk. Hvis kulturen blandt medarbejderne ikke passer til de nye krav, der stilles, er det dømt til at gå galt.

Manifestet nævner for eksempel en asiatisk virksomhed, hvor ingen ønskede at kritisere kollegernes arbejde, og et projektværktøj med tidsregistrering, der floppede massivt, fordi modstand mod stempelure gennemsyrede virksomheden.

De mest brugte modenhedsmodeller i Danmark er CMMI og ISO 15504, der også er kendt under navnet Spice. Og det er alle slags virksomheder med softwareudvikling, der bruger dem - ikke kun Terma, Systematics og andre, der leverer til militærkunder. Den mindste virksomhed, Jørn Johansen har rådgivet, havde fem medarbejdere.

Manifestet er blevet til ved at samle 30 internationale eksperter til en workshop og arbejde sig frem til essensen. Siden redigerede de to danskere bidragene sammen, og efter en runde mere blandt eksperterne, var resultatet klar i sidste uge.

Hent manifestet ved hjælp at det eksterne link herunder.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (19)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Claus Jørgensen

Virksomhederne bør kigge på procesforbedringer for netop at opnå mindre bureaukrati, i stedet for mere.

Typisk kan man jo netop kombinere procesforbedringer med en ny udviklingsmodel som Scrum, Kanban eller XP, og opnå mere udviklingstids samlet set.

Men for mange virksomheder er problemet mere at chefen misforståer ideen, og begynder at arbejde på den gammeldaws maner ligeså snart det begynder at gå godt. Altså flytter folk fra projekter til andre, selvom det er modstridende med den valgte udviklingsmodel.

Derudover forsøger for mange af virksomhederne at implementere alle niveauer af CMMI fra starten, i stedet for gradvist at arbejde sig op. At fokusere på rent faktisk at få en ensarbejdet arbejdsstruktur, som udviklerne kan bruge til noget (agilt/iterativt, tak!), er det første store skridt.

Så kan man fokusere på forbedringer når man når til det niveau hvor det er relevant (Niveau 5!)

  • 0
  • 0
Claus Jørgensen

Det er det vel, til dels. Uden et ordenlig proces er der ihvertfald stor risiko for at arbejde utrolig ineffiktivt hvis man er en del af en større virksomhed og/eller koncern.

Det er kun små virksomheder, enkeltmandsudviklere, etc. som kan tillade sig at ignorer det i perioder. Men som nyheden også påpeger, kan selv små grupper nyde godt af en specific arbejdsproces.

Det som det også hjælper, er når der skal oplæres nye medarbejdere, eller have en udvikler mere ind i et team. En dokumenteret proces, gør det nemt at tilpasse sig et arbejdsmiljø som udvikler.

Hvor at totalt kaos aldrig er godt for nogen!

  • 0
  • 0
Esben Nielsen

Jeg har lagt mærke til at folk generelt ikke kan finde ud af versionsstyring. Tag det som første punkt: Få integreret Subversion eller lignende i udviklingsprocessen. Dette gælder også for projekter med én deltager.

Få lavet et bygge miljø, hvor man kan lave et checkout fra ovenstående og bygge alt automatisk. Dette gælder også for projekter med én deltager.

Sæt en build server op, som bygge automatisk v.hj.a ovenstående, når folk checker nyt kode ind. Dette gælder også for projekter med én deltager, da det også here fanger, at man mangler at checke noget kode ind.

Indfør automatiske test så ovenstående buildserver checker mere end blot syntaxen.

Dernæst kan man tage styr på kravstyring og mere avancerede ting.

Ting man ikke skal starte med: Kode-stil. Folk kommer meget ofte op og slås om det og så stopper hele processen.

  • 0
  • 0
Morten Korsaa

"The software process creates software"..
Det er lidt en leg med ord, men det er yderst essentielt.
Det essentielle er at skelne mellem en proces og en procesbeskrivelse!
En proces skaber et eller andet. Hvad skulle den ellers gøre!
En procesbeskrivelse er en proces der er beskrevet i et dokument. Den gør ingenting af sig selv.
Men hvis man tror at procesforbedring handler om at skrive bedre procesbeskrivelser, så er det galt!
Procesforbedring handler om at blive bedre til at skabe et eller andet - her software. Og det kan der så være mange gode grunde til at skrive ned....

  • 0
  • 0
Kurt Frederichsen

På mange måder har du ret i at det er mennesker, der laver det meste SW - eller de funktioner, der laver den. Men uanset om det er bevist eller ubevist, så følger du en proces for at gøre dette stykke arbejde...

...det interessante er at du skal være bevist om hvad du gør, for at kunne gøre det bedre og for at kunne forudse resultatet. Det er derfor håndværkere træner deres fag og derfor udviklere også skal forstå hvorfor de gør hvad de gør. Desværre beviser erfaringen at mange SW projekter ikke når deres mål. Også projekter med et smart CM-tool og andre værktøjer. I den sidste ende er det kun dem, der forstår hvorfor de gør som de gør og vælger at gøre det, der er optimalt i den konkrete situation man er i, der laver gode projekter. Det er at have styr på sine processer og bruge de værktøjer der hjælper - det punkt når du kun ved en eller anden form for optimering - hvor procesoptimering er kernen - for de bevistgører dig om hvad der er det rigtige!

Det lader jeg mig gerne udfordre på! ;-)

  • 0
  • 0
Claus Jørgensen

Versionsstrying er altid godt, men man skal sørge for at vælge en teknologi der kan integreres med medarbejders hverdag.

IBM Clearcase (til IBM Rational), eller Microsofts SourceSafe (Til Visual Studio) er nok de mest relevante, da de hver især er godt integreret med normale udviklings miljø.

Folk skal ikke føle at versions styring er et problem, som tager tid og giver dem grå hår (Subversive i Eclipse skylder mig et glas pamoler).

Desværre bliver nye værktøjer tit udrullet over hovedet på udviklerne, og specielt i de virksomheder hvor procesforbedringer er nødvendige (store koncerner) er der mange gamle udviklere som har kodet uden versions styring i 20 år.

Så det skal gøres forsigtig, og der skal tages et stort hensyn til brugerne (udviklerne) i indlæringprocessen, ellers bliver det aldrig en succes.

  • 0
  • 0
Esben Nielsen

IBM Clearcase (til IBM Rational), eller Microsofts SourceSafe (Til Visual Studio) er nok de mest relevante, da de hver især er godt integreret med normale udviklings miljø.

Nu er Subversion også integreret i det meste - men personligt bruger jeg det aldrig fra Eclipse, som er vores udviklingsmiljø.

Jeg har før brugt ClearCase. Det er rigtigt godt - men er simpelthen alt for dyrt og tungt medmindre man er rigtigt mange (20+) udviklere, da det kræver megen administration (vi havde en mand, som ikke lavede andet og han havde travlt!) Og så har det mange små irreterende bugs, som sætter brugeren i stå i dagligdagen..

VisualSourceSafe: Tjaa, det følger vel med Visual Studie. Da jeg arbejdede med det omkring år 2000, "låste" den filerne, når man checkede dem ud, så andre ikke kunne rette i dem. Så det kan ikke bruges til mere end 2-3 udviklere. Og så ikke på andet end Windows, selvfølgelig.

Jeg må sige, at jeg ikke kan anbefale, hverken ClearCase eller VSS: Det ene er alt for stort og tungt, det andet for småt - og låser én til en bestemt platform.

Nej, Subversion er bedre end begge for langt de fleste. Hvis man bliver rigtigt mange kan man overveje at købe ClearCase eller lignende dyrt produkt.

Det eneste, som er galt med Subversion er manglende support for løbene merge af branches: Ligesom CVS husker den ikke, hvad man har merget allerede.
Jeg bruger istedet Git som Subversion klient, da den holder meget bedre styr på branches.

  • 0
  • 0
Claus Jørgensen

Men grunden til at Git ikke har opnået en brugbar udbredelse på dens 7 år, er at der ikke er nogen form for brugbar IDE support (ikke engang til Eclipse!)

Det er et fåtal som gider åbne en terminal for at comitte ændringer, og hvis du skal forsøge at prakke det på nogle udviklere som aldrig har brugt versions styring før, så er alt undtagen et par clicks med musen, ikke fremskridt.

Derudover så deler jeg Torvalsens meninger omkring SVN. Det er noget skrammel.

Og så synes jeg nu også at SVN låser en til en platform. Windows supporten er ihvertfald ikke optimal.

  • 0
  • 0
Michael Møller

@Morten Korsaa,
"Det essentielle er at skelne mellem en proces og en procesbeskrivelse!" - ja jeg kunne ikke være mere enig, men kom itvivl da jeg læste manifestet, og har læst det igen, og er stadig itvlvl :) - "We must close the Gap between the 'process' and 'how the work is really being done;'" står der, hvad jeg også er enig i, men udsagnet åbner bare for at der er 3 ting, software, en process, og en process beskrivelse, og det ved jeg egentlig ikke om jeg er tilfreds med!

@Kurt Frederichsen,
Jeg er meget enig i dine betragninger om at " I den sidste ende er det kun dem, der forstår hvorfor de gør som de gør og vælger at gøre det", eller som en kollega sagde en dag, efter et stykke tid er du fatter man nok til at programmere efter mønstre. Man bliver nemlig bevidst om hvad det er man laver.

  • 0
  • 0
Jesper Louis Andersen

Men grunden til at Git ikke har opnået en brugbar udbredelse på dens 7 år, er at der ikke er nogen form for brugbar IDE support (ikke engang til Eclipse!)

Git startede den 3. April 2005. Det er ikke engang 5 år gammelt. Det virker fint i mit IDE (som er UNIX, hvis nogen skulle være i tvivl).

Det er et fåtal som gider åbne en terminal for at comitte ændringer, og hvis du skal forsøge at prakke det på nogle udviklere som aldrig har brugt versions styring før, så er alt undtagen et par clicks med musen, ikke fremskridt.

Jeg sidder som regel og laver 90% af mit revision control arbejde i en terminal. De sidste 10% er gitk, som er et grafisk interface til git. Jeg vil tro at git er designet til brugere som jeg, for det virker forbandet godt.

Til Windowsudvikling ville jeg personligt kigge på Mercurial og tortoisehg projektet. Det er ikke git, men det er tæt på. Og det er helt sikkert tusind gange bedre end alternativerne (CVS, SVN, Visual SourceSafe, TFS,...)

  • 0
  • 0
Claus Jørgensen

Jeg sidder som regel og laver 90% af mit revision control arbejde i en terminal.

Størstedelen af dit revisionsarbejde skulle gerne være commits, gerne med en form of dokumentation/beskrivelse af rettelser samt refference til task/ticket hvis der bruges et system til det.

Det er repetivit arbejde som du ligeså godt kan have direkte integeret i dit udviklingsmiljø. Netop gode værktøjer (som et bedre IDE, eller et bedre versionsstryingsystem som integerer med ens værktøjer) er godt for arbejdsprocessen.

Og argumenterne om hastighed må Torvalsen altså selv stå for. På en arbejdsplads er det mest relevant at comitte til en lokal code/build server, og derfor er hastigheden ikke særlig relevant.

Specielt ikke hvis man bruger ikke et tvunget til at bruge Eclipse, som låser fuldstændig ned mens man comitter.

  • 0
  • 0
Morten Korsaa

@Michael. "...3 ting, software, en process, og en process beskrivelse, og det ved jeg egentlig ikke om jeg er tilfreds med!" Hvorfor ikke?
Er følgende sandt?? "Softwareudviklingsprocessen består af mennesker, der bruger deres evner og nogle værktøjer, på en måde som er beskrevet, til at lave software"
(Det er min favoritkæphest, og jeg tror at mange misforståelser har sin rod her, så jeg er meget interesseret i din mening ;-)

  • 0
  • 0
Michael Møller

Jo :) det er sandt, for en process er en transformation, i dette tilfælde fra ide til software, og det er mennesker der foretager den transformation ved hjælp af beskrivelsen. Og resourcer til at udfører en transformation er pr definition en del af processen. Altså er mennesker med. Det er bare ikke altid at det giver software, selvom man har alle de ting der burde udgøre processen. Jeg har set det en del gange efterhånden. Og jeg tror det er fordi at vi har travlt med det der er nemt, og aldrig gør det der er svært. Vi skriver om hvordan man kan ændre og indfører metoder til forbedringer af softeware udviking. Men det giver ikke bedre software.

  • 0
  • 0
Jesper Louis Andersen

Størstedelen af dit revisionsarbejde skulle gerne være commits, gerne med en form of dokumentation/beskrivelse af rettelser samt refference til task/ticket hvis der bruges et system til det.

Det er det nu ikke. Selve commit-delen er vel 2-3 procent. Resten er forberedelse af hvad jeg vil lave commit af, dokumentation af arbejdet, etc. Omkring 50-60 procent er at integrere andres arbejde, lave code review, lave QA, styre hvilke features der skal i produktion, hvad der skal til test osv.

Jeg er stærkt tilhænger af en udviklingsproces hvor alt kode bliver gennemlæst af andre før det slippes ud til alle programmører på et projekt. Og da jeg sidder med den rolle, så er det rart med et værktøj som git, fordi det gør det arbejde nemt. Min tese er at værktøjer som git (og mercurial) fordrer en sund udviklingsmodel for software.

Og argumenterne om hastighed må Torvalsen altså selv stå for. På en arbejdsplads er det mest relevant at comitte til en lokal code/build server, og derfor er hastigheden ikke særlig relevant.

Det er i andre situationer at det er rart det går hurtigt. Jeg laver nemt 10-20 merges om dagen, så hvis det tog et par minutter for hver ville jeg spilde min tid. Det andet centrale er hvor hurtigt systemet er til at lave arkæologi på allerede comitted kode. Det er yderst relevant når man jagter en regression i gammel kode eller vil vide hvad der skete med en ændring.

  • 0
  • 0
Log ind eller Opret konto for at kommentere