Smidighetsbevegelsen representerer alternativer til tradisjonell prosjektledelse i utviklingsprosjekter. Smidige metoder brukes typisk for å la utviklingsorganisasjoner respondere på usikkerhet og uventet hendelsesforløp. Scrum er den mest populære måten å introdusere smidighet, på grunn av sin enkelhet og fleksibilitet.

Tradisjonell plandrevet programvareutvikling er basert på separate utviklingsfaser hvor resultatene som skal produseres i hver fase er planlagt på forhånd. Selv om det man oftest tenker på her er vannfallsmetoden, er det også mulig å ha plandrevet inkrementell utvikling. Iterasjonen finner her sted i aktivitetene.

I smidig utvikling er spesifikasjon, design, implementasjon og testing flettet sammen, og resultatene fra utviklingsprosessen bestemmes ved hjelp av forhandlinger for hver iterasjon. Målet er å redusere overhead (forslag til bedre norsk ord mottas) i programvareprosessen, og sette seg i stand til å respondere hurtig på endrede krav (fra kunden eller omgivelsene) uten unødig dobbeltarbeid.

Prinsipper for smidige metoder

Prinsipp	Beskrivelse
Kundeinvolvering	Kunder bør være involvert i hele utviklingsprosessen. Rollen deres er å angi og prioritere nye systemkrav, og å evaluere iterasjonene av systemet.
Inkrementelle leveranser	Programvaren utvikles inkrementelt, hvor kunden spesifiserer kravene som skal inkluderes i hvert inkrement.
Mennesker, ikke prosess	Ferdighetene til utviklingsgruppen bør anerkjenens og utnyttes. Gruppemedlemmer bør få lov til å utvikle dine egne måter å jobbe på, uten obligatoriske prosesser.
Omfavn endringer	Forvent at systemkravene kommer til å endre seg, og planlegg systemet slik at det kan ta høyde for slike endringer.
Hold det enkelt	Fokusér på enkelthet både i programvaren som utvikles og i utviklingsprosessen. Overalt hvor det er mulig bør man jobbe aktivt for å eliminere kompleksitet fra systemet.

Manifestet for smidig programvareutvikling

I 2001 publiserte 17 programvare-guruer et manifest for smidig programvareutviking:

Vi finner bedre måter å utvikle programvare på
ved å gjøre det selv og ved å hjelpe andre med det.
Gjennom dette arbeidet har vi lært oss å verdsette følgende:

Personer og samspill fremfor prosesser og verktøy
Programvare som virker fremfor omfattende dokumentasjon
Samarbeid med kunden fremfor kontraktsforhandlinger
Å reagere på endringer fremfor å følge en plan

Dette vil si: Selv om punktene som står til høyre har verdi,
så verdsetter vi punktene til venstre enda høyere.

Den høyeste prioriteten er å tilfredsstille kunden gjennom tidlig og kontinuerlig leveranse av programvare som gir verdi for virksomheten. Bygg prosjekter rundt motiverte enkeltpersoner, og gi dem omgivelser og støtten de trenger, og ha tillit til at de er i stand til å gjøre jobben. Det primære målet på framdrift er fungerende programvare. Med jevne mellomrom reflekterer gruppen på hvordan de skal kunne bli mer effektive, og tilpasser og justerer oppførselen sin deretter.

Begrepet Scrum stammer fra rugby; det er en måte å starte spillet på nytt, enten etter et mindre regelbrudd eller hvis ballen er spilt ut over sidelinjen. Spillerne møtes i en klynge rundt ballen, denne klyngen kalles en scrum.

Scrum vektlegger empirisk tilbakemelding, selvadministrasjon av gruppen, og å anstrenge seg for å bygge skikkelig testede produkt-inkrementer i løpet av korte iterasjoner. Scrum har kun tre roller: Produkteier, Utviklingsgruppe, og Scrum-mester. Ansvar og oppgaver til den tradisjonelle prosjektlederen er delt mellom disse tre rollene. Hvis man skal gjennomføre Scrum slik det faktisk er definer kommer vanligvis i konflikt med eksisterende vaner i etablerte ikke-smidige virksomheter.

Et resultat av smidige metoder er at programvareutvikling blir en kontinuerlig prosess. Dette medfører kontinuerlig planlegging, kontinuerlig budsjettering, kontinuerlig integrasjon, kontinuerlig utrulling, kontinuerlig leveranse, kontinuerlig verifisering, kontinuerlig innovasjon og kontinuerlig eksperimentering. Testing har også blitt kontinuerlig – men hvordan påvirker disse verdiene sikkerhet?

Over 70% av sikkerhetsfeil og sårbarheter finnes på applikasjonslaget, ikke nettverkslaget. Som vi har nevnt før, er omtrent halvparten av sårbarhetene som introduseres i programvareutvikling designfeil. OWASP har et eget kodegjennomgangsprosjekt, og de har i løpet av det siste tiåret gjennomgått tusenvis av applikasjoner. I hvert eneste av disse tilfellene fant de alvorlige sårbarheter. Vi må følgelig konkludere at dersom du ikke har hatt en sikkerhetsgjennomgang av koden din, er sannsynligheten for at den inneholder sikkerhetsfeil så godt som 100%.

Det har vært hevdet at det koster hundre ganger så mye å fikse en sikkerhetsfeil i produksjon som i koding eller design. Det er ikke sikkert dette stemmer fortsatt, ettersom DevOps og kontinuerlig utrulling gjøre det enklere å gjøre raske endringer, men det er klart at sikkerhetsfeil i design kan medføre at man må gjøre dramatiske endringer flere steder, og dette er alltid kostbart. Det er derfor bekymringsfullt når de fleste sikkerhetsfeil skyldes koding eller design, men vanligvis ikke finnes før det gjøres penetreringstesting (eller faktiske angrep).

Grunnleggende forskjeller mellom hvordan vi oppfatter smidig utvikling kontra sikkerhet

Smidig utvikling

• Hastighet og fleksibilitet
• Korte sykluser
• Begrenset dokumentasjon
• Funksjonalitetsdrevet

Sikkerhet

• Stabil & grundig
• Ekstra aktiviteter
• Omfattende analyse
• Ikke-funksjonell

Oueslati et al. formulerte i 2016 fem utfordringer for sikkerhet i smidig utvikling:

1. Programvareutviklingslivssyklusen
2. Inkrementell utvikling
3. Hvordan oppnå tiltro til sikkerheten
4. Bevissthet og samarbeid
5. Administrasjon av sikkerhet

Vi skal i det følgende gå inn på hver enkelt av disse.

Utfordring 1/5: Programvareutviklingslivssyklusen

Smidige metoder har i utgangspunktet ingen aktivitet for identifisering av sikkerhetskrav, og heller ingen støtte for risikovurdering. Sikkerhetsrelaterte aktiviteter må typisk anvendes I hver utviklingsiterasjon, men tiden som er satt av til hver iterasjon er begrenset, og lar seg ikke nødvendigvis tilpasse tidskrevende sikkerhetsaktiviteter.

Produkt-bakleksa (product backlog)

Produkt-bakleksa er den klart viktigste artefakten i smidig utvikling. Den er et detaljert analysedokument som skisserer hvert et krav til systemet, prosjektet, eller produktet. Den kan være beskrevet som en omfattende “å gjøre”-liste, angitt i prioritert rekkefølge basert på forretningsverdien hvert enkeltarbeid vil generere. Scrum-bakleksa er motoren til virksomheten; den bryter historien fra “det store bildet” ned i håndterbare arbeids-inkrementer kalt produktbaklekseelementer (Product Backlog Items – PBIer)

Sprint-bakleksa (Sprint Backlog)

Sprint-bakleksa består av samlingen av PBIer forhandlet fram mellom utviklingsgruppa og produkteieren i sprintplanleggingsmøtet. Det omfanget man har forpliktet seg til står fast i gjennomføringen av sprinten. De første oppgavene identifiseres av utviklergruppen i sprintplanleggingsmøtet. Gruppen kommer til å oppdage ytterligere oppgaver som vil være nødvendige for å tilfredsstille den fastsatte omfangsforpliktelsen i løpet av gjennomføringen av sprinten.  Sprint-bakleksa er synlig for utviklergruppen, og blir henvist til i det daglige scrum-møtet.

Brukerhistorie

En brukerhistorie er en eller to setninger som beskriver hva en bruker ønsker seg fra systemet. Man starter med en tittel, og legger så til en beskrivelse, f.eks. etter følgende mal:

Som en [type bruker]
ønsker jeg å [utføre en eller annen oppgave]
slik at jeg kan [nå et eller annet mål]

Leg til andre relevante notater, spesifikasjoner eller skisser, og angi akseptansekriteriene (hvordan vet man at man er ferdig?).

Sikkerhetsaktivitet: Misbrukstilfeller (misuse cases) eller angrepshistorier

Vi kan lure applikasjonssikkerhet inn i programvareutvikling ved å skrive opp sikkerhetsrisikoer som historier. Som vanlig gjelder det å tenke som en angriper! Man kan gjerne formulere dette f.eks. som UML misbrukstilfellediagrammer, men tekstlige varianter kan fungere like bra.

Sikker kode lar seg ikke nødvendigvis representere som egenskaper

Programvaresikkerhet er ikke en brukerhistorie, og finnes ikke i produkt-bakleksa. Programvaresikkerhet kan ikke prioriteres inn eller ut, og det går ikke an å bestemme seg for at “vi gjør ikke sikkerhet i denne sprinten”.

Produkteieren

Produkteieren er den enkeltpersonen som er ansvarlig for å maksimalisere utbytte av investeringen (ROI) i utviklingsarbeidet, og er ansvarlig for produktets visjon. Produkteieren vil kontinuerlig re-prioritere produkt-bakleksa, og vil justere langtidsforventninger slik som utgivelsesplaner. Produkteieren er den som tar den endelige avgjørelsen om kravspørsmål, og aksepterer eller forkaster hvert produktinkrement. Produkteieren tar avgjørelsen på om man skal levere eller ei, bestemmer om man skal fortsette utvikling, og vurderer interessentenes interesser.  

Utfordring 2/5: Inkrementell utvikling

Refaktorering (eller omstrukturering av kode) bryter sikkerhetsbegrensinger, og kontinuerlige endringer i koden gjør det vanskelig å gjennomføre tradisjonelle sikkerhets-tiltro (security assurance) aktiviteter. Endringer i krav og design kan komme i konflikt med systemets sikkerhetskrav, og endringer i krav gjør det vanskelig å spore krav til sikkerhetsmål.

Smidig betyr stadige overganger – og hver overgang kan representere en risiko! Man går fra markedsføring/analytikere til arkitekter/designere, til utviklere, til kvalitetssikring, og til slutt til drift.

Microsoft har i den smidige versjonen av sin sikre utviklingslivssyklus (SDL Agile) delt sikkerhetsaktivitetene i tre grupper:

• Gjøres en gang
  • Aktiviteter som å etablere en responsplan, oppgradere kompilatorer etc.
• Gjøres i hver sprint
  • Forsikre seg om at man validerer data man leser inn og koder data man skriver ut på en sikker måte, og at man ikke bruker forbudte (usikre) APIer, etc. 
• Bøtte-aktiviteter som man gjør et utvalg av i hver sprint
  • Det er angitt tre “bøtter” hvor man velger en fra hver; bøtte A er sikkerhetsverifikasjon (f.eks. Fuzzing), bøtte B er designgjennomgang (f.eks. personverngjennomgang), og bøtte C er responsplaner (f.eks. lag eller oppdater kontaktlisten for bruk ved hendelser)

Sikkerhetsaktivitet: Trusselmodellering

Trusselmodellering er en strukturert tilnærming til å identifisere, kvantifisere og adressere trusler. Det er en essensiell del av utviklingsprosessen som burde være like selvfølgelig som spesifikasjon, design, koding og testing. Det finnes mange teknikker og verktøy tilgjengelig, som f.eks. Synopsys’ Architectural Risk Analysis, STRIDE og Microsofts Threat Modeling Tool.

Trusler mot applikasjonen

Trussel	Eksempel
SQL-injeksjon	Inkludere en DROP TABLE kommando i tekst som skrives inn i et felt
XSS (Cross-site scripting)	Bruk av ondartet kommandofil fra klienten for å stjele informasjonskapsler
Avlytting	Bruk av en pakkesniffer for stjele passord og informasjonskapsler fra trafikk på ukrypterte forbindelser
Sesjonskapring	Bruk av en stjålet sesjons-ID-informasjonskapsel for å aksessere noen andres sesjon
Identitetsjuks	Bruke en stjålet autentiserings-informasjonskapsel til å gi seg ut for en annen bruker.
Informasjons-røping	La en klient se innholdet av stakken når et uhåndtert unntak (unhandled exception) inntreffer

Av truslene over er det strengt tatt bare SQL-injeksjon, XSS og informasjonsrøping som er direkte relatert til programvaresikkerhet.

Sikkerhetsaktivitet: Kodegjennomgang

Gary McGraw regner kodegjennomgang som en av de viktigste programvarsikkerhetsaktivitetene. Man kan gjøre det manuelt ved å lese gjennom kode linje for linje, men det er særdeles tidkrevende, og svært avhengig av ekspertise. Det er følgelig vanligvis ikke regningssvarende unntatt for svært kritisk kode (som f.eks. referansemonitoren i et operativsystem).

Heldigvis finnes det mange statiske analyseverktøy på markedet som egner seg for å lete etter kjente feil. Imidlertid må man huske at mens det går an å bevise at et program inneholder feil, er aldri mulig å bevise at det er feilfritt.

Verktøy for statisk analyse er en tilnærming til hvit-boks analyse hvor man passivt leter gjennom kode uten å utføre den. Man studerer programvare “i ro”; primært dreier det seg om kildekode, men i noen tilfeller kan det også være (Jave) byte-kode eller binærkode. Resultatene presenteres vanligvis i rapports form, og statiske analyseverktøy kan integreres i utviklingsmiljøer (f.eks. Eclipse) og verktøy for kontinuerlig integrasjon/utrulling (CI/CD).

Utfordring 3/5: Tiltro til sikkerhet

Tradisjonelle sikkerhetsevalueringer (f.eks. iht. Common Criteria) forutsetter detaljert dokumentasjon, og det smidige manifestet fokuserer jo ikke noe særlig på dokumentasjon. Videre er testing generelt utilstrekkelig for å forsikre seg om at sikkerhetskrav er riktig implementert, og tester kan vanligvis ikke dekke alle mulige sårbarheter, ettersom det ikke er mulig å teste alle mulige kombinasjoner i kompleks programvare. For å gjøre det vondt verre, er sikkerhetstester generelt vanskelige å automatisere.

Kontinuerlig endring av utviklingsprosessene (for å ta opp i seg lærdom fra forrige sprint) er også i konflikt til evalueringskriterier som forutsetter enhetlige, stabile prosesser.

Sikkerhetsaktivitet: Bygging av en verktøykjede for sikkerhet

Det finnes mange forslag til slike verktøykjeder; her kommer et fra Securosis:

• Pre-Sprint (Tester og analyse)
  • Trusselmodellering
  • Liste med sikkerhetsfeil
  • Lapping og konfigurasjonsstyring
  • Måling og styring av retningslinjer
• Daglig (Tester)
  • Enhetstesting
  • Regresjonstester for sikkerhet
  • Manuell kodeinspeksjon elle rkodegjennomgang
• Hver Sprint (Innsendingstester)
  • Statisk analyse
  • Dynamisk analyse
  • Komponentanalyse
• Tillegg før utrulling (Tester)
  • Sårbarhetsvurdering
  • Penetreringstesting

Vi kan merke oss her at det er veldig fokus på tester, noe som sier oss at dette ikke kommer til å være nok alene!

Testing

Crispin & Gregory deler testing inn i fire kvadranter, hvor ytelses- og last-testing, sikkerhetstesting, og annen “-ility”-testing havner i den fjerde kvadranten som er vendt mot teknologien og går på kritikk av produktet. De fremhever behovet for verktøy i denne kvadranten

7 faktorer som påvirker ikke-funksjonell testing

1. Prioritet
   • Ikke-funksjonell testing blir vanligvis ikke prioritert, men det avhenger av egenskaper til systemet eller relatert funksjonalitet, prosjekttype, og hvor kritisk det er for forretningsdriften.
2. Tidspress
   • Funksjonell testing prioriteres over ikke-funksjonell testing pga. kort utviklingstid tilgjengelig for en gitt sprint eller utgivelse.
3. Kultur
   • (Manglende) vane for å tenke på og ta hensyn til ikke-funksjonell testing i utviklingsoppgaver
   • Av og til må man finne et kompromiss
     • Mer funksjonalitet kontra raskere og sikrere egenskaper
4. Erfaring
   • De mer erfarne medlemmene av utviklergruppen gir mer oppmerksomhet til ikke-funksjonelle aspekter, og forsvarer ikke-funksjonell testing med bakgrunn i tidligere erfaringer.
   • Yngre utviklere konsentrerer seg om hva som må leveres (primært funksjonalitet), og tenker i mindre grad på systemet som helhet eller kryssfunksjonelle egenskaper.  
5. Evaluering av utbytte av investeringen (ROI) når det kommer til testing gjøres typisk kun uformelt
6. Tekniske avhengigheter
   • Maskinvare, programvare og ressurser.
7. Sikkerhetsbevissthet til forretningssiden, utviklere og produkteiere
   • Hvis bevisstheten mangler, er det lav sannsynlighet for at det gjøres ikke-funksjonell sikkerhetstesting.

Utfordring 4/5: Bevissthet og samarbeid

Sikkerhetskrav blir ofte vanskjøttet (for ikke å si ignorert), og utviklere har vanligvis utilstrekkelig opplæring og erfaring i programvaresikkerhet. Når kundene i tillegg ofte mangler sikkerhetsbevissthet, blir resultatene deretter. For å sikre objektive resultater, må utviklerrollen være separat fra rollen som sikkerhetsevaluator, men i tillegg bør flere utviklere læres opp til å tenke som en angriper, slik at feil kan finnes før den formelle sikkerhetsgjennomgangen.

Utviklergruppen

I smidig utvikling er utviklergruppen kryssfunksjonell, dvs. omfatter all ekspertisen nødvendig for å kunne levere det potensielt leverbare produktet. Den er selvorganisert og selvstyrt, uten roller tilordnet utenfra, og består typisk av 7 ± 2 medlemmer. Utviklergruppen forhandler fram forpliktelser med produkteieren for en sprint om gangen, og kan bestemme selv hvordan den skal gå fram for å løse forpliktelsene. Smidige utviklergrupper er intenst samarbeidende, og fungerer best hvis de er plassert i et felles rom. Det fungerer også best hvis medlemmene deltar på fulltid over lengre perioder. Scrum flytter arbeid til en fleksibel, lærende utviklergruppe, og unngår å flytte på folk eller dele dem opp mellom utviklergrupper.   

Hva er rollen til utviklergruppen i sikkerhet?

Utviklerne fokuserer på funksjonelle krav, som oftest ses på som det som gir “verdi” til forretningsdriften, men de burde heller hatt en mer risiko-basert tilnærming med fokus på sikkerhet. Virksomheter som har en sikkerhetsleder opplever at sikkerhetslederen fokuserer på sikkerhetskrav og sårbarheter, men har vanskelig for å bli involvert i utviklingsprosessen. Testere er fokusert på funksjonell testing, og gis som regel ikke tid til å gjøre ikke-funksjonell testing. De har følgelig vanligvis lite kunnskap om sikkerhetstesting.

Microsoft utførte en studie for noen år siden som konkluderte at 64% av utviklere ikke har tiltro til sin egen evne til å skrive sikker programvare. Vi gjorde en mindre studie med et par norske virksomheter i 2016 hvor vi fant at 45% av utviklerne har moderat eller bedre ferdigheter i sikker koding. En interessant ting vi merket oss, var at dess mer erfaring en utvikler har, dess mer sannsynlig er det at utvikleren kan noe om programvaresikkerhet. Dette harmonerer med vår kunnskap om at det inntil nylig ikke fantes noe tilbud om utdanning innen programvaresikkerhet for generelle utviklere på norske utdanningsinstitusjoner.

Sprintplanleggingsmøtet

Produkteieren (PO) er ansvarlig for å erklære hvilke arbeidsenheter som er viktigst for forretningsdriften. Utviklergruppen er ansvarlig for å angi arbeidsmengden de mener de kan implementere uten å pådra seg teknisk gjeld (dvs. utvikle substandard løsninger som senere må forbedres). Hvis toppen på produkt-bakleksa ikke har blitt raffinert, vil en stor del av planleggingsmøtet brukes på dette. Utviklergruppen deler de utvalgte arbeidsenhetene inn i en første liste av sprint-oppgaver, og tar på seg en endelig forpliktelse for å gjøre arbeidet. De fleste utviklergrupper går ut fra at medlemmene kun kan fokusere på sprint-relatert arbeid i rundt 5-6 timer per dag. Utviklergruppen og produkteieren definer i fellesskap et sprint-mål (som tas opp til vurdering i den neste gjennomgangsmøtet).

Baklekseraffineringsmøtet

De fleste produkt-baklekse-elementer (PBIer) trenger i utgangspunktet raffinering fordi de er for store og ikke tilstrekkelig forstått av utviklerne. I baklekseraffineringsmøtet (backlog grooming) tar utviklergruppen en liten pause i sprintutførelsen for å bidra til å forberede produktbakleksa for det neste sprintplanleggingsmøtet.

Utviklergruppen estimerer arbeidsmengden de trenger for å ferdigstille elementene i produktbakleksa, og bidrar med annen teknisk informasjon for å hjelpe produkteieren med å prioritere dem. Store, vage elementer deles opp og gjøres tydeligere, med hensyn til både forretningsmessige og tekniske forhold. Noen ganger vil en undergruppe sammen med produkteieren og andre interessenter kombinere og dele opp PBIer før man involverer hele utviklergruppen i estimeringsarbeidet.

Sikkerhetsaktivitet: Protection Poker

Som trofaste lesere av bloggen sikkert husker, var Protection Poker opprinnelig foreslått som en aktivitet i sprintplanleggingsmøtet. Hensikten er å estimere risiko, dvs. rangere sikkerhetsrisikoen til PBIer som skal implementeres i denne sprinten sammenlignet med andre PBIer i prosjektet, og identifisere og prioritere sikkerhetsaktiviteter som er nødvendige for hver enhet (funksjon eller krav). På denne måten får man inkludert sikkerhet i ytelsesestimatet, og som en viktig bieffekt også økt sikkerhetsbevissthet i hele utviklergruppen.

Daglig Scrum og sprintutførelse

Hver dag, på samme tid og sted, møtes alle medlemmene i utviklergruppen og bruker rundt 15 minutter til å rapportere til hverandre. Hva gjorde du i går? Hva skal du gjøre i dag? Er det noe som hindrer deg i å løse oppgavene? Det å ta den daglige Scrum stående vil bidra til å holde det kort. Tema som trenger ytterligere oppmerksomhet kan diskuteres av alle som er interessert etter at hvert gruppemedlem har rapportert.

Utviklergruppen kan finne det nyttig å vedlikeholde en aktiv sprint oppgaveliste, en Sprint Burndown Chart (en grafisk fremstilling av hvor mye arbeid som gjenstår), og en liste med hindringer. Alle hindringer som løftes fram i scrum-møtet blir scrum-mesterens ansvar å løse opp i så hurtig som mulig.

Sikkerhetsaktivitet: JiraSecPlugin

Som en del av SoS-Agile-prosjektet har vi utviklet en plugin til Jira som bidrar til å klassifisere og rangere sikkerhetsrelaterte forhold, selv om den som rapporterte forholdet ikke selv identifiserte det som sikkerhetsrelevant.  JiraSec kan identifisere om et innslag er sikkerhetsrelatert eller ei, og rapporter om hvor viktig klassifiseringen er. Den gir tilbakemelding og har støtte for kontinuerlig utrulling, og bidrar til økt sikkerhetsbevissthet.

JiraSec kan fritt lastes ned her: https://bitbucket.org/ootos/jirasecplugin/downloads/

Sprintgjennomgangsmøte

Utviklergruppen holder et sprintgjennomgangsmøte for å demonstrere et fungerende produktinkrement til produkteieren og alle andre som måtte være interesserte. Møtet bør være i form av en levende demonstrasjon, ikke en rapport. Etter demonstrasjonen gjennomgår produkteieren forpliktelsene påtatt under sprintplanleggingsmøtet, og erklærer hvilke elementer han/hun nå betrakter som ferdige.

Uferdige elementer returneres til produktbakleksa, og rangeres i henhold til produkteierens reviderte prioriteter som kandidater for framtidige sprinter. Dette møtet er anledningen til å inspisere og tilpasse produktet som det skrider frem, og iterativt raffinere alles forståelse av kravene. Nye produkter, og i særdeleshet programvareprodukter, er vanskelige å visualisere i et vakuum. Mange kunder er nødt til å kunne reagere på et stykke fungerende programvare før de er i stand til å oppdage hva de egentlig er ute etter.

Sprint-retrospektiv-møte

Hver sprint slutter med et retrospektiv-møte hvor man ser tilbake på det som skjedde i sprinten. Utviklergruppen reflekterer over sin egen prosess, inspiserer sin egen oppførsel, og tar aksjon for å justere prosessen for framtidige sprinter. En dybde-retrospektiv krever et arbeidsmiljø preget at psykologisk trygghet som i utgangspunktet ikke finnes i de fleste tradisjonelle virksomheter. Uten slik trygghet kommer retrospektiv-diskusjonen enten til å unngå ubehagelige tema, eller degenerere til klandring og sinne. En vanlig demper på full åpenhet i utviklergruppen er tilstedeværelse av personer som har personalansvar (dvs. vurderer ytelsen til den enkelte).

Utfordring 5/5: Sikkerhetsadministrasjon

Sikkerhetsaktiviteter er jo ikke gratis, og øker derfor kostnaden ved å utvikle programvare. Virksomheter har ingen motivasjon for å utviklesikkerhetsegenskaper i tidlige inkrementer. For å kunne følge opp hyppigere leveranser, ofrer mange virksomheter sikkerhetsaktiviteter.

Det er ingen rett eller gal måte å gjøre det på – det er avveininger på alle kanter!

For store grupper kontra for mange grupper? For mye ovenfra-og-ned kontra for mye nedenfra-og-opp? For kort planleggingshorisont kontra for lang planleggingshorisont? For dypt hierarki kontra for mange direkte rapporteringer? For mye standardisering kontra for mye variasjon?

Smidig tankegang medfører at du må velge de rette løsningene basert på dine behov!

I moderne programvareutvikling er det om å gjøre å automatisere det man kan. Imidlertid er det nødvendig med kunnskap om sikkerhet før verktøyene blir nyttige. Verktøy kan hjelpe til med den lavthengende frukten, men ettersom statisk analyse typisk ikke finner designfeil, kan vi uansett ikke finne mer enn ca. halvparten av sårbarhetene på denne måten. Verktøy kan også ha vanskelig heter med å finne sikkerhetsfeil i forretningslogikken.

Verktøy lider også av falske negativer og falske positiver. Førstnevnte kan gi en falsk følelse av trygghet, mens falske positiver skaper ekstraarbeid med å analysere sårbarheter som viser seg å ikke være reelle.

For å sitere W. Edwards Deming: “Det er ikke nok å gjøre sitt beste – du må vite hva du skal gjøre, og så gjøre ditt beste.”

Dette blogginnlegget er basert på foiler laget av Daniela Cruzes m.fl.