Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- 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
Add Comment
Please, Sign In to add comment