Learn How to program.
Learn How to Program and Build Your Own Software Applications Quickly The world is moving…
Managing a software development project can be pretty challenging at times. Choosing a reasonable development methodology is important for ensuring the long-term success of the project. One area where developers and managers alike find it difficult to maneuver around is when the software requirements are not clearly defined and are very dynamic, i.e. changing rapidly. Extreme Programming could be the answer in such situations.
Extreme Programming is an agile development methodology that is designed to improve the quality of code in a dynamic environment and the quality of life for developers. The methodology was first devised and used by Ken Beck at Chrysler, and is explained in his 1999 publication titled Extreme Programming Explained.
Extreme Programming is a very popular methodology known for its ability to properly adopt to the changing needs of the client/customer. Like other agile methodologies, it also provides iterative releases that are small in size and frequent in number, thus allowing all stakeholders involved to examine the progress throughout the software development life cycle.
Like any other methodology, Extreme Programming (XP) can be broken down into a set of core values, rules and practices.
The core values of XP entail the following:
Simplicity: Keep costs and risks low by doing what’s necessary and nothing more.
Communication: Regular face to face communication for effective collaboration and management
Feedback: Listen to the feedback provided by clients and implement changes with each iteration
Courage: Have the courage to tell the truth about progress and estimates. Everyone should know about risk factors involved, rather than finding out the hard way
Respect: Respect everyone involved as a valued member of the team regardless of their level of contribution.
The use of XP ultimately boils down to a set of 12 basic development practices that are followed by an team using XP. Here are the 12 basic principles or activities for making XP successful.
Planning Game: Plan for the next iteration while also keeping the bigger picture in mind. Plan teams and resource allocation accordingly.
Pair Programming: Two programmers work on one piece of code. One writes the code while the other monitors it. This helps improve the quality of code and ensures that there are minimal mistakes.
Test-driven development: All code that is written is unit-tested thoroughly alongside development to make sure each small and individual piece of code works as expected.
Design improvement: Improve the code written by refactoring it, cleaning it and optimizing it according to industry standards.
Simplicity: New features are not implemented unless agreed upon in a user story. The team works on exactly what is expected, and nothing more.
System Metaphor: Files, classes, functions, variables and procedures within a system should be named in a standardized way such that anyone on the team can understand what their purpose is and how to implement changes.
Coding standards: Certain coding standards should be agreed upon and followed by the entire team
Continuous integration: Code written by the entire team is merged into a single repository and tested thoroughly regularly (often many times a day) to ensure that there are no errors when integrating different pieces of codes together.
Whole team: Involve all stakeholders, including clients/customers in the development process, ensuring the smooth flow of feedback and progress reports.
Small releases: Keep releases as small and as frequent as possible
Sustainable pace: Set a regular pace and stick to do. Do not force developers to work over time or clock extreme hours near the end of a release to get things ready on time.
Collective code ownership: Any developer across the team should be allowed to change any section of the code if necessary. This can be risky, but if done correctly can speed things up.
Extreme Programming is fairly focused towards speeding up the feedback loop and delivering projects in small iterations, which makes it easy to adapt to changes. This is especially useful for projects that are very dynamic in nature and do not have fixed requirements from the start. Such projects can fail very easily if the proper methodology is not implemented.