2203$ ) UHOlVQLQJ. Varför fungerar XP Några motiveringar till varje regel efter Beck. Innehåll. Planeringsspelet

Relevanta dokument
Design och utveckling. 2203$ ) UHOlVQLQJ

2203$ ) UHOlVQLQJ. Utvecklingsprocessen en översikt. Lite om kravspecifikationer. CRC-kort. XP som exempel på lättviktigare process.

12 principer of agile practice (rörlig)

Planeringsspelets mysterier, del 1

Agil programutveckling

OKIFAX hjälpguide

Kirunakortet. Fiska i Norrbottens fjällvatten. Fiska i Kiruna. Välkommen till Norrbottensfjällen!

Note to programmers. Embrace Change! Extreme Programming? Fyra basaktiviteter. 12 Practices / sedvanor. Vad är Extreme Programming

Utvecklingsmetoder och processer. UML och OCTUPUS en kort introduktion

Pdf- filer kräver et t hjälpprogram som het er Adobe Acrobat Reader. Acrobat Reader är en grat is programvara som du kan hämt a på den här sidan.

F2 XP Extrem Programmering översikt. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Görel Hedin Datavetenskap, LTH

XP-projekt: En fördjupning


FINLANDS FÖRFATTNINGSSAMLINGS FÖRDRAGSSERIE ÖVERENSKOMMELSER MED FRÄMMANDE MAKTER

F2 XP Extrem Programmering översikt. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Görel Hedin Datavetenskap, LTH

FÖRELÄSNING 8 DSV2PVT

Linköpings universitet 1 TDP029. Systemutveckling. Systemutveckling. Vanliga faser. Fler faser. Systemutvecklingsmetod

Linköpings universitet 1

Jokkmokkskortet. Fiska i Norrbottens fjällvatten. Välkommen till Norrbottensfjällen! Fiska i Jokkmokk

Therese Hansson & Magnus Jonsson. Motivationsfaktorer - Test inom Agila utvecklingsprojekt

Börja med at t st art a programmet Word. menyfält et. välj däreft er at t klicka på %LOGREMHNW och vidare på :RUG$UW. Tillbaka.

Användarcentrerad systemdesign

Agil projektmetodik Varför och vad är det?

3URJUDPE\JJQDGVNRQVWHQV HOHPHQW $EVWUDNWDGDWDW\SHURFK 'DWDVWUXNWXUHU $EVWUDNWDGDWDW\SHU +HOWDO/LVWD6WDFN. 7DEHOO

TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU

Testning av applikationer

Tentamen. 2D4135 vt 2005 Objektorienterad programmering, design och analys med Java Lördagen den 28 maj 2005 kl


Uppdraget. Växtstrategi för den lilla staden ² GHW ÀQQV UHFHSW. rubriker enligt programmets uppdragsbeskrivning:

- från idé 2ll produkt

extreme Programming refactored - recension och analys av Kent Becks senaste definition av XP

UML: Exempel. Ett modelleringsspråk. UML: Ansvar. UML: tre huvudanvändningar. Exempel: En klass position storlek. UML Unified Modelling Language

Kritik av Extrem Programmering

Text och foto: Erik Söderholm.

Att införa XP. Daniel Nilsson och Mattias Nordahl Lunds Tekniska Högskola. 27 februari Abstrakt

Fiska i Norrbottens fjällvatten. Välkommen till Norrbottensfjällen! Fiska i Arjeplog. Arjeplogskortet

Välkomna till DIT012 IPGO

Agile-metoder, XP och ACSD

Användarcentrerad systemdesign

En studie om parprogrammering i praktiken

Viktigt! Glöm inte att skriva Tentamenskod eller namn på alla blad du lämnar in.

69()2V IRWRXWIO\NW WLOO V GUD 'DODUQD GHQ VHSWHPEHU

F6 Arkitektur, Planering. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

,QI UDQGHW DY HXURQ NRPPLVVLRQHQ UHGRJ U LQJnHQGH I U I UEHUHGHOVHUQD RFK I UHVOnU WMXJR

Deluppgift 2 Kravhantering a) (2p) När man diskuterar krav brukar man ange två olika typer av krav. Beskriv dessa och ge exempel.

Projektarbete DAVC20

Extreme programming (XP)

Hjälpmedel: Hjälpmedel som finns på plats: Valda artiklar del 1 och del 2 (gäller för del 2 av tentan) Inga övriga hjälpmedel

Preliminär specifikation av projekt

Hej! På dessa sidor t änkt e vi hjälpa er med hur man loggar in mot en server och " lägger ut " sidor på I nternet.

SWE ANVÄNDARHANDBOK. Batteri Pellenc-verktyg 1200 / 1500

OCTOPUS utvecklingsmetod samt relaterade frågeställningar och diagram

F6 Arkitektur, Planering

AGILA METODER. (för oss som inte kodar) Nina Berlin

Objektorienterad programmering, analys och design med Java, 5p 2D4135, vt Kursprogram

I detta avsnitt beskrivs vart parprogrammering appliceras, hur det ska fungera och även i vilket projekt det introduceras i.

F4 Testning och Parprogrammering i XP. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson,Datavetenskap, LTH

F2 XP Extremprogrammering översikt

Avstyckning pågår från stamfastigheten Ljungby Löckna 2.1. Tomtens areal uppskattas bli ca m².

TDDD92 Artificiell intelligens -- projekt

F4 Testning och Parprogrammering i XP EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson,Datavetenskap, LTH

Testdriven utveckling. Teorin bakom testdriven utveckling. Bakgrund. Januari 2009, KTH. Alexander Tarnowski

Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson

Objektorienterad programmering, analys och design med Java, 5p 2D4135, vt Kursprogram

Melbye kompositmast. Framtidens lösning idag. Melbye kompositmaster på licens från

Djupstudie i parprogrammering

Programvaruutveckling i grupp Projekt EDAF45 (D2, C4, E4, F4, I4, Pi4) - 7,5HP F1Introduktion. Boris Magnusson, Ulf Asklund Datavetenskap, LTH

Programvaruutveckling i grupp Projekt EDA260 (D2, C4, E4, F4, I4, Pi4): F1Introduktion. Boris Magnusson, Ulf Asklund Datavetenskap, LTH

Bryssel den 16 december 2002

XP vs. Tillverkningsindustrin

Aktivitet ett: Kommunicera! Aktiviteter i praktiken. Parprogrammering. Aktiviteter. Parprogrammeringens sju myter. Parprogrammeringens sju myter

SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell.

SLUTRAPPORT RUNE TENNESMED WEBBSHOP

Rune Tennesmed. Oskar Norling 1DV430. Individuellt Mjukvaruutvecklingsprojekt 1DV430 Webbprogrammerare H12 Oskar Norling

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete

Parprogrammering i praktiken

BESKRIVNING AV PROCESSMETODEN SCRUM

Hjälpmedel: Hjälpmedel som finns på plats: Valda artiklar (gäller för del 2 av tentan) Inga övriga hjälpmedel

OOA Objektorienterad Analys. Exempel på informell kravspecifikation. DD2385 Programutvecklingsteknik Några bilder till föreläsning 11 13/5 2013

Praktiker som knäcker koden

Institutionen för datavetenskap Department of Computer and Information Science

F7 Agila metoder. EDAF45 Programvaruutveckling i grupp Projekt Boris Magnusson, Ulf Asklund Datavetenskap, LTH

Tentamen TEN1 HI

Föreläsning 11 Tisdag 6/6 2000

Proj-Iteration 3. Grov plan för releaser

Hjälpmedel: Hjälpmedel som finns på plats: Valda artiklar (gäller för del 2 av tentan) Inga övriga hjälpmedel

Objektorienterad programmering

Objektorienterad programmering

Game of 40. Regler och om sidan är in princip samma sak. Det som skiljer dem åt är att de inte har samma text.

LEGO Mindstorm-robot

Grundläggande datavetenskap 4p

Laboration 2: Designmönster

Configuration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar

Objektorienterad programmering, analys och design med Java, 5p 2D4135, vt Kursprogram

HT1 2013, FÖRELÄSNING 14 (INFÖR TENTAN)

Gör så här för att rapportera:

Grattis Yvonne Augustin

Lego Mindstormprogrammering

Alla rättigheter till materialet reserverade Easec

SLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS

Transkript:

XP: varför fungerar det? Något om tentan. Innehåll 2203$ ) UHOlVQLQJ Introduktion till extreme Programming (XP) Varför fungerar XP? Något om tentan Vad ska man läsa och hur ser den ut? Varför fungerar XP Några motiveringar till varje regel efter Beck Han säger i princip att alla regler behövs tillsammans för att det hela verkligen skall fungera Dock fungerar regler som testa först, enkel design, refactoring och kontinuerlig integration även utan att resten av reglerna används eller hela XP genomförs previous next previous next 3 extreme Programming extreme Programming (XP), hur var det nu Tillvägagångsätt (12 grundpelare) 3ODQHULQJVVSHO SODQHUD VQDEEW I UXWVlWWQLQJDUQD I U QlVWD UHOHDVH SULRULWHUD WHNQLNNUDY 6Pn UHOHDVHU VOlSS Q\D YHUVLRQHU RIWD 0HWDIRU KLWWD HQ HQNHO RFK EUD PHWDIRU (QNHO GHVLJQ J U GHVLJQHQ Vn HQNHO VRP P MOLJW 7HVWD WHVWD NRGHQ NRQWLQXHUOLJW 0nVWH O\FNDV LQQDQ XWYHFNOLQJHQ JnU YLGDUH 6NULY WHVWHUQD I UVW 2PVWUXNWXUHUD UHIDFWRULQJ VWUXNWXUHUD RP RIWD WD ERUW RQ GLJ NRG I UHQNOD RVY 3DUSURJUDPPHULQJ WYn SURJUDPPHUDUH SHU PDVNLQ.ROOHNWLYW ljdqgh DY NRGHQ DOOD ljhu RFK NDQ lqgud L NRGHQ.RQWLQXHUOLJ LQWHJUDWLRQ LQWHJUHUD RFK E\JJ V\VWHPHW IOHUD JnQJHU SHU GDJ WLPPDUVYHFND MREED VRP UHJHO LQWH PHU lq WLPPDU SHU YHFND,QNOXGHUD HQ NXQG L WHDPHW LQNOXGHUD HQ ULNWLJ DQYlQGDUH Sn IXOO WLG ) OM NRGVWDQGDUG I UHQNODU NRPPXQLNDWLRQ Planeringsspelet Man kan väl inte starta utvecklingen med bara en vag plan? Det är väl sedan inte möjligt att kontinuerligt uppdatera planen? Kunderna uppdaterar själva Baserat på uppskattningar av programmerarna Planera tillräckligt så kunden får en ide om vad som är möjligt Korta releaser så att eventuella fel snabbt uppdagas Kunden finns med och kan kontinuerligt uppdatera previous next 2 previous next 4 Björn Eiderbäck 2000 1 Björn Eiderbäck 2000 2

Täta releaser Antaganden: Man kan inte rimligen producera efter några få månader. Man kan inte rimligen göra releaser i cykler på bara några få dagar Planeringsspelet hjälper dig att fokuser på det mest väsentliga Man integrerar kontinuerligt, så paketeringskostnaden blir minimal Testningen reducerar defekterna så att långa testsekvenser inte behöver genomlöpas Du kan göra en enkel design, tillräcklig för aktuell release men kanks inte för alltid Enkel design Du kan väl inte ha tillräcklig design för dagens kod? Du målar in dig i ett hörn, utan möjlighet att fortsätta Du är van att strukturera om koden Så förändringar är inget som gör dig orolig Du har en bra metafor så framtida förändringar följer en ide Du programmerar med en partner, som hjälper dig att göra en enkel och motiverbar design previous next 5 previous next 7 Metaforer Man kan väl inte börja utveckla med bara en metafor? Det finns väl inte tillräckligt med detaljer och vad händer om man har fel? Du snabbt får feedback från riktig kod och tester Kunden gillar att prata om systemet med metaforen Du kontinuerligt refactors så att du modifierar dina kunskaper om metaforen och vad den betyder i praktiken Testning Man kan väl inte skriva alla tester som behövs? Det tar väl för lång tid. Programmerare skriver inte tester! Designen är så enkel den kan bli Du programmerar med en partner, så om du själv inte kommer på en test så kan kanske din partner Du känner tillfredställelelse då du ser att alla tester fungerar Kunden känner tillförlit till systemet då han/hon ser att alla tester fungerar previous next 6 previous next 8 Björn Eiderbäck 2000 3 Björn Eiderbäck 2000 4

Refaktoring Man kan väl inte strukturera om systemet hela tiden? Det tar väl för lång tid och är för svårt att kontrollera och troligen förstörs väl hela systemt? Du är van vid kollektivt ägande av kod Så att ändra där det behövs är inget du ser som ett problem Du följer en kodstandard Du programmerar i par Du har en enkel design Du har tester Du integrerar hela tiden Så man vet snabbt om någon del är i konflikt med någon annan Du är utvilad Kollektivt ägande av kod Alla kan väl inte tillåtas att ändra vadsomhelst överallt? Folk kommer väl förstöra till höger och vänster Du kan integrerar ofta, så att risken för konflikter minskar Du skriver och kör tester, så att risken för att förstöra något minskar Du parprogrammerar, så att man minskar risken för att förstöra koden Du följer kodstandard previous next 9 previous next 11 Parprogrammering Du kan väl inte skriva all kod i par? Det går väl för långsamt? Vad händer om folk inte passar ihop? Kodstandard används Alla är utvilade Paren skriver testerna ihop, så att dom kan förena förståelsen innan dom tacklar den huvusakliga implementationen Paren har en metafor Paren jobbar med en enkel design, så båda är med på vad som händer Kontinuerlig integration Du kan väl inte integrera efter bara ett par timmar? Integration tar väl för lång tid? Du kan köra testerna kvickt Så att man vet att inget är trasigt Du programmerar i par Hälften så mycket att integrera Du omsrukturerar, så att det är många smådelar Minskar risken för konflikter previous next 10 previous next 12 Björn Eiderbäck 2000 5 Björn Eiderbäck 2000 6

40-timmarsvecka Man hinner väl inte göra tillräckligt på 40 timmar? Planeringspelet ger dig det som är av mest värde att jobba med Kombinationen av planeringsspelet och testning reducerar frekvensen av hemska överaskningar Alla regler tillsammans gör att du kan gå fort fram Kodstandard Du kan väl inte be teamet att följa en viss standard? Programmerare är ju individualister och gör helst som dom brukar göra. Hela XP hjälper dem att vara med i ett vinnande lag previous next 13 previous next 15 Kund på plats Det kan väl inte var mest effektivt att ha en riktig kund på plats på full tid? Dom kan ge värde åt projektet genom att skriva funktionstest Dom kontinuerligt kan hjälpa till att göra prioriteringar Seminarium 6 På seminarium 6: första timme så presenterar deltagarna en läst artikel Väljs bland förslagen på http://www.nada.kth.se/kurser/kth/2d1359/00-01/contents/seminarier/xpartiklar.html Presenteras/diskuteras ca 10 minuter Troligen delar vi in grupperna efter vilka artiklar som lästs Andra timmen genomförs en extreme Hour previous next 14 previous next 16 Björn Eiderbäck 2000 7 Björn Eiderbäck 2000 8

Vad är en extreme Hour Under en extreme Hour går man igenom hela XPprocessen mycket snabbt, dvs på en timme Av nödvändighet så är den applikation som implementeras av mer artificiell natur och man brukar normalt jobba med papper och penna previous next 17 Tentamen vad ska jag läsa och kunna? Stora delar av boken och artiklarna i kursbunten tenteras Du tenterar antingen ti 24/10 kl 8-13 i F12-15, 45, 52-55 eller (ej båda gångerna) lö 28/10 kl 14-19 i V21-22, 32-34 Tentamen kommer bli lite mindre omfattande än tidigare Tentan bör klaras av på max tre timmar men av schematekniska skäl så får du ändå fem timmar på dig Extentor finns på följande sida http://www.nada.kth.se/kurser/kth/2d1359/00-01/contents.html För fler detaljer se läsanvisningarna på http://www.nada.kth.se/kurser/kth/2d1359/00-01/contents/infoochregler/lasanvisningar.html previous next 18 Björn Eiderbäck 2000 9