XP

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
3 hours 55 minutes
Difficulty
Intermediate
CEU/CPE
4
Video Transcription
00:01
>> Hello and welcome to lesson 3.3,
00:01
Extreme programming, also known as XP.
00:01
This is a [NOISE] flavor of
00:01
agile that was actually invented at
00:01
the Chrysler Corporation during
00:01
the 1990s as part of
00:01
their overhaul of their compensation system.
00:01
Several members of that project team went on to
00:01
publish their results and had several books
00:01
published and it became a flavor of
00:01
Agile since really the late '90s, early 2000s.
00:01
Extreme Programming is the idea that if we
00:01
decompile our tasks into ever smaller work packages,
00:01
then we can actually become more
00:01
productive and produce more value for the customer.
00:01
For those of you that are familiar with
00:01
the traditional work breakdown structure
00:01
of a waterfall type project,
00:01
you will recall or hopefully you recall
00:01
that the work breakdown structure they recommend
00:01
that you decompile somewhere
00:01
between 40 and 80 hours
00:01
within each work breakdown structure box.
00:01
In the case of extreme,
00:01
what they're actually going for is
00:01
the dramatic opposite of that where they're actually
00:01
trying to produce features
00:01
in a extremely short period of time,
00:01
so of course they're going to be smaller features.
00:01
One of the things that XP really focuses on also is
00:01
the idea of simplest possible code.
00:01
The least number of code lines,
00:01
reusing code as much as possible,
00:01
and so this idea that we can minimize
00:01
the complexity of the system itself and
00:01
actually get value to the customer quickly.
00:01
Some of the tenets of XP is one to sit together,
00:01
practitioners of XP really advocate
00:01
that members be in the same physical workspace,
00:01
that they interact physically as often as possible,
00:01
and some other research has shown that proximity actually
00:01
does increase in-group identification
00:01
and in-group behavior,
00:01
so they got that one right,
00:01
research has proven them out.
00:01
The second one is that the whole team concept,
00:01
the whole team concept is
00:01
every individual that you need to
00:01
produce your software project
00:01
should be a full-time member of your team.
00:01
As you start to integrate,
00:01
and I don't mean full-time as in they have to be doing
00:01
project things for you 40 hours a week,
00:01
but they are a full-time member of the team,
00:01
they go to all the meetings.
00:01
So if you're an SME or you're a customer,
00:01
you're still a full-time member of the team,
00:01
and that's a really common theme and agile anyway,
00:01
so that they're not really breaking new ground there.
00:01
They also advocate for an informative workspace.
00:01
They want you to design
00:01
your workspace to be as informative as possible,
00:01
so we've got the whole team together.
00:01
They're physically in the same space,
00:01
and all of the charts
00:01
and infographs and everything else that you
00:01
would have in that workspace is
00:01
designed to inform the project team.
00:01
Also has another benefit of energizing the workforce.
00:01
They want folks to not be distracted,
00:01
give people as much time off as
00:01
they need or structure their work schedule so they
00:01
don't have exterior distractions during
00:01
the workday while they're doing XP,
00:01
and then one of the unusual elements
00:01
of XP is what's called paired programming.
00:01
I've actually done a project with
00:01
paired programming and it
00:01
really did work out pretty well,
00:01
so the idea of paired programming is that you have
00:01
two individuals physically sitting
00:01
at the same desk with one keyboard,
00:01
one mind one or two monitors,
00:01
you need to pay a high I look at it,
00:01
but it's two hands on the keyboard.
00:01
But two brains and four eyes are
00:01
looking at the code as it's being written,
00:01
and it has a benefit,
00:01
one of having a built-in QA.
00:01
Two it actually speeds up the process of coding
00:01
because you have two people that are able to
00:01
resolve problems as they arrive.
00:01
Some detractors would say, well,
00:01
it's going to take you twice as long,
00:01
and do the work because you've got an essence,
00:01
one program or looking over
00:01
the other programmers shoulder,
00:01
but it's actually been found that not the case.
00:01
It takes a little bit longer,
00:01
but if you have built-in
00:01
QA then you don't necessarily need
00:01
to have an increased amount of testing time,
00:01
hopefully that's part of the goal there [NOISE].
00:01
Then they use instead of Scrums,
00:01
idea of sprints, they
00:01
have what are called stories and epics,
00:01
and stories and epics is
00:01
just a different way of talking about the work,
00:01
different way of looking at how these things roll up.
00:01
We've talked a little bit about strategy execution,
00:01
and then if those of you that have
00:01
done my enterprise class,
00:01
you've taken a lot of strategy execution information in.
00:01
When you develop a new feature or whenever
00:01
you try to add new functionality to your system,
00:01
you want to keep rolling that up into those stories,
00:01
into those user stories,
00:01
into those features that shows how that's going
00:01
to create strategic value within the program itself,
00:01
within the problem that the project is trying to solve.
00:01
They also advocate using Slack,
00:01
what that means, not slack the program,
00:01
although you can use that program if you want,
00:01
but what they're talking about here is continually adding
00:01
low priority features into each of
00:01
the build cycles so that if they don't get done,
00:01
if they fall off,
00:01
then it's not that big of a deal,
00:01
but if there is time to
00:01
build them and you get some of these nice to
00:01
have features in each of
00:01
your weekly, quarterly release cycles.
00:01
One of the things that they XP programmers like
00:01
to do is they build weekly or they don't build weekly,
00:01
but they released weekly to test.
00:01
That way they can get customer feedback and
00:01
their actual production releases, they do quarterly.
00:01
It's a little bit different than
00:01
Scrum as far as the idea of doing
00:01
your sprints and then putting that code into production,
00:01
they do us a weekly sprint.
00:01
You can call it that anyway, a weekly sprint and then
00:01
it goes into test and customers can test it.
00:01
They can submit feedback,
00:01
things can get reworked,
00:01
and then every quarter all of that
00:01
goes into a quarterly cycle.
00:01
They also talk about or
00:01
advocate for what's called a 10-minute build,
00:01
so it basically means that when you're writing code,
00:01
the process for compiling it, putting it,
00:01
integrating it into the other code,
00:01
and testing it should take no
00:01
longer than ten minutes and if it does,
00:01
you need to be doing it more often.
00:01
What they're trying to do here is
00:01
really get back to that simplest process,
00:01
if you're introducing new code in very small chunks,
00:01
it makes it easier when you're doing your testing
00:01
to find where that code might have caused problems,
00:01
so they're just basically advocating
00:01
that most programmers myself included don't like to test.
00:01
Rather than avoid it and push it off and test
00:01
the whole system at the end, do it more often,
00:01
so basically if it's painful,
00:01
do it more often so that way you get
00:01
more value and you have better quality code.
00:01
Same thing with continuous integration,
00:01
every time you write new code,
00:01
not only are you testing
00:01
it within the system that you're building,
00:01
but you're also testing all of the integrations that
00:01
system has to other systems to again,
00:01
try to catch any issues before they
00:01
become a distant memory
00:01
or before they overwhelm the team.
00:01
Then they also advocate test first programming,
00:01
which basically means run a test.
00:01
When the test fails,
00:01
then work on your software and you continue
00:01
to test until it passes.
00:01
If you test something it fails,
00:01
you troubleshoot it and test it again,
00:01
and then eventually you writing
00:01
this very small pieces of
00:01
code changes to get past that test,
00:01
then they also advocate for
00:01
incremental design and refactoring.
00:01
That's again going through that weekly to
00:01
quarterly cycle where you're
00:01
getting all that feedback from the customer,
00:01
and you're doing a little bit
00:01
of long-term planning with the customer,
00:01
especially for the new quarterly cycle that comes up.
00:01
But you're constantly going back to
00:01
that beginning point and looking at what's working well,
00:01
what's failing, things of that nature.
00:01
Here's a nice little infograph that shows what I'm
00:01
talking about as far as
00:01
the Extreme Programming Feedback loops.
00:01
Code, and within just a couple of minutes,
00:01
you're doing your pair programming.
00:01
You're getting into that cycle.
00:01
You're working on your feature.
00:01
Then you put that into unit test,
00:01
then you move that weekly
00:01
into the customer acceptance testing,
00:01
and then you do your quarterly integration cycles
00:01
to actually put the code into production.
00:01
That concludes today's lesson,
00:01
I hope everybody has a great day.
Up Next