Smidig praksis og verktøy

Smidig praksis og verktøy

  • fokuserer på bygging av produkt som kan prøves ut

  • sentrert rundt prosesser for dette, og ikke på verktøy og teknikk

  • men…​ forutsetter i praksis verktøystøtte

    • smidighet krever automatisering

    • verktøy smører prosessene

Ulike typer verktøy

  • oppfølging av den smidige prosessen

    • oversikt over (ulike typer) utviklingsoppgaver

    • planlegging av iterasjoner

    • samarbeidsstøtte

  • håndtering av kildekode

    • distribuert utvikling

    • endringshåndtering

    • versjonskontroll

Ulike typer verktøy forts.

  • kontinuerlig integrasjon (CI)

    • testing

    • bygging av artifakter

Historien om en utviklingsoppgave

Kunden ønsker å kunne importere et gammelt filformat. Dette funksjonsønsket deles opp i to utviklingsoppgaver, én for kjernefunksjonaliteten og én for brukergrensesnittet.

Cecilie starter med kjernen og skisserer først hvordan hun tenker å løse det teknisk vha. noen enkle klassediagram. Så defineres oppførselen til hver klasse i form av tester, og tomme klasser opprettes.

Historien om …​ forts.

Kristian kan starte på brukergrensesnittet til importfunksjonaliteten så snart klassedeklarasjonene er klare, han trenger ikke selve implementasjonskoden i starten.

Cecilie jobber seg så gjennom implementasjonen, og sjekker hele tiden at den er som tenkt ved å kjøre testene. Hun er ferdig i god tid før Kristian, og når han er det så…​ bare virker det! Til slutt oppsummerer de begge hva som ble gjort og gjør funksjonen tilgjengelig for kunden.

Historien om …​ og verktøy

Hva har dette å si for verktøystøtte?

  • oppfølging av den smidige prosessen:

    • to utviklingsoppgaver knyttet til hhv. Cecilie og Kristian

    • del av inneværende iterasjon

    • dialog/diskusjonstråd knyttet til oppgaven

Historien om …​ og verktøy forts.

  • håndtering av kildekode:

    • Cecilie må kunne dele sin kjernekode med Kristian, men holde den unna de andre

    • det må komme frem at koden er knyttet til respektive utviklingsoppgaver

    • den nye koden er knyttet til neste versjon

Historien om …​ og verktøy forts.

  • kontinuerlig integrasjon (CI):

    • hyppig kjøring av testene

    • ny versjon rulles raskt ut til kunden

gitlab.stud.idi…​

  • profesjonelt støtteverktøy for smidig utvikling

  • IDI har egen installasjon (tas kanskje over av NTNU IT)

    • innlogging med NTNU-navn og -passord

  • hierarki av grupper, med prosjekter (repo) under

    • IT1901-emnet er en gruppe: it1901

      • emnet har repo med læringsmateriale inkl. kode

    • hver gruppe er egen undergruppe (it1901-gr19xy)

      • gruppene opprettes av oss, så inviteres dere inn

      • dere oppretter nødvendige repo

Oppgavesporing (issue tracking)

En oppgave (issue) er arbeid som skal følges opp

  • ny funksjon, forbedring, feilretting, konfigurasjon …​

  • hver oppgave har en dialog/diskusjonstråd

  • halvautomatisk knytning til endringer (commits)

Oppgavesporing forts.

Oppgavesporing er viktig for transparens

  • kunder trenger innsyn i prosess

  • teamet trenger å dele kunnskap

  • løse og distribuerte prosjekter (f.eks. åpen kildekode) har ekstra behov

  • støtter vurdering…​

Oppgavesporing forts.

  • oppgaver opprettes ifm. planlegging av iterasjon, f.eks. fra brukerhistorier, funksjonsønsker eller feilrapporter

  • oppgaver knyttes til

    • milepæl for iterasjon

    • utviklinger som jobber med den

  • merkelapper (labels) kan angi fasen en oppgave er i

    • f.eks. planlagt, utvikling, testing, godkjent

    • oppgavetavler (issue boards) visualiserer fremdrift

Oppgavetavle (issue board)

workflow

Oppgavesporing forts.

  • dialog/diskusjonstråd dokumenterer prosessen

    • designidéer, avgjørelser, avhengigheter, …​

    • knyttes til endringer (commits) gjennom oppgavenummer (#)

    • oppsummerer hva som ble gjort

Viktig for transparens!

Kildekodehåndtering

Source code management (SCM)

Kontinuerlig integrasjon

Continuous Integration (CI)

Norwegian University of Science and Technology