Hello and welcome the lesson 3.3 extreme programming, also known as X X p.
This is a flavor of agile that was actually invented at the Chrysler Corporation during the 19 nineties as part of their overhaul of their compensation system.
And several members of that project team went on to publish their results and had several books published.
Um, and it became a flavor of agile since really the late nineties early two thousands.
The extreme programming is the idea that
if we d compile our tasks into ever smaller work packages than we can actually become more productive and produce more value for the customer. So for those of you that are familiar with, you know, the traditional work breakdown structure of a waterfall type project,
you'll recall, Or hopefully you recall that the work breakdown structure they recommend that you d compile somewhere between 40 and 80 hours
with the network breakdown structure box. In the case of Extreme, what they're actually going for is the dramatic opposite of that
where they're actually trying to produce
features in a extremely short period of time. So the course there gonna be smaller features one of the things that XP really focuses on also is the idea of, ah, simplest possible code. So the least number of code lines reusing code as much as possible.
Um and so this idea that we can,
um, minimize the complexity of the system itself and actually get value to the customer quickly.
So some of the tenants of XP is one to sit together. So they
practitioners of XP really advocate that
members being in the same physical workspace, that they interact physically as often as possible, and some other research has shown that proximity actually does increase in group
identification in group behaviour. So they got that one right. Research has proven them out.
The 2nd 1 is that the whole team concept. So the whole team concept is
every individual that you need to produce. Your software project should be a full time member of your team. So as you start to integrate and I don't mean full time as, and they have to be doing project things for you 40 hours a week,
but they are a full time member of the team, they go to all the meetings. So if you're an SME or you're a customer, you're still a full time member of the team, and that's a really common theme and agile anyway, so that they're not really breaking new ground. They're
They also advocate for informative workspace that you they want you to design
your workspace to be as informative as possible. So we've got the whole team together.
They're physically in the same space and all of the charts and infographics everything else that you would have in that workspaces designed to inform the Project team
also, that has another benefit of energizing the workforce. They want folks to not be
distracted, give people much time off as they need or structure their work schedule so they don't have exterior distractions during the work day while they're doing XP.
Um, and then one of the unusual elements of XP is what's called paired programming. And I've actually done a project with paired programming, and it really did work out pretty well. So the idea of paired programming is that you have to individuals physically sitting at the same desk
with one keyboard, one mind, one or two monitors, and I look at it,
but it's two hands on the keyboard, but two brains and four eyes are looking at the code as it is being written and has a benefit. One of having a built in Q A
to it actually speeds up the process of coding because you have two people that are able to resolve problems as they arrive.
Um, so it
some people that some detractors would say, Well, it's gonna take you twice as long and do the work because you've got, in essence one program are looking over the other programmers shoulder. But it's actually but been found that not the case. It takes a little bit longer. But if you built in, if you have built in Q A, then you don't necessarily need to
increase. The man a testing time hopefully s best for part of the goal there on and then they use
instead of scrums. Idea of sprints they have what are called stories and epics and stories and epics is just a different way
of talking about the work, a different way of looking at
how these things roll up. So we've talked a little bit about strategy, execution on if milieu that have done my enterprise class, you've taken a lot of strategy execution information in
when you develop a new feature. Whenever you try to add new functionality to your system, you want to keep rolling that up into those stories into those user stories into those features.
shows how that's going to
create strategic value within the program itself,
within within the problem that the projects trying to solve.
They also advocate using slack. So what that means not slack the program, although you can use that program if you want. But what they're talking about here is continually
low priority features into each of the bill cycles, so that
if they have, if they don't get done, if they fall off, then it's not that big of a deal. But if if there is time to build them, then you get some of these nice toe have features in each of your
weekly or quarterly release cycles. One of the things that they XP programmers like to do is they build weekly or don't build weekly, but they release weekly to test,
so that way they can get customer feedback and their actual production releases. They do quarterly. So with a little bit different dance crumb as faras, the idea of doing your sprints and then
putting that code into production. They do us a weekly sprint, if you call it anyway Weekly Sprint, and then it goes into test customers contest it. They can submit feedback. Things can get reworked,
and then every quarter, all of that goes into a quarterly cycle.
they also talk about or advocate for what's called a 10 minute build. So it basically means that when you're when you're writing code,
the process for,
compiling it, putting it, integrating it into the other code and testing it should take no longer than 10 minutes. And if it does, you need to be doing it more often. So what they're trying to do here
is really get back to that simplest process. So if you're introducing new code in very small chunks, it makes it easier when you're doing your testing to find where that code might have caused problems. So they're just basically advocating
that most programmers, myself included, don't like to test.
So rather than avoid it and push it off and test the whole system at the end, do it more often so Basically, if it's painful, do it more often. So that way you get more valuing and you have a better quality code.
Same thing with continuous integration Every time you write new code,
not only are you testing it
within the system that you're building, but you're also testing all of the integration that that system has to other systems to again try to catch any issues before they become sort of a distant memory or before they overwhelmed the team.
Um, and then they also advocate test first programming, which basically means run a test
when the test fails, then work on your software and you continue to test
until it passes. So if you test something, it fails. You you troubleshoot it, tested again, troubleshoot it, Tesic. And then eventually you writing this very small pieces of co changes to get past that test on. And then they also advocate for incremental design and re factoring. So that's
again going through that weekly quarterly cycle
where you're getting all that feedback from the customer you're and you're doing
a little bit of long term planning with the customer, especially for the new quarterly cycle that comes up. But you're constantly going back to that beginning point and looking at
you know what's what's working? Well, what's failing things of that nature.
Here's a nice little infra graph that kind of shows what I'm talking about. As far as the extreme programming feedback loops, um, we're gonna know you code
you And within just a couple of minutes you're doing your pair of programming. You're kind of getting into that cycle. You're working on your feature.
Then you put that in the unit test.
Um, then you move that weakly into the customer acceptance testing, and then you do your, ah,
quarterly immigration cycles to actually put the code into production.
So that concludes today's lesson. I hope everybody has a great day.