Software-procesforbedring mislykkes igen og igen

Linket henviser til http://www.version2.dk/artikel/www.madebydelta.com/manifest. Der skal vist lige skæres lidt i starten af URL'en ;-)

Tak for tippet. Det er rettet nu.

vh.

Jesper
Version2

Hvis man bliver ved med at tro på at:

"The software process creates software"..

NixenBixen

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!)

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!

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.

"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....

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å! ;-)

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.

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.

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.

@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.

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,...)

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.

@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 ;-)

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.

Jeg mener, det der er svært, er ikke at indføre nye process beskrivelser. Det der er svært at lave en process beskrivelse der er rigtigt.

Så rigtigt. En procesbeskrivelse, der ikke reflekterer virkeligheden, er en drøm. Forbedrer man den - er den stadig en drøm :-)

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.