Extreme Programming Theory & XPeriences

Slides:



Advertisements
Similar presentations
Extreme Programming Alexander Kanavin Lappeenranta University of Technology.
Advertisements

An Introduction to eXtreme Programming Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall B.1.
Agile development By Sam Chamberlain. First a bit of history..
Agile
1 JASS 2006, Sergey Konovalov, Stefan Misslinger XP Extreme Programming Joint Advanced Student School (JASS) XP EXTREME PROGRAMMING.
Agile Requirements Methods CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute October 26, 2004.
Agile Methods and Extreme Programming CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 23, 2007.
Extreme Programming: Practices and Strategies Extreme Programming Practices and Strategies Mohammad Alshayeb Information and Computer.
Introduction to XP “When the tests all run, you’re done”
Extreme Programming Team Members Gowri Devi Yalamanchi Sandhya Ravi.
EXtreme Programming By: Aaron Flocke, Leena Paulose, Geetha Krishna (Team 6)
EXtreme Programming Quick Introduction Daniel Arraes Pereira Eduardo Lourenço Apolinário Ricardo de Oliveira Cavalcanti.
Extreme Programming Mark Steverson. What Is Extreme Programming? ● Extreme Programming (XP) is a lightweight, agile methodology developed by Kent Beck.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
Extreme Programming--a “New” Process Model Extreme Programming-- a “New” Process Model.
Agile Software Development
Xtreme Programming. Software Life Cycle The activities that take place between the time software program is first conceived and the time it is finally.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
Software Engineering Modern Approaches
Chapter 5 Software Process Models. Problems with “Traditional” Processes 1.Focused on and oriented towards “large projects” and lengthy development time.
Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming.
Agile and XP Development Dan Fleck 2008 Dan Fleck 2008.
By Saravanan Bala. General Report 31 % of Software projects are cancelled 75 % of the software projects are considered failures by the people who initiated.
Extreme Programming Daniel Baranowski 3/29/06. What is Extreme Programming? An agile development methodology Created by Kent Beck in the mid 1990’s A.
1 e X treme P rogramming D. Dranidis September 2000 CITY College.
Extreme Programming Sylvain Giroux October 3 rd, 2000.
Coming up: What is Agile? XP Development Dan Fleck 2010 Dan Fleck 2010.
1 Software Process Models-ii Presented By; Mehwish Shafiq.
Planning Game in Artifacts Tracker (AT) Project Michal Pilawski.
Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming.
Extreme Programming (XP). Agile Software Development Paradigm Values individuals and interactions over processes and tools. Values working software over.
XP – Extreme Programming
EXtreme Programming Development Adrian Williamson People, Technology and People and Technology Consultant.
Implementing XP at PUT Copyright, 2000 © Jerzy R. Nawrocki Quality Management.
Extreme Programming David Li CTO, DigitalSesame. Problem in Developing Software The Basic Problem - Risk –Schedule slips –Project canceled –System goes.
1 김 수 동 Dept. of Computer Science Soongsil University Tel Fax
Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming.
Extreme Programming and Systems Engineering Similarities and Synergy (based on talk given to INCOSE New England Chapter) Joseph (Yossi) Weihs Sept 10 th,
DAVID STOTTS DEPT. OF COMPUTER SCIENCE UNIV. OF NORTH CAROLINA AT CHAPEL HILL Extreme Programming.
CS3100 Software Project Management Agile Approaches.
Chapter 7 The Practices: dX. 2 Outline Iterative Development Iterative Development Planning Planning Organizing the Iterations into Management Phases.
Extreme Programming (XP) XP is an agile methodology: –aims to be responsive to change Theme running through XP is the importance of communication –amongst.
AP-1 4. Agile Processes. AP-2 Agile Processes Focus on creating a working system Different attitude on measuring progress XP Scrum.
Extreme Programming Based on and
Extreme programming (XP) Variant of agile Takes commonsense practices to extreme levels © 2012 by Václav Rajlich1.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Appendix B Agile Methodologies B.1.
Copyright 2002 by RoleModel Software, Inc. Extreme Programming: So What? Roy W. Miller RoleModel Software, Inc.
Extreme Programming. Extreme Programming (XP) Formulated in 1999 by Kent Beck, Ward Cunningham and Ron Jeffries Agile software development methodology.
Agile. Processes Waterfall Traditional With prototyping Sprial Agile Dynamic Systems Development Method (DSDM) Scrum Crystal eXtreme Programming (XP)
Refactoring1 Improving the structure of existing code.
SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 1 eXtreme Programming – one of the Agile Software Development Methodologies.
CS223: Software Engineering Lecture 18: The XP. Recap Introduction to Agile Methodology Customer centric approach Issues of Agile methodology Where to.
1 Introduction to eXtreme Programming Remko Popma Azzurri Ltd.
Extreme programming (XP) Advanced Software Engineering Dr Nuha El-Khalili.
Coming up: What is Agile? XP Development Dan Fleck 2010 Dan Fleck 2010.
Project Management Software development models & methodologies
AGILE METHODS Curtis Cook CS 569 Spring 2003.
Requirements Engineering Lecture 4
Appendix B Agile Methodologies
Extreme Programming.
What do you need to know about XP?
eXtreme Programming (XP) and eXtreme Modeling (XM)
Coming up: What is Agile?
Refactoring.
Sylvain Giroux October 3rd, 2000
Appendix B Agile Methodologies
Agile software development
Extreme Programming (and Pair Programming)
Chapter 5: New and Emerging Process Methodologies
Presentation transcript:

Extreme Programming Theory & XPeriences Arie van Deursen 31 October 2000 - Achtergrond CWI, SIG, Abn Amro, XP ervaring, XP conferentie - Vragen naar achtergrond bezoekers: OO ervaring? Ontwikkelaars? Projectleiders? Management? Testers? - XP = ontwikkelingsmethodiek. Kent Beck, reflecteert op eigen software ontwikkeling. - Software Ontwikkeling: wat belangrijkste “gewoontes” , “best practices”? Vb: testen, code review, UML, up fron specs - XP: zet best practices op max. - Profiteer van ontwikkelingen in techniek: OO, design pattern, relational databases, GUI, CBD http://www.cwi.nl/~arie/

Software Development Risks What are your most pressing development problems? Schedule slips Project canceled System goes sour / high defect rate Business misunderstood / changes False feature rich Staff turnover Eerst vragen: wat zijn de belangrijkste risico’s?

XP Project Characteristics Use of object technology (use of modern language) Development team size: 2 to 20 people Developers take responsibility Participating customer

XP Practices The Planning Game Small Releases Metaphor Simple design Testing Refactoring Pair programming Collective ownership Continuous integration 40-hour week On-site customer Coding standards all applied to the extreme

Self-Testing Code Every class also has a TestClass TestClass methods: set up fixture invoke code to be tested Automatically check results tear down fixture Collect test in suites; run them all. All tests must run at 100% at all times

JUnit http://www.junit.org

Test First Run all tests and get green bar; Write (failing) test before coding: if interface is unclear if implementation might be hard for every special case (if-then-else) before dealing with bug report Modify the code to turn red into green bar

Our Testing XPeriences Test / production code ratio of 1:2 Writing tests forced us to write smaller methods Test case = documentation Having many test cases helps to dare change other people’s code. Systematic reuse of each other’s tests

Refactoring Refactoring A change made Refactor: Interactive Transformation Introduce design patterns Refactoring A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior Refactor: apply series of refactorings

Bad Smells in Code Duplicated Code Long Method Large Class Say it once! And only once! Duplicated Code Long Method Large Class Long Parameter List Divergent Change Shotgun Surgery Feature Envy Speculative Generality Inappropriate Intimacy Comments Switch Statements Data Clumps Data Class Delving into each other’s private parts Need to take some responsibility out of the cave into the centrally heated world of objects

Why Refactor? Improves the Design of Software Makes software easier to understand Refactor first to understand unfamiliar code Small refactoring -> larger ones “Wiping the dirt off a window, so you can see beyond” Helps you find bugs Helps you program faster

When should you Refactor? Three strikes and you refactor First time: just do it. Second time something similar: duplicate Third time something similar: refactor. Add feature Fix bug Review Code

Refactoring Process Modifying code involves: Test (add if necessary) Refactor to increase understanding Test Add tests for change, modify until it passes; Refactor to bring code to simplest state

Refactoring Catalog Name Summary Motivation Mechanism Examples Simple renamings up to major changes to class structure

Refactoring XPeriences Software improvement is explicit part of programming activity Possible thanks to test suites Small refactorings on a daily basis Large refactorings applied incrementally.

Simplicity XP: Have the simplest design that runs the current test suite: Code + tests communicate everything you want to communicate The system contains no duplicate code The system has the fewest possible classes The system has the fewest possible methods Achieved by constant refactoring! Vraag: eens of niet? Implicaties?

Design Through Refactoring Each change includes refactoring Each refactoring improves/repairs the design Large refactorings done by need Each refactoring = mini design-phase => Death of the big design (phase) => No separation programmer/architect

Design for Tomorrow Guess at the future. Tomorrow may never happen Learn a better way to implement a change before the time you need it Pay cost of carrying along a more complicated design Costs of unused generalizations > benefits of used generalizations

Design for Today Trust your ability to change Rely on tests Implement changes together Use modern programming technology Remove any flexibility that isn’t useful Design test by test: Repeatedly Write a test -> implies bit of design; Design & implement its code Refactor when necessary

Our Design XPeriences Designs evolve Re-design = refactoring Small refactorings done every day Major refactorings: Senior programmers involved Discussed with complete team Exploration first Implemented incrementally

Pair Programming All production code is written with two people looking at one machine, with one keyboard and one mouse. If code review is good, we do it all the time

Pair Programming XPeriences (Initial) resistance Changing pairs Discuss design, refactorings, tests Way to communicate system knowledge Improves quality (a lot) Coding is more fun, calmer, and less solitary More (> 2) productive

User Stories Collect requirements as user stories Possible to explain, test, and estimate Prioritize stories in order of business importance Development: Estimate effort for stories Highlight technical risks / consequences

Growing a System Have a running system from day 1. Integrate stories one by one Work with small iterations: Approx. 3 weeks Split (combine) stories into tasks, estimate Design, test, build, test Measure progress, learn to estimate

Planning a Release Release: every 2 - 6 months Fix date, cost and quality Determine scope: how many stories can be done following development estimates Most important user stories first Feedback / adjustment at every iteration New / modified stories Changed estimates

The Planning Game XP Planning: The Goal: Dialog between possible and desirable Set of rules to govern building respectful relationship Metaphor: Game The Goal: Maximize value of software produced by the team

Planning Game (cont.) The Strategy: The Pieces: Put the most valuable functionality into production as quickly as possible with minimal initial investment addressing risk first The Pieces: Cards containing user stories

Planning Game (cont.) The Players: The Moves: Business: decides what system must do Development: build the system The Moves: Exploration: what could system do? Commitment:decide on this release Steer: Guide actual development, adjust.

Our Planning XPeriences Planning internal product development Mimicked customer, “invented” stories Work in small iterations Always have a running system Planning customer development Made planning process “XP-like” Didn’t force customer into XP game (yet…) Learning to plan more systematically.

XP Values Communication Simplicity Feedback Courage Adopt practices that encourage talking & listening Simplicity What is the simplest thing that could possibly work? Feedback The system tests will tell you; Listen to the code! Courage Go at top speed

XP Basic Principles Rapid feedback Assume simplicity Incremental change Embracing change Quality work Teach learning Small initial investment Play to win Concrete experiments Open, honest communication Work with instincts Accepted responsibility Local adaptation Travel light Honest measurement

XP Roles Programmer -- pairing, testing, coding, designing, estimating -- courageous. Customer -- provide user stories + tests Tester -- implement functional tests Tracker -- log progress Coach -- teach to learn Consultant -- optional specialist Big Boss -- confident

Adopting XP Have motivated team Learn practices one by one Deceivingly simple tests, refactoring, pairing, planning Take sufficient time to learn Course (spread over year), mentoring But make sure you try!

Further Info K. Beck -- eXtreme Programming eXplained M. Fowler -- UML Distilled (2nd Ed.) www.c2.com/wiki www.xprogramming.com

Summary: XP Practices The Planning Game Small Releases Metaphor Simple design Testing Refactoring Pair programming Collective ownership Continuous integration 40-hour week On-site customer Coding standards all applied to the extreme