Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
9Activity
0 of .
Results for:
No results containing your search query
P. 1
Extreme Programming

Extreme Programming

Ratings: (0)|Views: 309 |Likes:
Published by Marvin Njenga
For your programming
For your programming

More info:

Published by: Marvin Njenga on Apr 22, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/30/2014

pdf

text

original

 
 Overview on Extreme Programming
Jeremy ChoiNestea@cs.ust.hk  March 20
th
, 2002
Introduction
The focus of Software Engineering is mostly on resolving technical issues on softwaredesigns. With tools such as UML developers can produce detail descriptions on all partsof the end production in a technical point of view. However, little attention has beenpaid on formalizing the interaction between developers and end users and on assuringthat design produced by developers are full understood by customers and satisfactory tothe customers. Most importantly, UML is not dynamic. A change in the requirement of end-users usually results in huge effort in redesigning the structure of the end product.Along came Extreme programming (XP), a lightweight development process createdby Kent Back. Unlike UML, which is used to pinpoint the details of implementation,Extreme programming is a methodology that copes with the ever-changing demands of end-users.Extreme Programming is a discipline of software development based on 4 principlevalues: simplicity, communication, feedback, and courage. It works by bringing thewhole team together in the presence of simple practices, with enough feedback toenable the team to see where they are and to tune the practices to their unique situation.Based on these 4 principles, 12 practices are implemented:
l
Planning Game
l
Testing
l
Refactoring
l
Simple Design
l
Collective Ownership
l
Metaphor
l
Continuous Integration
l
On-Site Customer
l
Pair Programming
l
Small Releases
 
l
Coding Standards
l
40-hour work week This paper attempts to first give an overview of the 4 principles and then explain thereasons behind the 12 practices
1. The 4 principles
1.1 CommunicationXP encourages extreme communication. If the customer needs to see the programin action to fully formulate requirements, put the customer on the developmentteam and release working versions every 2 to 4 weeks, developing requirementsalong the way. If the programmers need clarification on requirements, thecustomer is a member of the team -- lean back in your chair and ask the customer.Programmers work in pairs: two people to every one machine. Pair membersrotate regularly. All code is owned by the team, not by individuals. This promotescommunication of technical knowledge throughout the team. When technicalchallenges arise, the team is more able to address the problem.Pair programming also is excellent in matching up programmers of differingabilities. Less experienced members are constantly mentored, and the risk of lessexperienced code being added to the application is minimized.1.2 Feedback The faster change is identified, the faster it can be dealt with. XP strives for thefastest feedback possible in every aspect of the project.Unit Tests are written for most every piece of production code. Unit tests must runat 100% before any code is checked in. When production code needs to be changed,side-effect problems are identified. After new code is checked in, it's immediatelyintegrated with the latest changes from the rest of the team and again, all unit tests
 
must be made to run at 100%.Acceptance Tests are written with the customer to verify the application is doingwhat the customer needs it to do.Pair Programming provides constant code reviews. No more dreary code reviewmeetings -- put two sets of eyes on the code as it's written. Collective Ownership of the code by all members of the team helps ensure even more eyes will see the code,increasing the amount of code review performed.1.3 SimplicityThe customer is the ultimate driving force in XP. Do what the customer needs, assimply as possible, and nothing else. Take on a mindset to reduce complexity fromthe beginning.All code should be refactored as often as possible. Refactoring is a process of improving a code's structure without changing its functionality. Refactoringproduces highly decoupled objects which makes them easy to test, easy to use,more flexible, and therefore, more changeable.1.4 CourageNo more fragile code. With smooth communication, quick feedback and simplecode, programmers have the support they need to dive into changes when theycome ... and they will come.
2. The 12 practices
2.1. Planning Game
Each iteration begins with the Planning Game, an informal process that sets theagenda for the iteration. The game starts with the customer defining requirements,or 'user stories'. Technical members work with the customer to normalize thesestories into manageable chunks and break them down into specific tasks, as wellas introducing technical tasks needed to support the customer's requests (e.g.upgrading development software, automating builds, etc). Then the developersplace ideal time estimates on the stories/tasks. Based on the time estimates given

Activity (9)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
holapicu liked this
holapicu liked this
jayanta_1989 liked this
malisha89 liked this
rahulvgopinath liked this
arteepu37022 liked this
dinuflo liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->