Agile and XP Development Dan Fleck 2008 Dan Fleck 2008.

Slides:



Advertisements
Similar presentations
Agile Software Development کاری از : مهدی هوشان استاد راهنما : استاد آدابی.
Advertisements

Extreme Programming Alexander Kanavin Lappeenranta University of Technology.
NAUG NAUG Knowledge Evening – th February 2007.
Agile Process Models. Prescriptive models don’t work It is unrealistic to not have changes. Why? The Agile Manifesto: Individuals and interactions over.
Agile development By Sam Chamberlain. First a bit of history..
© ThoughtWorks, 2008 Improving Productivity and Quality With Agile Patrick Kua.
Agile
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.
Agile Software Development Matt Rice November 27, 2006.
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.
Programming with eyes wide open. Your host today Subby Angelov Team
An Agile View of Process
Introduction to Agile Methodologies and Concepts Roy Osherove Principal, Team Agile Blog : ISerializable.com.
An Overview of Agile L e a d i n g C h a n g e T h r o u g h C o l l a b o r a t i o n.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Extreme Programming.
Agile Software Development What is Agile? And How are we implementing Agile?
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
Software Development Landscape
Chapter 4 Agile Development
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.
Current Trends in Systems Develpment
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.
Embracing change with Extreme Programming Method Engineering Erik ten Brinke
© 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 Agile Assessment Gadi Lifshitz, Ayelet Kroskin, Barak Yagour, Yael Dubinsky.
Coming up: What is Agile? XP Development Dan Fleck 2010 Dan Fleck 2010.
5. Planning.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
Extreme Programming (XP). Agile Software Development Paradigm Values individuals and interactions over processes and tools. Values working software over.
XP – Extreme Programming
Agile
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.
Chapter 3 Agile Software Development (1/2) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
CS3100 Software Project Management Agile Approaches.
Agile Methodology Paul Mohrbacher. Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through.
Extreme Programming Based on and
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
AGILE XP AND SCRUM © University of LiverpoolCOMP 319slide 1.
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)
Agenda: Overview of Agile testing Difference between Agile and traditional Methodology Agile Development Methodologies Extreme Programming Test Driven.
Agile Development Chapter 10 - part 2. Agile Philosophy  A guiding philosophy and set of guidelines for : developing information systems in an unknown,
Extreme Programming מתודולוגיה לפיתוח פרויקטי תוכנה.
Extreme programming (XP) Advanced Software Engineering Dr Nuha El-Khalili.
By Manish Shrotriya CSE MS 4 Point Agile Manifesto 1.Individuals and interactions over processes and tools 2.Working software over comprehensive.
Coming up: What is Agile? XP Development Dan Fleck 2010 Dan Fleck 2010.
AGILE METHODS Curtis Cook CS 569 Spring 2003.
Embedded Systems Software Engineering
Chapter 5 Agile Development Moonzoo Kim KAIST
Software & Software Engineering Pertemuan-4 Dosen :Kundang K Juman
Extreme Programming.
Planning User stories are written.
Rapid software development
روش‌های سريع الانتقال (چابک) توسعه نرم افزار
What do you need to know about XP?
Agile and XP Development
Agile and XP Development
Agile and XP Development
Coming up: What is Agile?
Introduction to XP.
Extreme Programming.
Agile software development
Chapter 5: New and Emerging Process Methodologies
Presentation transcript:

Agile and XP Development Dan Fleck 2008 Dan Fleck 2008

What is Agile? »Software development practice aimed at: »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. - Excerpt from The Agile Manifesto »Software development practice aimed at: »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. - Excerpt from The Agile Manifesto

What is Agile? »A classification of methodologies that adhere to the agile principles »Developed at a conference in Utah in 2000 »Agile Manifesto (agilemanifesto.org) documentation »A classification of methodologies that adhere to the agile principles »Developed at a conference in Utah in 2000 »Agile Manifesto (agilemanifesto.org) documentation

eXtreme Programming (XP) »Predates Agile »XP was created by Kent Beck at DaimlerChysler in 1996 »Created by Kent Beck (attendee at the conference in Utah, 2000). »Is probably the best-known and most complete “agile-method” »Predates Agile »XP was created by Kent Beck at DaimlerChysler in 1996 »Created by Kent Beck (attendee at the conference in Utah, 2000). »Is probably the best-known and most complete “agile-method”

XP Fundamentals »Take the good things we do and turn them up to 10!  Simplicity  Communication  Feedback  Courage »Take the good things we do and turn them up to 10!  Simplicity  Communication  Feedback  Courage

XP Practices »The Planning Game »Small Releases »Metaphor »On-site Customer »Simple Design »Pair Programming »Test-Driven Development »The Planning Game »Small Releases »Metaphor »On-site Customer »Simple Design »Pair Programming »Test-Driven Development »Refactoring »Continuous Integration »Collective Ownership »Coding Standards »Sustainable Pace »Refactoring »Continuous Integration »Collective Ownership »Coding Standards »Sustainable Pace

The Planning Game »Distinguish between business people’s decisions and developer’s decisions »Short iterations (1-2 weeks) »Each iteration satisfies a number of user- stories »Total time for user stories cannot exceed previous iteration’s user story time  Velocity is a measure of the number of stories finished during an iteration. »Distinguish between business people’s decisions and developer’s decisions »Short iterations (1-2 weeks) »Each iteration satisfies a number of user- stories »Total time for user stories cannot exceed previous iteration’s user story time  Velocity is a measure of the number of stories finished during an iteration.

Planning Game Write a Story (Customer) Spike a Story (Developer) Estimate a story (Developer) Split a Story (Customer) Sort stories by value (Customer) Declare velocity (Developer) Choose scope (Customer) Exploration Planning “too big” “don’t know how”

XP - User Stories »Similar purpose as use cases  Written by customers  Estimated by developers  Replaces large requirements documents  Represents anything that is “progress” to the customer  Examples: »Students can purchase monthly parking passes online. »Parking passes can be paid via credit cards. »Parking passes can be paid via PayPal »Professors can input student marks. »Students can obtain their current seminar schedule. ・ Students can order official transcripts. »Similar purpose as use cases  Written by customers  Estimated by developers  Replaces large requirements documents  Represents anything that is “progress” to the customer  Examples: »Students can purchase monthly parking passes online. »Parking passes can be paid via credit cards. »Parking passes can be paid via PayPal »Professors can input student marks. »Students can obtain their current seminar schedule. ・ Students can order official transcripts.

The Whole Team »Communication is key!  Developers, business analysts, QA, project management, customers, etc… all work in one room  Maximizes collaboration »Communication is key!  Developers, business analysts, QA, project management, customers, etc… all work in one room  Maximizes collaboration

Small Releases »Systems released to production (or pre-production) very frequently (2-3 months maximum, 1 month is better!) »Much easier to plan next month than the next 6 months »Systems released to production (or pre-production) very frequently (2-3 months maximum, 1 month is better!) »Much easier to plan next month than the next 6 months

Continuous Integration »The whole system is built and tested several times a day »Automated testing is required (see TDD later) »The whole system is built and tested several times a day »Automated testing is required (see TDD later)

System Metaphor »Establishes common vocabulary for the system »Consistent naming of classes and methods »Names should be easy to learn and relate to »Establishes common vocabulary for the system »Consistent naming of classes and methods »Names should be easy to learn and relate to

Example System Metaphor »Examples: Shared blackboard  An Expert puts a Problem on the Board.  There are a number of Experts sitting around: when anyone sees a problem they can solve (or know how to break into easier sub-problems), they do so.  There's a protocol that defines, "Who gets the chalk next?" and "When are we done?" »This metaphor suggests a few potential problems:  experts have different skills, and they may not necessarily agree on how to solve a particular problem.  The chalkboard may become a scarce resource.  The most knowledgeable person may find they're doing all the work.  We may have "experts" who aren't as good as they think they are. »Examples: Shared blackboard  An Expert puts a Problem on the Board.  There are a number of Experts sitting around: when anyone sees a problem they can solve (or know how to break into easier sub-problems), they do so.  There's a protocol that defines, "Who gets the chalk next?" and "When are we done?" »This metaphor suggests a few potential problems:  experts have different skills, and they may not necessarily agree on how to solve a particular problem.  The chalkboard may become a scarce resource.  The most knowledgeable person may find they're doing all the work.  We may have "experts" who aren't as good as they think they are.

Sustainable Pace »Coding is a marathon, not a sprint. »Team works 40 hours a week - MAXIMUM! »Tired people aren’t productive »Coding is a marathon, not a sprint. »Team works 40 hours a week - MAXIMUM! »Tired people aren’t productive

Pair Programming »All code is written in pairs »One developer writes code while the other thinks about the code  Is the overall system going to work  Are there better ways of doing this  What test cases still don’t work »Pairs switch roles frequently (every two hours or so) »All code is written in pairs »One developer writes code while the other thinks about the code  Is the overall system going to work  Are there better ways of doing this  What test cases still don’t work »Pairs switch roles frequently (every two hours or so)

Collective Ownership »No individual owns any piece of the software. All pieces may be worked on by any team member »Coding Standard - All team members must abide by a coding standard »No individual owns any piece of the software. All pieces may be worked on by any team member »Coding Standard - All team members must abide by a coding standard

Test Driven Development (TDD) »Write automated unit tests FIRST »Tests must run and fail before code is written »Code then written until unit tests pass »Coding must STOP when unit tests pass (no extra features/functions) »No previously working unit tests can fail »Write automated unit tests FIRST »Tests must run and fail before code is written »Code then written until unit tests pass »Coding must STOP when unit tests pass (no extra features/functions) »No previously working unit tests can fail

Refactoring »All code is continuously reviewed and cleaned. Working code is not enough -- must be clean! »Simple Design - the simplest working design that satisfies the task at hand is used. More complex and general designs may become useful, but not now so we don’t use them! »All code is continuously reviewed and cleaned. Working code is not enough -- must be clean! »Simple Design - the simplest working design that satisfies the task at hand is used. More complex and general designs may become useful, but not now so we don’t use them!

XP Project People »Customer »Developers »Project Manager »Tracker »Coach »Customer »Developers »Project Manager »Tracker »Coach

Tracker »Tracker  Tracks release plan  Tracks iteration plan  Tracks acceptance tests (passed/failed) »Tracker  Tracks release plan  Tracks iteration plan  Tracks acceptance tests (passed/failed) »Coach  Watches everything  Responsible for the process (keep it extreme!)  Helps with anything else needed… but stay back to let the team be self- reliant! »Coach  Watches everything  Responsible for the process (keep it extreme!)  Helps with anything else needed… but stay back to let the team be self- reliant!

When not to use XP »Customer requires a big specification »Large teams > no way! Approx 15 people max. »If your solution requires you to create complex solutions for future problems (exponential cost curve) »When you can’t get feedback immediately (space shuttle?) »When you can’t get people physically close together (same room) »Customer requires a big specification »Large teams > no way! Approx 15 people max. »If your solution requires you to create complex solutions for future problems (exponential cost curve) »When you can’t get feedback immediately (space shuttle?) »When you can’t get people physically close together (same room)

Summary »eXtreme Programming is a set of practices that conform to Agile principles »Xp is one of many Agile methods: DSDM, Crystal, FDD, SCRUM, and others… »These processes are a logical next step from the older “heavyweight” processes »eXtreme Programming is a set of practices that conform to Agile principles »Xp is one of many Agile methods: DSDM, Crystal, FDD, SCRUM, and others… »These processes are a logical next step from the older “heavyweight” processes

References »These references were used to create these slides:   tions/agile_xp_differences.html tions/agile_xp_differences.html  Beck K., Extreme Programming Explained, 2000 »These references were used to create these slides:   tions/agile_xp_differences.html tions/agile_xp_differences.html  Beck K., Extreme Programming Explained, 2000