Extreme Programming Rules
Planning
1. User stories are written - User stories serve the same purpose as use cases but are not the same. They are used to create time estimates for the release planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customer’s terminology without techno-syntax. User stories also drive the creation of the acceptance tests. One or more automated acceptance tests must be created to verify the user story has been correctly implemented.
One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face. 2. Release planning creates the release schedule- A release planning meeting is used to create a release plan, which lays out the overall project. The release plan is then used to create iteration plans for each individual iteration.
It is important for technical people to make the technical decisions and business people to make the business decisions. Release planning has a set of rules that allows everyone involved with the project to make their own decisions. The rules define a method to negotiate a schedule everyone can commit to.
The essence of the release planning meeting is for the development team to estimate each user story in terms of ideal programming weeks. The release plan used to be called the commitment schedule. The name was changed to more accurately describe its purpose and be more consistent with iteration plan. 3. Make frequent small releases- e versions of the system to the customers often. Some teams deploy new software into production every day. At the very least you will want to get new software into production every week or two. At the end of every iteration you will have tested, working, production ready software to demonstrate to your customers. The decision to put it into production is theirs. 4. The project is divided into iterations- Iterative Development adds agility to the development process. Divide your development schedule into about a dozen iterations of 1 to 3 weeks in length. One week is the best choice even though it seems very short. Keep the iteration length constant throughout the project. This is the heart beat of your project. It is this constant that makes measuring progress and planning simple and reliable in XP.
Don't schedule your programming tasks in advance. Instead have an iteration planning meeting at the beginning of each iteration to plan out what will be done. Just-in-time planning is an easy way to stay on top of changing user requirements. 5. Iteration planning starts each iteration- An iteration planning meeting is called at the beginning of each iteration to produce that iteration's plan of programming tasks. Each iteration is 1 to 3 weeks long. User stories are chosen for this iteration by the customer from the release plan in order of the most valuable to the customer first. Failed acceptance tests to be fixed are also selected. The customer selects user stories with estimates that total up to the project velocity from the last iteration.
Managing
1. Give the team a dedicated open work space.
Communication is very important to an Extreme Programming (XP) team. You can add vital communication paths to your team by just taking down the barriers that divide people. Putting computers in a central area that no one owns makes pair programming easier and encourages people to work together with feelings of equal value and contributions. Putting a few desks around the perimeter gives people a place to work alone without becoming disconnected from the rest of the team. 2. Set a sustainable pace.
To set your pace you need to take your iteration ends seriously. You want the most completed, tested, integrated, production ready software you can get each iteration. Incomplete or buggy software represents an unknown amount of future effort, so you can't measure it. If it looks like you will not be able to get everything finished by iteration end have an iteration planning meeting and re-scope the iteration to maximize your project velocity. Even if there is only one day left in the iteration it is better to get the entire team re-focused on a single completed task than many incomplete ones. 3. A stand up meeting starts each day. 4. The Project Velocity is measured.
The project velocity (or just velocity) is a measure of how much work is getting done on your project. To measure the project velocity you simply add up the estimates of the user stories that were finished during the iteration. It's just that simple. You also total up the estimates for the tasks finished during the iteration. Both of these measurements are used for iteration planning. 5. Move people around.
Move people around to avoid serious knowledge loss and coding bottle necks. If only one person on your team can work in a given area and that person leaves or just has too much to do you will find your project's progress reduced to a crawl.
Cross training is often an important consideration in companies trying to avoid islands of knowledge, which are so susceptible to loss. Moving people around the code base in combination with pair programming does your cross training for you. Instead of one person who knows everything about a given section of code, everyone on the team knows much of the code in each section. 6. Fix XP when it breaks.
Follow the XP Rules to start with, but do not hesitate to change what doesn't work. This doesn't mean the team can do whatever they want. The rules must be followed until the team has changed them. All of your developers must know exactly what to expect from each other, having a set of rules is the only way to set these expectations.
Have retrospective meetings to talk about what is working and what is not and devise ways to improve XP. Make improving your process a normal part of your development.
Designing
Simplicity-A simple design always takes less time to finish than a complex one. So always do the simplest thing that could possibly work next. If you find something that is complex replace it with something simple. It's always faster and cheaper to replace complex code now, before you waste a lot more time on it.
Many people try to measure simplicity. Simple defies measurement because it is a very subjective quality. One person's simple is another person's complex. Adding an advanced technology can simplify one application and make a complete mess of another.

Choose a system metaphor.
Now System Metaphor is itself a metaphor for a simple design with certain qualities. The most important quality is being able to explain the system design to new people without resorting to dumping huge documents on them. A design should have a structure that helps new people begin contributing quickly. The second quality is a design that makes naming classes and methods consistent.
What you name your objects is very important for understanding the overall design of the system and code reuse as well. Being able to guess at what something might be named if it already existed and being right much of the time is a real time saver. Choose a system of names for your objects that everyone can relate to without specific, hard to earn knowledge about the system.
Use CRC cards for design sessions.
Use Class, Responsibilities, and Collaboration (CRC) Cards to design the system as a team. The biggest value of CRC cards is to allow people to break away from the procedural mode of thought and more fully appreciate object technology. CRC Cards allow entire project teams to contribute to the design. The more people who can help design the system the greater the number of good ideas incorporated.
Individual CRC Cards are used to represent objects. The class of the object can be written at the top of the card, responsibilities listed down the left side, collaborating classes are listed to the right of each responsibility. We say "can be written" because once a CRC session is in full swing participants usually only need a few cards with the class name and virtually no cards written out in full. A short example is shown as part of the coffee maker problem.
Create spike solutions to reduce risk.
Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increases the reliability of a user story's estimate.
When a technical difficulty threatens to hold up the system's development put a pair of developers on the problem for a week or two and reduce the potential risk.
Refactor whenever and wherever possible.
We computer programmers hold onto our software designs long after they have become unwieldy. We continue to use and reuse code that is no longer maintainable because it still works in some way and we are afraid to modify it. But is it really cost effective to do so? Extreme Programming (XP) takes the stance that it is not. When we remove redundancy, eliminate unused functionality, and rejuvenate obsolete designs we are refactoring. Refactoring throughout the entire project life cycle saves time and increases quality.
Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity. Keep your code clean and concise so it is easier to understand, modify, and extend. Make sure everything is expressed once and only once. In the end it takes less time to produce a system that is well groomed.
Coding
* The customer is always available. * Code must be written to agreed standards. * Code must be formatted to agreed coding standards. Coding standards keep the code consistent and easy for the entire team to read and refactor. Code that looks the same encourages collective ownership
Code the unit test first.
When you create your tests first, before the code, you will find it much easier and faster to create your code. The combined time it takes to create a unit test and create some code to make it pass is about the same as just coding it up straight away. But, if you already have the unit tests you don't need to create them after the code saving you some time now and lots later.
Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.
You also have immediate feedback while you work. It is often not clear when a developer has finished all the necessary functionality. Scope creep can occur as extensions and error conditions are considered. If we create our unit tests first then we know when we are done; the unit tests all run.
All production code is pair programmed.
All code to be sent into production is created by two people working together at a single computer. Pair programming increases software quality without impacting time to deliver. It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project.
The best way to pair program is to just sit side by side in front of the monitor. Slide the key board and mouse back and forth. Both programmers concentrate on the code being written.
Pair programming is a social skill that takes time to learn. You are striving for a cooperative way to work that includes give and take from both partners regardless of corporate status. The best pair programmers know when to say "let's try your idea first." Don't expect people to be good at it from the start. It helps if you have someone on your team with experience to show everyone what it should feel like.

Only one pair integrates code at a time.
Without controlling integration developers test their code and integrate believing all is well. But because of parallel integration there is a combination of source code which has not been tested together before. Integration problems happen without detection.
Further problems happen when there is no clear cut latest version. This applies not only to the source code but the unit test suite which must verify the source code correctness. If you cannot lay your hands on a complete, correct, and consistent test suite you will be chasing bugs that do not exist and passing up bugs that do.
You can have developers own specific classes. Class owners integrate and commit to the repository properly. Interclass dependencies can still be wrong. Class owners can become bottle necks if one class requires many changes and it doesn't solve the whole problem.

Integrate often.
Developers should be integrating and commiting code into the code repository every few hours, whenever possible. In any case never hold onto changes for more than a day. Continuous integration often avoids diverging or fragmented development efforts, where developers are not communicating with each other about what can be re-used, or what could be shared. Everyone needs to work with the latest version. Changes should not be made to obsolete code causing integration headaches.
Each development pair is responsible for integrating their own code whenever a reasonable break presents itself. This may be when the unit tests all run at 100% or some smaller portion of the planned functionality is finished.

Set up a dedicated integration computer.
A single computer dedicated to sequential releases works really well when the development team is co-located. This computer acts as a physical token to control releasing. There is also an objective last word on what the current build contains. Developers have a source for final arbitration on integration problems. The computer allows developers to see who is releasing and when. When the release computer is occupied no other changes can be released, stability is ensured.
Use collective ownership.
Collective Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or refactor. No one person becomes a bottle neck for changes.
Testing
All code must have unit tests.
Unit tests are one of the corner stones of Extreme Programming (XP). But unit tests XP style is a little different. First you should create or download a unit test framework to be able to create automated unit tests suites. Second you should test all classes in the system. Trivial getter and setter methods are usually omitted. You will also create your tests first, before the code.
Unit tests are released into the code repository along with the code they test. Code without tests may not be released. If a unit test is discovered to be missing it must be created at that time.
The biggest resistance to dedicating this amount of time to unit tests is a fast approaching deadline. But during the life of a project an automated test can save you a hundred times the cost to create it by finding and guarding against bugs. The harder the test is to write the more you need it because the greater your savings will be. Automated unit tests offer a payback far greater than the cost of creation.
Another common misconception is that unit tests can be written in the last three months of the project. Unfortunately, without the unit tests development drags on and eats up those last three months and then some. All code must pass all unit tests before it can be released. When a bug is found tests are created.
When a bug is found tests are created to guard against it coming back. A bug in production requires an acceptance test be written to guard against it. Creating an acceptance test first before debugging helps customers concisely define the problem and communicate that problem to the programmers. Programmers have a failed test to focus their efforts and know when the problem is fixed.
Acceptance tests are run often and the score is published.
Acceptance tests are created from user stories. During iteration the user stories selected during the iteration planning meeting will be translated into acceptance tests. The customers pecifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, whatever it takes to ensure the functionality works.
Acceptance tests are black box system tests. Each acceptance test represents some expected result from the system. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority. Acceptance tests are also used as regression tests prior to a production release.
A user story is not considered complete until it has passed its acceptance tests. This means that new acceptance tests must be created each iteration or the development team will report zero progress.
Quality assurance (QA) is an essential part of the XP process. On some projects QA is done by a separate group, while on others QA will be an integrated into the development team itself.

Agile software development
The most important thing to know about Agile methods or processes is that there is no such thing. There are only Agile teams. The processes we describe as Agile are environments for a team to learn how to be Agile.
We realize the way a team works together is far more important than any process. While a new process can easily improve team productivity by a fraction, enabling your team to work effectively as a cohesive unit can improve productivity by several times. Of course to be eligible for such a big improvement you must be working at a fraction of your potential now. Unfortunately, it isn't that uncommon.
The second change is making the customer, the one who funds the software development, a valuable and essential team member. When the dead line gets close a traditional approach to reducing scope is to let the developers decide what will work properly and what won't. Instead let the customer make scope decisions a little at a time throughout the project.
When your customer, or domain expert works directly with the development team everyone learns something new about the problem. True domain expertise and experience is essential to finding a simple, elegant, correct solution. A document can have plenty of information, but real knowledge is hard to put on paper. Left alone programmers must assume they know everything they need. When asking questions is difficult or slow the knowledge gap grows. The system will get built, but it won't solve the problem like one guided by an expert on a daily basis.
Perhaps the biggest problem with software development is changing requirements. Agile processes accept the reality of change versus the hunt for complete, rigid specifications. There are domains where requirements can't change, but most projects have changing requirements. For most projects readily accepting changes can actually cost less than ensuring requirements will never change.
Agile also means a fundamental change in how we manage our projects. If working software is what you will deliver then measure your progress by how much you have right now. We will change our management style to be based on getting working software done a little at a time. The documents we used to create as project milestones may still be useful, just not as a measure of progress. 1. Managing your goals instead of activities 2. Software Rots.
Is software designed to be simple and elegant more valuable than software that is complex and hard to maintain? An Agile process accepts this as an important fact.
It may surprise you to learn software rots. Intellectually we know it really doesn't, but it might as well. Software rot is caused by improper design and limited project resources. Complexity creeps in as easy code changes are made instead of difficult design changes. Code duplication accumulates rapidly during maintenance tasks.
After a while we notice that fixing one bug causes several even more subtle (and expensive) bugs to occur and the cost of maintenance goes up significantly. Eventually the cost of maintenance exceeds resources. It seems as if our code has decayed on its own in spite of our best efforts.
Agile processes are a re-evaluation of the way software is created. The quality of the source code is much more important than you may think. Just because customers don't see code doesn't mean we are excused from the effort needed to be ready for changes by keeping quality up, complexity down, and full test coverage. 3. Most important features first
The first symptom of a damaged customer relationship is when your customer considers it a waste of time to participate in the project. You may have delivered software that just doesn't meet return on investment (ROI). You may have delivered software that is frustrating to use. You may even have treated the customer with disdain. In any case your customer is important and you need to repair your relationship first.
One way to start a partnership with your customers is to listen to their needs and respond immediately. The best way to guarantee your customer's time (and thus money) isn't wasted is to involve them enough to guarantee success. Customers who don't want to be involved in their own software project believe the software will be built the same even if they don't participate. This belief needs to be dispelled.
Agile projects keep a set of unfinished features as stories in a simple spreadsheet, list, or stack of cards that form the backlog of product features. You want to prune or groom this list on a regular basis by removing and destroying things your customer or product owner doesn't need anymore. Only keep features you would consider paying good money for, the rest go into the trash can or shredder.
From the list of unfinished features you will choose the most important. Important means different things to different teams. Once we know what we want to build next we will use iterative planning to stay on track. 4. Iterative Planning
There are three Agile levels of planning.Release planning is a group of stories selected because they represent a usable set of features that can be released together. These types of plans are made by selecting the stories and deciding how many iterations are needed or by selecting a release date and seeing how much can be done by then. Release plans have no details other than a list of stories to be done by a date.
The second level of planning is theiteration or sprint plan. This plan is a subset of the release plan stories that will be done in the very next iteration or sprint. Only one iteration plan exists at a time.
The iteration plan will often be verified by breaking the stories into development tasks and estimating them with finer grain units. At this level use cases could also be created. This greater level of detail is permissible because iterations or sprints are kept very short.
The third level is the daily plan. A daily plan isn't usually represented by any artifacts. At the daily scrum or stand up meeting everyone will announce their plan for the day and then act on it. Even greater detail is allowed because the plan's duration is one day and no more. How do we know how much we can get done in an iteration or sprint? We need to talk about creating honest plans. 5. Honest plans
An agile process makes honest plans based on feedback. If a mistake is made a new plan is created by accepting how far we have come and revising our plans based on the new information. There is no blame, there is no sense of failure, we have learned something we didn't know before. 6. A project heartbeat
If your Agile project doesn't have a heartbeat declare it dead. A steady heartbeat has a fixed length iteration as short as you can make it. A strong heartbeat produces working software ready for deployment to production with completely finished iteration/sprint commitments. A responsive heartbeat creates a new plan each iteration based on feedback from the previous iteration and changing customer needs, not what was left unfinished.
Steady your heartbeat by making your iteration length a constant then shorten the length to less than you think is possible. Push against resistance to short iterations forcing your team to learn and adapt to Agile processes. Don't just accept that a one week iteration seems impossible. Trust your people to figure it out and fix existing broken procedures. Shorter iterations actually increase the chances of being done on time not reduce it.
Within an iteration make each day a heartbeat all its own. Start each day with a stand up/scrum meeting. Integrate code at least once a day if not every couple hours. With everyone integrating often you can frequently pull the latest code from your repository so that you always work in the context of the latest versions of everything. Work as if every day has a deadline too. 7. Team empowerment
Who is responsible, who has authority? Everyone. The most important thing on a project is good leadership; the least important thing is who leads. Leadership and management are two very different things. Leadership is about seeing a problem then getting people together to solve it. Any team member who knows enough to foresee a problem also knows enough to lead the solution. It is your responsibility to do so.
One thing that can expedite team empowerment is to remove blame. Some of your team will hesitate to make important decisions if they feel someone else will bully them over it later. In some companies being late with someone else to blame is just as good as being on time. Eliminate blame as acceptable by making it clear no one wants to hear it.
One of the biggest misunderstandings of team empowerment is that teams just become empowered when you announce Agility has arrived. The team starts out following a set of rules designed to set expectations between team members. Most people don't like rules because rules usually constrain. An Agile team sets rules to become free. Create simple rules focused on defining the interfaces between team members. A good example is the daily stand up/scrum meeting. A rule to have it in the same place at the same time for no more than 15 minutes actually frees up time for other things. 8. Daily communication
Many Agile processes have a stand up/scrum meeting everyday. One meeting with the entire team can eliminate much miscommunication later. Setting a consistent time and place helps make the meeting happens and adds to the feeling of a project heartbeat. During the daily meeting everyone answers at least three questions; what did you do yesterday, what will you do today, and what blocks your progress. Let this be an honest plan for what you will do today.