0% found this document useful (0 votes)
42 views

Unit-2 Agile Development Part2

This document discusses the Extreme Programming (XP) agile methodology. XP focuses more on the software engineering process and addresses analysis, development, and testing phases with novel approaches to improve product quality. The core requirements of XP are to improve communication, seek simplicity, get feedback, and always proceed with courage. These are implemented through 12 rules, including user stories, small releases, collective ownership, pair programming, and on-site customers.

Uploaded by

Vatsal Ghoghari
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
42 views

Unit-2 Agile Development Part2

This document discusses the Extreme Programming (XP) agile methodology. XP focuses more on the software engineering process and addresses analysis, development, and testing phases with novel approaches to improve product quality. The core requirements of XP are to improve communication, seek simplicity, get feedback, and always proceed with courage. These are implemented through 12 rules, including user stories, small releases, collective ownership, pair programming, and on-site customers.

Uploaded by

Vatsal Ghoghari
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 8

UNIT-2 AGILE

DEVELOPMENT
XP(EXTREME PROGRAMMING)

 XP ( E x t r e m e Programming) is a more radical agile methodology,


 Focusing more on t h e software engineering process
 Addressing t h e analysis, development a n d t e s t p h a s e s with
novel app r oac hes t h a t m a k e a s u b s t a n t i a l difference to t h e
quality of t h e e n d product.
REQUIREMENTS

 1. You need to improve communication.


 2. You need to seek simplicity.
 3. You need to get feedback on how well you are
doing.
 4. You need to always proceed with courage.
RULES

 I n XP t h e s e four basic activities a r e i m p l e m e n t e d by u s in g practices


which a r e t r a d iti on a l software engineering practices b u t elevated to
embody a n d encourage XP values.

 Although practices of E x t r e m e P r o g r a m i n g t h e y c a n be compacted


into twelve simple r u l e s
XP(RULES):

1. User stories (planning): U s er stories can be viewed a s a smaller version of use case. I n this way, t h e customer
define a s briefly a s possible t h e specification of t h e new application (features, value, priority). These stories will
be t h e base for t h e project t e a m to do cost estimation a n d m a n a g e m e n t of t h e project.

2. Small releases (building blocks): XP emphasizes on small, simple b u t frequent versions u p d a t e s of t h e


application. Each newly added r e q u ir em en t will ins tantly incorporated a n d t h e system is re-released.
3. Metaphor (standardized naming schemes): Developers a n d programmers m u s t ad h e r e to s t a n d a r d s on
n ames , class n a m e s a n d methods.
4.Collective ownership: I n XP methodology, all code is considered to be owned by t h e whole t e a m a n d not a n
individual property. Hence, all code is reviewed a n d u p d a t e d by everyone.

5.Coding standard: Styles a n d formats of coding m u s t be t h e s ame in order to enable compatibility between t e a m
members. This approach r es ults in more r apid collaboration.
6.Simple design: Always look for system implementation t h a t is a s easy a s possible implementation of t h e
system yet meets all required functionality.
XP(RULES):

7.Refactoring:: T h e application s hould be continually a d j u s t e d a n d improved by all t e a m m emb er s .


Th is r e q u i r e s ex tremely good communication b et w e e n m e m b e r s to avoid work duplication.
8.Testing: Ev e ry s ma l l r e l ea s e (called building block) m u s t p a s s t e s t s before being releas ed. XP’s
u n i q u e n e s s i n t h i s as pe ct is t h a t t e s t s a r e c r e a t e d f irs t a n d t h e n application code is developed to
m e e t a n d p a s s t h e challenges of tho se p r e- w ri tt e n te s ts .
9.Pair programming: XP progr a m m er s wor k in p a ir s . All code is d eveloped by two prog r a m m er s who work
to g et h e r a t a single machine. T h e expectation is t h a t p a i r p r o g r a m m i n g produces h i g h e r qu alit y code a t t h e
s a m e or less cost.
10. Continuous integration: Software builds a r e completed s ev er al t i m e s a day. I n t h i s w ay all developers c a n
avoid wo rk f r a g m e n t a t i o n s b ecaus e t h e y continuously rele as in g a n d i n t e g r a t i n g code together.
11.40-hour workweek: Keep m e n t a l a n d physical conditions to be u p a n d r u n n i n g by n o t working more t h a n
w h a t t h e bodies c a n h a n d l e .
12.On-site customer: T h e cu s t o me r m u s t be viewed a s a n i n t e g r a l p a r t of t h e project. T h e cus t omer m u s t be
a r r a n g e d to be available a t all t i m e s i n o rde r to e n s u r e t h a t t h e project is in t h e r i g h t t r a ck .
XP

You might also like