hello and welcome to lessen 4.4
our video lab on developing a scrum fall or were agile, basically hybrid schedule. There's all kinds of different names for it.
I'm your instructor cane. And if you recall from the last video when we were looking at a schedule for a purely agile project, we used Microsoft Dev ops. And in this case, I'm gonna use something different just to show you some different software that's available for
these different types of tasks. So let's go ahead and get started.
So this is a traditional
waterfall type software development project, and those of you that, um, have have done waterfall projects before this should look pretty familiar. So you notice you've got your
planning phase, your requirements, gathering things of that nature. Then you build your design phase Logic, model, physical model, uh, start creating your database structure so on and so on, do your testing
and then go on to acceptance. Now, if you notice in this type of set up here
that the customer doesn't really get their hands on the project until very, very late in the project, and in this case, and see what the dates are
March Early March is obviously not a very large project here that's being scheduled, but
they don't really get their hands on it until early March. Meanwhile, all of this work has been done between January and February in the GAN chart.
So that's a That's a true waterfall software development project, and that's what we want to avoid.
However, we're limited based on
the company's culture structure, government regulation, whatever the case might be. So we want to have a version of the hybrid project.
So what we do is we keep the first couple of elements
and then remove the rest. So you'll see here that I've got
my normal requirements gathering that's gonna happen,
that I'm going to build the generalized design model. What? What software? I'm going to you or what code based on my gonna use what platform or framework, whatever the case might be.
But then I'm going to go into an interactive and I'll type development.
So I'm gonna connect these. You'll notice how that pushes everything out.
Now connect this one to sprint to Okay,
so what we see here is I've got
a true product backlog
and then I've got several sprints. So I'm gonna make sprint one dependent upon the backlog
and then sprint too dependent on Sprint one,
and you'll does not gonna do it right now. But you'll notice that what actually should happen is
This new software haven't used it before. So, uh,
not sure why it's not playing nice.
Anyway, the idea is that I'm doing my requirements gathering. I'm doing all the normal planning thing. They go to procurement, I go get my money, whatever the case might be. And then I'm starting to add items to my overall backlog.
This is gonna be your
detailed backlogs the same way that you saw it in Dev Ops. The only difference is here that I've got
It's building the list, but it's not actually extending the project. So I don't want toe relate these items to each other. I want to actually relate the sprints to each other
in their own mother,
the dependencies are
on the sprints themselves.
And again, I don't really know why it's not working the way that I wanted to, but if you look at the chart here, this is kind of what I'm trying to get at. So I have an overall product backlog. And then I have these time box prints
that drill down. And then at the end of all of this, at the end of my last sprint than my customer, ah
is going to accept the final product. And this might again, this could go on for years.
But what I'm doing, in essence, is sort of the same type of execution strategy as
the earlier, uh, Dev Ops example. Except I'm still using my normal kind of gant charts schedule. So I've got all my normal planning independency process. And then when the time comes to plan for sprint one in the same way that we were going to do it in the previous video, I should be able to and
so then in sprint one,
I want to be able to add Might do item.
Alright. Software's not
you only crashed on me. Okay,
well, I don't I don't have a good backup software. Microsoft Project doesn't offer a Mac version, but the basic idea behind it is that I'm going to set up my structure in such a way
take those items from the backlog.
Let me get another one set up here.
It's really crashing.
All right, Well, note to self, Microsoft or Project Office is not the best way to do it.
Um, but I have my sprint set up. I do all my initial planning. I build out my requirements, I build out my overall design plan and then
once I get into the execution phase instead of doing the normal database structure than you y all that kind of stuff, I'm actually going ahead and
building that product backlog. And then when the time comes to plan sprint one, I move those items from from the backlog in this print one and sprint to and so on. So
the important part about it
is really more about how the schedule gets development. It's the idea that we are doing requirements gathering
you to those products.
Backlog items should have an associated requirement that they poured unquote live under that they're supporting. And once we get to the execution phase of the project, we're building at the same way that you would a an agile project.
But the difference is
no new requirements concomitant to the project without there being a traditional change control process. So if I've got, say, 50 requirements for the project
and somebody wants to add ah, 51st requirement, I go through traditional change control
at the execution level, all I'm really doing is marrying features to those requirements. But if the feature doesn't marry to the requirement, then it doesn't count. Right. So that's the key. There is that the change control processes there
in order to make sure that your scope doesn't increase
because you're procurement and your structure is set up in such a way. That is more of a traditional waterfall style. And this is like I said, it's a good beginning step. It's a good
agile project management from a traditional waterfall standpoint, and it tends to keep
government agencies and large corporations. They tend to buy off on it a little bit more than they would for a full blown change over from waterfall to agile.
So that completes this particular lesson. Hope everybody has a great day and I will see you in Module five