Konfigurationsstyring

Jeg har på Brüel & Kjær været ansvarlig for et antal projekter til forbedring af software udviklingsprocessen. Fokus i et af disse var at forbedre konfigurationsstyringsprocessen. Resultaterne af dette vil blive omtalt nedenfor. Resultaterne af de øvrige procesforbedringsprojekter findes via hovedsiden.
På det seneste har jeg mest interesseret mig om at studere konfigurationsstyring set fra en projektleders synspunkt.

Forbedringsprojektet på B&K

I juni 1999 påbegyndte vi et eksperiment til at forbedre konfigurationsstyringsprocessen på Brüel & Kjær. Det nåede desværre ikke at blive afsluttet inden udløbet af det store danske software procesforbedringsprojekt Center for Software Procesforbedringer (CSPI).

For at finde de virkelige årsager bag nogle af de konfigurationsstyringsproblemer, som Brüel & Kjær havde oplevet benyttede vi os af en problemdiagnoseteknik baseret på interviews af udviklere, projektledere og kvalitetsansvarlige.

Disse interviews ændrede fokus for forbedringsprojektet fra at dreje sig om nedskrivning/opdatering af konfigurationsstyringsprocedurer til gennem workshops at skabe bedre forståelse hos udviklerne for værdien af konfigurationsstyring set fra deres perspektiv, så de selv kunne skabe de optimale rammer og procedurer for konfigurationsstyring på deres projekt.

Vi var klar til at introducere de nye principper for forbedring af konfigurationsstyringen på de første projekter i september 1999, men stødte her på udviklingsledelsens modstand mod vores indfaldsvinkel til løsning af konfigurationsstyringsproblematikken. Det planlagte eksperiment afsluttedes derfor uden at ideerne havde været afprøvet i praksis.

Retur til toppen af siden.

Konfigurationsstyring fra udviklernes perspektiv

Konfigurationsstyring betragtes normalt som en kvalitetsstyringsdisciplin med fokus på at kontrollere ændringer til produkter, som frigives til markedet. Gennem interviews med udviklere, projektledere og kvalitetsansvarlige har vi imidlertid fundet, at der var et stort behov for at anvende konfigurationsstyringsteknikkerne under selve udviklingsforløbet.

Det har ført os til at arbejde med alternative metaforer for konfigurationsstyringsbegreberne, så vi i højere grad kan fange udviklernes eget behov for konfigurationsstyring. Vi har indarbejdet metaforerne i et workshop format, hvor udviklerne lærer selv at arbejde med konfigurationsstyringsteknikkerne.

Arbejdet med at definere konfigurationsstyring fra udviklernes perspektiv har jeg udført sammen med Lars Bendix, som er forsker med speciale i konfigurationsstyring. Resultatet findes nu i form af en heldags workshop, som vi kan afholde for udviklere på udviklingsprojekter. Workshoppen blev første gang afholdt som heldags tutorial på EuroSTAR 2001 i Stockholm: Configuration Management from a Developer's Perspective [1].

Retur til toppen af siden.

Konfigurationsstyring fra en projektleders synspunkt

Som underviser af kommende, master niveau projektledere på Roskilde Universitet, er jeg i stigende grad blevet interesseret i at gøre betydningen af konfigurationsstyring letforståelig for projektledere (og andre ledere højere oppe) – ligesom jeg gør det for krav- og testdisciplinerne.

Det har medført, at jeg gennem en årrække på den årlige "Scandinavian SCM day" i SNESCM-netværket (The Scandinavian Network of Excellence in Software Configuration Management) har holdt foredrag, paneldiskussioner og Open Spaces for at få udkrystaliseret, hvad CM-specialister opfatter som deres kernekompetencer på et projekt – og dermed hvad enhver projektleder bør efterspørge hos sin konfigurationsstyringsansvarlige.

I 2009 startede jeg med en præsentation med titlen: "SCM and Process Improvement". Præsentationen prøvede at give nogle ideer til, hvordan professionelle SCM personer bedre kan udnytte den enestående viden og erfaring de besidder, og derigennem bidrage til deres virksomheds succes.

I 2010 faciliterede jeg en paneldiskussion med titlen: "SCM as a service - what do our customers want?" Panelet diskuterede SCM ud fra de mange typer brugeres perspektiv og deres forskellige behov. Paneldeltagerne bestod af både SCM specialister og brugere af SCM.

I 2011 faciliterede jeg et Open Space med titlen: "Getting to the essentials of CM – what are our core tasks?", hvor vi prøvede at finde frem til kerneydelserne i CM ud fra de mange forskellige typer opgaver, som de deltagende SCM'ere udfører i deres hverdag. Der var enighed om, at det vigtigste task for en SCM er at holde rede på de forskellige konfigurationer, fordi den CM ansvarlige er den egentlige ejer af det fysiske produkt.
Gennem dette Open Space forsøgte jeg også at finde ud af, hvad det ”ene” spørgsmål, som enhver projektleder bør stille sin konfigurationsstyringsansvarlige for at finde ud af, hvad status for produktet (komponenterne) er. Denne måde at simplificere CM er selvfølgelig fuldstændig ekstrem, men tilstrækkeligt provokerende til at starte en diskussion om emnet. Det svar Open Spacet kom frem til var: Hvad forhindrer mig i at release mit produkt? Dvs: Hvilken release status har mit produkts komponenter?
Dette spørgsmål svarer til det ”ene” spørgsmål en projektleder skal stille til sine test managers: Hvad er vores testdækning? Dvs. Hvor langt er vi ift. vores testdækningsmål. Det kunne være interessant at finde lignene typer ad “ene” spørgsmål som en projektleder skal stille til enhver af sine tilknyttede fagspecialister (feks. kravanalytikere, design arkitekter, database eksperter, usability eksperter etc).

I 2012 faciliterede jeg endnu et Open Space med titlen: "CM in Heterogeneous Environments – what solutions do you use?", hvor vi prøvede at finde frem til praktiske løsninger på CM problemer som: Kombinationen af mainframe og .net systemer; Document og kode håndterings systemer; Leverandør og in-house CM systemer; Distribuerede CM systemer. Resultatet viste, at der ikke findes nemme løsninger (kun manuelle), men at der er ved at dukke produkter op der kan klare dele af opgaven.

I 2014 faciliterede jeg endnu et Open Space med titlen: "The 5 dimensions of CM – How can we manage them?", hvor vi diskuterede en artikel af Van den Hamer & Lepoeter om Product Data Management, fordi den hævdede, at automatiske værktøjer kun kan håndtere dem parvis. Dimensionerne er: Versioner, procesvinkler, hierarkier, status og varianter. Der var enighed om dette for de første 4 dimensioner, men at varianter er noget helt for sig selv – og skal behandles som sådan.

Retur til toppen af siden.

Seminarer og Præsentationer

Lars Bendix og jeg afholder en heldags workshop med titlen: "Configuration Management from a Developer's Perspective" [1]. Workshoppen er designet til at blive afholdt når et projekthold skal tage stilling til hvorledes de vil bruge konfigurationsstyring på deres projekt. Ideen er at projektholdet efter workshoppen er istand til at formulere alle deres konfigurationsstyrings procedurer så de passer til netop deres projekts situation. Det optimale vil være at lade en af firmaets proceskonsulenter deltage i workshoppen, så resultaterne kan indarbejdes i firmaets procesforbedringsprogrammer.

Vi afholder desuden en halvdags workshop med titlen: "What would you like CM to do for you - and what value can CM bring you?". Målet med workshoppen er, gennem diskussioner baseret på deltagernes konkrete virksomhedscase(s), at gøre CM principperne anvendelige i din/jeres kontekst. Workshoppen er beregnet på mellemledere og fagspecialister (ud over CM), der har behov for at få mere viden om principperne i konfigurationsstyring.

Vi afholder også præsentationer over samme emne af en varighed fra 45 minutter til 2 timer afhængig af behovet.

Retur til toppen af siden.

Home Page -
Hjemmeside - mail@ottovinter.dk