2. What is Agile ?
Agile is the ability to create and respond to change.
It is a way of dealing with, and ultimately succeeding in,
an uncertain and turbulent environment.
The authors of the Agile Manifesto chose “Agile” as the
label for this whole idea because that word represented
the adaptiveness and response to change which was so
important to their approach.
3. History of Agile Methods
□ Particularly in 1990s, some developers reacted against
traditional “heavyweight” software development processes.
□ New methods were being developed and tested,
□ e.g. extreme programming, SCRUM, Feature-driven
development
□ Generally termed “light” processes
□ “Representatives” from several of these methods got together
in Utah in 2001
□ Settled on term “Agile” as a way to describe these methods
□ Called themselves the “Agile Alliance”
□ Developed a “manifesto” and a statement of “principles”
□ Focuses on common themes in these alternative
methodologies
4. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
4 values of agile
5. 12 Principles behind the Agile Manifesto
1. Our highest priority is to satisfy the customer
through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in
development.
3. Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
H C W hey change work
6. 12 Principles behind the Agile Manifesto
4. Business people and developers must work
together daily throughout the project.
5. Build projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.
6. The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.
T M F
to mother fucker
to motivate face
7. 12 Principles behind the Agile Manifesto
7. Working software is the primary measure of
progress. -or- Measuring progress by the
amount of completed work
8. Agile processes promote sustainable development.
The sponsors, developers, and users should be
able to maintain a constant work.
9. Continuous attention to technical details and
design enhances agility.
P C C
8. 12 Principles behind the Agile Manifesto
10. Simplicity--the art of maximizing the amount
of work not done--is essential.
11. The best architectures, requirements, and designs
emerge from self-organizing teams.
12. At regular reflections on how to become more
effective, then tunes and adjust its behavior
accordingly.
S A R
simple as r
10. Extreme Programming (XP)
□ One of the most well-known agile methods
□ Developed in 1990s
□ Kent Beck, 1996
□ Chrysler Comprehensive Compensation
Project
□ Published book in 1999
11. Extreme Programming (XP)
Extreme Programming (XP) is an agile software development
framework that aims to produce higher quality software, and
higher quality of life for the development team.
XP is the most specific of the agile frameworks regarding
appropriate engineering practices for software development.
12. Extreme Programming (XP)
Extreme Programming technique is very helpful when
there is constantly changing demands or
requirements from the customers or when they are
not sure about the functionality of the system.
It advocates frequent "releases" of the product in
short development cycles, which inherently improves
the productivity of the system and also introduces a
checkpoint where any customer requirements can be
easily implemented.
The XP develops software keeping customer in the
target
13. Extreme Programming Practices
1. On-Site Customer
□ Customer is actively involved with development process
□ Customer gives “User Stories”
■ Short, informal “stories” describing features
■ Keep on “story cards”
2. Planning Game
□ Developers and customers together plan project
□ it gives cost estimatoion and budget of the project
□ Developers give cost estimates to “stories” and a budget of
how much they can accomplish
■ Can use abstract accounting mechanism
■ Later compare to actual cost, to improve estimates over time
□ Customer prioritizes stories to fit within budget
14. Extreme Programming Practices
3. Metaphor
□ A Metaphor is an expression, often found in literature that
describes a person or object by referring to something that is
considered to have similar characteristics to that person or
object.
□ For example, ‘The mind is an ocean’ and ‘the city is a jungle’
are both Metaphors.
□ You should guide the entire development with a simple
shared story of how the whole system works.
□ You can think of metaphor as the architecture of the system
to be built in a way that it is easily understandable by
everyone involved in the development.
it describes how project will fit together
it provides framework for the porject
tool and material provvides good metahpor
15. Extreme Programming Practices
4. Small Releases
□ Time between releases drastically reduced
■ A few weeks/months
□ Multiple iterations
□ Can have intermediate iterations between
bigger “releases”
16. Extreme Programming Practices
5. Testing
□ Test-first programming
□ Unit testing frequently by developers
□ Acceptance tests defined by customers
6. Simple Design
□ Design should be quick, not elaborate
□ Pick the simplest thing that could possibly work
□ Resist adding stuff not ready yet
17. Extreme Programming Practices
7. Refactoring
□ Refactoring as the word suggests, is restructuring or
reconstructing existing things. In XP over a period of time the
team produces lots of working code and it increases the
complexity and that contributes technical debt. To avoid this,
we should consider the below points,
□ Ensure code or functions are not duplicated.
□ Ensure all variables in scope, defined and used.
□ No long functions or methods
□ Removing unnecessary stuff and variables
□ Proper use of access modifiers etc.
□ By refactoring, the programmers look to improve the
overall code quality and make it more readable without
altering its behavior.
sometime code might get worst by adding new features or fixiing bugs. so rewrite
the code regularly. and rerun all the unit test.
18. Extreme Programming Practices
8. Pair Programming
Pair programming consists of two programmers sitting at
the same machine.
One programmer plays imp role and focuses on clean code,
and compiles and runs(pivot). The second one plays the
role of navigator and focuses on the big picture and reviews
code for improvement or refactoring(navigator).
Every hour or given a period of time this pair is allowed to
switch roles so that the pilot will play the role of navigator
and vice versa.
The pairs of pilots and navigators are also not fixed and
they are frequently swapped, the main benefits of that over
a period of time is that everyone gets to know about the
code and functionality of the whole system.
19. Extreme Programming Practices
9. Collective Ownership
□ Anyone can edit anything
□ Errors are the fault of the whole team
10. Continuous Integration
□ Commit changes frequently (several times a day)
□ Verify against entire test suite!
11. Coding Standards
□ Enables effective teamwork
20. Extreme Programming Practices
11. Coding Standard :
Developers write all code in accordance with the rules emphasizing-
• Communication through the code.
• The least amount of work possible.
• Consistent with the “once and only once” rule (no duplicate code).
• Voluntary adoption by the whole team.
These rules are necessary in Extreme Programming because all the
developers −
• Can change from one part of the system to another part of the
system.
• Swap partners a couple of times a day.
• Refactor each other's code constantly.
If the rules are not followed, the developers will tend to have different
sets of coding practices, the code becomes inconsistent over time
and it becomes impossible to say who on the team wrote what code.
21. Extreme Programming Practices
12. Sustainable Pace
□ No overtime
□ Only exceptions in final week
□ Good estimation skills for budgeting will help ensure
reasonable times
□ Time less likely to be wasted in pairs, bullpen rooms
□ Plan time each day for administrative work (<1 hour),
breaks
22. Drawbacks and Challenges of Agile Methods
□ Undefined goals
□ Need clear, single, invested customer
□ All-or-nothing adoption of techniques
□ Some parts work only if lots of other aspects
used
□ Team size limited (smaller teams)
23. Planning
The first phase of Extreme Programming life cycle is planning, where
customers or users meet with the development team to create ‘user
stories’ or requirements.
The development team converts user stories into iterations that cover a
small part of the functionality or features required.
A combination of iterations provides the customer with the final fully
functional product.
The programming team prepares the plan, time, and costs of carrying out
the iterations, and individual developers sign up for iterations.
Begins with the creation of a set of stories called user stories
Each story is written by the customer
The customer assigns a priority to the story
Agile team assesses each story and assigns a cost
Stories are grouped for a deliverable increment
24. Planning
□ Initial Exploration
□ Spiking, Splitting, and Velocity
□ Release Planning
□ Iteration Planning
□ Task Planning
□ The Halfway Point
□ Iterating
25. Planning
□ Initial Exploration
□ At the start of the project, the developers and
customers try to identify all the really significant user
stories they can. However, they don’t try to identify all
user stories.
□ As the project proceeds, the customers will continue to
write new user stories.
□ The flow of user stories will not shut off until the project
is over.
□ The developers work together to estimate the stories.
The estimates are relative, not absolute.
26. Planning
□ Spiking, Splitting, and Velocity
□ Splitting
□ Forexample, “Users cansecurely transfer money into, out of,
and between their accounts.” - big story. Estimating will be
hard and probably inaccurate. Further Splitting above
story in
■ Users can log in.
■ Users can log out.
■ Users can deposit money into their account.
■ Users can withdraw money from their account.
■ Users can transfer money from their account to another
account.
splliting of big stories into small
spptling above storie
27. Planning
□ Velocity (speed)
□ If we have an accurate velocity, we can multiply the
estimate of any story by the velocity to get the actual time
□ For example, our velocity is “2 days per story point,” and
we have a story with a relative estimate of four points, then
the story should take eight days to implement.
□ As the project proceeds, the measure of velocity will become
ever more accurate
□ Spike
□ Often, it is sufficient to spend a few days prototyping a
story or to get an idea of the team’s velocity. Such a
prototype session is called a spike (sharpening).
in velocity its all about estimation, what size, when to split or merge story
28. Planning
□ Release Planning
□ The developers and customers agree on a date for
the first release of the project. This is all about 2–4
months in the future. The customers pick the
stories they want implemented within that release
and the rough order in which they want them
implemented.
□ The release plan can be adjusted as velocity
becomes more accurate.
29. Planning
□ IterationPlanning
□ it is about two weeks long
□ the customers choose the stories that they want
implemented in the first iteration.
□ The order of the stories within the iteration is a technical
decision that makes the most technical sense.
□ The customers cannot change the stories in the iteration
once the iteration has begun - Reordering is possible
□ The iteration ends on the specified date, even if all the
stories aren’t done.
30. Planning
□ TaskPlanning
□ The developers break the stories down into
development tasks. A task is something that one
developer is implemented in 4–16 hours. The stories are
analyzed, with the customers’ help, and the tasks are
enumerated as completed as soon as possible.
□ A list of the tasks is created on a flip chart, whiteboard,
or some other convenient medium. Then, one by one, the
developers sign up for the tasks ARE they want to
implementED.
31. Planning
□ Developers, DatabaseGuys, GUIguys (whole Project
team) may sign up for respective kind of task.
□ Task selection continues until either all tasks are
assigned
32. Planning
□ TheHalfway Point
□ IN iteration ON Halfway, the team holds a
meeting.
□ At this point, half of the stories scheduled for the
iteration should be complete. If aren’t complete, then
the team tries to reapportion (distribute again) tasks and
responsibilities to ensure that all the stories will be
complete by the end of the iteration
33. Planning
□ For Example,
■ Suppose the customers selected 8 Stories
42 Tasks
21 Tasks should be
■ 8 Stories Totally 24 story points
■ Halfway point 12 story points
completed
□ At the halfway point, we want to see completed
stories that represent half the story points for the
iteration
34. Planning
□ Iterating
□ Every two weeks, the current iteration ends and the next
begins.
□ At the end of each iteration, the running executable is
demonstrated to the customers.
□ The customers are asked to evaluate the look, feel, and
performance of the project.
□ The customers can measure velocity. AND predict how
fast the team is going, and they can schedule high-
priority stories early.
35. Testing
Extreme programMING HAS UNIT test rather than
TESTING at the end .
All codes have unit tests to eliminate bugs, and the
code passes all such unit tests before release.
Another key test is customer acceptance tests,
based on the customer specifications.
Acceptance test run at the completion of the
coding, and the developers provide the customer
with the results of the acceptance tests along with
demonstrations.
Unit tests should be implemented FOR ELEMINATIONG BUGS
Integration and validation testing can occur on a daily basis
Acceptance tests, also called customer tests, are specified by the customer
Acceptance tests are derived from user storiES
36. Test Driven Development
We can add functions to the program, or change the structure of
the program, without fear that we will break something
important in the process.
□ we are immediately concerned with the interface of the
program as well as its function. By writing the test first,
we design the software to be conveniently callable.
□ we are immediately concerned with the interface of the
program as well as its function. By writing the test first,
we design the software to be conveniently callable.
□ The act of writing tests first forces us to decouple the
software!
FROM PDF
37. Acceptance Test
□ Unit tests are necessary but NOT ENOUGH as
verification tools.
□ Unit tests verify that the small elements of the system
work as they are expected to, but they do not verify
whole system works properly OR NOT.
□ Unit tests are white-box tests that verify the individual
ELEMENTS of the system.
□ Acceptance tests are black-box tests that verify that
the customer requirements are being met.
FROM PDF
38. Acceptance Test
□ Acceptance tests are written by folks who do not
know the internal mechanisms of the system.
□ They may be written directly by the customer or by
some technical people attached to the customer,
possibly QA. Acceptance tests are programs and are
therefore executable.
□ Acceptance tests are the ultimate documentation of a
feature.
39. Refactoring – What is it?
Process of changing a computer program’s source code
without modifying its external functional behavior
OR
“By continuously improving the design of code, we make it
easier and easier to work with. This is in sharp contrast to what
typically happens: little refactoring and a great deal of
attention paid to expediently adding new feature If you get into
the hygienic habit of refactoring continuously,you’ll find that it
is easiertoextendand maintain code.”
— Joshua Kerievsky
40. Refactoring – When do I use?
□ Duplicatedcode shareonesame method
□ Long method
□ Large class
extract one or more smaller methods
divide in more cohesive classes
□ Longparameter list encapsulate them
41. Refactoring
Refactoring or Code Refactoring is defined as
systematic process of improving existing computer
code, without adding new functionality or changing
external behavior of the code.
It is intended to change the implementation,
definition, structure of code without changing
functionality of software.
It improves extensibility, maintainability, and
readability of software without changing what it
actually does.
42. Refactoring
The goal of refactoring is not to add new functionality or
remove an existing one.
The main goal of refactoring is to make code easier to maintain
in future.
We do refactor because we understand that getting design
right in first time is hard and also you get the following benefits
from refactoring:
Code size is often reduced
Confusing code is restructured into simpler code
Both of the above benefits greatly improve maintainability
which is required because requirements always keep
changing.
