Extreme Programming (Xp) Overview - Day 1

• Posted by justin on September 1, 2004
• 0 comments

Sorry for the long post but there was lots of good information in the class today.

Extreme Programming (Xp) Overview

Day 1:

• Typical development goes database, middle tier, and then GUI.  Recommend GUI, Database, Middle Tier.  This give the customer the ability to see instant progress.  The GUI is created with mock data but is production ready.
• It is best for the planning game if everyone is FTF.  If this is not possible, use excel instead of 3x5 cards.  Use netmeeting and IM. 
• For virtual teams do daily standup meetings over the phone while standing up.  If you are standing up, you are more likely to make it a short meeting cause you want to sit down.
• Have automated build and deployment scripts.  Should be able to push to a test and production environment at any point during the iteration.  This script will get tested hundreds of times during a 3 week iteration.  Goal is to be able to push to production at the end of the iteration and just walk away while it is running cause you know that it works without issue.
• Developers do the stories that provide the most business value based on customer priorities.  This means that the developer may not get to work on the coolest stuff 1st since it may not provide the biggest business value
• 3 month release cycle, 3 week iterations.
• High level planning game every 3 months
• Every 3 weeks detailed planning game for that iteration.
• Developer give amount of time available for code
• Requirements are broken down into smallest piece possible.
• Developer estimates how long for each requirement
• Customer prioritizes the requirements and decides which ones will be in this iteration.
• Customer write how they are going to test the requirement.  This become the customer acceptance test
• 4 core values
• Communication
• This is key.  Need constant feedback from customers and developers.
• Simplicity
• Feedback
• Courage
• Practices:
• 14 of them
• Get the full benefit by putting them all together
• Without automated unit test, it is hard to re-factor since you can not prove that you did not break anything.
• Adopt as is or adapt.  Some of these processes would benefit any methodology
• Set of simple and concrete practices
• Planning Game
• XP does just as much planning if not more than the old methods.  They just do a little bit at a time instead of the whole project at once.
• Simple Design
• Build the application in the simplest manner possible.
• Easier to maintain in the long run.
• Easier to add functionality in the end.
• Motto: "Don't think about tomorrow's problems until tomorrow"
• Make sure code is very readable.
• Don't be afraid to re-factor other developers code in your program.  Everyone owns all of the code.
• Design Strategy rules
• Does not hurt to think about future functionality but do not actually implement it. 
• It will be wasted time if you add future stuff now cause when it finally comes up as a requirement, it most likely will be wrong and need to re-coded.
• "Only 10% of that extra stuff will ever get used, so you are wasting 90% of your time" ExtremeProgramming.Org.
• Refactor:
• Replace anything complex with something simpler
• Remove redundancy
• Eliminate unused functionality
• Enhance efficiency
• No comments in the code, typically if a developer finds comments, they are going to read them but most of the time the comments are out of date.  If you follow the kiss (keep it simple stupid) method, the code should be very readable and easy to follow without the need for comments. 
• The code should be in the smallest chunk possible,  if you have long pieces of code, you should look at spliting it up into multiple methods.
• Concentrate on what is scheduled for today only
• Pair Programming
• Program with 2 programmers sitting side by side, at the same machine or thru netmeeting if the developers are not co-locationed.
• It is bad to not do cause only one person knows parts of the code.  So if a person suddenly leaves the company, there is no one that know sections of an application.
• Takes some practice, it takes time to get good at it.  Try it for 2-3 months.
• 90% of the people prefer to pair after they have tried.
• Team decides how they want to pair up.
• Tech lead may step in and decide how to pair for stuff that needs to get out quicker, so that they can ensure that the senior developers are working on it.
• Can pair a senior and junior developer.
• When pairing, you are not answering the phone or checking email.  You are dedicated to the task at hand.
• This practice ensures:
• All production code is reviewed by at least one other programmer (QA)
• Better design
• Better testing
• Better code
• Serves to:
• Communicate application knowledge thru team
• Programmers learn, their skills improve, they become more valuable to the team and to the company
• Pairing, even on its own outside of XP, is a big win for everyone
• It may seem inefficient to have two programmers doing "one programmers job" but the reverse it true.
• Less Bugs
• Better Code
• More Manageable
• Ensures Test cases are created.
• About 50-60% more efficient.  If 1 takes, 10 hours, 2 may take 4-6 hours.
• Less interruptions.  Since you are taking up someone else's time, you are more likely to dedicate time to the task and do other stuff like check email, answer the phone, handle drive-by request, etc..
• Test Driven Development
• Why? XP is obsessed with feedback, Good feedback requires good testing
• How? Adding a test, then make it work
• What? Produce code with nearly 100% test coverage
• Write a test, watch your code fail, fix your code, the test passes.  You do this over and over and over again.
• This ensure that you are implementing your code in the proper way and are not breaking other functionality.
• Do not write code until you write a unit test for it as this ensures that you do not break anything else.
• Stops you from going beyond your simple design.
• Stops you from putting extra functionality in the product.
• Causes you to think thru how you are going to design you code since you have to write a class first.
• Vital for design improvement (refactoring)
• Unit test are all collected together, and every time any programmer releases any code to the repository every unit test must run correctly
• 100% pass rate or it is not integrated
• Re-factoring
• XP focuses on delivering business value in every iteration.  To accomplish this over the course of the whole project, the software must be well-designed.
• If you do not take time to re-factor as you code and test, you will end up going back and spending a whole iteration to clean up the code instead which is bad cause this iteration will not be delivering any business value to the customer.
• Write test, code, make test pass, re-factor, repeat until totally re-factored then integrate.
• Focuses on:
• Removal of duplication
• Increasing the "cohesion" of the code
• Lowering the "coupling"
• This lets the team sustain development speed (in fact generally increase speed as the project goes forward)
• Ensures that as the design evoles, nothing is broken.  Thus the story test and automated unit tests are a critical enabling factor
• Continuous Integration
• Build multiple times a day
• Have automated build and deployment scripts.
• Can quickly catch integration bugs that may occur before they are rolled to production and will easily be able to pinpoint what caused the problem since a minimal amount of code will have changed.
• Avoid "integration hell", where everything broke and no one knew why.
• If you have a strong build process, will eliminate problems when implementing in production.
• Infrequent integration leads to serious problems:
• Although integration is critical to shipping good working code, the team is not practiced at all
• Collective Ownership
• Everyone owns the code, no one owns a particular part of the code.
• Don't be afraid to refactor code that is not yours.
• Coding Standard
• If do not have one put one together
• Make it short so that folks will read and follow it
• Needs to be documented.
• CCSD standards is a 2 page document, it hits the key standards and does not try to hit every possible programming option that there is.
• Metaphor
• Least used practice in XP
• Least understood, most feared yet very important
• Created common vision and vocabulary of how the system works that helps everyone understand what the system is suppose to do.
• Hard to find something that describes it.
• Sustainable Pace
• Work hard at a pace that can be sustained indefinitely
• Work in a way that maximizes productivity week in , week out.
• Plan for email and meeting time in the plan for each week.
• When starting a new project, plan for only 50%.
• You will have phone calls initially
• Initial may have existing projects that you are still supporting
• If operating at a higher level after the 1st iterations then raise the velocity of the iteration
• Tired programmers just code more bugs
• Death march projects are neither productive nor produce quality software.
• Open Workspace
• Open Space
• Tables in middle of the space
• Cube around the outside of the space
• A room with a nice view - if possible
• Opens the lines of communication
• Does let people just put on their headphones and hide in their cubes.
• Generic Benefits
• Compared to other software methodologies it is quicker to get value out in small increments.
• Faster route to real value
• Higher quality code
• Business more likely to get what they need
• More fun
• Reduces peaks and troughs
• Lower risk of getting it completely wrong
• Flatter cost of change curve
• Cost of Change Curve
• Traditionally very expensive.  Cost of change eXPonentially with time.
• Xp flattens the cost curve. Cost of changes flattens over time.
• Benefits for Developers
• XP allows you to focus on coding and avoid needless paperwork and meetings
• It provides a more social atmosphere, more opportunities to learn new skills and a chance to go home at a decent hour each night
• It gives you frequent feelings of achievement, and generally allows you to product code that you feel good about.
• Benefits for Management
• Delivers working software for less money, and the software is more likely to do what the end users actually want
• It cuts risk in a couple of ways:
• Allows you to "pull the plug" on development at almost any time, and still have highly valuable code and probably even a valuable working (if incomplete) application
• It reduces your dependence on individual superstars, and at the same time can improve employee satisfaction and retention
• Spread the knowledge around the team instead of having experts.
• Disadvantages
• Difficult to get many developers to accept the practices and it takes a lot of discipline to keep doing them all
• Customers may not like the idea of having to be so involved
• Management may expect fixed-cost, fixed-scope estimates, which XP teams often refuse to create (because they are usually incorrect with any methodology)
• "Cowboy" coding "superstars" may dislike the reduction in fame, attention, and adrenealine from "saving" the project at the last minute
• Many developers and customer fear the process, because you do not know everything up front and do it in iterations but after going thru it for a bit, people tend to like getting something to play with every 3 weeks.
• XP Customers and Roles:
• XP Roles:
• Customer
• Writes stories
• Define and verify the business value of each story
• Prioritize what is in each iteration
• Key attendee at iteration planning sessions
• Clarifies the requirement
• Is always available to answer questions
• Writes test cases (story test) to validate each story. At the very least should be able to tell us how they are going to validate the test.
• Performs acceptance testing
• Customer is not always the end user. If could be a BA, Manager, End-User, anybody that wants requirements in an application.  They have still have to write the test and do the testing.
• End customer
• Person whose time the business commit to the project
• Person generally does not have much time available normally 25% or less
• Person should be empowered as the decision maker in terms of user requirements.
• If this person is not the customer from above, they are the ones interacting with the BA.
• What does XP mean to the customer
• Much less documentation.  Less emphasis on documenting the requirement up front
• More emphasis on evolution of requirements and hence functionality
• Change is considered a necessary part of software development
• More emphasis on testing up front
• Only do the documentation that is value added.  You should not spend weeks or months writing/updating documentation for a 3 weeks iteration.
• Much less chance of getting it wrong since you are doing small chunks of requirements at a time.
• With requirements they can go and make changes to the release plan provided that they can de-prioritize other things, if you can not fit it all into this iteration after the customers change.
• Customer is in control of when the product is deployed
• They can decide there enough value to go live or not.
• They decide when a requirement is completed per their acceptance test that they provided before you started coding.
• Business start seeing functionality earlier
• Reduced process in favor of increased business value
• Expectations of the end customers
• 1st iteration should aim to deliver 80% of biz value
• Don’t expect perfection
• Issues to be prioritized
• Customers needs to accept an 80% solution
• Postpone the "tweaks" till the next release
• Keep it simple
• Participates in and enlist the help of real users for usability testing
• Review the system after every iteration and give feedback
• Participate in user acceptance testing prior to deployment.
• Customer Rights
• Prioritize stories based on business value
• Critical means we can not go live without it
• High means high value but we could still deploy without it
• Do the most important/valuable ones first
• Many teams have medium and low items below the zbb line.
• Some teams do not use levels, they instead number them 1 to x.  They can be re-ordered but this is the order that they will need to be completed in per the customer.
• It is up to the team to decide what levels they want (e.g. critical, high, medium, low).
• Ensures that 1st release contains a mixture of critical and high stories
• Give us the flexibility to allow/embrace change
• High stories could be postponed till a later release to safeguard 1st release.
• The smaller we can get the feature set down to the quicker it can be released.
• Have the right to an overall plan to know what can be accomplished when and at what cost
• Right to get the most value out of every release.
• How does re-use and xp play?
• Add new methods as you go.
• Make sure the code is clean
• Re-usability naturally falls out of re-factoring.