- [Instructor] If you've ever wondered
what programming methodologies go well
with agile development,
look no further than pair programming
and test-driven development.
Full disclosure, there are many, many more.
But these two are the most likely to deliver
immediate value to you and your team,
if you're not already implementing them.
Let's start with pair programming first.
Because, honestly, it's my favorite.
Two developers sit at one computer.
One writing code, the other watching
and offering advice, direction, and possible improvements.
We call whoever is writing the code, the driver.
You can either set time limits for when to switch roles
or simply go onto the current driver gets stuck.
The benefits of this strategy are many.
First, you get code that is written by two people.
This will often result in less errors
and more elegant coding solutions.
Second, each member of a team
will get to work with each other one-on-one.
Since you want to change the pairings on a daily basis,
if your team size can handle it.
This drastically increases the level of competence
and knowledge that every member of an agile team has,
combining learning with practical software delivery,
not to mention the fact that all credit
for code written is shared, not singular.
Test-driven development is a more
time-intensive programming practice,
but it's also extremely powerful.
First, you write a failing test.
This is the red phase.
Next, you write production code
to pass that failing test.
After your code passes, you're out of the green phase
and into the refactor phase.
This is where you'll streamline
the code you've just written.
Now here's the great part.
Because you're only allowed to write code
that pass specific tests,
extraneous code gets left on the cutting room floor.
It doesn't hurt that developing this way
naturally enforces good object-oriented programming
techniques and all around clean code.
On top of that, you have a functional test suite
that grows right alongside your production code base.
If you want to know more about test-driven development,
head over to my hands-on course for iOS development.
I just want to note that the use of these
and any other development techniques,
doesn't determine whether you're running an agile project.
I've met developers who have expressed this view,
and I simply can't agree.
These are available tools, nothing more.
If you want to run your agile project
using some other methodology or other technique,
go right ahead.
You'll still be running an agile project
if you stick to the tenants and philosophy
of agile software development.