1 / 64

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 Hvem jeg er Systemudviklings erfaringer eXtreme Programming (XP) Hvad er XP

fletcher-maddox
Download Presentation

Udvalgte Udviklingsmetoder

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • Lidt om min baggrund • 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

  3. Agenda • Lidt om min baggrund • 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

  4. 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

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

  6. 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)

  7. Lidt om min baggrund • Systemudviklings erfaringer • 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

  8. 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

  9. 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

  10. 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

  11. 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!

  12. 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

  13. Lidt om min baggrund • Systemudviklings erfaringer • 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

  14. Agenda • Lidt om min baggrund • 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

  15. eXtreme Programming (XP) • XP is a lightweight way to produce softwareStarted 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.

  16. eXtreme Programming (XP) • 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

  17. eXtreme Programming (XP) • 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

  18. eXtreme Programming (XP) • Warning…. DO NOT USE EXTREME PROGRAMMING

  19. eXtreme Programming (XP) • 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

  20. eXtreme Programming (XP) • Use XP if You like the Agile Alliance value Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaborationover contract negotiation Responding to changeover following a plan

  21. eXtreme Programming (XP) • 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

  22. eXtreme Programming (XP) • 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

  23. eXtreme Programming (XP) • Traditional Cost Model

  24. eXtreme Programming (XP) • XP Cost Model

  25. eXtreme Programming (XP) • 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

  26. eXtreme Programming (XP) • 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

  27. eXtreme Programming (XP) • Benefits of XP • Software stays soft Martin Fowler, “Keeping software Soft” (http://www.martinfowler.com/articles/soft.pdf) • Handles changing requirements • Quickly produces something useful, keeps making useful enhancements • Average developers can produce great software

  28. eXtreme Programming (XP) • XP Roles • Customer • Programmer • Manager • Tracker, Tester, Consultant, Big Boss • … and a cast of thousands

  29. eXtreme Programming (XP) • 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

  30. eXtreme Programming (XP) • 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

  31. eXtreme Programming (XP) • Things we know we should do • Staged delivery • Business people make business decisions and technical people make technical decisions • Regression testing, unit tests • Review

  32. eXtreme Programming (XP) • Extreme Programming • Analysis • Test • Code • Design • + project management

  33. eXtreme Programming (XP) • Extreme Analysis • Describe system as a set of user stories • Users write stories explaining one use of the system • Like use cases, but informal

  34. eXtreme Programming (XP) • 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

  35. eXtreme Programming (XP) • 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

  36. eXtreme Programming (XP) • 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

  37. eXtreme Programming (XP) • 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

  38. eXtreme Programming (XP) • 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

  39. eXtreme Programming (XP) • 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

  40. eXtreme Programming (XP) • What is extreme? • Extreme, but not unusual • user stories, schedule negotiation, staged delivery, testing, simplicity • Extreme and unusual • pair programming • refactoring

  41. eXtreme Programming (XP) • 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.

  42. eXtreme Programming (XP) • Kritik af XP Case Against XP (http://www.softwarereality.com/lifecycle/xp/case_against_xp.jsp) • 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

  43. eXtreme Programming (XP) • 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

  44. eXtreme Programming (XP) • 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

  45. eXtreme Programming (XP) • 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

  46. eXtreme Programming (XP) • 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.

  47. eXtreme Programming (XP) • 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

  48. Forretningen Brugerne HCI’er Kunden Manager Teamet eXtreme Programming (XP) • Kundens forretning repræsenteres af Kunden • Teamet repræsenteres af Manageren • Brugerne repræsenteres af HCI’eren

  49. Iteration planning Iteration planning Iteration planning Estimates Estimates Estimates eXtreme Programming (XP) • Overview Iteration I Iteration II Iteration III Tasks User Stories

  50. eXtreme Programming (XP) • During the iterations • Continuos summarisation of workload • On a day to day basis

More Related