There are many programming methodologies teams adopt.
One of them is extreme programming.
In this article, we’ll look at the lifecycle of development when working with the extreme programming methodology.
Circle of Life
The development lifecycle using the methodology starts with the customer.
They define the value by telling programmers what they need.
Then programmers build programs that meet the customer’s needs.
Business value depends on what we get and how much it cost to build the features the customer needs.
This way, the business can actually be profitable selling the features that the customer wants.
If the business doesn’t take into account the cost, it can easily go into the red building things that customers want, but it might take too long or it’s too complex to build.
Most things take longer than we’d like.
So we should also give ourselves a more generous estimate than we think we need.
Pressuring programmers won’t do much since quality will decrease if we rush.
Also, if the software that’s built is bad quality, then we’ll have to fix lots of bugs later.
We also have received lots of customer complaints, which also isn’t good.
If we build our feature quickly, but the customer isn’t happy with it, then that wouldn’t be good.
Also, bad code quality means the code will be hard or impossible to work on.
This means that giving the customer more value in the future would be difficult and time-consuming.
Customer
We should see customers what they need.
It’s important since it’s the foundation of programmers’ work.
Without proper requirements, we wouldn’t know what to build.
Therefore, before creating user stories, we should ask the customer what he/she needs.
In extreme programming, we want to program at high speeds.
But written specifications take a long time to write and they don’t communicate well.
Therefore, to speed things up, it’s better to talk about the requirements as needed, as the project goes on.
The more time the customer and programmer spend together, the better things go.
This is because we get feedback as soon as something is built.
This is good news for us.
Onsite Customers
Ideally, we can talk to the customer as soon as we need them.
We can talk to them onsite or we can talk to them remotely.
In either, we can show them what we have and if they want it.
They can prioritize the features that they want.
Likewise, programmers can reach out to the customer.
We release code so that they can see what we have.
We make sure that they can see the system working.
Also, we’ve to plan for any misunderstanding that may arise.
User Stories
User stories are small features that can be written in a card.
They are small features that add up to one big project.
The description of a user story is short and it describes the behavior of the system from the user’s perspective.
In extreme programming, a project is defined entirely through user stories.
To know what stories to create, we’ve to do our research.
This means doing an analysis to find out what customers want.
We should do the analysis informally as we do the project.
To start the project, we do some analysis and build some features according to the initial stories.
They as we progress, we do more analysis, write more stories, and build more stuff.
We realize that we should learning as needed, based on what’s done so far.
By keep stories small and releasing often, we can bring customers and programmers together by getting feedback on what’s built so far.
Then we keep getting feedback and iteration as we go on.
Starting with Stories
To start writing stories, we write them on small cards.
Of course, to save paper, we can also write them on virtual cards in some task tracking software.
However, the description should be short so that it can be built and tested easily.
We write some descriptions and ask the customer how they want to work with the feature described in the story.
Conclusion
In extreme programming, the developer lifecycle starts with the customer.
We should get feedback from them to see what they want and write user stories based on them.
They should be short so that be released quickly.
Then we can start building.