Lecture 7 - XP Agile
Lecture 7 - XP Agile
Fundamentals of
Software Engineering
LECTURE: AGILE AND EXTREME PROGRAMMING
2
AGILE DEVELOPMENT
2001 Kent Beck and 16 other software developers,
referred to as “Agile Alliance”, signed the “manifesto for
Agile software development” It stated We are
uncovering better ways of developing software by
doing it and helping others do it
Through this work we have come to value
Agile ▪ Individuals and interaction over processes and tool
Development ▪
▪
Working software over comprehensive documentation
Customer collaboration over contract negotiation
▪ Responding to change over following plan
3
4
Agile Principles
Agile Alliance defined 12 agility principles:
1. Highest priority is to satisfy the customer through early and continues delivery of valuable software.
2. Welcome changing requirements even late n the development (for customers competitive
advantage).
3. Deliver working software frequently, from couple of weeks to couple of months.
4. Business people and developers must work together daily throughout the project.
5. Build project around motivated Individuals. Give them the environment and support they need,
and trust them to get the job done.
6. Most efficient and effective method of conveying information to and with team is face to face
conversation.
5
Agile Principles
8. Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity the art of maximizing the amount of work done is essential.
11. The best architectures, requirements, and designs emerge from self organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
6
Agile Methods
Extreme Programming
XP (according to inventor Kent Beck) is
characterized by 12 practices:
Planning Game
Small Releases
Metaphor
Simple Design
XP (Xtreme Testing
Continuous Integration
Programing)
Pair Programming
Collective Ownership
Refactoring
40 Hour Week
On Site Customer
Coding Standards
11
12
XP Practices
Planning game programmers estimate effort of implementing
customer stories and customer decides about scope and timing of
releases
Short releases new release every 2 3 months
Simple design emphasis on simplest design
Testing development test driven.
Refactoring restructuring and changes to simplify
Pair Programming 2 people at 1 computer
14
Pair
Programming
(Key practice
of XP)
15
XP (Extreme Programming)
XP Practices
Collective ownership anyone can change any part of the code at any time.
Continuous integration new builds as soon as code ready
40 hour week maximum 40 hour week. No overtime
On site customer present and available full time for team
Coding standards rules exist and are followed
Open workspace large room small cubicles
Just rules team has own rules but can be changed any at time
16
Key Practices of XP
Planning
User stories are written.
Release planning creates the schedule.
Make frequent small releases
The Project Velocity is measured.
The project is divided into iterations
Iteration planning starts each iteration.
Move people around
A stand up meeting starts each day.
Fix XP when it breaks.
17
Key Practices of XP…..
Designing
Simplicity
Choose a system metaphor . (system of names for your objects that
everyone can relate to)
Use CRC cards for design sessions.
Create spike solutions to reduce risk.
Refactor whenever and wherever possible e.g. Techniques for
improving names and location of code Move method or move field
move to a more appropriate class or source file Rename method or
rename field changing the name into a new one that better reveals
its purpose
18
Class-
responsibility-
collaboration
card
19
Key Practices …
Coding
The customer is always available
Code must be written to agreed standards
Code the unit test first
All production code is pair programmed
Only one pair integrates code at a time
Integrate often
No overtime .
Testing
All code must have unit tests
All code must pass all unit tests before it can be released.
When a bug is found tests are created.
Acceptance tests are run often and the score is published.
20
Fitting it
all
together
21
XP Advantages/Disadvantages
Advantages
Built In Quality
Overall Simplicity
Programmer Power
Customer Power
Synergy Between Practices
22
XP Advantages/Disadvantages
Disadvantages
Informal, little, or no documentation
Scalability
Contract Issues
Misconception on the cost of change
Tailoring
23
When to use / Not to use
Applicable
Highly uncertain environments
Internal projects
Joint ventures
Not Suitable / Applicable
Large, complex environments
Safety critical situations
Well understood requirements
Distant or unavailable customer
24
Final Thoughts
Why XP succeeds
Why XP is popular
Why XP fails
Why XP is not the silver bullet
25
SCRUM
26
SCRUM
Scrum
framework
38
39
Example
of Scrum
Artefacts
40
A
sample
product
backlog
41
Putting it
all
together
42
Typically 5 9 people
Cross functional:
Programmers, testers, user experience
The team designers, etc.
M embers should be full time
May be exceptions (e.g., database
administrator)
45
The team