Arkitektur og smidighet

Agenda 14:00 – Behovsanalyse + bakgrunn 15:00 – Planlegging 15:15 – Gjennomføring 17:15 – Retrospektiv 17:30 – Avslutning 18:00 – Oslo XP meetup (valgfritt)

Som en instruktur i smidige metoder Ønsker jeg at deltagerne skriver en ”participant story” for seminaret Slik at jeg forstår de problemene deltagerne står ovenfor i sin hverdag

Hva er arkitektur?

“The software architecture of a program or computing system is the structure […] of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.” (wikipedia)

“ the highest level concept of a system in its environment “ the highest level concept of a system in its environment. [The] organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.” (IEEE/RUP) (via http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf)

“Architecture is about the important stuff. Whatever that is “Architecture is about the important stuff. Whatever that is.” (Ralph Johnson, via [Fowler])

“Architecture is the decisions that you wish you could get right early in a project” (Ralph Johnson, via [Fowler])

The Code is the Design Utvikling er som bygging, men gal metaforbruk: Konstruksjon er kompilering, ikke koding Design er koding, ikke tegning Å ”konstruere” er kjempebillig Jack Reeves: The Code is the Design

Oversikt Lean: See The Whole

Oversikt over hva? Domene Koden og designet Integrasjon med omverden Infrastruktur Systemegenskaper Konsept til cash – utviklingsverdikjeden Fra konsept til krav Fra krav til testet kode Fra testet kode til produksjon

Systemegenskaper Testbarhet Driftbarhet Vedlikeholdbar Når kan disse måles?

Det smidige manifest Individer og samspill framfor prosesser og verktøy Fungerende system framfor utførlig dokumentasjon Samarbeid med kunden framfor kontraktsforhandlinger Å reagere på endringer framfor å følge en plan

De smidige prinsippene: Levere verdifullt, kjørende system hyppig Endringer = kundens konkurransefortrinn Hyppige leveranser Forretning og utvikling jobber sammen Stol på teamet Samtale ansikt-til-ansikt. Mål fremdrift ved programvare Bærekraftig arbeidstempo Teknisk utmerkelse Enkelhet Arkitekturen vokser fram Teamet reflekterer

Organisk arkitektur  blindveier (8) Prosjektstart i smidige prosjekter (6) Å gjøre et prosjekt smidig (6) Kvalitet  desentraliserte beslutninger (4) Levere verdi  Lever kode (4) Å bruke smidige verktøy i ikke-smidig prosjekt (2) Å ”selge” smidig (3) Å håndtere krav i endring (3) Mislykkes med smidige metoder (3) Verktøy i et smidig prosjekt (2) Tekniske beslutninger  hyppige leveranser (3) Prosjektets virkelighet  hyppige leveranser (3) Hva er ”endringsdyktighet”? (3) Hva er ”teknisk utmerkelse”? (3)

Retrospektiv Hva er jeg enig i? Hva er jeg uenig i? Hva vil jeg studere mer? Hva vil jeg gjøre annerledes fra i morgen? Hva skulle jeg ønske vi hadde snakket (mer) om?

Handouts

Referanser Wikipedia Martin Fowler: ”Who Needs an Architect” Jack Reeves: ”The code is the design” Agile Manifesto

Hva er arkitektur “The software architecture of a program or computing system is the structure […] of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.” (wikipedia) “ the highest level concept of a system in its environment. [The] organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.” (IEEE/RUP) “Architecture is about the important stuff. Whatever that is.” (Ralph Johnson) “Architecture is the decisions that you wish you could get right early in a project” (Ralph Johnson) “Arkitektur er oversikt” (Johannes)

Oversikt over hva? Krav og domeneområdet og hvordan det forbindes med andre omliggende områder Hvordan helheten av koden fungerer Hvordan systemet samhandler med systemene rundt Hvordan infrastrukturen og systemet samhandler Hvordan man kommer fra konsept til cash Hvordan man kommer fra testet kode til produksjon

Det smidige manifest Vi oppdager stadig nye og bedre måter å utvikle systemer på, både ved å gjøre det selv og ved å hjelpe andre. Derved har vi lært oss å verdsette: Individer og samspill framfor prosesser og verktøy Fungerende system framfor utførlig dokumentasjon Samarbeid med kunden framfor kontraktsforhandlinger Å reagere på endringer framfor å følge en plan Det betyr at selv om punktene til høyre er verdifulle, verdsetter vi de til venstre mer.

De smidige prinsippene: Vår høyeste prioritet er å tilfredsstille kunden gjennom å levere et verdifullt, kjørende system tidlig og hyppig. Ønske endrede krav velkommen, også selv om det er sent i utviklingen. Smidige prosesser utnytter endringer til å gi kunden konkurransefortrinn. Hyppige leveranser av fungerende system, fra et par uker til et par måneder, med preferanse for den korte enden av skalaen. Forretningssiden og utviklere må jobbe sammen daglig gjennom hele prosjektet. Bygg prosjektene rundt motiverte individer. Gi dem det miljøet og den støtten de trenger, og stol på at de får jobben gjort. Den mest effektive metoden for å spre informasjon til og innen et utviklingsteam, er samtale ansikt-til-ansikt. Fungerende programvare er den viktigste målestokken på fremdrift Smidige prosesser skal understøtte bærekraftig arbeidstempo. Sponsorer, utviklere og brukere bør være i stand til å holde et konstant tempo i ubegrenset tid. Kontinuerlig fokus på teknisk utmerkelse og godt design forsterker smidighet. Enkelhet - kunsten å maksimere mengden arbeid som ikke gjøres - er essensielt. De beste arkitekturene, kravene og designene vokser fram fra selv-organiserende team. Med jevne mellomrom reflekterer teamet over hvordan det kan bli mer effektivt, og så justerer det arbeidsmåten sin tilsvarende

Spørsmål Hva er rollen til verktøy innen et smidig prosjekt? Betyr "individer og samspill framfor prosesser og verktøy" at verktøy som FitNesse, JUnit, byggservere, applikasjonsservere, regelmotorer og databaser ikke skal brukes?  Hvilke tekniske beslutninger understøtter og undergraver hyppige leveranser? Hvilke forhold i prosjekt gjør hyppige leveranser vanskelig, og hva kan vi gjøre? Hvordan kan vi levere verdi og ikke bare kode? Hvilke faktorer gjør et system endringsdyktig? Hvordan kan vi få kvalitet med desentraliserte beslutninger? Hva er konsekvensene av å ha for mye eller for lite dokumentasjon? Hva betyr egentlig "enkelhet"? Hvordan kan arkitekturen "vokse fram" uten at vi maler oss inn i et hjørne? Hva er det som skjer når vi "maler oss inn i et hjørne"? Hvordan kan vi unngå dette? Hva betyr egentlig teknisk utmerkelse?