Lasse Lasse

Ja. Har han mon noget at skjule?

Jeg er meget uenig. Den helt konkrete fejl vile blive fanget af en integrationstest af 75 minutters simulering af normal drift. Det er faktisk en utrolig ussel lille test.

Hvis nogen påstår, at sådan en test er for ressourcekrævende til at kunne gennemføres, må jeg spørge om følgende: Hvordan kan man så finde ressourcer til at drifte det 24/7/365 bag efter?

Men du har ret i, at typen af fejl kan være så sporadisk, at den ikke kan findes via tests. Men det gælder ikke for den konkrete fejl i artiklen.

Hvis man skal lære noget af det, må det være, at ordentlige tests af hele systemet er vigtigt. Man kan ikke nøjes med små hurtige unittests.

Martin: Er du softwareudvikler? Jeg spørger altså ikke for at fornærme, men fordi jeg kommer til at antage, at alle er det :)

Dit svar ligger nemlig ret langt fra det, jeg spurgte om.

Med dit mapping vil man jo som start bare vide, at "Funktionen X er for langsom". Og det, du ikke ved, er årsagen. Du har nu fået ansvaret for at dykke ned i C++ koden og løse det.

Sprintet starter senere i dag og varer 14 dage. Hvad lægger du ind i sprintet? (Opgavernes navne, epics/stories, hvad udfylder du i felterne med story points?).

Og vigtigst af alt, som jeg aller helst vil have svar på: Hvad gør du med dit SCRUM board, når "virkeligheden" ændrer sig, jeg som gav eksempler på?

Martin: Hvordan har I så håndteret diffuse opgaver? Lad os sige, at en bestemt funktionalitet er langsom.

At undersøge årsagen er en naturlig første task. Men man ved ikke engang, hvor lang tid undersøgelsen tager. Måske ser man med det samme, at det er netværksdelay. Måske skal man efter 5 arbejdsdage igang med at finde en egnet C++ profiler og tage den derfra.

Årsagen findes måske midt inde i 2. sprint, og løsningen er algoritmisk. Man afsætter så noget tid til først at lære om dem, men opdager efter noget tid en helt anden og simplere løsning.

Hvad lægger I helt konkret ind i de forskellige sprints? Kunne du evt. opdigte et konkret eksempel?

Et af målene er vel at hjælpe med at nedbryde opgaver til overskuelige bidder, så man ikke hænger fat i en kæmpe-opgaven

Jeg er "opfinder", både med software og fysiske ting, og både på hobbyplan og kommercielt. Jeg har også haft normale fuldtidsjobs med SCRUM. Så jeg har prøvet lidt af hvert.

Den håndfuld af de mest geniale ting/løsninger, som jeg har fundet på, er opstået via en meget lang grublen og tænken og en masse eksperimenter. Dernæst tilbage til start og forfra igen, utallige gange.

Tro mig, den process kan ikke opdeles på nogen måde. Den er diffus og kan ikke engang beskrives. Et sjovt eksempel er https://www.youtube.com/watch?v=13MhbNzqS_k som gennem en årrække beskriver et forsøg på at lave en blanding mellem en saks og en foldekniv.

Eller spørg enhver iværksætter, om de mon ville have haft gavn af at have haft en SCRUM master til at "hjælpe" med at styre deres tankebaner om deres nyskabende produkt.

Giv nu plads til innovation, det er det, Danmark skal leve af. Standardprodukter og hyldevarer er ret usikkert i dag.

Der er intet af det, som SCRUM gør, som du ikke kan gøre uden. Du kan lave deadlines og tidsestimater, du kan prioritere dine opgaver, du kan opfordre folk til at opdele opgaver, du kan arbejde i parallelt og du kan få endda samarbejde med dine brugere og få feedback fra dem.

Helt uden diktator.

produktivt team

"Falsk" fordi jeg gætter på, at hvis man lavede en statistik på overskredne deadlines, tror jeg ikke, at SCRUM virksomeheder ville klare sig signifikant bedre. Men dette er dog et gæt.

Produktivitet på grund af timeforbruget på micro management og møder, hvor man bliver afbrudt i sine tankebaner.

Innovation fordi man skal forsøge at få virkeligheden til at passe ned i en skabelon.

Kunden/brugeren kan se præcis hvilke opgaver der fokuseres på.

Hvad nu, hvis virksomheden er af en type, som overhovedet ikke har dette behov? Fx hvis du udvikler hyldevarer uden en bestemt kunde. Er der så ingen grund til at bruge SCRUM?

Og, kan kunden ikke se, hvad der fokuseres på, hvis man bruger Kanban? Man kan jo bare vise dem sin prioritetsliste. Du kan endda sætte tidsestimater på hver opgave uden problemer. Hvad er meningen så med SCRUM?

@Martin: Jeg kan ikke forstå dit svar. Siger du, at man skal diktere, at opgaven skal tage 2 uger uanset hvad, fordi SCRUM siger det?

@Ole Kaas: Præcis. SCRUM siger, at man så skal opdele opgaven. Og jeg gav et real life scenarie, hvor det kikser.

Alle steder, jeg har arbejdet med SCRUM, har burndown-grafen været vandret. Det er meningen, den skal gå linært skråt nedad.

Tilhængerne vil nu sige, at skyldes, at man ikke er dygtig nok til at underinddele sine opgaver og tidsestimere dem korrekt. Hvortil jeg typisk kommer med praktiske eksempler:

1. Der er en mærkelig sporadisk fejl i produktet, som ermeget diffus svær at reproducere. Du aner ikke, om det vil tage 1 eller 30 dage at løse, eller hvordan du skal starte. Hvad skal ind i sprintet?

2. En bestemt funktionalitet er langsom og skal optimeres. Som med opgave 1 kan det tage dig ned ad fuldstændig uforudsigelig veje, som overhovedet ikke kan planlægges på forhånd.

Tilhængerne vil svare, at SCRUM tillader fleksibilitet fordi verden er uforudsigelig og tilgiver dig når den ændrer sig.

Hvortil jeg så spørger, hvad værdien så består i i forhold til Kanban. Og sådan kører vi i ring.

Martin: Hvad gør man i SCRUM, hvis man har en opgave, som man kun ved, vil tage mellem 3 og 5 uger at løse, og ens sprints varer 2 uger?

Morten: Det var ikke hele story'en jeg trak ind i sprintet. Det var opgave A, som var veldefineret med story points, og gik ud på at undersøge hvordan opgave B skulle løses.

Martin: Vi snakker forbi hinanden.

Er vi enige om, at ingen opgaver må være så stor, at de ikke kan løses i et enkelt sprint?

Hvis ja, hvordan vil du så håndtere en diffus opgave, hvor du ikke på forhånd ved, hvor mange dage den vil tage?

Du er nødt til at indføre en slags "tovholder"-opgave, som kan indeholde de opdelte underopgaver, og en slags "måleenhed" for varighed.

Det kommer tit til at kollidere med den virkelige verden. Tilhængerne af SCRUM vil så påstå, at det fint tillader, at den fysiske verden er uforudsigelig. Det forbyder ikke, at du trækker opgaver ind og ud af sprints eller at "Actual story points" blier helt anderledes end "Estimated story points".

Mit svar er så: Hvilken værdi giver det så? I forhold til bare at have en liste af opgaver, som du tager fra en ende af.

Det er noget mere fundamentalt, der er galt.

Lad os sige, at programmet kan ikke finde ud, hvordan man tilføje et nyt kæledyr i en kæledyrsapp.

Man aner ikke, hvor stor opgaven bliver. Så man må oprette en epic som siger "A: Find ud af hvordan det skal løses, B: Løs det" og tildele 100 story points til A.

Da du ikke må forstyrres i dit sprint, skal du trække opgaven hen i næste sprint som starter om 12 dage. Da næste sprint starter, er brugeren blevet syg. Så du trækker opgaven ud af sprintet igen og trækker opgave X ind i stedet.

Brugeren er tilbage næste dag, så du er nødt til at trække opgaven ind igen, og det bliver SCRUM Burndown-grafen sur over, fordi X nu står som uløst.

Brugeren siger, at man bare skal skrive en anden tekst på brugerfladen, så er det super nemt. Du retter derfor de 100 story points til 10. Nu bliver SCRUM Burndown grafen glad igen.

Geez. Blev SCRUM opfundet i Strasbourg?

Udover det, så dræber SCRUM al innovation, fordi det ikke passer ind i rammerne.

Jeg vil anbefale alle at kikke på Kanban i stedet. Her har man en prioriteret liste af opgaver og så spiser man dem eller bare fra toppen af.

Jeg har forgæves kæmpet mod SCRUM gennem hele min karriere på alle mine arbejdspladser.

Jeg er kommet til konklusionen, at det er fordi følelsen af kontrol er vigtigere end selve arbejdet.

Det samme ses mange andre steder i samfundet.

Trist.

I stedet for at kaste fakta og argumenter mod hinanden tror jeg, at det i dette tilfælde handler mere om at indse, at ikke alle er lige som en selv, og at samfundet skal virke for alle.

Korrekt. Men hvordan beviser du, om du har åbnet postkassen derhjemme? Hvorfor skal IT systemet belemres med krav du ikke kan opretholde i den analoge verden?

Er du softwareudvikler?

Bare for at blive lidt konkret, så er C++ compilere blevet meget gode til at eliminere køretids bounds checks. Lad os prøve følgende på https://godbolt.org/, med -std=c++17 -O2:

int main(unsigned int i) { std::vector v {1, 2, 3}; i = i % 4; return v.at(i); }

.at(size_t index) funktionen skal kaste en exception, hvis index er uden for range, og vi kan se, at compileren tilføjer checket "cmpl $3, %eax".

Men hvis vi skriver "i % 3" så fjernes checket.

Selvfølgelig findes der problemer, som ikke er mulige at checke statisk. Hvis vi har en vector af aktiekurser over tid, og vi itererer fremad ind til vi finder et dyk i kursen, så afhænger indexeringen af værdier, som kun er kendt på køretid.

Hvis man er sikker på, at ens kode er korrekt, og performance er meget vigtig, kan man bruge [] subscript indexering, som aldrig vil checke på køretid.

I øvrigt - C++11 introducerede constexpr (garanteret evaluering af udtryk og funktioner på compiletid) og lempede kravene til, hvad såddanne udtryk måtte indeholde (if, else, aritmetik, etc) i C++17. Et gæt (og det er kun et gæt) er, at det måske har muliggjort at eliminere endnu flere køretidschecks, også af ikke-constexpr udtryk...

What I would really like is a language with all of the flexibility and power of C++ but without the pitfalls that leads to memory corruption.

If your program is in clean C++11 or later, then all the traditional memory errors are pretty much gone. Havn't seen a stray meory access, memory leak or double-free in such code because it's simply semantically impossible.

I have seen new classes of bugs though, that are due to the ever increasing complexity of the C++ language.