INF112 Innføring i systemutvikling

Innføring i systemutvikling

Software Engineering

Ikke «programmerings-gud» – men:

fungere bra sammen med andre,
bruke det du kan
kunne lære mer

Samarbeid

Håndverk

- Heter innføring i systemutvikling, men kunne også vært kalt utviklingshåndverk

- Litt som sjakk: lære grunnreglene er enkelt, spille på en god måte: vanskelig

- Lære om håndverket gjennom forelesninger og prosjektarbeid i team

- Praktisk fag, praktisk fokus

--down

### Hvordan skal vi jobbe med faget?

* Forelesninger

* Les pensum, så du blir klok og vis

* Oppgaver, så du blir bedre håndverker

* Obliger (teamarbeid) – vis hva du lærer (40% av karakteren)

* Du må bestå *både obligatoriske arbeidskrav og eksamen for å stå i faget*

- Forelesninger i første halvdel av kurset, prosjektarbeid resten

- Oppgaver for å lære verktøy og å lære seg å jobbe sammen og bruke ulike

verktøy

- Totalt fire obliger, disse angir 40% av poengene før karaktergiving. Dere skal lage et

system, og alle innleveringene omhandler dette systemet. Begynner om noen

uker.

Praktisk informasjon

Meld dere på grupper selv på Mitt UiB
Gruppene er faste
Undervisningsassistent: Wim van den Broeck
Gruppeledere

Lærebok

Forelesningsnotater og kode

https://git.app.uib.no/inf112/23v/lectures

(ikke aktiv ennå)

Tema

Kommunikasjon og samarbeid
Prosjektorganisering
Krav og design
Abstraksjon og modellering
Utviklingspraksis, testing og debugging
Bygg og deploy av prosjekt
Refaktorering og vedlikehold
Designmønstre
Lovverk

Mål

Både praktisk, sosialt og teknisk!

Konsepter og terminologi
Mental modell
Problemløsing – finn ut av ting på eget initiativ!
Bruke og få hjelp til verktøy
Reflektere over ferdigheter og begrensninger
Sosialisering som utvikler, ikke pugging

Vær aktiv

Kommunikasjon

Men vi skal jo bare kode?

Mye vanligere enn du tror

- person A snakker om sirkler

- person B snakker om firkanter

- person C snakker om trekanter

- Eller gjør de det? Kanskje det høres ut som om de snakker om ulike ting, mens

de egentlig prater om det samme?

- Kanskje de diskuterer noe de egentlig er enige om?

- Eksempel: språkforvirring i prosjektet jeg nettopp har jobbet i

- svindelforsøk (fraud)

- reklamasjon (dispute)

- fraud brukes også om reklamasjon, fordi det ofte er svindel som er

utgangspunkt for en reklamasjon. Delsystemet vi har laget har faktisk feil

navn (ett års utvikling, og mange år før det), fraud i stedet for dispute.

- språket vi bruker er veldig abstrakt.

- Helt vanlig med slike misforståelser. God kommunikasjon gjør at det er lettere

å oppdage, og håndtere denne type ting. Vi må øve på å få til god og vellykket

kommunikasjon

Hva er vellykket kommunikasjon?

Kommunikasjonskanaler

Epost
Chat
Issue tracking
Ansikt til ansikt
Møter
Telefon/video
Tekst og figur
Dokumentasjon og kode

Respekt

tid, opppmerksomhet
mengde informasjon – unyttig informasjon
forståelse, mangel på forståelse

Kontekst

Sett kontekst:

Bakgrunn? Hva vil du oppnå?
Har du gitt nok informasjon?
- Lenke til kode, f.eks.
- Hvordan spurte du om hjelp i INF10x?

Ansikt til ansikt

Hvem har rett?

"Den skal være stor"
"Den skal være liten"

Alle gjør antagelser

«Har jeg forstått det riktig at ...»

Møter

- For prosjektrelatert arbeid som må diskuteres i fellesskap

- Ansikt til ansikt (kanskje også over video)

- Spesifikt tema

- Diskusjon, planlegging, status

- Korte eller lange (feks status i teamet vs dybdediskusjon om et problem)

- Bør ikke være for lange, legg i så fall inn pauser (1,5 - 2 timer er maks uten

pause)

- Vær kritisk med hvem som trenger å være med

- Legg møter til ettermiddag eller i forbindelse med lunsj (minst mulig

avbrytelser)

- Er alle tilstede i rommet? Hvis remote, kamera eller bare lyd?

- Interaktivt (hvis ikke, er møte rett format?)

- Hold konstruktiv tone (den som kaller inn bør ta ansvar for det, men gjør det hvis

ingen andre gjør dette)

- forklar kontekst så kort som mulig

- Agenda: ALLTID

- Må noen forberede? Gi dem tid til det. Respekter andres tid.

- Etter møtet: Referat hvis nødvendig. Veldig kort bakgrunn/sett kontekst. Hva ble bestemt?

Hvem skal gjøre evt oppgaver? Hva er tidsfrist? Når skal neste aktivitet

skje?

Kroppsspråk

Telefon og video

Trygg kommunikasjon

Trygg for å være effektiv
Les kroppspråk og stemning?
Kreativt yrke – du må være avslappet og komfortabel!

Epost

To, CC, BCC – aldri flere enn nødvendig
God tittel
Mer formelt
Viktig, men ikke hast

Online chat

(Discord, Mattermost, Slack, Teams, etc)

Flyktig, uformell, rask, stille – lav terskel
men: samle viktig informasjon i Wiki e.l.
Bruk evt. tråding hvis det er mye som foregår

Discord

https://discord.gg/uDpNebWCP6

Issue tracking og prosjekttavle

(GitHub/GitLab, Trello, Trac, Bugzilla)

Online – eller fysisk tavle med lapper
Inneholder:
- hva, hvem, hvorfor, hvordan...
- prioriteringer, historie, avgjørelser

Tekst

Figurer

Arbeidsflyt

Arkitektur

Kode-arkitektur, brukergrensesnitt

Mega-modell: data-representasjoner og prosesser

Kode

Forretningsregler
Beskriver realiteten
Lever lenge
For både menneske og maskin
Kommunisere om kode!

Hvordan diskutere sammen – dårlig eksempel

https://bit.ly/2smxwW0

Hvordan diskutere sammen – godt (bedre?) eksempel

https://bit.ly/2RFTbqh

Kommunikasjon rundt kode

- Vi bruker mye tid på å kommunisere rundt kode

- kode er ekstremt personlig, tanke oversatt direkte til tekst

- mange tar kritikk av kode som personlig kritikk

- hvis du reagerer på noe: hvorfor?

- hvis du reagerer på noe: hva kan være et alternativ?

- være løsningsorientert, ikke problemorientert

- partner er ikke tankelesere, forklar retningen du beveger deg i

- vær høflig, profesjonell, konstruktiv

- når den andre skriver kode: følg med

- spør om å få overta hvis du har en ide

- spør om partner vil kode hvis du har kodet lenge

- la mobil og annen laptop ligge med mindre du leter etter løsning på problem

dere nå jobber med

- hvis du må forlate arbeidet, gi beskjed hvor lenge du forventer å bli vekke

- si ifra om du trenger en lengre pause

- forsiktig med mat, er det OK for partner?

- personlig hygiene teller, veldig tett på partner

- pass kroppsspråk

- OK å være usikker

- OK å prøve ut

- OK å være uenige, kan vente med å løse noen problemer til senere

- universelle regler, enter man koder eller prater sammen, tegner sammen osv.

Hvordan jobbe sammen i par

- http://sedano.org/toddsedano/2017/10/24/considerate-pair-programming.html

(både del 1, 2 og 3)

- Ha to tastatur, helst to skjermer også, likeverdig plassering av partnere

- Kan være bedre å stå

- Gi komplimenter hvis du gleder deg, si hvorfor

- Introduksjon hvis du ikke har sittet sammen med noen før

- Hva er forventninger til utfall av parprogrammering? (løse problemer i

fellesskap, levere funksjonalitet osv)

- Hvordan har den andre det i dag? Kan vi tilpasse situasjon slik at det blir

mest mulig effektivt?

- Eks: "Er bekymret for om featuren vi lager løser problemet vi egentlig har"

- Eks: "Gleder meg til å få hjelp med dette, for jeg har stått fast i 2 dager"

- Eks: "Du har mer erfaring enn meg, så jeg er nervøs"

- Sjekk tilstand halvveis i sesjonen, be om tilbakemelding. Vær konstruktiv!

- Ta pauser når det ikke går an å konsentrere seg

- Den som trenger mest tid setter tempo på arbeidet, begge skal være med

- Si takk på slutten av dagen!

- Hvis noe går gale:

- Gjenta/forklar med egne ord hva problemstillingen er (kan hjelpe på

forståelse)

- ulike ideer til hvordan løse problemet? Prøv å argumentere FOR partneren sin

- gå gjennom hvordan dere har havnet i situasjonen

- prøv å tenke ut andre løsninger

- få noen andre fra teamet til å hjelpe

- prøv begge løsninger

- Forklar hva du føler: "Når du gjør .. så oppfatter i hodet mitt ... da føler jeg.."

- Snakk om noe annet: spør hva partneren er opptatt av? (trenger ikke være

faglig)

- Deeskaler situasjonen (pause/samtale om andre ting osv)

Lønner deg seg å jobbe sammen?

Hva oppnår vi med god kommunikasjon?

Kommunikasjon er essensielt

Testing

Beware of bugs in the above code; I have only proved it correct, not tried it.

– Donald Knuth

Former for testing

Unit, Integration, Regression, Functional, Acceptance, Accesibility, Performance, Security, …

Automatisk? Interaktiv? Med utvikler? QA team? Brukere?

Hvor trygg kan du være?