MyDigitalSauce
Share
Recent graduates who take a software engineering course in school are taught the software development lifestyle and may have heard a bit about XP.
The will believe that software development lifecycle is: analysis, design, coding and testing.
Which is true but XP software life cycle is working on analysis, design, coding and testing simultaneously and deploying releases every week.
On XP teams all the software engineers sit in one big workspace to collaborate effectively.
In the interactive software engineering lifecycle you’re able to develop what you think is right, yet there’s enough structure for everyone to understand what’s going on and make constant progress.
The iterative lifecycle makes your life easier and you get more done and it’s higher quality.
The XP Lifecycle
One of the most astonishing premises of XP is that you can eliminate requirements, design, and testing phases as well as the formal documents that go with them.
This premise is so far off from the way we typically learn to develop software that many people dismiss it as a delusional fantasy.
XP emphasizes face-to-face collaboration. This effectively eliminates communication delays and misunderstandings.
This approach doesn’t mean the team is more productive, it means that the team gets feedback much more quickly.
The amount of unproven work is very small , which allows the team to correct mistakes on the fly.
Any information you learn in one phase can change the way you think about the rest of the software. If you find a design defect during coding or testing, you can use that knowledge as you continue to analyze requirements and design the system in subsequent interactions.
How It Works
XP teams perform nearly every software development activity simultaneously. Analysis, design, coding, testing, and even deployment occur with rapid frequency.
That’s a lot to do simultaneously. XP does it by working in iterations: week-long increments of work. Every week, the team does a bit of release planning, a bit of design, a bit of coding, a bit of testing, and so forth.
They work on stories: very small features, or parts of features, that have customer value. Every week the team commits to delivery four to ten stories. Throughout the week, they work on all phases of development for each story. At the end of the week, they deploy their software for internal review.
The following sections show how traditional phase-based activities correspond to an XP iteration.
Planning
Every XP team includes several business experts.
On-site customers point the project in the right direction by clarifying the project vision, creating stories, constructing a release plan, and managing risks.
Programmers provide estimates and suggestions, which are blended with customer priorities in a process called the planning game.
Together the team strives to create small, frequent releases that maximize value.
The planning effort is most intense during the first few weeks of the project. During the remainder of the project, customers continue to review and improve the vision and the release plan to account for new opportunities and unexpected events.
In addition to the overall release plan, the team creates a detailed plan for upcoming week at the beginning of each iteration. The team touches base every day in a brief stand-up meeting, and its informative workspace keeps everyone informed about the project status.
Analysis
Rather than using an upfront analysis phase to define requirements, on-site customers sit with the team full-time. On-site customers may or may not be real customers depending on the type of project, but they are people best qualified to determine what the software should do.
On-site customers are responsible for figuring out the requirements for the software.
When programmers need information they simple ask. Customers are responsible for organizing their work so they are ready when programmers ask for information. They figure out the general requirements for a story before the programmers estimate it and requirements before programmer implements it.
Customers and testers create the customer tests for a story around the same time that programmers implement the story.
For the user interface (UI) customers work with the team to create sketches of the application screens.
Design and Coding
XP uses incremental design and architecture to continuously create and improve the design in small steps. This work is driven by test-driven development (TDD), an activity that inextricably weaves together testing, coding, design, and architecture.
To support this process, programmers work in pairs which increases the amount of brainpower brought to beat on each task and ensures that one person in each pair always has time to think about larger design issues.
Programmers use version control system for configuration management and maintain their own automated build. Programmers integrate their code every few hours and ensure that every integration is technically capable of deployment.
All programmers share coding standards and share ownership. They share a joint code aesthetic and everyone is expected to fix problems in the code regardless of who wrote it.
Testing
Each member of team; programmers, customers, and testers makes his own contribution to software quality. Well-functioning XP teams produce only a handful of bugs per month in completed work.
Programmers provide the first line of defense with test-driven development. TDD produces automated unit and integration tests. Use end-to-end tests in some cases.
Customer tests help ensure that the programmers’ intent matches customers’ expectations.
Testers help the team understand whether their efforts are in fact producing high-quality code. They use exploratory testing to look for surprises and gaps in the software.
When testers find a bug the team conducts root-cause analysis and considers how to improve their process to prevent similar bugs from occurring in the future.
Testers also explore performance and stability.
Customers then use this information to decide whether to create additional stories.
When bugs are found programmers created automated tests to show that the bugs have been resolved.
Every time programmers integrate they run the entire suite of regression test to check if anything is broken.
The team also supports their quality efforts through pair programming., energized work, and iteration slack.
Deployment
XP teams keep their software ready to deploy at the end of any iteration. They deploy the software to internal stakeholders every week in preparation for the weekly iteration demo.
Deployment to real customers is scheduled according to business needs.
When the project ends the team may hand off maintenance duties to another team. In this case, the team creates documentation and provides training as necessary during its last few weeks.
Summary
XP software engineers perform testing, design, coding, and integration all at once. They deploy every week.
Software engineers integrate every few hours and do test driven development, refactoring and design simultaneously.
With XP software engineers jump back and forth between all the normal development activities as the situation dictates. Focus on what you’re delivering rather than trying to figure out what phase of development you’re in.
Pitfalls
One of the pitfalls that arrises with XP teams is that the on-site customers often have difficulty with release planning. XP gives them freedom to change their mind at will, and they do, too much. They slip into agile thrashing which means they overreact to every opportunity. They change direction every time something new comes up. As a result the team never finishes anything valuable.
The XP Team
Working solo on your own projects can be a lot of fun.
There are no questions about which features to work on, how things out to work, if the software works correctly, or whether stakeholders are happy. All the answers are right there in one brain.
Team software development is different. The same information is spreadh out among many members of the team. Different people know:
- How to design and program the software (Programmers, Developers, Engineers)
- Why the software is important (Product Manager)
- The rules the software should follow (Domain Experts)
- How the software should behave (Interaction Designers)
- How the User Interface should look (Graphic Designers)
- Where defects are likely to hide (Testers)
- How to interact with the rest of the company (Project Manager)
- Where to improve work habits (Coach)
All of this knowledge is necessary for success. XP Acknowledges this reality by creating cross-functional teams composed of diverse people who can fulfill all the team’s roles.
On-Site Customers
One-site customers often just called customers, are responsible for defining the software the team builds. Customers are responsible for what stakeholders find valuable.
Customers’ most important activity is release planning. Customers need to evangelize the project’s vision; identify features and stories; determine how to group features into small, frequent releases; manage risks; and create an achievable plan by coordinating with programmers and playing the planning game.
In addition to planning, customers are responsible for providing programmers with requirements details.
Don’t neglect this role; it’s essential to increasing the value of the product you deliver.
There should be two customers for every three programmers. This seems like a lot, huh. But customers will usually struggle to keep up with programmers. Many XP teams have field tested and they’ve found 2:3 ratios to be the best.
Product Manager (a.k.a. Product Owner)
The product manager has only one job on an XP project, but it’s extensive. The job is to maintain and promote the product vision.
In practice this means documenting the vision, sharing it with stakeholders, incorporating feedback, generating features and stories, setting priorities for release planning, providing, direction for the team’s on-site customers, reviewing work in progress, leading iteration demos, involving real customers, and dealing with organizational politics.
They are responsible for ensuring successful deployment of the product to market.
Software development is expensive. If the software isn’t valuable enough to warrant the time of a good product manager perhaps it isn’t worth developing in the first place.
Some companies have a committee play the role of Product Manager, but I advise against this. Committees have trouble creating consistent, compelling visions.
Interaction Designers
The user interface (UI) is the public face of the product.
For many users, the UI is the product. They judge the product’s quality solely on their perception of the UI.
Interaction designers divide their time between working with the team and working with users.
Designers have the opportunity to take real software to users, observe their usage patterns, and use that feedback to effect changes as soon as one week later.
Business Analysists
Business analysts augment a team that already contains a product manager and domain experts. The analyst continues to clarify and on-site customers needs, but the analyst does so in support of the other on-site customers, not as a replacement for them. Analyst help customer think of details they might otherwise forget and help programmers express technical trade-offs in business terms.
Programmers
A great product vision requires solid execution. The bulk of the XP team consists of software developers in a variety of specialties. Each of these developers contributes directly to creating working code. To emphasize this, XP calls all developers programmers.
The customer’s job is to maximize the value of the product. The programmers’ job is to minimize its cost. Programmers are responsible for finding the most effective way of delivery the stories in the plan.
Programmers also ensure that the customers may choose to release the software at the end of any iteration. With the help of the whole team, the programmers strive to produce no bugs in completed software. They maintain a ten-minute build that can build a complete release package at any time. They use version control and practice continuous integration, keeping all but the last few hours’ work integrated and passing its rtests.
Prorgrammers rely on customers for information about the software to be built. Rather than guesting when they have a question, they ask one of the on-site customers. To enable these conversation programmers build their software to use a ubiquitous language. They assist in customer testing by automating the customer’s examples.
Programmers help ensure the long-term maintainability of the product by providing documentation.
Team Sizes
The guidelines assume teams with 4 – 10 programmers ( 5 – 20 total team members). For new teams 4 – 6 programmers is a good starting point.
XP teams can be as small as one experience programmer and one productr manager, but full XP might be overkill for such a small team. The smallest team I would use with full XP consists of five people; four programmers, one acting as coach and one product manager. The product manager acts as domain expert and tester.
XP Concepts
As with any specialized field, XP has its own vocabulary. This vocabulary distills several important concepts into snappy descriptions. Any serious discussion of XP uses this vocabulary.
Refactoring
There are multiple ways of expressing the same code. Some are better than others.
Refactoring is the process of changing the structure of code, rephrasing it without changing its meaning or behavior.
Refactor to improve code quality to fight of software’s unavoidable entropy and to ease adding new features.
Technical Debt
More coming soon…
