Requirements Challenges
Business requirements are more complex
Difficulty in expressing requirements
Difficulty in identifying all requirements
Shifting business priorities
Integration Challenges
Multiple Technologies
Integration Hell
Long rework cycles
Resource Challenges
Shift in resource costs from hardware to human resources.
Diverse technologies
Limited HR Pool
These are the major challenges before us before the implementation of this project. Then we started researching on what kind of Methodologies whether to go for heavyweight or light weight Methodologies Was put together as a response to the increasing difficulty of practicing heavyweight methodologies, especially in medium and small projects and finally decided for light weight because of these advantages.
Has very few rules and practices
* Planning
* Design
* Coding
* Testing
What is Extreme Programming (XP)?
In the early 1990s Kent Beck was thinking about better ways to develop software. He had spent some time working with Ward Cunningham. Ward and Kent together had experienced an approach to software development that made every thing seem simple and more efficient. Kent contemplated on what made software simple to create and what made it difficult. In March of 1996 Kent started a project at DaimlerChrysler using new concepts in software development. The result was the Extreme Programming (XP) methodology.
What Kent came to realise is that there are four dimensions along which one can improve any software project. You need to improve communication. You need to seek simplicity.
You need to get feedback on how well you are doing. And you need to always proceed with courage. Communication, Simplicity, Feedback, and Courage are the four values sought out by XP programmers.
This methodology also emphasises team work. Managers, customers, and developers are all part of a team dedicated to delivering quality software. XP implements a simple, yet effective way to enable groupware style development.
XP improves a software project in four essential ways; communication, simplicity, feedback, and courage. XP programmers communicate with their customers and fellow programmers. They keep their design simple and clean. They get feedback by testing their software starting on day one. They deliver the system to the customers as early as possible and implement changes as suggested. With this foundation XP programmers are able to courageously respond to changing requirements and technology.
XP is different. It is a lot like a jig saw puzzle. There are many small pieces. Individually the pieces make no sense, but when combined together a complete picture can be seen. This is a significant departure from traditional software development methods and ushers in a change in the way we program.
XP Focuses on People not on Process.
4 Variables to Control Software
The four variables control the development project like a steam .If you move any lever the others move. You can lock any lever you like, but if you lock three levers you cannot move the fourth.
XP deals with Scope in an iteration way Time, Cost, and Quality for each iteration is fixed. Scope has to be determined in every iteration
Make the Four Variables visible to the customer let the customer choose 3 of four variables and develop controls for the 4th variable.
XP Outline
* XP does not define a process with a set of products .The code is the only valid reference of documentation.
* XP uses lists of principles , rules and heuristics
* Testing Runs throughout process starting from day one. Goal is to have full test coverage during the whole life cycle.
* XP emphasizes teamwork. This teamwork is based on vales communication, simplicity, feedback and courage.
* System is delivered incrementally to customer very often .Evolve in the light of experience. Changes are implemented in a controlled fashion.
* XP is about constant planning instead of making constant plan.
Why XP has this Extreme Name?
*
o If code reviews are good, we'll review code all the time (pair programming).
o If testing is good, everybody will test all the time (unit testing), even the customers (functional testing).
o If design is good, we'll make it part of everybody's daily business (refactoring).
o If simplicity is good, we'll always leave the system with the simplest design that supports its current functionality (the simplest thing that could possibly work).
o If integration testing is important, we'll integrate and test several times a day (continuous integration) .
o If short iterations are good, we'll make iterations really, really short seconds and minutes and hours, not weeks and months and years (the "planning game").
XP is a System of Practices
XP is a system of practices that a community of software developers is evolving to address the problems of quickly delivering quality software, and then evolving it to meet changing business needs
Schedule of an XP Project
* Business cycle revolves around business activities (like press release, software release, manufacturing, and installation, training, billing). In XP called a release.
* Development cycle shorter than business cycle to be able to correct
* project in midcourse. In XP called iteration.
* You can’t complete the set-up of the whole infrastructure or build a framework in a few weeks. We need other measure of progress. We use what customer understands - the story.
* The result of every iteration must be a fully tested, production-ready system.
1 To 6 weeks
Outline of iteration
* XP addresses long projects by breaking them into a sequence of self- contained, one- to three-week mini-projects - called iterations.
During each iteration:
* Customers pick the features to be added based on
o their priorities
o the time estimation of the programmers
o the agreed upon time frame
* Programmers add the features so they are completely ready to be deployed.
* Programmers and customers write and maintain automated tests to demonstrate the presence of these features.
* Programmers evolve the design of the system to gracefully support the addition of new features to the system
Traditional Versus XP Way
Traditional Way XP Way
Limited Customer Contact Dedicated Customers on team
Central Up-front design Open evolving design
Build for the future Evolve to the future , just in time
Complex implementation Radical simplicity
Developers in Isolation Pair Programming
Tasks assigned Tasks self-chosen
Infrequent big-bang integration Continuous integration
Fear Aggressiveness
Ad-hoc workspace testing Unit /functional testing
Limited top-down communication Communicate, Communicate, Communicate
Consequences Of XP
If we don’t XP
* After burning all the project money find out that the system doesn’t work
* Miss Opportunity to deliver valuable systems on time at a high quality in an accelerating World.
* Let the industry bandwagon pass by.
If we do XP
o Change our mindset and “ the way things are done around here”.
o As a customer be part of the development team from day one.
o As a developer concentrate on business value first.
o Allow the team to find the most effective way to build the desired system.
o Be consequent .
Software Economics –Business Value for XP
XP avoids a long up-front investment phase by producing runnable artifacts very soon. The most
Important requirements are implemented first to create business revenue as fast as possible.
Short cycles enable the customer to define the next most important requirements based on the
Experiences with the already running system. The probability to meet the expectations is reset to
100 % every few weeks.
Maintain the ability to respond to understand events very quickly. Don’t try to predict the future.
Create revenue early Short cycles Constant reality check Flexible schedule No big design up-front respond to unexpected events quickly.
Conclusion and References
* Books: XP Series
* Kent Beck: Extreme Programming Explained; Embrace change
* Kent Beck & Martin Fowler: Planning Extreme Programming
* Ron Jeffries et.al: Extreme programming Installed
* Bill Wake: Extreme Programming explored
* James Newkirk, Robert C. Martin: Extreme Programming in Practice
* G. Succi & M. Marchesi: Extreme Programming Examined
References
* Martin Fowler: Refactoring
* Alistair Cockburn: Agile Software Development
|
