Martin Storgaard Dieu

Cloud-ekspert: Fatal mangel på styring af nøgler i skyen driver mig til vanvid

Meget interessant problemstilling. Uden at være helt inde i hverken Rene Løhdes eller Cloudflares Keyless SSL, så synes jeg at noget af problemstillingen for begge løsninger overlapper.

Med Cloudflares Keyless SSL kan man holde sine private nøgler centralt og "nede på jorden" (modsat oppe i skyen).

Om princippet kan genereliseres er jeg ikke "sikkerhedsekspert" nok til at kunne svare på.

24. maj kl. 21:46
Er der noget godt at sige om cryptocurrency ?

Er der noget godt at sige om cryptocurrency ?

Det vil jeg vove at påstå at der er.

Jeg har snakket kryptografi, med personer, som jeg aldrig havde forestillet mig, at jeg skulle snakke kryptografi med. Det er altid startet med crypto currency, men har så bevæget sig over til reel kryptografi. Hashing, collision resistance, randomness, digital signatur, RSA, primtal osv.

Kryptovaluta har vækket en vis form for interesse for kryptografi, hos helt almindelige, ikke-tekniske personer. Det synes jeg personligt er godt. Om det er godt til prisen (CO2, ransomware, osv) er jeg i tvivl om. Men det er godt at flere viser interesse for at opnå basal forståelse for krypto.

18. maj kl. 22:36
Danskeres data deles 280 gange om dagen: »Det største databrud nogensinde registreret«

I rapporten står der noget ala (jeg kan ikke kopier fra den): Microsoft købte i December 2021 RTB virksomheden Xandr fra AT&T og udvider dermed dramatisk sin involvering i

17. maj kl. 18:06
Danskeres data deles 280 gange om dagen: »Det største databrud nogensinde registreret«

bygger på data hentet fra Google og dermed ikke fra store spillere i industrien

Er Google ikke en stor spiller i industrien? Altså Google er blot en lille privacy-venlig spiller i reklame branchen?

Interactive Advertising Bureau (IAB), der repræsenterer den digitale annonceindustri – og som indeholder blandt andre Google, Meta og Amazon

Ah ok.

17. maj kl. 18:02
Velkommen til det nye Version2

Andre har snakket om den horrible hastighed på siden , men hold da op formatting af debatindlæg på telefonen er ringe .

Telefonens tastetur sletter automatisk mellemrum før komma eller punktum. Dette ser ikke ud til at virke her .

Citering af andre debatindlæg ved at markere og trykke svar virker sporadisk . Eller måske var jeg bare ikke tålmodig nok . Jeg kunne se at jeg trykkede på "svar", men der skete ikke noget , med mindre at jeg fjernede markeringen .

Og så skal man lige tage formateringen af gamle debatindlæg med et gran salt . Reglerne er skiftet og den automatiske oversættelse har ændret layout lidt .

Kudos for WYSIWYG . Men implementeringen er... Øh... Skør

21. marts kl. 11:21
Netcompany-fejl gav adgang til skolebørns Aula-data: Alvorlig kritik af Kombit

testing og potentielle faldgruber

Man kunne også smide en gang peer review og andre kvalitetssikringsværktøjer oveni. Men igen, så tager det tid og dermed penge. Nogle steder bliver man nødt til at trække en streg i sandet, og sige at det er godt nok .

Jeg er i øvrigt imponeret over pen-test af et ordinært release

Fuldstændig enig!

21. marts kl. 11:09
Netcompany-fejl gav adgang til skolebørns Aula-data: Alvorlig kritik af Kombit

Det kræver så, at man skriver en automatisk test til den nye funktionalitet.

Eller at man skrev en håndfuld automatiske test til UNI-login med efterfølgende eskalering af privilegier via NemID, den gang man udviklede den funktionalitet.

Men givet dette scenario, med to forskellige brugere, så kræver automatiske test lidt mere avancerede test fixtures. Det tager tid og så bliver det typisk nedprioriteret.

Men forhåbentlig har de så lavet en automatisk test nu, så samme fejl ikke bliver reintroduceret igen.

21. marts kl. 10:26
Netcompany-fejl gav adgang til skolebørns Aula-data: Alvorlig kritik af Kombit

»Hverken Netcompany, F-secure (som udførte en ekstra penetrationstest i forbindelse med release 1.1.5), Kombit eller kommunerne havde grund til at tro, at den nye programmeringskode, der alene vedrørte IdP-loginløsningen, ville kunne påvirke UNI-loginløsningen, og at der derfor var behov for at teste UNI-loginløsningen yderligere,«

Det er jo ikke fordi at der ikke er blevet tænkt på at teste. Desværre er tænkte tests bare ikke nok. Automatiske test derimod - det virker!

“Program testing can be used to show the presence of bugs, but never to show their absence!”

  • Edsger W. Dijkstra
18. marts kl. 14:33
Arbejder I med sprints? Hvorfor egentlig?

Men hvor opstår opgaverne så?

Jeg er hverken produktejer eller produktmanager, men mit bedste bud er hos en stakeholder, som har set et behov der skal opfyldes.

For at svare på det spørgsmål, jeg antager du spørger om: Hvornor bliver de refinet? Det afhænger. Scrum begrænser det ikke eller dikterer hvornår eller hvordan det skal gøres.

Det kan være at produktejeren har så stor indsigt i produktet og detaljebehovet for udviklerne, at produktejeren alene kan gøre dette. Noget produktejeren normalt får igennem både sprint review, retrospective og planning.

Det kan være at man har afsat en en time til en halv dag hver uge, hvor man i fællesskab gør det.

Det kan være at udvikler, produktejer og stakeholders udveksler mails eller bruger et Kanban board, til løbende at refine "offline"/"async" i mellem context.

Det kan være at man afsætter et sprint til at refine de næste 2-5 sprints ud i fremtiden (Det er hvad SAFe gør).

Det kan være noget helt femte eller en kombination af ovenstående. Jeg har prøvet det hele og det afhænger jo helt sikkert af hvad der passer til de enkelte hold og organisationer. Scrum dikterer det ikke.

17. marts kl. 17:55
Arbejder I med sprints? Hvorfor egentlig?

Er du softwareudvikler?

Jeps

Sprintet starter senere i dag og varer 14 dage.

Så har jeg brugt tid på at forfine opgaven inden da. Dykket ned i koden for at finde mulige steder. Hvis jeg ikke allerede ved det, så finde ud af om jeg har de værktøjer jeg skal bruge. Du nævner at man pludselig opdager, at man skal bruge en ny profiler.

Er opgaven meget diffus, så kan man bruge det der hedder en spike. Altså en tidsbegrænset opgave, hvor man undersøger, eksperimenter og opnår en større indsigt.

Har man mange diffuse opgaver, så har man højest sandsynligt også en kæmpe bunke "legacy" kode, som ikke har den bedste software arkitektur. Måske man har kørt deadline driven development (en term der dukker op på mit linkedin feed)?

Hvad gør du med dit SCRUM board, når "virkeligheden" ændrer sig, jeg som gav eksempler på?

Husk på at i scrum, der committer holdet sig til et sprint mål. Hvis planen man har lagt (User Stories, Task o.l.) ikke er rigtig, men målet stadig er, så bruger man daily på at lave en ny plan. Opdaterer sit Kanban board (husk at scrum ikke har et board), så det er transparent for omverdenen, hvor man er, hvor langt man er osv.

Hvis målet ikke længere er gyldigt, så stopper man sprintet. Afholder review, retrospective og ny planlægning. Ofte lader man sprintet køre færdig, da man heldigvis kun har committed sig til 2 ugers arbejde.

17. marts kl. 15:54
Arbejder I med sprints? Hvorfor egentlig?

Hvad lægger I helt konkret ind i de forskellige sprints?

Som en del af refinement af opgaven vil jeg nok bruge øvelsen "Example Mapping". Det er en konkret metode, til at finde frem til ting man ved og ting man ikke ved. Her vil personer med teknisk viden mødes med personer med forretningslogik viden (nogle gange er der overlap).

Denne øvelse er et godt udgangspunkt i at nedbryde en opgave. Så kan man prioritere de ukendte, man i fællesskab tror, kunne være løsningen. Her tager man så toppen af de prioriterede løsningsforslag og definere hvad man opnår, hvis man løser disse det. Åbenlyst, så vil en mulig løsning på problemet være noget af det man får ud af det. Men hvad ellers? Optimering af forretningsprocessen? Bedre dokumentation? Nye værktøjer til hurtigere fejlfinding i fremtiden? Refaktoring af kode der lugter (code smell), så løsningen bliver nemmere at vedligeholde? Eller?

Hvad så hvis løsningen ikke bliver fundet? Uanset hvad, så mødes minimum de samme mennesker, som var med til example mapping til sprint review. Her deler man den viden man har opnået og kan så se på, om de resterende løsningsforslag, som ikke blev taget ind, stadig giver mening at hive ind eller om man har lært noget nyt, som måske er en bedre vej. Det kan også være at forretningen prioritere en anden opgave højere nu, men er glade for det, der dog er opnået.

Og sådan bliver man ved indtil løsningen er fundet eller forretningen/kunden/stakeholder skifter prioritet.

Indtil nu har jeg ikke berørt estimater. Det er naturligt, at kunden ønsker et estimat på leverance tid eller pris. I ovenstående betaler kunden for et sprint. Ved at nedbryde opgaven, så kan i sammen sætte målsætning for, hvad der er opnået i det sprint. Du får tid til at tænke og dykke ned i koden før du bliver tvunget til at give estimater. Du giver estimater på mindre og mere konkrete løsningsforslag. Kunden får ny viden i slutningen af sprintet og har mulighed for at tage beslutninger på baggrund af den viden; Fortsætte med andre løsningsforslag eller skifte opgave til noget mere værdiskabende?

17. marts kl. 06:38
Arbejder I med sprints? Hvorfor egentlig?

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.

Det lyder præcis, som den version af scrum, som jeg har arbejdet med!

Det lyder til at du har haft en dårlig oplevelse med noget, som nogen har kaldt scrum.

16. marts kl. 18:44
Arbejder I med sprints? Hvorfor egentlig?

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

Det lyder til at du har haft en dårlig oplevelse med noget, som nogen har kaldt scrum. 8 sammenhængende dage kun med 15 minutters møde er hvad scrum beskriver for 2 ugers sprint. En halv dag med planlægning før dette og så afsluttet med en halv dag med feedback fra slutbrugeren, samt planlægning optimering af arbejdsprocesser, redskaber, relationer og personlig udvikling. Alt andet er ikke fra scrum, men fra en organisation, som ønsker noget andet/mere.

15. marts kl. 09:00
Arbejder I med sprints? Hvorfor egentlig?

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?

Jeg stopper mine svar her og henviser til mine tidligere svar. Vi går lidt i ring og mit svar på de to spørgsmål er at finde i tidligere svar.

14. marts kl. 11:45
Arbejder I med sprints? Hvorfor egentlig?

Siger du, at man skal diktere, at opgaven skal tage 2 uger uanset hvad, fordi SCRUM siger det?

Jeg siger at man skal sørge for at involvere sin slutbruger og sørge for at få feedback. Om du kalder det Scrum, mini vandfald, Kanban eller Lasses model er under ordnet.

At nedbryde opgaven vil oftest blotlægge nogle af de fuldstændige uforudsigelige veje. Det vil blotlægge de antagelser de enkelte medarbejdere har. At bruge en time eller to på at kortlægge "known unknowns", kan spare en dag, en uge eller et måned i et kaninhul. Det er i øvrigt også en teknik man bruger i Kanban - hvis man vil.

Jeg siger at scrum er et værktøj. Nogle gange er det det eneste man har behov for, andre gange er det et andet værktøj, fx Kanban og nogle gange en kombination, fx Scrumban.

14. marts kl. 11:35
Arbejder I med sprints? Hvorfor egentlig?

opgave, som man kun ved, vil tage mellem 3 og 5 uger at løse, og ens sprints varer 2 uger?

Det afhænger. Scrum dikterer det ikke, så jeg kan tale ud fra egen erfaring. I projektplanlægning er der typisk tre parametre man kan rykke på, uden at gå på kompromis med kvaliteten: Scope, Budget, Tid.

Vi er allerede enige om at tiden er fastsat: 2 uger.

Hvad med budget? I scrum vil man gerne følge en fast og stabil rytme. Så foruden "9 gravide kvinder giver ikke en baby på 1 måned"-problemet, så bør man heller ikke tilføje flere hjerner. Hvis man på anden vis kan øge produktiviteten ved at bruge flere penge (måske bare midlertidigt) så er det et parameter der kan virke. Hurtigere udviklingsmiljø, kortere CI/CD kørselstider og lignende (I SAFe har man et system team, som kan hjælpe med det).

Og så er der scope. Den utrolig svære diciplin at mindske scope og samtidig give værdi til slutbrugeren. Det er nok her filmen knækker for mange, når man snakker Scrum.

Når man stadig er i gang med at lære disciplinen med scope, så er der mange som viser hvor man er i opgaven. Man snakker med slutbrugeren, om hvilke antagelser man har lavet, hvilke uforudsete problemer man løb ind i, hvordan man løste dem, hvor meget man er tror der er tilbage og hele tiden prøver at spore sig ind på om man er på rette vej.

Det vigtige er at man snakker med slutbrugeren. Tidligt og ofte. Afstemningsforventning samt minimere antallet af personer i mellem dem der har et behov, som skal dækkes og dem, som skal udføre opgaven.

Det er et overhead, som hjælper med at navigere i et komplekst system, forretningsområde eller kompleksitet generelt. Det er ikke noget, som alle har brug for. Hvis man arbejder på små trivielle opgaver i simple og veldefineret omgivelser, så er det kun et overhead uden værdi. Scrum er en torx skruetrækker. Nogle gange har man bare brug for lim, andre gange en pensel og nogle gange det hele.

14. marts kl. 10:40
Arbejder I med sprints? Hvorfor egentlig?

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.

Nej. Det behøver man ikke. Som Morten Jensen er inde på, så bruger man refinement på det. Noget som produktejeren er ansvarlig for. Ofte kræver det input fra både slutbruger og udvikler. Ofte er det implementeret som et møde. Men det behøver det ikke at være.

Man arbejder i rytme og når man kender sin rytme, kan man "eyeball'e" om behovet kan dækkes på et sprint.

Det vigtige, fra mit perspektiv, er at man får feedback fra slutbrugeren tidligt og ofte. Scrum tvinger feedback ved at have møder i slutningen af et sprint. Kanban kan man få det i irregulære intervaller (endda nogle gange når man kommer til testfasen i vandfaldsmodellen) og andre gange endnu bedre end Scrum.

(Lidt relateret men lidt off topic, så kalder SAFe ikke-værdiskabende arbejde for Enablers. Det kan man jo så mene om hvad man vil).

14. marts kl. 09:26
Arbejder I med sprints? Hvorfor egentlig?

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.

Man gør vel egentlig det samme i Scrum. Der planlægger man også bare hvad man ønsker feedback på fra slutbrugeren et sprint af gangen. Og så tjekker man hver dag om man følger planen, om den skal tilrettes og om man evt skal have hjælp fra andre til at komme videre.

Kanban og Scrum går godt hånd-i-hånd. Nogle kalder det endda for Scrumban.

14. marts kl. 08:43
Arbejder I med sprints? Hvorfor egentlig?

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"

Lad os lige blive enige om hvad vi snakker om. Epic er ikke en del af Scrum. Det samme med story points. Det samme med metrics og burn down.

En Epic, Feature eller User Story (for at holde os i den gængse terminologi) skal jo helst være værdiskabende for slutbrugeren. Gerne uafhængig af andre Product Backlog Items (PBI).

Din Epic burde forklare hvorfor det er værdiskabende og for hvilken slags slutbruger. Den bør forklare i akkurat nok detaljegrad, hvad det er slutbrugeren ønsker.

Hvordan det bliver implementeret er ikke en bekymring, som slutbrugeren behøver at have. Det er heller ikke sikkert at de har ekspertisen i det.

Det er (åbenbart) svært at tage et skridt tilbage og spørge slutbrugeren om hvorfor de har deres behov og hvilke roller disse behov dækker, før man begynder at snakke om krav, arkitektur, og implementeringsdetaljer.

Hvis du har afdækket hvorfor, til hvem og hvad, så er det fløjtende ligegyldigt om slutbrugeren er syg. Du ved hvad de vil have og hvorfor. Så kan du tilpasse din (langsigtet) arkitektur og implementere løsningen uden indblanding af slutbrugeren før løsningen er klar. I Scrum, der er det bl.a. det en produktejer er ansvarlig for (men de må gerne uddelegere arbejdet). I SAFe får de bl.a. hjælp af produkt manageren.

Det scenario du beskriver viser at produktejeren ikke lever op til deres ansvar.

Scrum er utrolig let at forstå og utrolig svært at gøre. Diciplinen med at forstå hvad slutbrugerens egentlige behov er og samtidig bryde det ned i stykker, som er små nok til at kunne blive leveret inden for et sprint (1-4 uger) og samtidig store nok til at være værdiskabende i sig selv. Jeg kan godt forstå at det er nemmere bare at gøre som man altid har gjort. Hvem har brug for forandring?

14. marts kl. 08:30
Arbejder I med sprints? Hvorfor egentlig?

Hvis man ikke bruger Sprint Review på at få feedback fra slutbrugeren og retter sit produkt/opgaver til baseret på den feedback, så er Sprint Review spild af tid.

Hvis man ikke bruger Sprint Retrospective på at se tilbage på arbejdsprocesser, arbejdsforhold, individuelle færdigheder og de redskaber man bruger med henblik på at lave umiddelbare forbedringer, så er Sprint Retrospective spild af tid.

Hvis man ikke bruger Sprint Planlægning, på at forene holdets fokus, på det der giver slutbrugeren værdi og dermed sikre at alle (udviklere, stakeholders, produktejere og slutbruger) arbejder sammen, så er Sprint Planning spild af tid.

Hvis man hele tiden bliver afbrudt i sit arbejde med nye krav, process ændringer, eller arbejder ufokuseret på mange forskellige opgaver på samme tid, så er Sprint spild af tid.

Hvis man lader udviklerne arbejde uforstyrret i en kort periode (1-4 uger, typisk 2), hvor de har samme fokus, samme scope og ingen møder (udover de daglige planlægningsmøder og de førnævnte inspektion og tilretningsmøder), så giver sprint mening. Man minimere risikoen for at arbejde på det forkerte, ved relativt ofte at se om man er på rette vej, mens man lader holdet samarbejde uforstyrret på det samme.

Scrum er et redskab. Ikke alting kan fikses med en torx skruetrækker. Hvis man er vant til at bruge lim, søm eller skruer med Phillips hoved, så kan torx skruer se mærkelige ud. Det kræver lidt tilvænning. Hvis man til gengæld bruger pensel til hverdag, så er en torx skruetrækker nok ikke det rigtige redskab.

Scrum er fantastisk når det virker. Det er et helvede at være i, når det aktivt bliver modarbejdet eller aktivt presset ned over hovedet på folk.

14. marts kl. 06:27