2. Process and toolsProcess and toolsIndividuals and
interactions
Individuals and
interactions
over
Following a planFollowing a planResponding to changeResponding to change over
Source: www.agilemanifesto.org
Comprehensive
documentation
Comprehensive
documentationWorking softwareWorking software over
Contract negotiationContract negotiationCustomer
collaboration
Customer
collaboration
over
3. 12 PRINCIPLES
Our highest priority is to satisfy the customer
through early and continuous delivery of valuable
software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a couple
of weeks to a couple of months, with a preference to
the shorter timescale.
Business people and developers must work together
daily throughout the project.
4. 12 PRINCIPLES
Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
The most efficient and effective method of conveying
information to and within a development team is
face-to-face conversation.
Working software is the primary measure of
progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
5. 12 PRINCIPLES
Continuous attention to technical excellence
and good design enhances agility.
Simplicity--the art of maximizing the amount
of work not done--is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts its
behavior accordingly.
6.
7. INTRODUCTION EXTREME PROGRAMMING?
An agile development methodology XP is “a light-
weight methodology for small to medium-sized
teams developing software in the face of vague or
rapidly changing requirements
It works by bringing the whole team together in the
presence of simple practices, with enough feedback
to enable the team to see where they are and to tune
the practices to their unique situation?
Created by Kent Beck in the mid 1990’s
A set of 12 key practices taken to their “extremes”
A mindset for developers and customers
8. EXTREME PROGRAMMING
Hence XP is a lightweight (agile) process:
Instead of lots of documentation nailing down what
customer wants up front, XP emphasizes plenty of
feedback
Embrace change: iterate often, design and
redesign, code and test frequently, keep the
customer involved
Deliver software to the customer in short (1-3
week) iterations
Eliminate defects early, thus reducing costs
13. FOUR CORE VALUES OF XP
Communication
Simplicity
Feedback
Courage
14. XP PRACTICES
The Planning Game
Small Releases
Metaphor
Simple Design
Testing
Refactoring
Pair Programming
Collective Ownership
Continuous Integration
40-Hour Workweek
On-site Customer
Coding Standards
15. THE PLANNING GAME
Planning for the upcoming iteration
Uses stories provided by the customer
Technical persons determine schedules, estimates, costs, etc
A result of collaboration between the customer and the
developers
Advantages
Reduction in time wasted on useless features
Greater customer appreciation of the cost of a feature
Less guesswork in planning
Disadvantages
Customer availability
Is planning this often necessary?
16. Small in terms of functionality
Less functionality means releases happen more
frequently
Support the planning game
Advantages
Frequent feedback
Tracking
Reduce chance of overall project slippage
Disadvantages
Not easy for all projects
Not needed for all projects
Versioning issues
17. METAPHOR
The oral architecture of the system
A common set of terminology
The system metaphor is a story that everyone - customers, programmers, and
managers - can tell about how the system works. It's a naming concept for classes and
methods that should make it easy for a team member to guess the functionality of a
particular class/method, from its name only. For example a library system may
createloan_records(class) for borrowers(class), and if the item were to
become overdue it may perform a make_overdue operation on a catalogue(class).
For each class or operation the functionality is obvious to the entire team.
Advantages
Encourages a common set of terms for the system
Reduction of buzz words and jargon
A quick and easy way to explain the system
Disadvantages
Often the metaphor is the system
Another opportunity for miscommunication
The system is often not well understood as a metaphor
18. SIMPLE DESIGN
K.I.S.S (Keep it simple Stupid)
Do as little as needed, nothing more
The author should ask themselves 'is there a simpler way to introduce the same
functionality?'. If the answer is yes, the simpler course should be chosen.
Refactoring should also be used, to make complex code simpler.
Advantages
Time is not wasted adding superfluous functionality
Easier to understand what is going on
Refactoring and collective ownership is made possible
Helps keeps programmers on track
Disadvantages
What is “simple?”
Simple isn’t always best
19. TESTING
Unit testing
Test-first design
All automated
Advantages
Unit testing promote testing completeness
Test-first gives developers a goal
Automation gives a suite of regression test
Disadvantages
Automated unit testing isn’t for everything
Reliance on unit testing isn’t a good idea
A test result is only as good as the test itself
20. REFACTORING
Changing how the system does something but not what is done
Improves the quality of the system in some way
Advantages
Prompts developers to proactively improve the product as a whole
Increases developer knowledge of the system
Disadvantages
Not everyone is capable of refactoring
Refactoring may not always be appropriate
Would upfront design eliminate refactoring?
21. PAIR PROGRAMMING
Two Developers, One monitor, One Keyboard
One “drives” and the other thinks
Switch roles as needed
Advantages
Two heads are better than one
Focus
Two people are more likely to answer the following questions:
Is this whole approach going to work?
What are some test cases that may not work yet?
Is there a way to simplify this?
Disadvantages
Many tasks really don’t require two programmers
A hard sell to the customers
22. COLLECTIVE OWNERSHIP
The idea that all developers own all of the code
Enables refactoring
Advantages
Helps mitigate the loss of a team member leaving
Promotes developers to take responsibility for the system as
a whole rather then parts of the system
Disadvantages
Loss of accountability
Limitation to how much of a large system that an individual
can practically “own”
23. CONTINUOUS INTEGRATION
New features and changes are worked into the
system immediately
Code is not worked on without being integrated for
more than a day
Advantages
Reduces to lengthy process
Enables the Small Releases practice
Disadvantages
The one day limit is not always practical
Reduces the importance of a well-thought-out architecture
24. 40-HOUR WEEK
The work week should be limited to 40 hours
Regular overtime is a symptom of a problem and not a
long term solution
Advantages
Most developers lose effectiveness past 40-Hours
Value is placed on the developers well-being
Management is forced to find real solutions
Disadvantages
The underlying principle is flawed
40-Hours is a magic number
Some may like to work more than 40-Hours
25. ON-SITE CUSTOMER
Acts to “steer” the project
Gives quick and continuous feedback to the development team
Advantages
Can give quick and knowledgeable answers to real development
questions
Makes sure that what is developed is what is needed
Functionality is prioritized correctly
Disadvantages
Difficult to get an On-Site Customer
The On-Site customer that is given may not be fully knowledgeable about
what the company
May not have authority to make many decisions
Loss of work to the customer’s company
26. CODING STANDARDS
All code should look the same
It should not possible to determine who coded what
based on the code itself
Advantages
Reduces the amount of time developers spend reformatting
other peoples’ code
Reduces the need for internal commenting
Call for clear, unambiguous code
Disadvantages
Degrading the quality of inline documentation
27. Customer
Writes User Stories and specifies Functional Tests
Sets priorities, explains stories
May or may not be an end-user
Has authority to decide questions about the stories
Programmer
Estimates stories
Defines Tasks from stories, and estimates
Implements Stories and Unit Tests
Coach
Watches everything, sends obscure signals, makes sure
the project stays on course
Helps with anything
28. Tracker
Monitors Programmers’ progress, takes action if things seem to be
going off track.
Actions include setting up a meeting with Customer,
Coach or another Programmer to help
Tester
Implements and runs Functional Tests (not Unit Tests!)
Graphs results, and makes sure people know when test results
decline.
Doomsayer
Ensures that everybody knows the risks involved
Ensures that bad news isn't hidden, glossed over, or blown out of
proportion
29. Manager
Schedules meetings (e.g. Iteration Plan, Release Plan),
makes sure the meeting process is followed, records results
of meeting for future reporting, and passes to the Tracker
Possibly responsible to the Gold Owner.
Goes to meetings, brings back useful information
Gold Owner
The person funding the project, which may or may not be
the same as the Customer
30. Coding: You code because if you don't code, at the end of the
day you haven't done anything.
Testing: You test because if you don't test, you don't know
when you are done coding
Listening: You listen because if you don't listen you don't
know what to code or what to test
Designing: And you design so you can keep coding and
testing and listening indefinitely (good design allows
extension of the system with changes in only one place)
31. Exploration Phase: In this phase the customer will provide a
shortlist of high-value requirements for the system. These will
be written down on user story cards.
Commitment Phase: Within the commitment phase customer
and developers will commit themselves to the functionality that
will be included and the date of the next release.
Steering Phase: In the steering phase the plan can be
adjusted, new requirements can be added and/or existing
requirements can be changed or removed
32. Iterative process of gathering requirements and estimating the
work impact of each of those requirements.
Write a Story:
Customer has come with a problem; during a meeting,
Developer will try to define this problem and get
requirements. Based on the business problem, a story (
user story) has to be written. This is done by Customer, where
they point out what they want a part of the system to do. It is
important that developer has no influence on this story. The
story is written on a user story card.
Roles : Customer , Developer
Artifact : User Stories
33. Estimate a Story: Developer estimates how long it
will take to implement the work implied by the story
card. Developer can analyze or solve the problem.
These solutions are used for estimation and
discarded once everyone gets clear visualization of
the problem. Again, this may not influence the
business requirements.
Split a Story: Design critical complexity has to be
addressed before starting the iteration planning. If
developer isn't able to estimate the story, it needs to
be split up and written again.
34. This phase involves the determination of costs,
benefits, and schedule impact. It has four
components:
Sort by Value: Customer sorts the user stories by business
value
Sort by Risk: Developer sorts the stories by risk.
Set Velocity: Developer determines at what speed they can
perform the project.
Choose scope: The user stories that will be finished in the
next release will be picked. Based on the user stories the
release date is determined.
35. The business side sorts the user stories by business
value. They will arrange them into three piles:
Critical: stories without which the system cannot
function or has no meaning.
Significant Business Value: Non-critical user stories
that have significant business value.
Nice to have: User stories that do not have significant
business value.
36. The developers sort the user stories by risk. They also categorize into three piles: low, medium
and high risk user stories. The following is an example of an approach to this:
Determine Risk Index: Give each user story an index from 0 to 2 on each of the following factors:
Completeness (do we know all of the story details?)
Complete (0)
Incomplete (1)
Unknown (2)
Volatility (is it likely to change?)
low (0)
medium (1)
high (2)
Complexity (how hard is it to build?)
simple (0)
standard (1)
complex (2)
All indexes for a user story are added, assigning the user stories a risk index of low (0–1),
medium (2–4), or high (5–6).
37. Within the steering phase the developer and customer can
"steer" the process. That is to say, they can make changes.
Individual user stories, or relative priorities of different user
stories, might change; estimates might prove wrong. This is the
chance to adjust the plan accordingly.
38. Plans the activities and tasks of the developers. In this process
the customer is not involved..
Role : Developers
3 Phases of Iteration Planning
39. Exploration Phase: requirement will be translated to different
tasks. The tasks are recorded on task cards.
Commitment Phase: The tasks will be assigned to the
programmers and the time it takes to complete will be
estimated.
Steering Phase: The tasks are performed and the end result is
matched with the original user story
40. It is about creating tasks and estimating their
implementation time.
Translate the requirement to tasks: Place on task
cards.
Combine/Split task: If the programmer cannot
estimate the task because it is too small or too big,
the programmer will need to combine or split the
task.
Estimate task: Estimate the time it will take to
implement the task
41. Within the commitment phase of the iteration planning
programmers are assigned tasks that reference the
different user stories.
A programmer accepts a task, each programmer picks a
task for which he or she takes responsibility.
Programmer estimates the task, because the programmer
is now responsible for the task, he or she should give the
eventual estimation of the task.
42. Set load factor: The load factor represents the ideal
amount of hands-on development time per programmer
within one iteration. For example, in a 40-hour week, with
5 hours dedicated to meetings, this would be no more
than 35 hours.
Balancing: When all programmers within the team have
been assigned tasks, a comparison is made between the
estimated time of the tasks and the load factor. Then the
tasks are balanced out among the programmers. If a
programmer is overcommitted, other programmers must
take over some of his or her tasks and vice versa.
43. The implementation of the tasks is done during the
steering phase of the iteration planning.
Get a task card: The programmer gets the task card
for one of the tasks to which he or she has
committed.
Find a Partner: The programmer will implement this
task along with another programmer. This is further
discussed in the practice Pair Programming.
Design the task: If needed, the programmers will
design the functionality of the task.
44. Write unit test: Before the programmers start coding
the functionality they first write automated tests. This
is further discussed in the practice Unit Testing.
Write code: The programmers start to code.
Run test: The unit tests are run to test the code.
Refactor: Remove any code smell from the code.
Run Functional test: Functional tests (based on the
requirements in the associated user story and task
card) are run.
46. A short description of the behavior of the system
from the point of view of the Customer
Use the Customer’s terminology without technical
jargon
One for each major feature in the system
Must be written by the users
Are used to create time estimates for release
planning
Replace a large Requirements Document
47. Drive the creation of the acceptance tests
Must be one or more tests to verify that a story has been
properly implemented
Should only provide enough detail to make a reasonably
low risk estimate of how long the story will take to
implement.
Written by the Customer, not the Programmers, using the
Customer’s terminology
More “friendly” than formal Use Cases
48. User stories have three crucial aspects:
Card
Enough information to identify the story
Conversation
Customer and Programmers discuss the story to elaborate
on the details
Verbal when possible, but documented when required
Confirmation
Acceptance tests to confirm that the story has been properly
implemented
49. A user wants access to the system, so they find a system
administrator, who enters in the user's First Name, Last Name,
Middle Initial, E-Mail Address, Username (unique), and Phone
Number.
Risk: Low Cost: 2 points