Scrum er, som jeg ser det en meget firkantet process. Dermed er den direkte i modstrid med "the Agile Manifesto"s første punkt "people over processes". Dette er nok årsagen til at Scrum er blevet så populær (hos ledelsen). Samtidigt virker det som om at Scrum forudsætter at teamet lever i sin egen lille beskyttede verden. I min daglige verden er der drift/incidents og de skubbes ikke til næste sprint! Samtidigt har vi en hel del opgaver sammen med andre i virksomheden. Her er det meget svært at forudsige hvad der kommer af opgaver og hvornår. Meget ofte er vi afhængige af svar fra ekstern tredjepart hvor svartid er ukendt. Scrum arbejder også med et princip med at alle kan håntere alle typer opgaver. Sådan ser vores verden ikke ud. De forskellige medlemmer i teamet har forskellige kompetencer, og supplerer hinanden. Der holdes stand-up møder, men det er mest en afrapportering af hvad man har brugt timer på, ikke hvor langt man er nået, da det er et krav i organisationen. Vi er en verden hvor der er eksterne "regulatory bodies" der kræver at all dokumentation er der. "Running code" er et af trinnene men langt fra det at projektet er færdigt. Det er i virkelighedens verden også meget svært at få den "project owner" der tales om til at eksistere. Det burde være en fra forretningssiden, men ..
Sidst men ikke mindst så savner jeg en udviklingsmodel der sørger for at der laves en arkitektur og et design før man koder.
Vi gør det, fordi vi skal, og så forsøger vi at holde os "under radarhorisonten" samtidigt med at vi forsøger at levere et produkt med en høj kvalitet.
Der er brug for afleveringsfrister som det vel hidder på almindeligt dansk. Det der er problemet er når de misbruges. Når der laves afleveringsfrister der ikke har hold i virkeligheden. Et af de store problemer idag er positivitisk (urealistisk) planlægning. Når man kommer med indvendinger bliver man ofte beskyldt for at være "negativ" og bagstræberisk. Jeg synes der er rigtigt mange eksempler på dette i øjeblikket. Det engelske udtryk "the perfect is the enemy of the good" indikerer også at man normalt har brug for en frist, så man undgår evige "forgyldninger".
For en kunde der har kvalitets og sikkerhedskrav, Sikkerhedsnettet f.eks, så er det ikke en rar tilbagemelding at få. Hvis man som virksomhed har sikkerhedskrav til den software man får leveret, så er en sådan "karakterbog" ikke fremmende.
IEEE Spectrum bladet fra februar 2019 indeholder en artikel om "How Mayhem won a DARPA challenge..". Der er et hold mennesker med rødder i Carnegie Mellon University, CMU der har deltaget i DARPA's Cyber Grand Challenge. De har udviklet et værktøj der finder og patcher sårbarheder i software. Gruppen testede i 2014 deres værktøj med den samlede Debian distribution. Værktøjet fandt næsten 14.000 unikke sårbarheder i koden., heraf 250 nye sårbarheder. Det indikerer at selv om det er Open Source Så er der formodentligt læssevis af sårbarheder i det og det er nok i praksis umuligt at få reviewet al koden manuelt. Hvad gør vi så? P.S. De har vist nu dannet en virksomhed der hedder ForAllSecure.Der har gemt sig store sikkerhedshuller (muligvis ikke decideret ondsindet kode) i OS-SW i årevis før det blev spottet af nogen.
Nåede de lige at melde det inden GDPR trådte i kraft, elller ... Som jeg husker det, så har man 72 timer fra at en fejl opdages og indtil den skal meldes til myndighederne, ellers falder hammeren. Måske er der noget der skal kigges på her.
Sårbarheden viser at så at det ikke bare er "små kældervirksomheder" der har problemer med sårbarheder. Godt nok er der her tale om et "consumer product" men også de helt store i branchen har tilsyneladende problemer. Det viser bare i hvor høj grad der er brug for forberdringer på området.
I den forbindelse er en artikel fra IEEE Spectrum Februar 2019 meget interessant.https://spectrum.ieee.org/computing/software/mayhem-the-machine-that-finds-software-vulnerabilities-then-patches-themHvis linken ikke virker så gå til https://sprectrum.ieee.org og søg på "mayhem". Der er tilsyneladende en gruppe forskere på Carnegie Mellon Unversity, CMU, der er kommet ret langt på området. (CMU er der hvor USA's CERT er placeret). De har lavet en maskine der kan finde sårbarheder (og patche dem). I 2014 udsatte de Linux distributionen "Debian" for en analyse og fandt omkring 14.000 enkeltsårbarheder! Af dem var 250 nye sårbarheder! Jeg håber +£#"&?! ikke at der er nogle "Blackhats" der får fat i deres teknologi. NSA har den nok allerede. Spørgsmålet er så hvornår andre "stats-sponsorerede tjenester" får dem.
Der er ikke noget der hedder en strålingsradius. Hvis vi snakker om tilstedeværelsen af elektromagnetiske felter så er det nærmere WiFi systemet og Mobiltelefonnettet der genererer de nære felter, for ikke at tale om "helios" der midt på dagen om sommeren rammer os med en effekt på omkring 1 kW / m2 i et meget bredt spektrum.indenfor strålingsradius
Er, som en der er over efterlønsalderen, vandt til at tage notater med papir og blyant. Dog oplever jeg ofte unge mennesker der hellere vil skrive ned på PC'en "for det er hurtigere". Hvis de nu er hurtigere til at tage notater på Pc'en, hvordan får man så vist dem at de derved mister deres "tilstedeværelse i rummet"?
Sidder i et lille team i en stor organisation hvor teamet, som jeg ser det, er meget tæt på den verden du taler om. Det kræver fleksible kollegaer. Det passer dårligt i en verden med kontrolfreaks.
Når virksomheden så pludseligt vil være agil så glemmer man at analysere. Man kaster sig over udvikling men glemmer at se på hvor det er forsinkelserne opstår. Det er ofte i beslutningslagene. Hvornår gør man noget ved forsinkelserne der?
Der er samtidigt i den agile verden en mangel på forståelse for at der er en drift. Det er muligt der er defineret et sprint med en række opgaver, men det er ret uinteressant når der pludseligt er produktionsproblemer. Den agile verdens mantra med vi retter undervejs er ikke altid en mulighed. Der er rigtigt mange steder hvor fejl i drift er et no-go. Der er ikke noget med at "lige" ruller tilbage. Jeg fandt for et stykke tid siden følgende i en diskussion på Linked In "Another thing that gave me hope was during Facebook's IOP - I know this from my venture IP days - Their philosophy was "move fast and break things." And recently while I was at Facebook headquartes, I saw that motto had been replaced: there were signs on the wall that said, "Move slowly and fix your sh_t."
Når der så indføres "agile processer" så er det som man går over i den anden grøft og helt glemmer noget af det der står i The agile manifesto. "That is, while there is value in the items on the right, we value the items on the left more". Man glemmer balancen.
Nu aner jeg ikke hvor serveren fysisk befinder sig, men det burde, alt andet lige, være muligt at finde plads til en 1U server ;-)så har jeg noglet 1U Servere der kan side 3.5" Diske i
Der er endnu en af de små nevøer, der har givet et bidrag. Ved ikke om det er Rip, Rap eller Rup ;-)Jeg vil gerne sponsere én af de tre diske.
Ifølge bloggeren Brian Krebs https://krebsonsecurity.com så er en stor del af dette ret gamle data. De er mindst 2 til 3 år gamle.
Jeg meldte ind med brug af en Zywall USG 20. Er det et rimeligt FW valg når man ikke vil nørde selv, eller er den utæt som en si? Jeg har været med fra den gang hvor vores FW på arbejdet var et Tis Toolkit der af UniC blev kompileret på stedet på en HP-UX workstation. Siden blev det RedHat Linux med IP-chains og IP-tables. Nu prioriterer jeg min tid anderledes. Jeg forsøger at købe mig fra det, uden at det koster en bondegård. Den håndfuld Raspberry Pi's jeg har fat i hænger, når de er i brug, på træer ude i skoven. Ja rent bogstaveligt ;-).vi allesammen hele tiden råber UniFi
Njaee, det var sådan en situation jeg refererede til længere oppe i tråden. Havde besøgt en bekendt med mine to Ubiquity AP'er og set at det kunne dække deres hus. Så ville de selv købe ind. Det blev så to, så vidt jeg husker ZTE enheder. Derefter var det på jævnt jysk træls. AP'erne forventede, til konfiguation, et andet RFC 1918 net end det som huset router leverede. Det kunne ikke ændres. Det betød så at det var noget med kun at tænde et access point af gangen, og at sætte statiske IP adresser op i min medbragte PC mens jeg konfigurerede AP'erne, et af gangen. Det gik fra at være en varighed af "en kop kaffe" til en hel eftermiddag. Når vi taler om prisforskelle der ligger i prisforskellen "et par kopper kaffe latte" så kan det ikke svare sig at være nærig, med mindre man elsker at nørde med udstyret.... så behøver man ikke noget kompliceret.
Fik kablet LAN da jeg fik mit 2400 baud modem. Det var RG58 og BNC stk, trukket udvendigt på huset. Næste trin, da der kom ISDN var CAT5 trukket fra et krydsfelt i husets ene ende. Kabler ligger i kabelkanal langs panelet, invendigt i huset lngs ydervæggen. Fik WiFi da der kom en Mac i huset. Men alle faste maskiner/printere/NAS kører kablet. Da der var problemer med dækning af WiFi blev der indkøbt et Ubiquity 2,5 GHz Access point. Dækker fint hus på 150 m2, også terassen. Det at AP bruger POE gør at man kan opnå en rimelig WAF. Hvis du skal ha' et AP så sørg for at få et 2,5 GHz / 5 GHz AP. Der er en App til Android, "WiFi Analyser" som er god til at gå rundt og måle hvor god/dårlig dækning der er i boligen. Satte en Zyxel firewall bagved yousee's router. Har prøvet at skulle konfigurere et WiFi net med to ZTE AP'er for en bekendt. Det var ret træls. Så bliver man glad for Ubiquity. Hvis man vil kunne printe noget der ligner fotokvalitet er inkjet den eneste løsning. Med den mængde jeg (foto)printer nu er der problemer med printhovedet (Epson printer) på en blækprinter. Min standard printer var en Lexmark CS540N. Kostede under 1000,- og med en rimelig pris per side (købte stor SH patron). Da den døde købte jeg en CS410 DN, også til under 1000,-. Et skrummel på 20 kg men printer fin kvalitet, fornuftig farvegengivelse, har duplex men er lidt langsom.
Har her i weekenden siddet og læst i "Crosstalk Magazine", http://www.crosstalkonline.org/. Bladet (nu elektronisk) udgives af USAF Software Technology Support Center (STSC). Det ser desværre ud til at udgivelsen er gået i stå i 2017. November/December 2016 udgaven af bladet har titlen "Beyond the Agile Manifesto". Her er der et indlæg af Alistair Cockburn, en af medskribenterne på Agile Manifesto. En anden af artiklerne "Beyond the Agile Manifesto" er også spændende. Den ser på hvad der får et team til at virke. En af erfaringerne fra Googles "Project Aristotele" er:
"that the real key ingredients are the interactions of the team members and the structure of their work. The No. 1 characteristic Google identified, and that they asserted made the most difference in whether a team could be high-performing, was the presence of psychological safety". samt: "the final piece is the realization that members of those teams need to feel that they are operating in an environment in which they can not only do their best work but also learn from their failures."
Dette står i skærende kontrast til den måde hvorpå vi opfører os her hjemme, især i offentlige projekter. Folk får mundkurv på. Man vil ikke have at der er nogen der kigger projektet efter i sømmene. Embedsværket/politikerne gør tilsyneladende deres bedste for at undgå high-performing teams.
Verden er ikke sort/hvid. Det hjælper næppe noget at fyre den siddende leder, men det jeg gerne vil have er at der kommer noget ind i diverse lederes successkriterier der gør at det vi andre benævner som "sund fornuft" / "rettidig omhu" vægter kraftigere. Eksemplet fra Mærsk med at der var bevilget penge til opdateringer af servere, men da det ikke var på de respektive lederes "score cards" så var det ikke blevet sat i gang, er et af de klareste eksempler. Et andet eksempel er, at lederne i Bane Danmark fik en stor bonus til trods for at der var et voldsomt overløb. Som sidste eksempel kan vi se på Skat hvor der sikkert er nogle ledere der har fået nogle pæne bonusser for at implementere besparelse der nu koster samfundet et to-ciffret stigende milliard beløb der løbende stiger. Hvis bare der havde været en minimum at påvirkning af disse minstre/departementchefers løn/pension hvis deres handlinger medførte tab så havde de måske ikke opført sig (så tåbeligt) som de gjorde.Det ville blot resultere i et gyldent håndtryk,
Her er det klassiske dilemma, brugervenlighed kontra sikkerhed. Vi vil gerne have begge dele, men det er svært at få. Web shops vil gerne have sikkerhed (for at de får sine penge) men på den anden side skulle brugeren helst ikke nå at "hoppe af krogen" fra sit impulskøb. Derfor vil mange forretninger at der ikke kræves "two -way authentication" for små beløb. Når de så har tab hyler de op. Den nærmeste fremtid bliver en lang sej kamp om at tilvende brugeren til sikkerhed. Samtidigt bliver hackerne mere og mere udspekulerede. Det er svært at forstå, især i et land som Danmark hvor vi grundlæggende kan kunnet stole på hinanden. Det bliver spændende hvor længe det varer inden der kommer betingelser / regler / bekendtgørelser / love der tillader ISP'er at blokere netværk hvis der er en "bot" i dette netværk.
Så kommer det spændende spørgsmål, hvilke virkemidler har datatilsynet? Overfor private virksomheder har de med GDPR fået en meget stor økonomisk vognstang at vinke med. En vognstang der vil kunne få de fleste CxO'er til at makke ret. Hvilke virkemidler har de overfor offentlige projekter? Uddele en næse hvorefter organisationen forsætter som de plejer? Hvordan får man offentlige ledelser til at gøre noget ved det? Skal der være regler for at bonus først udbetales efter 2 år og kun hvis der ikke er kommet "lig i lasten" siden da. Skal en bonus være betinget at at der ikke kommer påbud fra Datatilsynet? Er der andre muligheder?
Der tales ved agile projekter om, at man hele tiden kan ændre tingene, og at det er forretningskrav der styrer det. Det skurrer i mine ører når jeg tænker på store systemer. Hvis man ikke får lavet en ordentlig arkitektur bliver det ikke et godt system. Jeg mangler i dag en respekt for systemarbejdet. Hvis der ikke er en ordentlig arkitektur så når vi ikke i mål. Arkitekturen skal defineres først og laves ordentligt (af en meget lille gruppe). Ideen med at vi bare laver refaktoring holder ikke. Et af de tydeligste eksempler herpå er Kent Beck eXtreme programming projekt for Chrysler, der fik masser af omtale, men som aldrig kom i drift.
Chris Bagge