/elektronik

Scrum speeder elektronikudvikling op

En stribe danske elektronikvirksomheder er begyndt at arbejde efter Scrum og andre agile udviklingsmetoder. Det giver en mere dynamisk produktudvikling.

Klik for at se billedet i stort

Scrum-metoden, en af de nye agile modeller, adskilller sig fra vandfaldsmodellen ved, at krav og design løbende kan ændre sig. Der arbejdes i korte cykler, sprints, fra typisk 2-4 uger ned til et døgn. Hver sprint leverer en funktionel del af projektet. (Grafik: Lasse G. Jensen)

Klik for at se billedet i stort

Læs også

Læs mere om

Af Eskil Sørensen, lørdag 10. apr 2010 kl. 10:00

Flere store danske elektronikudviklere, blandt andre Foss i Hillerød og udviklingshusene Axcon og Crysberg, har inden for de seneste to år taget Scrum og tilsvarende agile udviklingsværktøjer til sig. De har ellers hidtil kun været brugt af softwareudviklere.

»Scrum er eksplosionsagtigt på vej frem i elektronikbranchen. Jeg blev selv helt religiøst vækket, da jeg hørte om det. Alle vores udviklingsprojekter kører efter Scrum-metoden nu,« fortæller Niels Klagenberg, direktør for elektronikvirksomheden Crysberg med 30 medarbejdere.

Foss i Hillerød med 180 ansatte i udviklingsafdelingen har også taget værktøjet til sig.

»Vi har haft en voldsom produktivitetsstigning, efter at vi indførte det,« siger ingeniør og udviklingschef Kim Vejlby Hansen, Foss.

Korte cykler

Det er centralt i Scrum og andre agile planlægningsværktøjer, at man arbejder med korte "cykler", hvorefter man evaluerer resultaterne. Det betyder, at der bliver stor kommunikation mellem udviklerne i et udviklingsteam, og at man hurtigt opdager, hvis projektet er ved at køre af sporet. Faktisk holdes der daglige møder, hvor deltagerne opdaterer hinanden på, hvor langt de er.

»Vi har et dagligt stående møde på et kvarter. Det betyder, at man tidligere kommer ud af busken med problemer over for de andre projektdeltagere,« siger Rolf Østergaard, direktør i udviklingshuset Axcon i Lyngby.

»Derfor får man tidligt identificeret, hvor det går galt, og andre kan give en hånd med. Det bliver en dynamisk planlægningsproces. Dér hvor det går godt, får man løst de svære problemer først,« siger han.

Rolf Østergaard advarer dog om, at værktøjet ikke er nogen garanti for succes. Man kan også komme til at stå med nogle svære problemer til sidst. Men generelt giver det mulighed for at udvikle hurtigere.

»Man kan udvikle elektronik hurtigere, og man kan ikke mindst reducere risikoen for, at projekterne løber ud over tidsrammen,« siger han.

Ud over de daglige møder er der også længere cykler, typisk over et par uger, hvor der holdes et længere møde, hvor målene for den næste periode fastlægges.

Et andet vigtigt træk ved Scrum er, at det så vidt muligt skal testes løbende, om man virkelig er nået frem til de ønskede resultater.

»Processen bliver mere struktureret. Vi får identificeret, hvilke elementer vi bør teste undervejs,« siger ingeniør Torben Rasmussen fra udviklingshuset Axcon i Lyngby.

På væggen hos Axcon hænger nogle A3-ark, hvor Torben Rasmussen og hans kolleger har klæbet delopgaver op på gule sedler. Oversigten tvinger ham og kollegerne til hele tiden at forholde sig aktivt til, hvor langt de er nået i projektet.

»Man kan godt have en tendens til at springe over nogle ting, som man synes er lette. Det kan man ikke med den her type planlægningsværktøj,« siger han. Axcon arbejder med en variation af de agile planlægningsværktøjer, som hedder Kanban.

Pas på med at kopiere

Hidtil har Scrum som nævnt været meget brugt i softwareverdenen. Men man kan ikke uden videre bruge de metoder, som softwareudviklerne anvender, påpeger Bent Jensen, direktør i konsulentfirmaet Best Brains. Han arbejder med lean og agile udviklingsprocesser med udgangspunkt i softwareverdenen.

»Scrum kan forbedre teamworket og skabe et fælles fokus i en gruppe. Det kan også medvirke til at problemer opdages hurtigere. Jeg er ikke i tvivl om, at de agile modeller er på vej frem i hardwareverdenen. Men man kan ikke bare ureflekteret kopiere modellen fra softwareverdenen. Man må tilpasse den til den virkelighed, der gælder inden for hardwareudvikling,« siger Bent Jensen.



13. apr 2010 kl 14:52

Rolf Østergaard

Serviceinfo: Erfagruppe

Som en lille serviceinfo kan nævnes at Bestbrains og Axcon faciliterer en erfa-gruppe om emnet agil/lean udvikling af integrerede produkter (altså med hardware, software, mekanik og andre dicipliner).
Læs mere på vores web: www.axcon.dk/blog/nyheder/agil....htm
Der er plads til flere deltagere


13. apr 2010 kl 21:21

avatar

Bent Myllerup

Supplerende erfaringer med Scrum

Her er der nogle supplerende erfaringer med anvendelse af Scrum i forbindelse med elektronikudvikling

Hos TC Electronic i Risskov har man ligeledes gennem de seneste to år anvendt Scrum i forbindelse med produktudviklingen. Erfaringerne er positive og resultaterne nærmest storslåede.

Tilgangen til indførsel af Scrum ved TC har været at koncentrere sig om udvikling af hele produkter og ikke blot indføre Scrum særskilt i software eller hardware udvikling! Scrum teamene består altså både af systemprogrammører, embedded udviklere, elektronikingeniører, konstruktører, designerer og testere med domænekendskab. Det er altså tværfagligheden som hyldes frem for isolerede faglige discipliner. Teamene arbejder tæt sammen med tilknyttede business managers og program managers, der tilsammen dækker Scrum Product Owner rollen for det enkelte team.

Den valgte tilgang har skabt et fantastisk grundlag for forståelse af produkternes kunder og brugernes behov, hvilket understøtter udvikling af helstøbte og sammenhængende løsninger og eliminerer flaskehalse i teamt. Dette skyldes at hver enkelt medarbejder har forpligtet sig på det endelige mål (det færdige produkt) frem for individuelle delmål.

Som Bent Jensen udtaler i artiklen, kan man ikke uden videre kopier de metoder som rene software teams anvender når der er tale om hardware eller blandede teams. Faktisk kan et rent software team heller ikke forvente at kunne kopiere et andet rent software teams metoder uden at der sker tilpasninger. Det er derfor vi taler om Scrum som et rammesystem, frem for en egentlig metode eller proces. Scrum bliver først en metode den er implementeret i organisationen.

Tilpasning af Scrum til også at kunne dække elektronikudvikling, må ske med et stort refleksionsrum i teamene og organisationen som helhed. Jeg anbefaler at man behandler indførelsen af Scrum som et forandringsprojekt i virksomheden, således at der er det fornødne ejerskab og ledelsesmæssige støtte til at kunne sikre en succes. En væsentlig del af reflektionsrummet opnås ved at teamet afslutter det enkelte sprint med aktiviteten Sprint Retrospective, hvor teamet forholder sig til sin læring og sætter mål for dets procesforbedring.

Der er elementer i elektronikudvikling som nærmest kolliderer med principperne bag Scrum. F.eks. er printspin og sourcing af komponenter, der oftest er langstrakte forløb, en stor udfordring i forhold til de kortvarige og intense sprints (”sprints” er den originale betegnelse for de cykler der omtales i artiklen). Hvor sprints er forløb på maksimalt en måneds varighed med veldefinerede mål for blokke af funktionalitet, er printspin oftest forløb på mere end 6 uger hvor man arbejder sig frem mod at blive så færdig som muligt med hele elektronikprint. Ved TC Electronic kører teamene med hhv. 2 og 3 ugers sprint. Forsøger man at mappe printspin over i Scrum sprint uden at definere konkrete mål for hver enkelt sprint, kommer man nemt til at udvande effekten af Scrum. Hvis man f.eks. definere Scrum sprintenes delmålene for printspinnet som ”fase 1”, ”fase 2”, ”fase 3”, osv. i stedet for ”kritiske komponenter sourcet”, ”schematic klar til layout”, ”floor planning udført”, osv., fjerner man muligheden for at kunne evaluere om delmålene er nået og dermed er målingen af projektets fremdrift heller ikke bedre end hvis man havde anvendt en traditionel metode.

Den forøgede effektivitet som Scrum giver virksomheden bygger på følgende elementer, som bør adresseres i nævnte rækkefølge:
1) DONE! – det at teamet sprint efter sprint er i stand til fuldt ud at færdiggøre og opfylde de satte delmål for projektet.
2) READY! – det at de som stiller krav og laver den overordnede planlægning (vi kalder denne rolle for Product Owner i Scrum) er i stand til at stille klare krav som teamet kan anvende som driver for dets arbejde og målopfyldelse. Kravene skal stilles i fornuftig tid før sprintets planlægningsmøde.
3) Selvorganisering – det at teamet oparbejder modenhed som et højtydende team og gives det fornødne råderum til at træffe de kloge beslutninger om løsning af arbejdsopgaverne.

Hvis man ikke efterstræber at kunne opfylde disse elementer, vil man ikke opnå det bedst mulige resultat med indførelse af Scrum.

Man kan læse mere om grundlæggende forhold i Scrum i den officielle Scrum Guide, som bl.a. findes i en dansk oversættelse på http://www.scrum.org/scrumguid...des.

TC Electronic har sammen med andre interesserede virksomheder i det jyske dannet en netværksgruppe som adresserer Scrum i forbindelse med elektronikudvikling. Netværksgruppen er dannet under Scrum Forum, der er den danske Scrum User Group under Scrum Alliance. Interesserede kan få yderligere informationer ved at henvende sig til undertegnede på bemyl@tcelectronic.com.

Med venlig hilsen,

Bent Myllerup
Certificeret Scrum Coach og Product Owner ved TC Electronic.


Ny i debatten? Opret en brugerkonto

  • Seneste nyt
  • Mest læste
  • Topdebat
Populært på Facebook
 

Nyhedsbrev

Tilmeld dig vores nyhedsbrev.