Forelesning - Det agile manifestet, 25.10. (kveldsforelesning)



Software engineering != software development.
Organisering av arbeidet rundt programutvikling..

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Historie:

1969 - Identifisering av fagfeltet software engineering
1970 - Fossefallsmetoden. De aktivitetene som en metode måtte inneholde var kravsspesifikasjon, analyse, design, utvikling bla bla.. (trickles down).
1980-tallet - Inkrementelle metoder
1999 - Unified Process (inneholdt alle de utviklingsmetodene som tidligere, men de organiserte det på en annen måte. De sa feks imotsetning til fossefallsmetoden at det ikke er nødvendig at ALLE
metodene er fullført før man går videre, men kanskje 80%)

oppsumert da... sekvensiell, rigid og lineær utviklingsplan vs “ekstremprogrammering” og dynamisk “samtale-basert” programmering.


STATUS FOR PROGRAMMERING RUNDT ÅR 2000:

Viktige aktiviteter identifisert
	kravarbeid, design, programmering, testing
Brukerdeltagelse
Inkrementell utvikling
Grundig kravspesifikasjon
Tidlig design og programspesifikasjon
Testing utført av testteam


I noen tilfeller har et utviklingsteam vært 80% ferdig med utvikling, men har ingenting å vise kunden fordi det er ikke satt sammen enda. En bedre metode er å sette sammen de grove funksjonene og teste de,
at man ikke utvikler hele fundamentet, og toppen på slutt, men at man utvikler “fra bunn til topp”, en og en funksjon, så godt det lar seg gjøre.

Noen erfaringer:
Det mytiske månedsverket
	Brooks lov: Å sette inn flere mennesker i et forsinket programutviklingsprosjekt gjør det enda mer forsinket.
Krav er ikke statiske (Alt kan endre seg)
Dokumentasjon blir ikke vedlikeholdt
Stor tidlig design låser løsningsmuligheter
Programmerere følger ikke gitte praksiser
SVAR: Agil (smidig) programvareutvikling



Twelve principles underlie the Agile Manifesto, including:[7]
	•	Customer satisfaction by rapid delivery of useful software
	•	Welcome changing requirements, even late in development
	•	Working software is delivered frequently (weeks rather than months)
	•	Working software is the principal measure of progress
	•	Sustainable development, able to maintain a constant pace
	•	Close, daily co-operation between business people and developers
	•	Face-to-face conversation is the best form of communication (co-location)
	•	Projects are built around motivated individuals, who should be trusted
	•	Continuous attention to technical excellence and good design
	•	Simplicity
	•	Self-organizing teams
	•	Regular adaptation to changing circumstances
	•


Teamarbeid og kundeorientering, et kjennetegn ved Agil/Smidig programmering.




Xtreme programming og praksiser:
Utviklet på 1990-tallet.
12 praksiser, forventet høy disiplin:
	planleggingsspillet
	små versjonsendringer
	metafor
	enkel design
	testing
	refaktorering
	parprogrammering
	kollektivt eierskap
	kontinuerlig integrasjon
	40-timers arbeidsuke
	kune til stede
	kodestandarder



KRITIKK AV AGILE METODER:

Krever for mye disiplin for å virke etter hensikten
	- kan utarte til “hacking”
Utviklerfokus på prosjekt
Lite innsyn
Vanskelig å skalere opp
Passer ikke for uerfarne utviklere