agiletools.adoc

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)

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)