Udvalgte Udviklingsmetoder

Udvalgte Udviklingsmetoder
En introduktion til eXtreme Programming (XP) Agile Development …og andre udviklingsmetoder og elementer v/Per Molsing Beining

Agenda Lidt om min baggrund eXtreme Programming (XP)
Hvem jeg er Systemudviklings erfaringer eXtreme Programming (XP) Hvad er XP Kritik og udfordringer Agile Software Development Manifest Principperne bag Introduktion til andre interessante udviklingselementer Diskussion og spørgsmål Kort introduktion til de 4 hoved emner: Først fortæller jeg lidt om min baggrund Hvor jeg har arbejdet med hvilke udviklingsmetoder og de erfaring jeg kan drage af disse Specielt vil jeg fremhæve de 2 seneste udviklingsmetoder jeg har arbejdet, og deraf også bruge lidt mere tid på dem. Den ene er eXtreme Programming. Jeg vil forsøge at ridse hovedtrækkene op i metoden. Fortælle lidt om hvad der gør at jeg - og et temmelig stor community - tror på XP. Som med alt er der også kritikere af XP. Jeg skal også gøre et forsøg på at ridse de væsentligste anker med XP op. Og nogle af de udfordringer jeg har mødt. XP adskiller sig fra de mere gængse metoder (fx Vandfaldsmodellen) ved at have en noget mere let-vægts tilgang til planlægnig, dokumentation og de øvrige elementer der indgår i systemudvikling. XP er dog ikke den eneste letvægts metode i landskabet. Hvilket også er årsagen til at jeg vil bruge lidt tid på at fortælle om et møde mellem 17 af ophavnsmændene til de mest udbredte af disse. Dette møde resulterede i et manifest de alle – hvor forskellige deres metoder end er - kunne tilslutte sig. Agile Software Development – eller på dansk Adræt software udvikling – og principperne bag – er det tredje hoved emne. Det fjerde punkt jeg kort vil berøre er Use Case Driven Software development. Use Cases er en måde at omskrive eller udtrykke kravene til systemet på. Disse er så det centrale i beskrivelsen eller modelleringen af det nye system – og danner basis og sammenhæng med alle andre deliverables. Use Case driven development kan anvendes i traditionel såvel som Agile system development. Da det dog er en dokumentations metodik der bliver mere og mere udbredt er den medtaget som introduktion. Det sidste punkt er en ”buffer” hvor vi kan gå mere i dybden med enkelte delområder eller hvis nogen skulle have noget på hjertet der ikke er dækket – men som passer ind – kan vi tage det.

Hvem jeg er Systemudviklings erfaringer eXtreme Programming (XP) Hvad er XP Kritik og udfordringer Agile Software Development Manifest Principperne bag Introduktion til andre interessante udviklingselementer Diskussion og spørgsmål Først fortæller jeg lidt om min baggrund Hvor jeg har arbejdet med hvilke udviklingsmetoder og de erfaring jeg kan drage af disse

Lidt om min baggrund Per Molsing Beining, 33 år,
selvstændig internet konsulent (systemudvikling) med firmaet XPand, siden januar 2001. Systemudviklings baggrund Pascal HTML Perl Java Windows,Solaris og Linux Specialiseret i internet udvikling og drift

Lidt om min baggrund Funktions erfaring System udvikler DBA
System Operator & Drifts ansvarlig Senior systemudvikler & mentor Teknisk Projektleder Udviklingschef Projektleder/-koordinator Technical Manager

Lidt om min baggrund Systemudviklings erfaringer
Dive, Handelshøjskolen I København DanNet (Vandfald) Networkers / Framfab (Kaos og struktur) Konsulent (XP) Konsulent (Use Case driven development) Dive – vicevært – feauture driven development Dannet – Vandfalds modellen Networkers – kaos gående mod struktur (udvikler,udviklingschef, Senior udvikler, mentor) Framfab – kaos og strukturerede metoder (networkers metode, RUP etc) Tele Selskab – Dixa Net – XP Java – UseCase driven development

Dive, Handelshøjskolen I København System til formidling af noter tli studerende Udvikler, projektleder, AD’er m.m. – Alt I een person Styregruppe/kunde – også een person

Lidt om min baggrund Systemudviklings erfaringer DanNet
Internet: Corporate sites & info systems EDI: Klient applikation til samtale registrering Udvikling efter Vandfalds model Gængse problemer Kunden er meget langt væk fra udvikleren Forholdsvist dyrt at lave ændringer Gængse fordele Let at planlægge, kontrollere fremdrift og styre Let at prissætte

Lidt om min baggrund Systemudviklings erfaringer Networkers Internet
Alle typer, fra micro sites til Corporate Kaos: “fra hånden til munden” projektstyring og udvikling Ingen reel faseopdeling – ingen dokumentation Svært at vedligeholde for andre Idriftssættelse og vedligeholdelse uden større planlægning – mere held end forstand Server sikkerhed sporadisk – firewall og hardware

Lidt om min baggrund Systemudviklings erfaringer Networkers (fortsat)
Svært at focusere på hvad er vigtigst når alt er vigtigst Forsøg på at skabe orden I kaos med egen process model baseret på erfaring fra tidligere projekter “Corporate spirit” blev bygget op sammen med firmaet Socialt netværk meget stærkt – næsten kult-agtigt Lange arbejdsdage – meget lidt plads til privatliv

Lidt om min baggrund Systemudviklings erfaringer Framfab
Fra Bolchebutik til Bolchefabrik Vækst kan være godt – ukontrolleret vækst er farligt – specielt mellemlederne forsvinder Mere styring af process og metode, bl.a. anvendelse af tilrettet version af RUP QA process nødvendig for at sikre at process og deliverables følges – meget vigtigt!

Lidt om min baggrund Systemudviklings erfaringer Konsulent (TelCo)
Opgaver Opbygge intern udviklingsafdeling til produktion af Customer Self Service via web (TelCo) Opbygge intern driftscenter til Web aktiviteter Fastsætte udviklingsstrategier Fastsætte standarder og metode Fastsætte dokumentations krav etc. Løsningsmodel eXtreme Programming

Konsulent (køb af internet systemer) Opgaver Placeret på den anden side af udviklingsbordet Rådgive om tekniske muligheder Hjælpe leverandører ved tekniske vanskeligheder og spørgsmål Reviewe leverandørs forslag til teknisk løsning Sikre og kontrollere teknisk kvalitet i de leverede løsninger Løsning Use Case Driven development

Hvem jeg er Systemudviklings erfaringer eXtreme Programming (XP) Hvad er XP Kritik og udfordringer Agile Software Development Manifest Principperne bag Introduktion til andre interessante udviklingselementer Diskussion og spørgsmål Specielt vil jeg fremhæve de 2 seneste udviklingsmetoder jeg har arbejdet, og deraf også bruge lidt mere tid på dem. Den ene er eXtreme Programming. Jeg vil forsøge at ridse hovedtrækkene op i metoden. Fortælle lidt om hvad der gør at jeg - og et temmelig stor community - tror på XP. Som med alt er der også kritikere af XP. Jeg skal også gøre et forsøg på at ridse de væsentligste anker med XP op. Og nogle af de udfordringer jeg har mødt. XP adskiller sig fra de mere gængse metoder (fx Vandfaldsmodellen) ved at have en noget mere let-vægts tilgang til planlægnig, dokumentation og de øvrige elementer der indgår i systemudvikling.

eXtreme Programming (XP)
XP is a lightweight way to produce software Started March 6, 1996 with Project to write a payroll system for Chrysler Project done in Smalltalk Kent Beck brought in to help an existing project Light methods are adaptive rather than predictive Light methods are people-oriented rather than process-oriented.

Software development Risks Schedules slip Building the wrong product Market for product changes Buggy software Too many features that users don't want Struggle between management and developers …and the list just goes on Risks need to be managed If you can't manage risks then it is hard to succeed

A software development process aligned with “developer nature” It sounds very constraining, but it’s not Targeted at dynamic projects developed with small teams Based on social & collaborative values as well as technical practices

Warning…. DO NOT USE EXTREME PROGRAMMING

If... You’re using a process and developers and customers are happy with it Your requirements are truly fixed You cannot keep the cost of change low in your environment But you might still benefit from some XP practices

Use XP if You like the Agile Alliance value Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Controlling a project Control Variables Let’s assume that there are four control variables for a software project: Cost (Resources) Time Quality Scope Management can fix three of these, and the development team controls the fourth

Controlling a project Why not fix all four? You can certainly try to do this If you try to fix all four, then the one that is hardest to measure (quality) will suffer The effects of this are highly non-linear XP projects use scope as the control variable

Traditional Cost Model

XP Cost Model

Rights & Responsibilities Manager & Customer Rights You have the right to an overall plan, to know what can be accomplished, when, and at what cost You have the right to get the most value out of every programming week You have the right to see progress in a running system, proven to work by passing repeatable tests that you can specify You have the right to change your mind, to substitute functionality, and to change priorities without paying exorbitant costs You have the right to be informed of schedule changes, in time to choose how to reduce scope to restore the original date. You can cancel at any time and be left with a useful working system reflecting investment to date

Rights & Responsibilities Programmer Rights You have the right to know what is needed, with clear declarations of priority You have the right to produce quality work at all times You have the right to ask for and receive help from peers, superiors and customers You have the right to make and update your own estimates You have the right to accept your responsibilities instead of having them assigned to you

Benefits of XP Software stays soft Martin Fowler, “Keeping software Soft” ( Handles changing requirements Quickly produces something useful, keeps making useful enhancements Average developers can produce great software

XP Roles Customer Programmer Manager Tracker, Tester, Consultant, Big Boss … and a cast of thousands

XP Values and Principles Open, honest communication Rapid feedback at all levels Quality Work Assume Simplicity Incremental Change Small initial investment Embrace Change Travel light Courage - play to win Local adaptation

Practices Continuous integration Small releases On-site customer The Planning Game Metaphor 40-hour week Coding standards Simple design Testing Pair Programming Collective ownership Stand-up meetings Refactoring

Things we know we should do Staged delivery Business people make business decisions and technical people make technical decisions Regression testing, unit tests Review

Analysis Test Code Design + project management

Extreme Analysis Describe system as a set of user stories Users write stories explaining one use of the system Like use cases, but informal

Extreme Testing Write tests before code Convert each user story into a set of tests All unit tests must run 100% all the time Don’t worry if you can’t test everything GUI real-time I/O complete coverage Don’t worry if testing is expensive

Extreme Coding Write code for test cases one at a time. Write the simplest thing that could possibly work Goal: make the tests work ASAP Enforce coding standards Make code as clear as possible

Extreme Coding Pair Programming All code is written in pairs Pairs talk continually Pair switches driver frequently People switch pairs several times a day Continuous code review

Refactoring: Extreme Design Make sure each thing is done in one place - Eliminate all duplicate code Make sure each class/function does one thing All code must be readable All tests run

More Design Project starts with a few days of design on white-boards/CRC cards Major problems lead to group design sessions Documentation is after the fact, and no more than necessary Start simple, refactor to keep simple

Extreme Scheduling Customer write stories Developers estimate cost Customer decides which to do next Group a few weeks worth of stories into an iteration Developers implement stories one at a time until iteration is finished

What is extreme? Extreme, but not unusual user stories, schedule negotiation, staged delivery, testing, simplicity Extreme and unusual pair programming refactoring

Next step… Start to practice Extreme Programming. It is OK not to do it all at once! Your software will be better, cheaper, and make your customers happier.

Kritik af XP Case Against XP ( Slagsmål om ord og tvetydigheder XP er rettet mod kunder der ikke ved hvad de vil – symptom behandling fremfor… Integrate often – kan være problematisk Do a little design Hard to correct errors – due to travel light

Problemer XP er skrevet til anvendelse af een faggruppe – dette er typisk ikke tilfældet Udviklere Interface udviklere AD’er Project Manager HCI Med flere… Giver udfordringer i forhold til “Planning game” og generel styring af projekt flow

Release Planning Kunden Analyserer behov Kunden, Manager og Tracker holder velocity møde Kunden skriver User Stories sammen med: Head Programmer Head Interface Programmer Head AD’er Head Manager Head HCI’er Disse stiller afklarende spørgsmål til User stories indhold Er med I beslutningen om hvorvidt en User Story skal deles

Release Planning (fortsat) Kunden beslutter Business Value for hver eneste User Story De enkelte User Stories estimeres af hver faggruppe (Programmer, AD, HCI etc.) Kunden specificerer acceptance test Kunden går hjem og prioriterer Kortene til brug ved release planning

Planning Iterations Kunden præsenterer prioriterede User Stories Alle faggrupper laver brainstorm sammen på tasks til hver User Story Afhængigheder mellem task’s fastslåes og noteres Team members melder sig til User Stories ownership Teammembers melder sig til udførsel af og estimering af de enkelte User Stories Kunden beslutter sig for at tilføje/fjerne User Stories, baseret på Work Load. Der laves en detaljeret Iterations plan for den aktuelle fase.

Mellem Release planning og Iterations planning møderne Release date og/eller scope er specificeret af kunden Iterations value er specificeret af Manageren End dates for iterationen er fastsat af Manageren

Kundens forretning repræsenteres af Kunden Teamet repræsenteres af Manageren Brugerne repræsenteres af HCI’eren Forretningen Brugerne Teamet Kunden Manager HCI’er

Overview Iteration planning Iteration planning Iteration planning Estimates Estimates Estimates Iteration I Iteration II Iteration III Tasks User Stories

During the iterations Continuos summarisation of workload On a day to day basis

Exploration phase Commitment phase Steering phase Team sign up Release planning Experiments Cust presents stories Brainstorm

Hvem jeg er Systemudviklings erfaringer eXtreme Programming (XP) Hvad er XP Kritik og udfordringer Agile Software Development Manifest Principperne bag Introduktion til andre interessante udviklingselementer Diskussion og spørgsmål XP adskiller sig fra de mere gængse metoder (fx Vandfaldsmodellen) ved at have en noget mere let-vægts tilgang til planlægnig, dokumentation og de øvrige elementer der indgår i systemudvikling. XP er dog ikke den eneste letvægts metode i landskabet. Hvilket også er årsagen til at jeg vil bruge lidt tid på at fortælle om et møde mellem 17 af ophavnsmændene til de mest udbredte af disse. Dette møde resulterede i et manifest de alle – hvor forskellige deres metoder end er - kunne tilslutte sig. Agile Software Development – eller på dansk Adræt software udvikling – og principperne bag – er det tredje hoved emne.

Agile Software Development
Februar 11-13, 2001 – The Lodge at Snowbird ski resort, Utah 17 personer Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Kent Beck XP Mike Beedle SCRUM Arie van Bennekum DSDM Alistair Cockburn Crystal Ward Cunningham XP Martin Fowler XP James Grenning XP Jim Highsmith ASD Andrew Hunt Pragmatic Programming Ron Jeffries XP Jon Kern (togethersoft) Brian Marick (testing) Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

Repræsentanter for “Light methodologies” eXtreme Programming SCRUM DSDM Adaptive Software Development Crystal Feature-Driven Development Pragmatic Programming dX (XP version af RUP – drej 180° = XP :) “UML”-samarbejde for “Light methodologies”

Manifest: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 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. Manifest for adræt software udvikling "Vi afdækker bedre måder at udvikle software på, ved at gøre det og ved at hjælpe andre gøre det. Gennem dette arbejde værdsætter vi" Individet og samarbejde - frem for processer og værktøjer Fungerende software - frem for omfattende dokumentation Samspil med kunden - frem for kontraktforhandlinger Reaktion på forandring - frem for at følge en plan Dette Selvom der er værdi I de punkterne til højre værdsætter vi værdierne til venstre mere

Principperne bag (1/2) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Principperne bag (2/2) Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Links: Agile Manifest: Agile Alliance: Martin Fowler & Jim Highsmith, The Agile Manifest: Martin Fowler, The new Methodology:

Hvem jeg er Systemudviklings erfaringer eXtreme Programming (XP) Hvad er XP Kritik og udfordringer Agile Software Development Manifest Principperne bag Introduktion til andre interessante udviklingselementer Diskussion og spørgsmål Det fjerde punkt jeg kort vil berøre er Use Case Driven Software development. Use Cases er en måde at omskrive eller udtrykke kravene til systemet på. Disse er så det centrale i beskrivelsen eller modelleringen af det nye system – og danner basis og sammenhæng med alle andre deliverables. Use Case driven development kan anvendes i traditionel såvel som Agile system development. Da det dog er en dokumentations metodik der bliver mere og mere udbredt er den medtaget som introduktion.

Andre udviklings elementer
Hvad er Use Case Driven development Krav omskrives til Use Cases Use Cases er bindeled til den øvrige dokumentation Flere niveauer af beskrivelse Conceptuel Logisk Fysisk Flere iterationer

Waterfall model Phase breakdown depends on author Status can be summarized by a single parameter (e.g. 75% of analysis) Not hard to decide order in which to do things Great at handling fixed requirements Original Waterfall model (developed by Win Royce) was NOT presented as a one-way flow (“Myth of the Waterfall”).

Vandfald eller Whirlpool (iterativ) (J. Rumbaugh artikel: “Over the Waterfall and into the Whirlpool. JOOP”, may 1992) Multiple iterations Breath Iterate on the number of individual elements Depth Level of abstraction or detail. For Top-Down the entire system is first sketched (containing major subsystems with few details) and the process then iterates at lower levels adding more detail. Maturity Degree of completeness, correctness and elegance. It takes refinement and rework to get things right.

Multiple iterations (continued) Phase Stage of description. (analysis, system design, object design etc). It’s not necessary that all elements are at the same phase at the same time. All elements must be understood (analysed) before you can build (design and implement). Alternative Different possible solutions to a problem. Usually accompanied by actual prototypes (testing performance, stability, availability etc.) Scope The goal and purpose of a system. The system requirements often change

Hvem jeg er Systemudviklings erfaringer eXtreme Programming (XP) Hvad er XP Kritik og udfordringer Agile Software Development Manifest Principperne bag Introduktion til andre interessante udviklingselementer Diskussion og spørgsmål Det sidste punkt er en ”buffer” hvor vi kan gå mere i dybden med enkelte delområder eller hvis nogen skulle have noget på hjertet der ikke er dækket – men som passer ind – kan vi tage det.

Diskussion og spørgsmål
Om nogen har noget på hjertet…

Udvalgte Udviklingsmetoder

Lignende præsentationer

Præsentationer af emnet: "Udvalgte Udviklingsmetoder"— Præsentationens transcript:

Lignende præsentationer

Om projektet

Feedback

Log ind

Logge ind via sociale netværk:

Udvalgte Udviklingsmetoder

Lignende præsentationer

Præsentationer af emnet: "Udvalgte Udviklingsmetoder"— Præsentationens transcript:

Lignende præsentationer

Om projektet

Feedback