SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Extreme Programming

hughd avatar
hughd
14 diapositives · 235 Views · Jan 01, 2020

Extreme Programming. David Stotts Dept. of Computer Science Univ. of North Carolina at Chapel Hill. In Reaction to…. “Big Process” SEI Capability Maturity Model ( CMM ) “Heavy” development practices Hard to steer, unresponsive Can we do better for smaller efforts?. Extreme Programming.

Extreme Programming - slide 1
01 / 14Extreme Programming
1 / 17

Télécharger la présentation

Extreme Programming
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  1. Extreme Programming David Stotts Dept. of Computer Science Univ. of North Carolina at Chapel Hill

  2. In Reaction to… • “Big Process” • SEI Capability Maturity Model (CMM) • “Heavy” development practices • Hard to steer, unresponsive • Can we do better for smaller efforts?

  3. Extreme Programming • Kent Beck, late 90’s • One of several “Agile” processes • Small teams (2 to 8 people) • Modest projects • Emphasis on customer as project driver

  4. “Change Happens” • Embrace change as normal • Not an aberration whose cause needs to be found • Process must be lightweight and agile to respond to change • “Steer”able

  5. XP Core Values • Communication • Simplicity • Feedback • Courage (fearlessness)

  6. XP Practices • Pair programming • Test-first development • Simple design: Add no function before its time • Re-factoring • The planning game • User/client on-site

  7. XP Practices • Small releases • Continuous integration • Collective code ownership • Coding standards (and self-documenting code) • No overtime • System metaphor

  8. Why Agile Methods? • Why is change inevitable? • People… • People are noisy and unpredictable • Process involving people needs small steps, constant measurement to be steerable

  9. eXtreme Programming Try it … Further reading: “XP” by J. Highsmith

  10. Test-first development • If a class does not have automatic tests, you must assume it does not work • Regression testing … tests retain value • JUnit (Beck & Gamma): industrial-strength regression testing for the common man

  11. JUnit • Small, easy to learn, easy to use, effective • Java classes • TestCase, Suite, runners • 15 other language implementations • http://www.junit.org • http://www.xprogramming.com/software.htm

  12. JUnit Test Class • One test method per target method • “test anything that can break” … “don’t test anything that can’t” • Can we give better guidance? • Can we systematically produce consistent and complete test classes?

  13. The Planning Game • Informal brainstorming… few hours to a few days • Customer talks about what he/she wants • Engineers listen, ask questions, make “user stories” • Each story is a card, a few sentences, describes some function of the system

  14. The Planning Game • Engineers “cost” each story • Customer “values” each story • Rank order of cards • Customer selects top 4 or 5 items… • Engineers produce Release One