Category: Extreme Programming

There are many programming methodologies teams adopt.

One of them is extreme programming.

In this article, we’ll look at the purpose of acceptance and how to do them.

Also, we look at how to do estimates.

Acceptance Tests

Tests are important in any system si that we can find out whether it works or not.

We should create tests as soon as possible so that we can test our system.

If we don’t, then it’ll lead to pain later on.

We definitely got to test before we ship.

Putting off overall testing until release if probably not a good idea.

If we fall behind, then testing time will be decreased.

Programmers forget what they did, so we should have tested as soon as we can.

If we test now, then we find defects now and fix them earlier.

If we find issues later, then we probably forgot what we did from earlier, so we would have to dig up what we did from memory and investigation, which may take a long time.

Extreme programming values feedback.

There are no better things than early feedback that’ll steer us in the right direction.

If there’s a way that can let programmers find mistakes earlier, then there would be a lot fewer mistakes.

There are many ways to implement acceptance testing in our project.

It’s up to the programmer to pick one.

Each programmer tests the thing they work on.

If a system is built to replace a legacy system, then they can bring over the test cases from the legacy system.

We can also use spreadsheets to keep track of what’s needed.

The values from them can be extracted and be used in our tests.

Some customers give input numbers to programmers and check the outputs by reading it.

This is a bad idea since checking outputs of a computer is an error-prone process.

It’s far better to have the correct values upfront so we can check against them.

We should have repeatable tests so that we can run them and check if our work is correct.

Automating the Tests

The tests must be automated.

This reduces of the burden of testing significantly.

However, there are many ways to do this.

We can write tests to read inputs and produce of puts.

Also, we can write unit tests to test small parts like functions an classes by running them one by one and checking the results.

We can also set up tests from a spreadsheet and run them.

GUI tests can also be done to simulate user actions.

We should build them so that they are automatic so we can run them again and again.

Timeliness

Tests need to be available in the same iteration as the story is included.

This way, we won’t forget about them.

Customers can also use automated tests to see them in action.

Estimation

Stories need to be estimated on size.

This way, we know how many of them we can do in each iteration.

Also, we can see how fast we’re going after each sprint so that we can do better planning in the next iteration.

It’s not easy to know how fast we go at first, but it’s easy to observe our pace after a few iterations.

Estimate by Comparison

We can estimate by comparing our project to similar projects.

Then we have a reference point of how fast it can be done.

If the scope and work are similar, then we can see how fast we can go according to that.

We estimate our stories in points, with each point based on 1 day of work for a perfect engineering day.

This means that we have the whole day free to work and everything foes well.

In the beginning, we can start with intuitive time estimates.

First, we begin with a spike solution, which is an experiment where we do enough work to get a feeling of how to implement the story.

If we don’t know how to do it, then we can chat with our teammates.

Then we should get an idea of how to implement the story.

Coming up with the estimate would be easy.

For each perfect engineering day of work, we give it one point.

If we feel that it takes more, then we give it more points.

If it’s more than 2, then we may ask the customer to split the story into 2 or more.

Conclusion

We should have automated acceptance tests as soon as we write our code.

This way, we can check against them as soon as we can.

Also, we can estimate our stories with points by comparing them against related work.

There are many programming methodologies teams adopt.

One of them is extreme programming.

In this article, we’ll look at user stories and how they’re used in extreme programming.

User Stories

User stories are the foundation of extreme programming.

They are descriptions of small features that can be fit on a card.

A project would have many of these and they would be implemented one by one.

The description in these stories would all be from the user’s perspective.

Description of a User Story

A user story has a description.

An example of a user story would be:

‘As a user, I can save employee data by entering the data in a form’.

It’s simple and to the point.

However, we can add more details as well.

They can include things like specific cases and handling failure cases.

For example, we can write:

‘We must be able to enter North American phone numbers’.

This way, we won’t forget about these specific details when we’re implementing the story.

We should be able to implement whatever is in a story in a week or less.

With what’s written, we should get a picture of how we implement it.

Stories and Conversation

User stories are made up of 2 components.

There’s the written document.

We just write the description of the story in card or a virtual version of it.

Then there’s the 2nd component, which is much more important, which is the conversations that take place between the customer and the programmers over the life of the story.

We may want additional clarification or talk about things that we didn’t foresee before implementing the story.

Each story is carried through the project.

It servers as a token for planning and implementing whatever it requests.

The programmer needs to be able to estimate how difficult each story is.

The estimate should be in days or weeks of effort.

However, it can vary from project to project.

The best way to start is to write a few stories and ask programmers if they’re the right size or detail.

Programmers and Stories

Ideally, programmers don’t write stories.

We want all stories to belong to the customers.

Stories are all about expressing what customers want.

Therefore, the programmer should keep our hands off of them.

If the customer doesn’t know to write stories, programmers can guide them through the process.

How Many Stories?

The number of stories depends on the complexity of the system.

If a system is more complex, then we need more stories.

A simpler system will need fewer.

There should be at least one story for every major feature in the system.

We’ll probably need at least one story per programmer per month.

More is better.

Therefore, if we have 20 programmers working for 6 months, there would be 120 to 240 stories in the project.

Story Size

A story should encompass a week or 2 of programming time.

The customer can scope the work based on this.

Therefore, we can break stories down to smaller ones if they take longer than that.

Stories often have a more important part and a less important part.

We can split stories into to 2 based on that.

Some stories would be too small.

In that case, we can combine some of them into bigger ones.

Not Having All the Stories

We probably don’t have the stories outlined.

But this is fine because we keep the feedback from the customer as we do the project.

The planning is iterative and ongoing so we don’t have to worry about lacking stories.

Acceptance Tests

Tests are important in any system si that we can find out whether it works or not.

We should create tests as soon as possible so that we can test our system.

If we don’t, then it’ll lead to pain later on.

We definitely got to test before we ship.

Putting off overall testing until release if probably not a good idea.

If we fall behind, then testing time will be decreased.

Programmers forget what they did, so we should have tested as soon as we can.

If we test now, then we find defects now and fix them earlier.

If we find issues later, then we probably forgot what we did from earlier, so we would have to dig up what we did from memory and investigation, which may take a long time.

Conclusion

We should have customers write user stories.

This way, they can express what they want.

User stories have a written part and a conversation part. It’s important that we communicate.

Acceptance tests should be done earlier so that can fix defects earlier.

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.

There are many programming methodologies teams adopt.

One of them is extreme programming.

In this article, we’ll look at what is extreme programming.

What is Extreme Programming?

Extreme programming is a discipline of software development that values simplicity, communication, feedback, and courage.

It focuses on customer and business needs.

Roles and responsibilities are accorded according to those needs.

This means that the methodology is meant for programming any programs for businesses.

Businesses are the focus. Customer care is the top priority.

Also, we have active communication channels and teamwork.

Feedback is also given more often.

It realizes that the success of projects is a team effort.

It’s not just the development team. It’s also the business as a whole, including management, customers, and developers.

Extreme programming brings everyone together and helps them succeed together.

It’s aimed primarily at object-oriented objects using teams of a dozen or fewer programmers in one location.

Both internal and customer-facing software can be built with it.

Customers will learn simple ways to communicate what they need effectively.

They’ll steer the project to success.

Programmers define the architecture, design the system, write tests, and the code that supports them.

This allows programmers to deliver value quickly and deal with changing requirements.

We’ll learn to build for tomorrow today.

Managers measure progress to gauge performance and measure quality.

The Customer

Customers choose what will deliver business value to them.

They also help us prioritize features and what to defer.

They also define acceptance tests to let programmers know what we need to do.

This way, we’ll always deliver what the customers want.

There got to be one representative for the customers.

It’s impossible to talk to all customers at the same time.

Features are built in small pieces as stories.

Stories tell us how individual pieces of the system needs to work.

Each story must be understood well enough that programmers can estimate its difficulty.

Also, they must be testable.

The customer expresses what must be done in stories.

There may be dozens or hundreds of stories in a project.

We may have a delivery date in mind. To determine that, we can manage the scope of the project so that it’s likely to be delivered by that date.

The customer picks the most valuable features to be included in the project scope.

We can choose that with great flexibility.’

Programmers’ Roles

The programmer role delivers business value.

Each story must be understood so that it can be built.

The software product must be designed, tested, and built to implement stories.

The software must be a coherent whole.

This way, we produce quality software quickly.

Extreme programming isn’t coe and fix or slash and burn.

It’s about careful design and fast feedback.

Testing is done extensively/

We keep the systems integrated at all times so that we won’t run into problems later on.

This way, we won’t step on each other’s toes when we have to integrate large pieces later.

The ownership of the code is sharted. This way, everyone takes care of it.

We make the code look-alike make communication and understanding easier.

Also, we make sure our system always works with unit tests and acceptance tests.

The tests allow us to change rapidly and keep us from introducing mistakes.

We may write production code in pairs sometimes, especially if the work is hard.

It’s an approach to software development that lets programmers the best and giving customers what they need the most.

Managers’ Roles

Manager’s role in extreme programming is to make the people doing the work easier.

They remove blockers and do planning for people.

It’s all about coordination and resolving conflicts.

There are planning meets and status meetings.

Rights and Responsibilities

Customers and managers plan and change priorities.

Also, changes are informed and coordinated.

Programmers know what’s needed as priorities are declared.

Quality work are done by programmers.

Estimates are controlled by programmers as well.

Programmers accept responsibilities.

Conclusion

Extreme programming is a methodology that teams partially adopt at least.

It’s about quick iterations, creating features in small stories, and putting the customer first.

Tests are also emphasized.

This way, we ensure quality by getting quick feedback.