2. OUTLINE
Introduction
Agile Manifesto
Agile Development Vs Waterfall Model
Agile Software Development Methodologies
Case Study
Performance Evaluation
Conclusion
April 17,2012 2
3. INTRODUCTION
Agile software development is collection of software development
methodologies.
It is based on iterative and incremental software development methods.
Main Initiative
team can be more efficient in responding to change
if it can reduce the cost of moving information between people and
decrease the time elapsed between making a decision to seeing the
consequences of that decision.
April 17,2012 3
4. AGILITY
Goldman in 1995 said:
“Agility is dynamic, context-specific, aggressively change-embracing, and
growth-oriented.
It is not about improving efficiency, cutting costs, or battening down the
business hatches to ride out fearsome competitive storms.
It is about succeeding and about winning: about succeeding in emerging
competitive arenas, and about winning profits, market share, and customers in
the very center of the competitive storms many companies now fear.”
April 17,2012 4
5. AGILE MANIFESTO
In February 2001, a group of 17 software expert comprised
Creator of XP(Extreme Programming), Scrum, DSDM(Dynamic
System Development Method),and others,
got together to talk about lightweight methods.
They come to a decision to use the term agile to explain new class of agile
methods.
April 17,2012 5
6. AGILE VALUES
Individual and their interactions over processes and tools
Delivering working software over comprehensive documentations
Customer Collaboration over contract negotiations
Responding to change over a following plan.
April 17,2012 6
7. AGILE PRINCIPLES
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. Agile
processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
April 17,2012 7
8. AGILE PRINCIPLES
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.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely
April 17,2012 8
9. AGILE PRINCIPLES
9. Continuous attention to technical excellence and good design enhances
agility.
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 intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.
April 17,2012 9
10. AGILE DEVELOPMENT VS
WATERFALL MODEL
70 percent of software projects using this methodology fail to meet their
objectives.
Water fall model features
distinct phases with checkpoints and at each phase are deliverable
Agile Methods
have iterations rather than phases.
Each iteration output is running code that can be used to estimate and
answer to changing and evolving user requirements.
April 17,2012 10
In waterfall model, one phase makes difficult to create last minute changes in
requirements or design,
13. EXTREME PROGRAMMING(XP)
developed by Programmer Kent Beck
For programmer
XP guarantee that—to work on the things that actually matter every day.
alone wont face scary situations.
Everything will be in their power to make system successful, and make decision
that can make best.
For customer and managers
XP guarantees—to get the most possible value out of every programming week.
In few weeks –able to see concrete progress on their require set of objectives.
able to alter the track of the project in the middle of development without incurring
overpriced costs.
April 17,2012 13
14. XP FUNDAMENTAL PRINCIPLES
1. Rapid Feedback
to obtain feedback, understand it, and place as soon as possible what is learned back
into the system
2. Assume Simplicity
Treat every problem with ridiculous simplicity—saves time on the 98 percent of
problems for which it is true
3. Incremental Change
problem can be solved in series of smallest changes that actually make difference.
4. Embracing Change
preserves the most choices while in reality solving most fundamental problem.
5. Quality Work
four project development variables scope, cost, time and quality
possible values to perform good job are “excellent” and “insanely excellent
April 17,2012 14
15. EXTREME PROGRAMMING
PRACTICES
1. Planning Game
Quickly determine the scope of the next release by combining business priorities
and technical estimates.
2. Small Release
Each release should be as small as possible, and include the most valuable business
requirements
3. Metaphor
Guide all development with a simple shared story of how the whole system works.
4. Simple Design
The correct design for the software at any specified time is one that runs:
Run all test, no duplicate logic, has fewest possible classes and methods
April 17,2012 15
16. EXTREME PROGRAMMING
PRACTICES
5. Testing
Programmers write unit tests and customer writes functional test
6. Refactoring
improvement in communication, simplify or add flexibility by reforming
the system without altering its performance to eliminate duplication
7. Pair Programming
all production code is written with two programmers at one machine
8. Collective Ownership
anyone can change any code anywhere in the system at any time
April 17,2012 16
17. EXTREME PROGRAMMING
PRACTICES
9. Continuous Integration
Integrate and build the system after a completion of every task.
10. 40 Hours Week
Never work overtime a second week in a row.
11. On-site Customer
Include a real, live user on the team, available full-time to answer questions
12. Coding Standards
Programmers write all code in accordance with rules emphasizing
communication through the code.
April 17,2012 17
18. SCRUM
April 17,2012 18
The term Scrum was coined by Takeuchi, DeGrace, Schwaber, in the late
1990s.
Concept
drastic simplification of project management
based on iterative development
comprises of three roles, three documents, and three meetings
19. ROLES OF SCRUM
1. Product Owner
make sure that he/she is representing the interest of all stakeholders
providing the requirements funds the project as well as signs off on any
deliverable
writes customer-centric items (typically user stories),
prioritizes them, and appends them to the product backlog
role cannot be combined with that of Scrum Master.
April 17,2012 19
20. ROLES OF SCRUM
2. Scrum Master
Represents management to the project
make sure that the team is delivering high quality and is not cutting quality
to get the job done
check the team, verify that the test cases and code reviews are done,
Ensure that the team is fully functional and productive
Enable close cooperation across all roles and functions
Shield the team from external interferences
April 17,2012 20
21. ROLES OF SCRUM
3. Team
Typically 3-9 people
Cross-functional:
Analyzers, programmers, testers, user experience designers, etc.
Members should be full-time
May be exceptions (e.g., database administrator)
Teams are self-organizing
Ideally, no titles but rarely a possibility
Membership should change only between sprints
April 17,2012 21
22. DOCUMENTS OF SCRUM
1. Product Backlog
All requirements are collected and prioritized in single list
It is the master list of all functionality desired in the product
each item in the product backlog has a description, a priority and an
estimate of the effort needed to complete it.
April 17,2012 22
23. DOCUMENTS OF SCRUM
2. Sprint Backlog
In Scrum project development is done in small iterations, and termed as
“Sprint”.
Each sprint is small and manageable iteration.
It comprised design, development, testing and documentation.
duration of sprint is usually about 2-4 weeks.
At the start of a sprint, the team picks most important use cases that can
be delivered in that current iteration.
The list of those use case is called “Sprint Backlog ”.
Sprint backlog is the subset of product backlog.
April 17,2012 23
24. DOCUMENTS OF SCRUM
3. Sprint Result
The use cases that are completed during that sprint are documented as
sprint results.
April 17,2012 24
25. MEETINGS OF SCRUM
1. Sprint Planning Meeting
Held in the beginning of every new sprint planning
In this meeting, the product owner and the scrum master
decide on the sprint backlog, on the basis of requirements which are
prioritized by the product owner,
therefore on what the team can commit to deliver in one sprint.
April 17,2012 25
26. MEETINGS OF SCRUM
2. Scrum Meeting/ Daily Scrum Meetings
Held every day
moderates by scrum master
short 15 minutes project meeting throughout the project
Exchange information what was achieved in the last 24 hrs, and
what was the problems faced that need to be discussed.
April 17,2012 26
27. MEETINGS OF SCRUM
3. Sprint Review
In the end of each daily sprint meeting
scrum master, team and product owner along with the stakeholders meet
again to review the result achieved during the iteration.
April 17,2012 27
29. SCRUM BURN CHART
April 17,2012 29
For tracking the progress of the development activities
to measure the progress towards achieving the given goals
36. CONCLUSION
Objective
to explore the Agile Software Development methodologies
(such as Extreme Programming, SCRUM).
Observation
observed that agile software methodology is growing
software development methodology.
Most companies and most people are adopting agile
software development methodologies
April 17,2012 36
37. REFERENCES
[1] A. Cockburn and J. Highsmith, “Agile software development: The people
factor,” Computer, vol. 34, no. 11, pp. 131–133, Nov. 2001.[Online]. Available:
http://dx.doi.org/10.1109/2.963450
[2] A. Cockburn, Agile software development, ser. Agile software development
series. Addison-Wesley, 2002. [Online]. Available:
http://books.google.co.in/books?id=JxYQ1Zb61zkC
[3] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M.
Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R.
C. Martin, S. Mellor, K. Schwaber, J. Sutherland, and D. Thomas, “Manifesto
for agile software development,” 2001.[Online]. Available:
http://www.agilemanifesto.org/
April 17,2012 37
38. REFERENCES
[4] W. W. Royce, “Managing the development of large software systems:
concepts and techniques,” Proc. IEEE WESTCON, Los Angeles, pp. 1–9,
August 1970, reprinted in Proceedings of the Ninth International Conference on
Software Engineering, March 1987, pp. 328–338. [Online]. Available:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
[5] K. Beck, Extreme programming explained: embrace change. Boston, MA,
USA: Addison-Wesley Longman Publishing Co., Inc., 2000.
[6] T. Stober and U. Hansmann, Agile Software Development: Best Practices
for Large Software Development Projects. Springer, 2010. [Online]. Available:
http://books.google.co.in/books?id=DX9v4pqTDwkC
April 17,2012 38