DevEX - reference for building teams, processes, and platforms
extreme programming
1. Submitted in fulfilment of the
requirements for the award of the degree
of
Bachelor of Technology
in
COMPUTER ENGINEERING
Submitted To: Submitted by:
MS. Poonam Gera HIMANSHU MUNJAL
HOD , C.S. VIII SEM , C.S.
2. INTRODUCTION
AGILE METHODOLOGIES
EXTREME PROGRAMMING(XP)
XP WORKFLOW
XP VALUES
XP PRACTICES
ADVANTAGE & DISADVANTAGE
XP PROGRAMMING EXAMPLE
3. An agile development methodology
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
4. A methodology is a formalized process or set of practices for
creating software.
An early methodology was the waterfall model.
PROBLEMS:
◦ It assumes that there will be no unforeseen difficulties in the
software development.
◦ It assumes that the customers know (and can specify) what they
want, in extreme detail.
5. Agile programming methodologies assume:
◦ Customers can best discover what software meets their needs
via frequent iterations
◦ Requirements will need to be revised, probably multiple times,
during software development.
6. XP has nothing new, yet it has something new
XP is a specific instantiation of an agile process
XP combines best practices in a different way
XP is a different approach to development which
provides-
Incremental planning
Flexible implementation
Automatic tests
7.
8. Short description of what customer wants the software
to do.
Written by the customer in the customer terminology
without techno-syntax.
Used to create time estimates for the release planning
meeting.
Used instead of a large requirements document.
9.
10. ◦ Pair Programming
Teams of two people
◦ Test Driven Development
Writing lots of tests, and writing them early
◦ Continuous Integration
Putting code together as you write it, not at the last minute
◦ Coding Standards
Learn and follow well-established conventions
◦ Collective Code Ownership
You are responsible for your partner’s code
◦ Simple Design
12. User R
P1, P2, P3 Program
R and Data manager
P2
Senior Pro.
Pro 2
Prog1
P3
P1
DBA
CONVENTIONAL APPROACH
Data
13. P1, P2, P3
R and Data
User
Pro 2
PROGRAMMING WITH
XP
Prog1
Pro
Lead
14. Built-In Quality
Overall Simplicity
Programmer Power
Customer Power
15. Hard to do
constant involvement of the customer
Informal, little, or no documentation
Misconception on the cost of change
16. Light-weight: discipline without bureaucracy
Under stress, people do what is easiest
◦ All XP practices have short-term benefits as well as long-term
benefits
Development as a Conversation
The code is the documentation
17. Not on very large projects
Not for embedded software if the hardware is frozen
Not with data-driven apps – RAD for these
Not with ―Old Economy‖ management
18. Work as closely as you can with your partner
Don’t just ―contribute‖ your share of the code—also review your partner’s
code, checking for problems.
You can use all the Java you know, if your partner also understands it
Don’t:
◦ Depend on your partner to do it all
◦ Take off and do it all yourself
