Certificeret Scrum Master og hvad så?

I denne uge har jeg været på kursus for at blive certificeret Scrum Master - og som jeg så Robert Martin (Clean Code-fyren) skrev på twitter;

"There are 50,000 Certified Scrum Masters! That's a measure of significant success and acceptance. Agility has crossed the chasm."

Disse mange certificeringer er altså et tegn på at Scrum bliver mere og mere udbredt - i teorien altså, for som Robert Martin også skrev;

"Agile isn't really that hard to understand. It's just hard to do – rather like losing weight."

Eksempler på, at projekter bliver kørt efter Scrummetoden på papiret, mens praksis er noget helt andet, ses ofte. En del af det 2-dages kursus jeg lige har været på, var fyldt med historier om faldgruber og historier om hvordan man genkender tegnene på at man misbruger Scrum. Scrumteorien er bestemt ikke svær, men det er praksis!

En del af problemet som jeg ser det er så også at man ikke skal overvurdere en certificering som Scrum Master. Den fortæller ikke specielt meget, fordi der jo ikke er eksamen efter kurset. (Men det kommer der.) Noget man ikke hører om så ofte er, at der er en mere sigende titel til dem der kan finde ud af at praktisere Scrum - Scrum Practitioner. Denne titel kræver dokumenteret erfaring med Scrum.

Kurset jeg var på, blev afholdt af Scrums ophavsmand Jeff Sutherland og som han fortalte os, så er certificeringen mest at sammenligne med et kørekort - når man får kørekortet er man ikke nødvendigvis en superbilist, men man kender færdselsreglerne og de grundlæggende begreber. Og så skal man ud og lave rav i den - ligesom de nyslåede certificerede Scrum Mastere. (Jeg er ikke helt enig i den betragtning, før der er indført eksamen i kurset, men derefter er det nok en meget god sammenligning.)

Når alle disse forbehold så er taget, så er jeg stadig glad for, at jeg har været på kurset. Agile udviklingsmetoder har ikke været en del af min datalogiuddannelse, så det er rart at have været på et kursus der tager fakta fra ende til anden og giver overblikket, i stedet for at man samler brudstykker op hen ad vejen. Det fik mig i hvert fald til at indse, at de gange jeg har forsøgt at køre Scrum på et projekt har været fulde af begynderfejl. Nogle gange er lidt viden værre end ingen viden.

I virkeligheden forsøger jeg nok bare at sige, at hvis man ser bort fra at titlen som certificeret Scrum Master virker misvisende, så er det et godt kursus, som jeg klart kan anbefale. Kurset er bare ikke nok - der skal praktisk erfaring til og krigshistorierne fra skyttegravene er nok noget man lærer mest af. Så hvad er din krigshistorie' Kører I Scrum - og bruger I hele metoden eller plukker I ud, hvad I kan li'' Virker det for jer' Eller er det hele bare overvurderet hype'

Therese Hansens billede

Kommentarer (19)

Thomas Wittenburg

Vi forsøger at køre Scrum i min projektgruppe på ingeniørstudiet, men det er virkelig svært at komme i gang med. I virkeligheden kræver det utroligt meget disciplin at få en gruppe på fem mand til at fungere i Scrum-sammenhæng. Så indtil videre kører en slags Scrum-light hybrid. Men målet er helt sikkert få det sat i system, så det fungerer, for det er et super værktøj, og det virker som noget, der er godt at have i bagagen til når vi kommer ud i det virkelige liv.

Så det jeg i virkeligheden prøver at sige, er at jeg også ser frem til en masse historier fra skyttegravene :o)

//Thomas

Pawel Lipinski

Hej
Det er ikke Certified Scrum Master, men Certified ScrumMaster. Forskellen er, at efter certificeringen er man ikke en 'Master' i Scrum, men man er certifieret som ScrumMaster - en role i et hold.

Som anden kommentar til posten, jeg synes alle udviklere bør have en Scrum training. Det er ikke at jeg tror at alle bør bruge Scrum i sine projekter, men lige for at få 'a gist' af hvad betyder det at være agile og at arbejde i et agilt hold, så man kan beslutte selv hvad de synes er en god måde at skabe projekter.

Pawel

Martin Falck-Hansen

jeg har flere gange ønsket at få den til trods for at jeg har et rimeligt godt indblik i Scrum og har kørt flere projekter med Scrum-agtige forløb. Jeg skriver "scrum-agtige" fordi det primært har det været den omgivende organisation som har bremset for en full-blown Scrum og f.eks. insisteret på traditionel projekt rapportering fremfor den dokumentation som Scrum projekter ellers leverer. Dertil kommer, at det kan være svært at praktisere "stop the line"-princippet om at gå tilbage og replanlægge når (ikke hvis) personer bliver taget ud til andre opgaver (læs: brandslukning).

CSM udemærker sig ved at deltagerne får et par dage med en underviser som ved meget om Scrum (Jeff er meget underholdende - jeg så ham på JAOO for et par år tilbage). Styrken og ulempen ved Scrum Practitioner er jo, at man skal have praktisk dokumenteret erfaring med Scrum. Det kan være lidt svært, hvis man arbejder et sted hvor der ikke køres Scrum.

Therese Hansen

Jeg mener ikke der er forskel på en Scrum Master og ScrumMaster - rollen i teamet som ScrumMaster er jo netop at være den der mestrer Scrum og kan guide resten af teamet. Deraf navnet. Selv Robert Martin skriver Scrum Master :-).

Jeg er til dels enig i din anden betragtning - derfor er titlen på kurset også endnu mere misvisende. Kurset er en gennemgang af Scrum af en der virkelig ved hvad Scrum går ud på (det er vist svært at blive Scrum Trainer) og hvis man har tænkt sig at køre Scrum burde man overveje at sende hele sit team på Scrum Master-kursus eller i hvert fald nogle stykker, som kan finde ud af at lære fra sig. At traditionelt styrede projekter burde tage på Scrum Master-kursus er jeg ikke enig i - det er nok overkill. Læs en bog om emnet istedet. Alle professionelle bør holde sig opdateret på hvad der rører sig på deres felt - i hvert fald i store træk.

I uformelle settings er den krigshistorie jeg hører mest nok den om at teamet holder morgenmøder, hvor man står op og svarer på de tre scrumspørgsmål - men resten af arbejdet bliver ikke udført som Scrum (Og Scrummødet trækker ud til en time, hvor alle og enhver udenfor teamet kommer og snakker, så det er heller ikke korrekt Scrum.) Teamet kender typisk ikke sin velocity, har ikke et Scrumboard (eller i hvert fald ikke et burndownchart), estimerer sine historier i timeantal (og så er velocity-begrebet ødelagt), bliver forstyrret af stakeholders gennem hele dagen, har opgaver i mange forskellige (ikke-alle-opdaterede) lister, får sprintopgaverne trukket ned over hovedet, kører 3 måneders "sprint" osv. osv. osv. - og når de så fejler, får Scrum skylden.

Therese Hansen

Det er typisk at der er bremser på i den omgivende organisation - og det er faktisk en rigtig god grund til at tage på Scrum Master-kursus; Jeff giver mange fif til at løse problemer med organisationen - det var et ret stort emne i kurset.

Uden at kende til de konkrete problemer i dit tilfælde, kan jeg fortælle at Jeff rådede til at man i tilfælde af at org. kræver traditionel projektrapportering, så skal man spørge sig selv hvorfor - 5 gange. Et eksempel kunne være: Hvorfor kræver din chef traditionel projektrapportering (hvad det så indebærer)? Fordi han skal rapportere til sin chef? fordi hans bonus afhænger af det? Fordi han ikke støtter Scrum og gerne vil se projektet fejle? Fordi han ikke kender fordelene ved Scrumprojekter? osv. - find et svar og spørg så hvorfor igen... Hvorfor kan han ikke se fordelene ved at køre Scrumprojekter? Fordi du ikke har vist ham effekten? Og hvorfor har du ikke det? Fordi dit team ikke måler jeres velocity og dermed ikke kan dokumentere at Scrum gør jer mere effektive? Og hvorfor så ikke det? Fordi I estimerer i mandetimer og derfor vil jeres velocity være meningsløs i forhold til at vise øget effektivitet. OSV.

Det er selvfølgelig tænkte eksempler, og først og fremmest tror jeg mange problemer kommer af at man som Scrum Master ikke tør at tro på at man kan ændre noget i org. - hvis chefen siger det, så er det nok det sidste ord i den sag.

Hvis det er en generel ting at folk bliver taget ud til brandslukning, så estimer med det og sig højt at I ikke kan nå længere i denne uge fordi jeres team ikke har fred til at arbejde på projektet. Scrum handler i høj grad om synliggørelse af issues - og måske er det bare sådan prioriteringen er i jeres org; Jeres projekt er ikke lige så vigtigt som brandslukningen - men sig højt at det er den prioritering, der bestemmer hvor hurtigt projektet går.

Altså det var sådan jeg forstod Scrum-træningen - det kan være der er nogle mere erfarne mennesker der vil korrigere?

Pawel Lipinski

Robert C Martin er en XP guy, ikke Scrum, så han kan tage fejl - spørg Ken Schwaber eller Jeff istedet :)

Nej, det mener jeg faktisk ikke, skønt på min certifikat står stolt 'ScrumMaster'.

Jeg er enig i, at CSM kan være en overkill for programører, hvis de ikke vil blive scrummastere. Jeg selv havde først 'Intro to agile and Scrum' og så CSM efter et år i forskelige scrum teams og synes at det var den bedste måde at blive virkelig ScrumMaster.
Men jeg er ikke enig i,at det er nok at læse en bog. Det er en speciel ting om agil, at man må føle det. Det er vigtigere at føle det end at kenne alle processer. Og det kan man kun opnå hvis man er i kontakt med agile-infected folk (karismatisk og motiveret).
Og det, du skriver om disfunktionelle scrum teams er netop fordi man ikke føler agil, og er stadivæk i en process-opfylde mode. Normalle scrum teams, der føler og forstår ideen bag scrum gør det ikke, eller prøver at gøre det ikke (det er min erfaring after at arbejde 1.5 år i tre forskellige scrum projekter).

Pawel
(og undskyld mit dårligt dansk, jeg har lært det herhjemme i Polen)

Michael Møller

Lad os lige kigge på argumenterne..

Jeg har selv været i en stor international biks, på et par store projekter hvor der blev kørt scrum. Mit indtryk er at det ikke hjalp det store. Nu var det et par lange projekter, så der var god tid til at få styr på tingene, men det var præcis det samme argument der kom op igen og igen – jamen det er fordi vi ikke kører rigtigt Scrum at det ikke virker, også blev der ellers nævnt at både microsoft og jeg ved ikke hvad skam brugte det og havde fået fantastiske resultater med det. I starten var argumentet for Scrum følgende. Kravene til store udviklings projekter ændrede sig hele tiden, og det kunne Scrum hjælpe med. Når man tænker nærmere efter er det forkert. Kravene ændre sig sjældent så voldsomt at det hele skal smides væk, tit skal der udbygges – og derfor er det så arkitektens opgave at sørge for at det kan lade sig gøre på en fornuftig måde.

Kravene var mere eller mindre væk, nu kom der en række kort sigtede mål fra en ”produkt owner”, i dette tilfælde en projekt leder. Der er ikke noget galt med kort sigtede mål, der hvor det går galt er simpelthen i rækkefølgen. Rækkefølgen er utrolig vigtig når man laver software, og man kan ikke bare starte et vilkårligt sted, og det kræver faktisk at man ved noget om software, det ved projektledere sjældent nok til at kunne vurdere. Scrum ikke en software udviklings metode, da den intet siger omkring hvordan man kan eller bør analysere, designe, skrive, teste software. Det er nok her det går rigtigt meget galt, hvis man smider alt hvad man ved om at lave software væk, og bare siger nu kører vi scrum.

Næste argument for at bruge scrum er at det er meget mere effektivt, projekterne bliver hurtigere færdig, tilfredse kunder, og bedre kode. Mere effektivt end hvad? – tit når jeg har hørt om virksomheder der opnår en 30% bedre effektivitet, har jeg efterlyst..hvad gjorde de da før?. Det melder historien ikke noget om, til gengæld hører man tit, vandfaldsmetoden. Men det er jo nærmere end software udviklings metode, der siger at man skal analysere, designe, implementere, og i parallel lave test. Scrum siger intet om rækkefølger eller om software. De projekter jeg har set kører hurtigt i starten, også langsommere og langsommere. Ikke i forhold til velocity, da det jo er et relativt mål i forhold til de opgaver der i backloggen, men langsommere i at nå målet om et færdigt produkt.

Jeg kan undre mig over at man til stadighed prøver at få en metode som alle siger, er så svær i praksis til at fungere, til trods for at den ser så nem ud på papiret. Og når man kommer med kritik får man at vide, jamen det er fordi du ikke kører scrum rigtigt.

Der er gode ting i scrum som er helt basal viden, det er sundt at mødes og snakke om hvordan det går, det er sundt at planlægge 2 – 3 uger ud i fremtiden. Men det er alt sammen ting som jeg enhver fornuftigt projektleder har gjort også før scrum kom til.

Scrum kommer nemt til at føles om micro-mangement og det er jo et paradoks, når metoden netop slår på at NU får udviklerne fred til at udvikle og ikke rapportere status. Faktum er bare at det lige præcis er det vi gør, hverdag på det daglige scrum møde. I stedet for at fortælle hvor lang tid vi har tilbage skal man nu så bare sige hvor mange timer man vil ”brænde” ned på en given task, men resultatet er jo det samme hvad enten man kan li det eller ej. Med de estimeringer der er lavet er det jo simpelt at regne ud hvornår man er færdig.

Jeg har ofte hørt at estimeringer bliver mere præcise, og det mener jeg er noget vrøvl. Det er stadig svært at vurdere hvor lang tid noget tager, fordi software udvikling også er en kreativ proces. Man prøver så at fjerne den statiske usikkerhed ved ”poker planning”, og tage gennemsnittet af usikkerhederne i håb om at gennemsnittet af usikkerhederne giver et bedre mål for hvor lang tid noget tager. Problemet er bare at det kræver at dem der er med i poker planning, dels har den domæne viden der skal til, og dem der er med i poker planning begrunder estimeringen med valget den løsning der kommer på bordet. Forskellige løsninger giver forskellige estimeringer, men ligger også vægt på forskellige kvalitets attributter. Og netop det forhold bliver aldrig berørt.

Jeg kunne blive ved, tror jeg har stof nok til en hel bog. Men min konklusion er at scrum i sin nuværende form sjældent fungere i praksis, og at det kræver meget arbejde og forståelse for software at få det til at fungere - og lad os da bare arbejde på at få det til at fungere, men fri mig for argumentet med at det ikke virker fordi jeg gør det forkert.

Ole Østergaard

Hej Michael

Jeg har til gengæld rigtig gode erfaringer med Scrum, og jeg har en anden opfattelse af mange af dine punkter.

For det første synes jeg at den klart største fordel ved Scrum og alle andre agile udviklingsmetoder er at kunden bliver tvunget ind i processen. Det kan godt være at det af og til kan virke meget irriterende at kunden har meninger om produktet, men det sikrer et bedre slutresultat. En del af idéerne i Scrum gå ud på at bruge denne kommunikation konstruktivt og sikre at man ikke spilder programmørernes tid.

Noget andet virkelig vigtigt ved Scrum er at man har et produktionsklart, kørende system hver 2.-3. uge. Det gør at alle bliver klogere på systemet efterhånden som udviklingen skrider frem, og man undgår at spilde flere år på at diskutere mulige designvalg på et alt for abstrakt niveau uden at komme nogen vegne. I stedet laver man det p.t. bedste bud. Viser det sig at være helt til rotterne, må man så bare rette på det når kunden synes det er tilpas vigtigt at gøre noget ved.

Synes kunden så efter 2/3 af projektets forløb at der er leveret nok værdi, kan kunden jo bare vælge at afbryde projektet og bruge det der er kommet ud af det indtil videre. Det synes jeg er en af de største styrker ved at kunden skal prioritere hvad der skal med i et sprint.

"Kravene ændre sig sjældent så voldsomt at det hele skal smides væk": Nej, det sker sjældent så voldsomt, men er man i gang med at skrive en ny applikation til en kunde, er det naturligt at kunden har lyst til at ombestemme sig i løbet af processen mht. visse dele af systemet efterhånden som det bliver brugbart. Pludselig ser kunden større potentiale i en del af systemet som tidligere ikke var prioriteret særlig højt, og så er det jo fint at kunden med Scrum ved næste sprintopstart (der typisk maks. ligger 3 uger ude i fremtiden) kan ændre på sine prioriteter.

Dette fungerer selvfølgelig bedst hvis man er i gang med at lave et nyt system til kunden. Mange projekter er blot re-implementationer af eksisterende systemer, og her får man ikke helt lige så god effekt. Men af og til ombestemmer en kunde sig altså ret markant mht. hvad der er vigtigst, og så skal man bare have en proces der giver råderum til dette.

"Der er ikke noget galt med kort sigtede mål, der hvor det går galt er simpelthen i rækkefølgen": Denne del af dit indlæg forstår jeg slet ikke. Jeg synes det er oplagt at kunden først får det der giver størst værdi. Ved sprintafslutning kan kunden så tage de nye dele af systemet i brug og tjene/spare en hulens masse penge på sin forretningsgang. Så er det selvfølgelig op til udviklerne at skrive ordentlig kode så det er muligt at udvide systemet med det man skal lave i næste sprint, og næste sprint igen... Det gør man ved at bruge ordentlige abstraktioner, teste rigtigt, ikke skrive "over-engineered kode" og den slags. Den slags siger Scrum ikke noget om, men det betyder absolut ikke at det er ligegyldigt!

"Scrum ikke en software udviklings metode, da den intet siger omkring hvordan man kan eller bør analysere, designe, skrive, teste software. Det er nok her det går rigtigt meget galt, hvis man smider alt hvad man ved om at lave software væk, og bare siger nu kører vi scrum": Ja, det vil da være aldeles tåbeligt!!!!

"Men det er alt sammen ting som jeg enhver fornuftigt projektleder har gjort også før scrum kom til": At have produktionsklar, kørende software hver 2. eller 3. uge? Det har jeg aldrig set før Scrum og de andre agile metoder.

"Det er stadig svært at vurdere hvor lang tid noget tager, fordi software udvikling også er en kreativ proces": Helt enig - estimering er altid gætværk. Men i stedet for at lave en stor, forkromet plan "up front" på baggrund af gætværk som det sker i vandfaldsmodellen, kan man i Scrum navigere fra sprint til sprint på baggrund af hvordan de forløbne sprint er gået. Og sandsynligvis bliver udviklerne også bedre til at estimere undervejs i et projekt, da de gradvist kommer til at kende domænet bedre og bedre.

/Ole

Michael Møller

Hej Ole, nu bliver det sjovt :)

At kunderne bliver tvunget ind i processen er ikke specielt for hverken scrum
Eller agile, faktisk er det beskrevet i objekt orienteret analyse fra 1993, og faktisk ligger alle udviklings metoder jeg kender op til det - heldigvis. At kunderne så kan finde det frustrerende kan jeg godt give dig ret i, men det er en nødvendighed. Alene for at forstå domænet, samt vægtningen af kvalitets attributter.

At man har produktions klart software, du skriver endda system kørende efter 2 til 3 uger, kommer godt nok an på hvad det er for et projekt. Nu kommer jeg fra en embedded verden, hvor det aldrig vil kunne lade sig gøre. Man kan godt have software efter 2 -3 uger som kan være produktions egnet, men produktions klart er det i hver tilfælde ikke. Men det betyder ikke at man bruger år på at vurdere design valg på et abstrakt niveau, det er jo dumt, og der må arkitekten sætte kursen og stoppe diskussionerne.

At kunden skulle afbryde et projekt efter 2/3 af projektet forløb fordi at kunden nu er glad for produktet er altid en mulighed, også uden Scrum. Tror aldrig jeg har været på et projekt hvor alt blev implementeret, for så kan man blive ved, der kommer hele tiden nye ideer – men begrænsningens kunst er vigtigt.

Vil lige beskrive hvad jeg mener med rækkefølger. Et simpelt arkitektur mønster som næsten findes over alt er en simpel opdeling i lag, du må kende det. Det betyder også at hvis man ikke skal til at skrive mange stubs ja så skal man have de nederste lag i en eller anden stand inden man begynder på det lag umiddelbart ovenover.
Det som typisk ender i ens backlog, er bare de øverste lag - det er det kunden kan se og derfor er det helt naturligt at der er fokus på det.
Når sådan et ønske bliver brudt ned under en scrum planlægning, ender man derfor med vertikale slices ned igennem ens lag. Altså en feature, eller dele af den fra bund til top. Og sådan en laver man bare ikke produkt moden på 2 – 3 uger!.

Så med rækkefølger mener jeg, at man skal passe på ikke at betragte sit projekt som en række af verticale slices igennem sin arkitektur. Derimod mener jeg at der ofte er et stort behov for at forstå hvad der skal i de enkelte lag, om de skal bruges af andre komponenter, og hvordan man får det designet på en måde så tilgangen til sådan et lag, eller service bliver nogenlunde konsistent så det er til at forstå at kode op imod. Det sjove er så når det under en scrum planlægning viser sig at man har brug for et service lag af en slags og et koncept for det, og tager det med ind i sin scrum plan – ja så slutter det gerne med at man naturligvis sammenligner det man har planlagt med kundens ønske, eller sit sprint mål. Og det kan ligge ganske langt fra hvis man skal implementere et service lag før kunden kan se noget. Også bliver scrum masteren frustreret, for så har man jo ikke noget produktions klart software kørende i en vertikal feature efter 2 – 3 uger. Det tager måske 6 uger, eller 4. Og så kommer spørgsmålet: Skal man så gå efter kundens ønske, eller bruge et sprint på at lave et koncept for sit service lag der holder mere end 2 sprints?. Jeg mener klart man skal gå efter konceptet og implementere det og ikke lade sig begrænse af om det kan gøres på 3 uger, eller om der skal komme demonstration ud.

Jeg er enig i at ens estimeringer bliver bedre med tiden, efter hånden som man får overblik og kender platformen, koden, sine kollegaer og hvad har vi, sådan vil det altid være, og det er også derfor at ”gamle” platforme selvom de måske rent teknisk ikke er fantastiske stadig er konkurrence dygtige fordi man ren projekt logistisk har stor erfaring med dem og derfor rammer mere præcist i sine estimeringer end med nye platforme, og det må bestemt også være en konkurrence parameter.

Ps: Jeg er glad for at du også ser software udvikling som en kreativ process. Tror vi skal kigge mere i den retning for at komme med nye metoder til at lære at styre software udvikling mere effektivt.

/Michael

Ole Østergaard

Der er flere ting fra dine indlæg jeg ikke kan få til at passe med min verden. Måske fordi jeg aldrig har lavet embeddede systemer?

Det med at man absolut skal have ét lag på plads i sin arkitektur før man begynder på det næste, er noget vrøvl i den verden jeg bevæger mig i. Man kan nemt starte med vertikale "tråde" i arkitekturen, og så efterhånden "lade dem brede sig" og udmønte sig i sammenhængende services, DAO'er osv., efterhånden som der kommer flere og flere stories til.

(Robert C. Martin gav en fantastisk keynote på sidste JAOO, hvor han bl.a. kom ind på dette. Jeg kan desværre ikke finde den på blip.tv - Therese, ved du om den er lagt op, eller om den er på vej?)

Det er noget der kræver disciplin fra udviklernes side, og det er helt sikkert noget af det sværeste ved at køre agilt, men fordelene opvejer klart ulemperne. Hvis ikke udviklerne har disciplin og sørger for at gruppere funktionalitet i services osv., så får man en rigtig dårlig kodebase.

Alternativet med at lave et helt lag før man bygger videre, giver "over-engineering" og spild, efter min erfaring. Desuden er der ingen der har nogen idé om hvor langt man er i opgaven, og om komponenterne rent faktisk kommer til at hænge sammen. Det ender altid med at "projektets helt" sidder dagen inden aflevering og limer alting sammen. Det kan jeg godt forstå at en Scrum-master bliver frustreret over :-)

Du nævner igen at du plejer at tage kunder ind i processen. Jeg har bare aldrig haft nogen kunde der har interesseret sig for mine DAO-klasser. Jeg har heller aldrig haft nogen kunde der har bekymret sig om ordentlig lagdeling i arkitekturen. Eller "clean code". Eller databaseskemaet. Men jeg har haft masser af kunder der har givet feedback på fungerende features, også selvom produktet på mange måder virkede halvfærdigt.

Alt andet lige vil jeg hårdnakket påstå at man med Scrum får kunden bedre med end hvis man insisterer på at have alle arkitekturlagene på plads ét ad gangen før man tør vise noget frem.
/Ole

Michael Møller

Jeg skrev vist ikke at:

"Det med at man absolut skal have ét lag på plads i sin arkitektur før man begynder på det næste"

min formulering var:

"så skal man have de nederste lag i en eller anden stand inden man begynder på det lag umiddelbart ovenover" - i en eller anden stand. Der kommer altså bare ikke noget på skærmen uden display driver, og der er flere afhængigheder i software. Men kender kunden dem? - næppe, og hvis ønsket er at få noget på skærmen inden for 3 uger hvad gør man så i scrum?. Jeg har set forskellige tilgange til det problem, men måske vi skulle spørge en scrum master? :)..

Du har ret i at store UML diagrammer osv. ikke har den store interesse for kunderne,kørende software er bare sjovere. Og jeg har intet sted læst at man skal gemme sin software for kunden indtil sidste linie er skrevet, heller ikke i andre metoder.

Jeg har dog været med til at holde en komponent tilbage indtil den havde en vis stabilitet og var klar til at blive integreret i "verden". Du kender det sikkert, en semantisk fejl i et interface som 20 andre komponenter pludeslig bruger og du kan aldrig få det rettet, og alle siger - det var dog et pudsigt interface det er da ikke logisk.

Du er inde på at udviklerne skal have disciplin, og det forbavser mig lidt, altså ikke at de skal have det, men at det kræver mere at køre noget agilt.

Hvorfor?

/Michael

Ole Østergaard

OK, vi befinder os i forskellige verdener, og som sagt har jeg aldrig lavet embedded software. Så hvis du siger at det vitterligt altid tager over 3 uger at få en display-driver op at køre, må jeg tro på det. I den verden jeg befinder mig i, er det nemt at få noget op i GUI'en (men knap så nemt at gøre det pænt, selvsagt).

Så i dit første sprint hvor du skal have display-driveren op at køre, har du et problem med at køre 100% Scrum. Det må man så bare leve med, og bøje reglerne for denne specielle opstart. Når den så kører, kan jeg ikke se hvad der skulle forhindre dig i at levere features på kortere tid end 3 uger? Eller tager alt bare minimum 3 uger når man laver embeddede systemer?

Hvilket naturligt leder frem mod lagene i arkitekturen - jeg tror vi har meget forskellige opfattelser her. Hvor jeg har en fornemmelse af at du gerne vil have lagene på plads tidligt, og måske også definere nogle services, DAO'er osv., så vil jeg hellere starte "billigt" med at få hul igennem fra den ene ende af systemet (GUI'en, eller hvad kunden nu ellers interesserer sig for) til den anden (databasen, fx) så hurtigt som muligt. Derefter, når jeg efterfølgende tilføjer features, kan lagene i arkitekturen udkrystallisere sig. Jeg sørger hele tiden for ikke at "gentage mig selv" eller lave kode som kun jeg forstår, og jeg rydder op efter mig selv.

Og det er her disciplin kommer ind. Det kommer af at man i starten forsøger at lave features hurtigt. Det er også fint, for der er ingen grund til at bruge tankekraft (og kodelinjer) på at forberede funktionalitet som kunden ikke tilvælger alligevel. Men man skal selvfølgelig hele tiden stramme metoder op, smide død kode væk, samle relaterede funktioner i services osv. Altså refaktorere. XP lægger meget vægt på denne del, men Scrum indeholder ingen kode-rettede elementer. Hvad jeg mener, er blot at man skal huske på det, især fordi dårlige projektledere (og dårlige Scrum-mastere) ofte giver køb på dette hvis et projekt er presset.

Alternativet, som jeg tidligere har set i vandfaldsprojekter, er at man i stedet lader kode rådne og dø, og så tager man og skriver om fra bunden af når det gør "ondt nok". Så hellere holde kodebasen levende og smidig.
/Ole

Michael Møller

Nah nu var en display driver bare et naivt forslag til en åbenlys afhængighed, som jeg viste vi kunne blive enige om var der. Om det tager tre uger eller ej at skrive sådan en har jeg ingen anelse om.

Faktisk tror jeg ikke vores verdener er så forskellige, vi bruger forskellige ord, men det er nogenlunde det samme vi snakker om tror jeg.

Jeg er sådan set enig med dig i at ”hul igennem” er en god strategi – af den simple grund at det ligesom giver ro i maven, og at ens komponent arkitektur ligesom falder på plads og man kan se at det nok skal gå det hele. Det er næsten som om at udviklere bruger induktion beviser ubevidst.
Og jeg tror der er flere gode grunde til det. For det første at se at ens software kan virke for en begrænset del mængde af det problem som skal løses. Et andet aspekt mener jeg helt klart er at få tvivls spørgsmål ryddet af bordet i en fart. Hvis man er i tvivl om at noget kan lade sig gøre i software, så er det med at få det afprøvet i en fart og få fortalt kunden at der skal en anden løsning på bordet. Her mener jeg ikke man kan vente til sprint 6. Hvis kunden påvirker ens backlog så man starter et helt andet sted.

Det som jeg til gengæld tror er en stor forskel, er at det du udvikler som regel har samme mønster.
Så du kender dine afhængigheder på forhånd, og det gør jo livet lidt nemmere.

1 stk GUI, 1 stk database, 1 stk service lag med en eller flere DAO(er) – har aldrig skrevet sådan en, men går ud fra at det er abstraktion over at hente data fra databasen på en måde som gør det lettere for GUI folkene at have med at gøre. Og her har du måske ret, at det mere eller mindre er lige gyldigt hvor man starter, forud sat at man bare ved lidt om hvad det er for en database (måske?).
Men jeg kan med tilfreds læse at du skriver at du selv helst vil starte med at have ”hul igennem”.
Håber kunden er enig med dig :), eller at du kan overbevise din backlog ejer at målet i sprint 1 er er ”hul igennem”.

Det er sjovt du skriver det med refactorere, for her er vi inde ved kernen af noget væsentligt.
Hvordan får du den task ind på din backlog? – for du har helt ret, det kode der kommer ud efter et sprint er ikke klar til produktion, det skal højst sandsynligt skriver om, efterhånden som man bliver klogere og det tror jeg er godt nok. Jeg synes bare tit de kunder jeg har set, har tænkt efter sprint demo. ”Godt klaret, næste problem”. Selvom man jo godt viste at meget skulle skrives om i næste sprint og næste igen. I de projekter jeg har været på, har jeg set en hel del af det, uanset hvad for en metode der blev brugt, så jeg tror det er faktum at man ikke rammer rigtigt første gang.
Men for få år siden kan jeg huske at det var projekt lederen der bremsede ”refactoring”, det var der sgu ikke tid til, vi gjorde det selvfølge alligevel af professionel stolthed så meget vi nu turde.
Kan en scrum master virkelig bremse refactoring?

Men du har ret i min betragtning om lagene, eller som jeg ynder at kalde det komponenterne, altså logiske firkanter indholdene flere klasser, moduler eller hvad nu det kan være der har et logisk ansvars område. Når den er så stabil at man som erfaren udvikler kan mærke at nu kommer der ikke flere store mega kasser, så kører vi. Det giver mindst 2 fordele i store projekter ihvertilfælde.

1),Jeg kender min arkitektur nogenlunde, altså kan jeg også lave en team organisation. Jeg ved simpelthen for mange folk projektet kan bære og hvor få. Og din arkitektur og din organisation vil altid følges af. Og de påvirker hinanden, og hvis organisationen vinder hver gang bliver det tit noget mystisk software. Her er scrum jo mere selvorganiserede og en mere organisk størrelse.
Så kan man vide hvor mange scrum teams der skal til at løse en given opgave?

2) komponenterne kan udvikles parallelt. Deres afhængigheder er på tavlen, eller på bagsiden af en serviet fra kantinen, og alle på hele holdet, ved hvem de snakker med, nemlig hvem der ”sidder” i de andre kasser der har streger hen til dem. Her synes jeg tit det har været svært med scrum, fordi at afhængighederne ikke var kendt på forhånd, så hvad for et scrum team arbejde nu med den klasse, komponent som jeg lige har opdaget jeg har en afhængighed til osv?. Og har de tid til at hjælpe, eller er deres mål for deres sprint et helt andet.?

Det er klart at hvis det mønster eller den samme komponent arkitektur man udvikler efter er den samme hver gang, så har man måske ikke så store problemer, så måske skyldes dine gode erfaringer dette simple faktum?

/Michael

Ole Østergaard

Jeg synes nu ikke jeg laver systemer der ligner hinanden - selvom jeg da for det meste har en database i den ene ende og en eller anden form for GUI i den anden. Men ikke altid. Jeg sørger for så vidt muligt at bruge frameworks der ikke har en vild og voldsom indlæringskurve og derfor er et problem ifm. Scrum. (Enkelte gange modsætter kunden sig det desværre, og så er der ikke noget at gøre ved det.)

Hvordan man får tid til at refaktorere? Der er flere måder at gøre det på:

  • Man kan parprogrammere, og har derfor altid "sin dårlige samvittighed" siddende ved siden af sig.
  • Man kan indføre tvunget kodereview når en "story" eller lignende er færdig.
  • Hvis ovenstående er glippet, og man har en smule kode liggende der trænger til en opstramning, så lægger man lidt til estimatet i næste opgave der kommer omkring denne kode.
  • Og hvis det går helt galt med ovenstående, må man tigge og bede sin product owner og forklare hvorfor denne kode skal ryddes op.

Nå, men diskussionen er efterhånden røget en del væk fra hvorfor man til at begynde med skal overveje Scrum. Og her er min holdning at jeg...

  • ...elsker at have en person på holdet hvis fornemmeste opgave det er at give mig ro i hverdagen (Scrum-masteren).
  • ...synes det er rart med "check points" hver 2. eller 3. uge (dvs. ved sprintafslutning/opstart), hvor man er sikker på at alt hænger fint sammen.
  • ...holder af "selvorganiserende teams" der i høj grad bygger på at folk laver det de synes er sjovest.
  • ...mener at det er sundt at stå i en rundkreds hver morgen og komme "up to date" med hvad hvert medlem på teamet laver.
  • ...bestemt kan se fordelene i fleksibiliteten man får ved at kunden kan lave om på prioriteterne hver 2. eller 3. uge.
  • ...kan lide at tage et kig på Scrum-tavlen for lynhurtigt at få et billede af hvordan sprintet går.
  • ...sætter stor pris på jævnlig feedback fra kunden.

Det får man med Scrum. Også med enkelte andre udviklingsmetoder, men i hvert fald med Scrum. Sådan er min erfaring i hvert fald.

/Ole

Michael Mortensen

Det jeg finder svært ved SCRUM modellen er opbygningen af teknisk gæld - netop kode der bør refactores fordi det måske liiige blev implementeret en tand for hurtig pga. en ivrig produkt owner eller to :-)

Her prøver vi så pt. med en hybrid - det kunne meget vel være en løsningsarkitekt der har en aktie fra udviklingsafdelingen, så teknisk gæld løbende kan blive indfriet.

Har store forventninger til dette, da der ellers er relativ høj risiko for en "autonom" kodebase ...

Lars Ole Belhage

OØ:
Jeg sørger for så vidt muligt at bruge frameworks der ikke har en vild og voldsom indlæringskurve og derfor er et problem ifm. Scrum. (Enkelte gange modsætter kunden sig det desværre, og så er der ikke noget at gøre ved det.)

Nemligt:
Har du ngole eksempler på FW som IKKE har denne indlæringskurve (og modsat) - og specielt hvilke det er kunder ønsker/fravælger... (jeg ville tro at kunde normalt vil give 'FF' (~ligeglad med) til hvilket FF man vil prædike ?) ?

Log ind eller opret en konto for at skrive kommentarer