Software Engineering 102: Development Models and Agile Programming

1. Introduction: Hello, everyone. And welcome to this course. We're gonna be talking about software development models in this course, and it said so what that's just gonna come down to is a few of the really popular models that we have been using for a very long time in software engineering, as well as talking about this new idea of agile scrum and combine, which is driving more flexible way of developing software. So they'll at this course we're just going to be going over different models and how they relate to the real world and how you can use them to better develop software. Now, a quick note. This is a 102 class. You can take it independently by itself, and most of it is going to make perfect sense. However, in the one a one class, we talk about sort of the basics of all of this stuff. So if some of this stuff is not sounding 100% let's say clear to you. Maybe it sounds a little bit confusing. Check out the 101 course. It will have a very big sort of introduction to all of this material before you actually get into the models them self, So I just want to give that quick disclaimer. It's also on my channel. If you would like to check the one on one video out as well. But everyone, welcome to skill share. If you have any questions, leave them in the comments of the course and I will gladly help you in any of the areas, and I can't wait to get started. 2. 1-1 Waterfall Model: The first major model we're going to be covering is that of the waterfall model. So with waterfall model, what we're doing is we're basically water falling from step to step two step. So we started the requirements, and then once we're sure the requirements are perfect, we moved to the design that we move from there to the implementation once we're sure that's perfect down to testing down the deployment down to maintenance. Now this doesn't have to be. You know, these steps. It could be any Siris of steps that get us to this final conclusion. But the importance of the water for method or the waterfall model is that we're moving from step to step two step, and it's sort of what we've been covering the whole course, how we're talking as if everything is in one linear flow and you always follow. Follow those steps. However, the problem with the waterfall model is that it isn't very adaptive. It's very, very predictive. Remember those two words we use in the last lecture, and because it's very, very predictive, it means that if we find errors, let's say in the testing phase, that means we're gonna have to go backwards. So if, for example, we find it in the testing, let's switch the color right here, then we're gonna actually have to go back to the implementation and then from the implementation back to the design and then requirements and basically, what we're gonna have to do let's say we find an air in here a really serious error with the way we've programmed are our software. We're gonna have to go and change the requirements, fix the requirements. Then we're going to go fix the design, have come up with new subsystem designs, new module designs, etcetera. Then we're going to go back into the implementation, will have to recode it, and then we're gonna have to retest it. And if the things already deployed, we have to go even farther. We have to keep going back and rework everything from there. And once we get to the maintenance phase, it's sort of like just in a circle down here, gonna keep going. However, if we're making major changes in the maintenance phase, we still have to do the exact same thing or still graphic heat going all the way back and redo everything to make sure that the all the documentation everything is supported within the waterfall model. So the waterfall model is one that is very, very like I said, predictive. It is something where your team must have coded this before for it to be successful. Now with this, it is also very efficient and it is very simple to use. So there's a lot of overhead. So again, if you're creating multiple websites or something like that, then this model is probably something that is gonna be good fear team, because I don't have to spend a lot of time actually thinking about the software design process. They can use a process that's already been designed with a whole bunch of steps, and they could just work with that now with the waterfall model. We also have this issue of this cost over time to fix. So let's say each of these of the different steps, so you know this is once the requirements are finished. Once the design is finished, once the implementation is finished, once all the testing is finished, what's deployment is finished and so on again, it could be different steps. But the importance of this graph is to show you that as you go farther, it isn't just a linear cost over time, meaning that Oh, if we fix it, if we have to do something here, it's just all of this combined to get back to this point. It's this sort of exponential thing where if we make a mistake and we find out about it, maybe in the implementation or near the deployment phase, it's going to take a substantially more time than if we fix it in the requirements phase maybe up to 50 times the amount of time to go back and change everything to get it to work again. And because of that, the waterfall model is not flexible at all. Each step must be extremely well planned. We must basically make sure it's all perfect, and some corporations will do this, and it actually is very, very sort of. A lot of programmers will sit around and twiddle their thumbs, waiting for the requirements or something to be passed through a whole bunch of different committees to make sure that it's perfect and so those there could be some time loss in there as well. But it needs to be extremely well planned. And it's going to take a while to get the product on the market. If we do something which we're gonna talk about later, something more, more iterative where we sort of create a V one that's really basic, and we start adding features with the three and version for inversion five. Then we get the product out really, really soon. And then from that, we can, you know, start building onto it, and I don't know why, but a snowman sort of came to mind here, and we can actually get a product out that, you know, sort of start working for that. We can get feedback from that weaken beta test that we can get money for, but with this were doing it all in one shot. The first version of the product is probably going to be the final version of the product, and because that we might actually miss our market opportunity, Maybe if we had gotten out, you know, half assed many features three months earlier, it would have been far more successful than being three months late with all the features, and something that's very important is that technology moves fast and what this? We won't be able to adapt to new technology. So if we're in a fast developing field, like, for example, cars where you know car software is really developing pretty quickly things same with, like, Internet of things software, you know, like smart watches or like smart shirts or whatever. That whole market is developing really fast. And new technologies are coming out 68 maybe one year at a time. And so because of this sort of quick iteration, because of, you know, the yearly or maybe even like monthly iteration of technology, if we're building a piece of software that takes two years to build, and we're not gonna put out anything in between those two years, By the time we get our software out, the technology may have moved on and our entire project is obsolete, so we need to take that into account as well. But the waterfall model. Because of all this, it's decently bad in a lot of areas, but it shouldn't be written off immediately. It does have its benefits in more organized structures and places where teams are creating the same things over and over, and it does have that efficient, low cost to run sort of idea with it. But this is the first model, the water for model. It's very important and a lot of things are based off of it. 3. 1-2 V Model: So the next model we're talking about is going to be that of the the model. And the V model is sort of an improvement on the waterfall model. Or at least it takes care of a problem that people noticed with the waterfall model. And this V model basically takes the water fall. So the waterfall being, you know, the down, that down, down and down and it takes it and it bends it on this sort of implementation down here, and it brings the testing up to the right side, and then deployment is just sort of like maybe the next step to the right over here once all this is complete. But what this model does is it works this way. So don't think we're going like this and then back up the right side. What we're doing is we're working basically on these layers right here. So we have this top layer, which is this connection between requirements and acceptance testing than design and system testing, architectural integration and module and unit testing. And the reason we do this is because remember in the last lecture, we're talking about how there was a problem with this in that testing is the situation where we find bugs, right? Well, if we find large bug, we have to go all the way back to fix those bugs. So we have to go. All of active environments designed the implementation to fix those bugs. Well, someone died. Well, if were, if this is the step where we find the most bugs wouldn't make sense not to put it at the end, but near the beginning and do it at each step as we go down. And that is what the V model does. So with this, we have each step, and then we have testing to verify that step. So there's right side over here is basically verification verification. So the right style is going to be us verifying that each one of these steps are actually good before we move on. And this right side is just what we've been doing. That the design now with this model, we took this design portion and we actually broke it out into its sub components. Remember how we talked about architecture and they different modules and then design as a whole? So that's what we're doing here. We're taking this on were actually breaking it out so that we can have different parts to test. So the 1st 1 is requirements with requirements. What we have is we have this idea of acceptance. Testing, acceptance. Testing is testing to make sure the requirements are exactly what we want. An example of this would be to just come up with the requirements and try to almost create simulations or potentially come up with documents that would detail each use case. So how exactly are we planning on having the user used the system? And then we're basically trying to almost simulate what a user would do and see if it's going to accomplish those tasks. So we look at the requirements. We try to create a user that would use it and see if there's something that we missed, something that we're not understanding. This is usually done with the client to make sure that again it's acceptable, were doing what we want to do and therefore will be an acceptable solution. The next step is the design, and when we talk about design like this, we're talking about the entire system designed, so we're talking about that really top level or we say we're gonna have this section, this section, this section in this section and maybe just a little bit, like, perhaps communication here and communication like that. And this is gonna be the whole thinks This is the design of the entire system as a whole. And the once we get that, we're gonna do some system testing, maybe make up a couple of test cases right up a little bit of code just to see and make sure that this design is working properly. Then we go one step farther. We actually break into these. We start designing architectures, figure out all this stuff, works and then we do integration, testing, making sure that this all works together and then that it works together, still with the other ones. And then we do all the way down to module testing, which is where we break up these into the tiny modules, the bits of code that are actually communicating with one another. We do that idea of unit testing, which we talked about, and then we sort of go maybe back up the chain to make sure that the rest of it will work with everything else because of all of this because we've done all the testing in this phase. Once we get to implementation and we coat it, we're done because the testing was done throughout the entire part of it. And now we're sort of guaranteeing that we don't run into this, this big area where we're going to have a lot of bugs that will find them sooner and therefore will reduce the cost because instead of finding them maybe up here on the the cost timeline, we find them down here. And we're trying to make sure that we find them before this point, and they don't end up cascading all the way up to that point. And so that's what the V model is all about. It's a sort of a next step on the waterfall bottle. Now the only con with this is that there's more upfront work in that. Every step we take, we have to come up with entire testing algorithms. Remember, we're talking about testing. Testing is difficult. It's something that is not very easy to think about and also not very easy to implement. So with that in mind, we have to understand that because of the way we're doing this, we have to test that every single SEC section here, and that means that we're going to have more upfront costs. It's gonna be more difficult. It's gonna be slightly more complex to manage this software. But it's great if we are maybe not 100% sure, we have sort of an idea of the way that we want to go, but we're not 100% sure on the on how to get there in that situation. We want to use the V model so that we can take steps to keep testing it to make sure that we're walking down the right path. 4. 1-3 Sashimi Model: the next model we're going to talk about is this a Sheemie model? And this model sort of was built off of an idea that maybe we didn't think about at first. But when you think about it, it's very practical, and that is that in each one of these phases, we don't necessarily have the exact same engineers. So a lot of times we are under the assumption that maybe we have one or two engineers and they're going to do the requirements and then design and then the implementation in the testing and deployment in the maintenance. But usually what we have is, especially in larger companies, is we have specific engineers that do things like the requirements that do things like the design, whether it be the back end or the front end, that we have implantation engineers. We have testing engineers, we have deployment and maintenance engineers. And because of all this, we have this issue where if we do it step by step, like in the previous examples with E V model and the waterfall model, all of these engineers, it down here have to wait until the previous step is completed, and then once the previous step is completed, all the engineers and the top are waiting once again. So you get this sort of area where a lot of your workforce is sitting around waiting for other work force to complete their tasks. And so the sashimi model, we have the ability to draw these lines down it. So basically we cut it up. So it's the sashimi model. If you ever had sashimi, it's a, uh, a dish of basically raw fish cut up, and it's usually laid out on top of one another, like so usually over one another. And that's why this is so. She me model is because you have these pieces all laid on top of each other, and then you basically cutting down two different categories here. So if we you go ahead, we couldn't draw these basically slices here and what this is. These are the different phases of development, and we would, of course, maybe make these phases like maybe we have one month objectives or two month objectives. But essentially what we're doing is were doing a little bit of everything in each one of these phases. So with the requirements and this graph we're going this way. So time as we go through time, we head this way. So as when we start, we you know, we start with the requirements, the design and maybe a little implementation, maybe a little testing here and then the next phase. We're still working on the requirements and the design and now a lot of the implementation . But we're also getting our testing and our deployment are maintenance. Engineers involved the deployment. Engineers are figuring out the best way to play it the maintenance or maybe creating systems. Maybe there were putting out test models or betas. That these guys are working on is well, and we keep doing this with each step. So in the next step over here, what we do have is we're now doing everything. We're slicing all of it at the same time. And then down here, we slowly taper off until we're just in the maintenance phase. And again, this helps us because it allows different disciplines to begin working quicker and also shortens the development time instead of having to wait. Let's say, if it was, you know, appear two weeks. So this is amount of weeks 23456 and seven weeks for each one of these. After this task is seven weeks to complete, this task would take five weeks. Imagine if we did these one at a time that would be two plus three plus four plus five plus six plus seven. Or what we can do is we work on them all a little bit, and we all are basically starting them almost within the same week. So the total time will probably come out to someone around seven or eight weeks instead of adding all these together. And that's a lot of the time safe there. Now, the issue that we might have with this is it may result in air and redesign. What this means is just like what? The waterfall model. If we find an air, ATT's some point, we're gonna have to go all the way back, and the error is mawr prevalent in this situation, and that's because we haven't finished the requirements or the design. Yet. By the time we're implementing and testing, which means over here we might find something that needs to be completely reworked and everything back toe, maybe like this over here needs to be reworked. And because of that, all of the work we don't Onley just have to rework the requirements. We now have to rework everything that the requirements touched. So everything down here, we're gonna have to rework. So it sort of opens us up to this, this potential where if we don't think about this and if we are a little bit sloppy and having air late, we're going to have to do a whole lot of reworking and it can actually turn out that it will make it slower to develop this way if we have those airs. But if we don't have those arrows, we have great work for its utilization and efficiency and we have really shortened the development time. 5. 1-4 Incremental vs Iterative : So for the next couple of models, we need to understand a couple of terms. So that makes sense. And this is gonna be this idea of incremental verse. Iterative and incremental and iterative are pretty similar, except that they have a sort of different way of having the in product. And what we mean by this is that they both advance and move forward to the final goal by building onto an original product. So there is something that we started with and we're building onto it. However, with incremental were building over time. Think of like an assembly line where we're never getting to the final product until we're at the final product and an iterative where we actually build many final products and keep making new ones that are slightly closer to our final product. But that almost fully function. So let's go over the to hear a little bit more in depth. So again, our 1st 1 is incremental. Build steps over time, assembly line we have, you know, we start off with a car and it started like a frame, and then it moves to, you know, the outer side of the interior than maybe the engine, etcetera, etcetera. Maybe we were talking about building a computer. So we start off with, you know, the case, and then the next step, we send it to the people who put in the motherboards. So we have a little mother board in there, and then the next step, we send it to the people who are gonna put the CPU in. So now we have a mother board in the CPU and next step. We now have a mother board CPU, and then we put some ram into it, and so on and so on until we have a Finnish computer. But notice that at no point during this do we have a computer which can operate. There's there's nothing where we're actually going to basically have something we can give to a client to see how it's going. We're building at over time. We're giving it one step to the next to the next. And that's what the incremental model is is. We look at these steps, these goals that we want to accomplish, and basically we build up to that goal and we have these, like almost many projects to build it from this state to this state. So let's say ST 123 and four. So we're building it from state one to try to get it to the beginning of state to then we go from state to try to get to the beginning. Estate three and we move across, like so now with the iterative model were building prototypes, and we're adjusting it with new prototypes. This would be like if we build a car and we built a really, really bad version. Maybe with, like almost, you know, steal seats inside. So there's not not even like padding on the inside. It's just this steel seat inside of this. This car, it's got a couple of wheels on it, and that's pretty much it there. It's still a block to We haven't even designed that part. But the next one, we actually start refining it a little bit. Maybe we add a little bit of a shape to it. So instead of this sort of blocky appearance now, we actually have ah better part of the aerodynamics into it. We had, you know, better wheels to it. We had better seeding, and then the next part we had the luxury features. Maybe we had something else and so on and so on. But each of these products are all going to accomplish the tasks at hand, meaning that if we have this product rate here, it should be able to do basically everything that the final product should be able to dio. However, this product right here is gonna be a worse version of that. It's gonna be using cheaper part. It's gonna be where the design isn't fully implemented. Maybe some things are experimental on this. We're testing some things out. We're testing the wheels on this, for example, but we should still be able to operate it. We should still be ableto show it to a client. If this is, ah, software on each of these sides, this one, we would never be able to show to a client until this portion here, we could maybe show it once it gets almost done. But definitely not in the beginning. While this one rate after we finish the first prototype, we should be able to show this to the client and say, This is where we're at right now, you know? Come on, let's take a little test driver let me show you how this program works. Let me show you some of the little details of the program. And then the next time, maybe they're gonna give feedback and that'll go into our next generation. We're gonna make some adjustments and show it to the begin and again again. And that's the difference between incremental and iterative. It's an important difference. They sound a lot of like, and they're very easy to confuse, but understanding that is important for some of the next steps. 6. 1-5 Incremental Model: so the incremental model uses that term that we just talked about, which is incremental, were implementing passed something. So with incremental model, what we do is we basically complete the software development process multiple times throughout the course of development. However, with each process, we have a certain goal in mind. So we have, for example, the gold to, you know, build the back end or build the front end or build a for mount. Build a page out and we go ahead. We create the requirements to design the implementation, the testing and then we deployed into what our final product is going to be. So we basically go into the first increment. Once that's finished, we'll go into the second or it doesn't have to be. Also, we don't have to finish this to get to the second. A lot of times will move to the steps and then once we're past, for example, the implementation we go into testing unemployment will begin. The next increment will begin the next phase of development, and this allows us to sort of have this little bit of overlap here, which again allows us to keep working at an efficient pace, and throughout this process, we're slowly building towards the end product. The's increments also allow us to show off final parts of the design. So if this for example, was the front page and a couple of forms, we could send that off to the client and say, Does this part of it look good again? This isn't a finished product. We can't have them test out the entire thing and give us feedback to change the whole thing . What we can do, though, is given a little bit of feedback on the current parts and pieces we built and see how, exactly they like those parts and pieces. So we build the front page and a couple of farms in a couple of pages, and that's our first increment. Once that's done, we can send to the client for feedback and then move into the next phase, uh, with any of those changes, or we have created new phase about actually changing anything that the client had problems with, and with this we have this idea of being able to sort of put these gates throughout the process where we can keep going. We can keep producing, but We can also keep getting feedback to see if the product and the project is going in the direction that we want it to be going. It adds a little bit of adaption to the process. Remember predictive and adaptive. This allows us to get a little bit farther over into that adaptive side where we can actually move and adapt with what the client is thinking and with the way that production is going. This also adds layers of those feedback which helps us out as well. A negative side of this is again reworks. If we do need to do Major reworks here, maybe we already begun developing with this in mind up here so we might have to change some of the future developments. Change the requirements on only here but here and here, which would change the whole bunch of processes later on as well. We have to go backwards and rebuild different things. Another thing is the cost. The cost to run a whole bunch of different increments is going to be a lot greater. Not only are we going to have to have this overhead of managing this thing, we're also gonna have to have multiple teams toe work on different increments because the same team that's working on this increment to finish this one out might not be the same team that can work on this. Otherwise, we sort of go into this linear thing or we're just moving from one to the next the next, and that can be a process. We can do an incremental process where we do just move from one to the next. But we lose a little bit of the benefit when we do that, because we lose a little bit of this speed and stuff. We gain through this, but that is the incremental model. It's a great way of sort of packaging up different design processes. And what's neat about this is that in each one of these processes, we can actually use a whole different model. So this could be the incremental model, and we could use the waterfall for this model. We could use the the model down here, and we could use a she me down here. It doesn't really matter because they're all little individual products. But the incremental model is important, and it's a very good building block for other models in the future. 7. 1-6 Unified Process Framework: So the next model we're going to talk about is actually not a model, but more of a we call a framework, and the reason for this is that we can actually use models within this model. So throughout this process, we can use different models like the waterfall model or TV model. Is that see me throughout this entire every single step with in here? And so we're not sort of constrained to a single model, were basically have a game plan or a overview of what we're trying to get done. And then from this we use models to accomplish those tasks. So this is the unified process framework. And there are a lot of deviations of this probably maybe upwards of 20 different deviations of people who have looked at this and tried to come up with one that solves a specific problem. For example, there's one called the Rational, Unified Process model. There's one that's a very lightweight one. There's one that's specifically designed for more things like Agile. There is a lot of different iterations because this is a very good way of capturing the idea of software development and then sort of giving a really Ni overview of it. So this is sort of the graph over here on the left of where we spend our time. We have these different phases called inception, elaboration, construction and transition. And these right here are sort of basically placeholders. If you're in a company, you would create your own eyes or ease or sees Ortiz and each one of these would have a goal at the end of it. So in each construction phase, you would put a goal at the end of the phase. And that's how you know, if you've moved to the next phase of once, those things have been completed, and this is just trying to give you an idea about how this process works. It's on the inception phase. We are determining the feasibility of the project. Can it be something that we can build this even possible? We look at the potential project schedule and cost. Try to estimate, you know, how long is it gonna take? How much you gonna cost the company? What's the return on investment? Then we decide. Do we want to buy or build it? Maybe there's a solution out there. Maybe there's a partial solution out there that we can purchase the partial solution and build from there. We need to look into that in the inception phase as well. And then the delivery ble or the goal for this is to try to get some lifecycle goals, try to figure out the plan, figure out where we're headed, what the costed, who We need a higher stuff like that. And that's in this inception phase, and you'll see that we have these sort of the what we've been talking about this whole time down the left side. Here we got the requirements to design the implementation and testing and deployment here and then this idea of business modelling, which is just that idea, you know, costs and people to hire and things like that. And so you'll notice that in the inception phase, what we're doing is we're doing a little bit of requirements, sort of maybe giving a rough sketch of what we're trying to create. But really business modelling, we're figuring out is this something that our company wants to spend the time and the resource is to build, and that's important because we don't want to build something that isn't gonna make us money in the long run. And this is a great way for risk management. Instead of jumping into a project and spending a whole lot of money, we spend a tiny amount of of sort of exploratory money up front and figure out if this is good for us once we're out of this phase. Once we have an idea, we have some check marks who say, Yeah, let's go ahead with it. We move down into the elaboration phase, the elaboration phases where we take this idea. This and this idea that we had an inception and we build it out, we come up with their requirements. So this is where the requirements come in heavy. Here we address the known risk factors. We verify and validate the system architectures. So in that case, we're actually going to potentially build the very core prototype code for testing. So we're gonna build a very, very loose sort of idea of code that's going to talk to each other. It's sort of gonna do what we do have, but it's basically going to show us that it's possible. Basically, proof of concepts is what we call these. So we're going to type out some code, see if it works the way that we think it's gonna work. And from there we can really start, you know, elaborating it on it in the construction. But in this phase, we're doing just a little bit of that. And that's why you can see the implementation goes up here. We're starting a little the implementation again to try to figure out Can it be done? And if so, in what way? We're doing a little bit of testing because we need to see if it's doing what we think it should be and then deploying. We're deploying it to other people were giving it to testers were showing people that, hey, this proof of concept actually does work. And then this is heavy and the analysis and design as well. So we're building use case diagrams and class diagrams and architecture diagrams, etcetera in construction with the construction. What we're doing is we are building the thing. So we're actually working strongly in the implementation here. We are going to put all of our resource in this, and this is the longest and the largest phase of the project. You can see by this that they elaborated with multiple see values here, multiple different phases and sort of ways of going through this. This system is built on the foundation laid out by elaboration. So we've built this sort of architecture, this very small model or maybe even a little project. And from that we're going to build out from there. Features are implemented in short time box iterations. This is important. This means that we're building out basically fully working in products without features. So we have, of course that you know, it starts off with the box, and later on we add the features like it's a car we had the wheels and later on we add, you know, the windshield, etcetera, etcetera. But what we're doing is we're starting off with a workable unit. So here, you know, I mean evil. Quit out. We could put, you know, square blocks on here. It's still a car. It still is able to be driven, but over time we're making it better and better and better. We're adding more features were getting a little bit of feedback, and we are adding more features because of that feedback and making better and better iterations. And this is getting along that idea of it aeration. Remember, intuitive and incremental Will this actually accomplishes a little bit of both in the tiny parts here. What we're doing is we're incriminating. So we're doing one doing tiny increments up until we make an actual iteration. Once we finish generation, we deploy it, get some feedback from it, and we start again into tiny increments until we get to that iteration and so on and so on and so on. And the deliver What? Here is a continual stream of improving software. So we're gonna have, you know, this is where we have the version. You know, I believe it usually starts with, like, 0.1, that we get 0.20 point three etcetera, where we actually start coming up with these version labels as we get better and better. And finally we have this idea of the transition. The transition is where the system is deployed to target users. Feedback is received, refinements are made and the deliver bull is once this is complete, the final product is complete as well. So in the transition phase, most of our design is pretty much done were winding down. Deployment were refining and making sure the business modelling and requirements are completely find. The testing phase kicks up here, and we really begin the deployment phase where we give it out to people and see what they think about it. See if there needs be any changes if we need to make a couple of more iterations on the final project. And so, with that sort of idea with this idea, we have a framework on which we could sort of create our plan. So this isn't something that you know you can look at. And there's gonna be a 123 guide on how to create a unified process framework for your project. All it is is it's just these groups and this sort of outline of what you should do. And then from that, you have to develop an entire plan for your project. Because of this, we have certain pros and cons associated with this. The pros are it's adaptive. Its quality and reuse focus. It's focused on risk management at every step. We're sort of re evaluating the requirements, figure out if we do need to keep continuing or if we should abandon the project flexible doing corporate. Other models we can, like I said, include other models and areas in each one of the steps each increment. We can change up the model entirely and work from there. The cons O r If you looked at this and said, Well, how do we actually implement that? Well, the way that you do it is you need a whole lot of good managers and skilled people to come up with this plan from beginning. It isn't easy. Isn't something where we can just look at it and go, Yeah, OK, let me just get out a piece of paper and write this down really quickly. It has a lot of overhead, and that makes it very complicated. It's gonna have way too much overhead for small scale projects if you're gonna. And small scale is something even as, uh, as big as, like, an app like an application on the APP store that just as a single task, let's say maybe it's a game on the APP store. That might be too small of a scale for this to actually be ah workable framework to use. And so That means you have this really large thing where you don't have a lot of projects that fit in this. We're talking really, really large projects or projects which have a lot of different disciplines involved. You know, things that contact servers and different AP eyes and things that are built on the front end and the back end and all these different things. That's where you might this might be justified for. But for a lot of projects, this is way too complicated and also because of the way that it's designed because of this way of where we're doing all the phases at once, and we're potentially working on different models and it orations all at the same time, it's gonna need more. Resource is running. The more programmers, more managers, more testers. Mawr Uh, basically everything more money to get this thing done, and the timeline as well is probably gonna be pretty fast, but it's gonna cost a whole lot, so we have the way. That is the speed of it important due to this cost. But that is the unified process framework. I definitely go look this up on Google or something on, and look into it a little bit more because there's a lot of different variation of this, and they're all pretty meat and meat and good to understand whenever you're learning about software engineering. But this is a very important thing, and this is actually one of the most used frameworks within the industry today. 8. 1-7 Spiral Model: So now we have the spiral model. The spiral model is just that it is a spiral. What we're doing here is we are constantly going over the same sort of areas of of development over and over and over again to ensure both that we are hyper analyzing the risks or analyzing at every single step. And we're making sure that we are going and validating what we're doing as we go forward, there's a very risk oriented. We're trying to advance forward with very small steps and making sure that we have this idea of go or no go. Meaning. Do we want to continue the project, or do we want to scrap it here? It's very good for experimental ideas, ideas that you think might be possible, but you don't really know yet, so we sort of take these little steps forward and make sure that we don't go all in on unedited point. We just want to make sure that we are analyzing the situation, analyzing what we've done and proceeding if it still is feasible and a good idea to proceed . So what? The spiral model? What we do is we start in these quadrants and we move through them continually. So this is quadrant 123 and then four. And what we do is we go. 123412341234 Like this and what we're doing as we keep going out farther and farther is we're expanding the scope, the cost, the the in depth nous of each step, the overall time we spend on it. So it at the very beginning, we're creating quick prototypes. And then as we get out, it becomes slower. We look at it more. We put a little more analysis into what we do. More tests until we get to a final product at some point. So let's say we start here rate in this part, which is we're gonna determine objectives, alternatives and constraints. So here we're determined these objectives, the alternatives that constraints were determining everything that the project is, we're basically coming up with a plan. From there we move over and identifying and resolving risks. At this point, we're just pretty much identifying risks. There's nothing to really solve since we haven't coded anything and we come up with a prototype which in this situation is just a plan. Then we actually start executing that plan, the concept of operation. So here we may have instead of actually coding in this initial first phase, maybe we create, you know, class models. Or maybe we sort of come up with a general idea about how the concept is going toe work. And that's why this is a concept validation. We haven't even made it into the requirements and stuff like that. We then create the or we look at it. So we play in the next generation. So we've come up with this concept that come with this general idea of how a prototype should work, analyze the risk. Now, we're gonna come up with the requirements plan and lifecycle plan. How are we actually gonna develop this? How we're going to come up with a solid set of requirements and then we planned that, and that's on exploration. So now we're coming around this here, do another set of risk analysis is it's still something that looks like it's feasible with our costs and our budget and our manpower. If so, we build that next prototype again. This could just be an iteration on the plan. Overall, it doesn't have to be an actual working prototype. It is just sort of maybe the documentation is a little thicker here. We then move on to the simulations. Eso are in this particular situation. We're doing simulation models or benchmarks. That's his whole area. So we're sort of just in here extending what we're doing. So in this particular loop were probably doing software requirements, requirement validation, things like that, we just coming up with the general plan of it. Then we actually come up with a plan for the next phase, which is development. Move over here, do the development of verification, Do the risk analysis to the integration movement. The next phase Do risk analysis, Look at an operational prototypes of something that we can actually give to someone doom or benchmarks testing and then release. And this is a very, very sort of basic model. There might be ah, lot of loops, and between these, especially during the development phase, we can make this sort of an iterative model in that sense. So here we just had a single loop where we basically coated the whole thing, and it moved on, but there might be a ton of loops, and there there might be, you know, 100 different little. It orations within that development process where we're constantly checking risk and planning our next phase, constantly going over the objectives and constraints and moving outwards from there. And this is a very, very powerful model because of that risk focused thing is very good if we're, you know, taking steps forward in a unknown area, and it's very, very adaptive. So again it's it's along that idea of. Instead of going straight line, we might have to move around to get to our objective. This is a great model. Do that because we're constantly reevaluating what we're doing, looking at what we've done in the last cycle and coming up with a new idea for the next cycle. Now this looks complicated, and that's because it is complicated, especially in designing this for a riel project. It gets very complicated, and it costs more to manage. You need to have a very good idea of what you're doing to keep everything in track so you don't, you know, start off with a spiral and they just sort of like, Okay, we're just gonna coat it and, you know, not actually go through the testing and the implementation and the constant risk analysis. And you also need more constant stakeholder engagement. What this is the stakeholder is like the client, the person who's paying for the software. You need their constant engagement in this. If you're going to go with the options for go or no go, which means do we continue, or do we abandon the project? You're going to need their say every single loop. If these loops are, let's say every five days, maybe there every two weeks. Even you're gonna need that stakeholder every two weeks to come to a meeting, sit down, learn about what you did this previous week and then decide whether they want to continue or not. And this could get a little bit of tedious for them. So you need stakeholders which are prone to that which want to be engaged with the project . A lot of times they don't. They just want to pay the person have it built, they don't want to actually be involved in the day to day process of it. But if you have all that spire model is a great model for that risk. Management is great model for building things that need discovery, where you're trying to take small steps forward. 9. 2-1 Agile Introduction: Now we've gone over a couple of the more traditional areas. I wanted to go over something that's very sort of new. I mean, when I say new, it's within the last 20 years. But it's something that a lot of companies have switched to, and that's this idea of the agile methodology or the agile. In general, Agile is a way of thinking. It's a sort of a set of principles that you apply. And then we're gonna go over a bunch of different models that work with the agile methodology, things like Scrum and Kon Bon and other terms that you might have heard because they are more prevalent in today's industry. The old ones, they weren't bad. It's just There were slow. We were developing products from point A to point B. So we started. We went straight across and we made it there. Now sometimes, you know, maybe we deviated up a little bit. We had to come back down and we found our end objective. But that's about all that we could do with the old ones. In today's moving market, things change. Ways of developing technology are changing every single day, and because of this. We need to make sure that we're developing the software that solves the problem. The problem itself might change. And because of this we have this idea of this agile sort of manifesto and this set of principles that allow us to be really, really fluid and flexible in our development process. So that means that we can come up with ideas that make us go in completely different directions and will keep developing with the client until we find exactly what they were looking for. And with the typical model, it would be very hard for us to keep moving this. We'd lose lots of money, but with this we actually take it in little increments and we can keep moving at every increment in the right direction and over time we begin to develop the correct software. So every decision we make, we slowly get to wear. The client is happy or constantly communicating with them to build their end product and to the waterfall method or the waterfall sort of set of ideas, which is sort of everything in the previous example that that set of, you know, we first do design and then or we first do requirements and then we do design and then we start implementing and then we start testing that sort of idea. Where we go one to the next to the next has issues. One of them is during verification. A lot of unexpected issues arise. We, for example, if we coded a bug into the architecture and we're in the verification before we find that out, there's not really any where we can go with that. Or if we get to a verification, we show it to our our clients. And they say, Oh, no, that's not exactly what we wanted But there was a little bit of a miscommunication. This is what we wanted. Well, there's no way to go back and we didn't really have an opportunity to fix that beforehand with Agile. It has some solutions of that. Software systems are complex and can't be 100% predicted. This is something that's very, very true is that if we are hiring someone to create a nap, we might not know exactly what we want. The app to dio. We want to communicate with them over time to slowly build this application to build it. The way that we want, and we want them to help us in finding out what we want in an app, because they're the ones who know how to program. They're the ones who know how to create things, us as the idea. People don't exactly know what we want the app to do and what's capable. So we wanna work with someone very, very smart. A technology company that actually develops apt to come up with the final idea and an agile methodology helps you with that. By the end, some software didn't meet the original or modified requirements again. If it's not very flexible, the requirements may have changed over time, and we want to be flexible so we can change with them and then markets move over time. The product could be outdated by the time we finish. Ah, lot of the agile models actually have this idea of coming up with an M V P or minimal viable product, something that we can get out to the market, you know, within four months something that we can throw out there that has just the basic features but nothing else. And we can actually start getting user feedback and we can start solving the problem. Maybe not 100% but we're at least solving it a little bit with this. With the waterfall, it's typically we don't get a product out until it's completely 100% finished. And because of this we have this really big problem of it might be outdated. Let's say it takes two years to develop this software fully well. The problem could have already been solved by another company in that time. The problem could have changed over that time. Ah, lot of different things can happen where we could become outdated by the time we finish and then all that money is wasted. So we want to make sure that we can be flexible in situations where we know the markets are constantly moving. And the agile manifesto was sort of this. It's a group of engineers got together and they decided change was needed. Together they came up with the agile manifesto which we're going to discuss in detail in the next lecture is a set of ideas to develop better, quicker and more agile software. I supposed to improve the system overall, and a lot of companies have found that it does just that 10. 2-2 Agile Manifesto: So now let's actually talk about the agile manifesto. We mentioned it in the last lecture, but let's go over it a little bit more in depth. The important thing to understand about this is agile is a set of guidelines that set of ideas that we then develop models with. So there isn't an agile model out there. There isn't an agile development process. There is the agile guideline, and then we create models based off of the agile guidelines. Something like Scrum, for example, is a model that's based off of these guidelines. So scrum is the model we would develop in scrum. But scrum is an agile model, and that's just something important cause a lot of people get this mixed up. They say, You know, we're developing an agile when that's technically not true. What they're doing is they're using a model that's based off of agile, so agile again is this manifesto. It's this idea. It's his set of guidelines that we use to developed software, and we can actually, if we want, we can put these numbers right here and they're different sort of tenants or different ideas and guidelines. Instead of engineers, they Basically, the story goes that they basically came together and they came up with this. I think it was somewhere in the early two thousands. They all met together and they decided that software engineering in general had an issue. There was a set of problems, and it was mostly because software engineering came from regular engineering. It was designed as a almost a direct transition from, you know, like building a bridge and people thought, OK, we'll build software the same as we build a bridge. However, software is a little bit different, and there are slightly different requirements and ways of going about things when you talk about software. So they got together and they thought, Let's come up with a way that would better the entire software development industry And together they came up with these four tenants and a lot of companies use these for tenants nowadays because they are basically a very, very good way of doing business. They increase productivity, they increase customer relations and overall increase profit, which is what companies air going for. So the 1st 1 is individuals and interaction over process and tools. So this one is focusing on the individuals and the engineers and everyone involved in building the software over using some tool or some process that we've used in the past and a lot of companies. Whenever they sort of develop or they go in a way, they get a set of processes and a set of tools that they use. And if a team of engineers come up to a lead and they tell them, you know, we think these tools and processes would be better. A lot of times those ideas air shot down because it's the way it's always been done. Those old processes and tools are already in place, so why change it in this were trying to say that the individual should have more control over the way that they developed the software. If the the set of individuals come together and they decide that a new set of process, a new set of tools should be implemented to basically improve the situation than they should have higher priority over the old way of doing things, and we want to sort of also in this sense work, saying that the individual is more important than the process in the tools themselves, we want to treat the individuals with respect. We want to treat the interactions that they have with respect. We want to try to create a good work environment. We don't want to, you know, put people down because they want to use new software and tools it because they're slightly deviating from the current processes and tools. We want to elevate our engineers, and we want to give them the most respect as possible. Number two is working software over comprehensive documentation, and this is a pretty far deviation from the previous ideas that we've gone over the waterfall methodologies and the sashimi models and everything like that. And this is because it knows it was very focused on documenting and getting everything squared away Before we began developing here, though we sort of turned that on its head. And we want a working software before or at least as a higher priority than comprehensive documentation. Documentation is always important because it allows our software to be maintainable. However, there is a limit where if we have 15 books about how our software should work and how it's going to be built, we probably aren't going be able to show that to anyone and actually get any real feedback on that. We want to create a working software with a little bit of documentation. Maybe, you know, a medium amount of documentation, something we can give to the clients or two testers or the users and get actual feedback on that so we can make changes in real time. We don't want to wait till the very end to start getting feedback, realize something is wrong, have to change the whole software and then have to rewrite all of our documentation. It doesn't make sense. So we want to focus on getting software working, getting software designed, correctly, built correctly over documenting the entire process. Again, we're not saying we're give up documentation. We're just saying we want to give a little more focused to getting the software actually built, then working on getting it perfectly documented. Number three Customer collaboration over contract negotiation. We want to have a good relationship with our customers and our clients. We do not want to have to point to a contract every time a changes wanted or every time something needs to basically just move a little bit a lot of times with businesses. They get this contract and they'll point to the contract. Anytime something comes up and say, What's the contract say? Okay, we're not doing anything differently. We're trying to say is that the customer collaboration is what's going to get us that good final product. If the customer comes in and they say Okay, I love where the software is going But there's this new thing that recently came out and it's gonna be, you know, maybe this software needs a little bit of in addition here. Maybe it needs to be a little bit reworked there. We want to make the customer happy so that a they give us good reviews. They pay us properly all that stuff. We want to make the customer feel appreciated. We want to make the process really, really nice for them. If every time they come in and ask for flight changes, we say, Well, let's go rework the contract. We end up going into getting legal teams involved, readjusting prices and going through this whole thing. It's going to be a pain and no one's gonna want to work with us. So what we're trying to say is that we want to make that collaboration paramount to Oh, it were, at least over contract negotiation contracts. Again, they're still important. We're not throwing all this stuff out. We're just saying, Let's talk to the customer Mawr. Let's make a really strong relationship for we go and we just on. Lee worked with contracts for responding the change over following a plan. We want to be able to be flexible. We don't want to be locked into a certain plan, and every time an issue comes up, we say, Well, what's the plan say we're going to stick with the plan if we can't respond to change that we're not in and of its ent or in and of itself, agile, that the word agile were not being that we're not being flexible with our design process, And that's what Agile is trying to do is trying to create an empowerment of the people, actually build the software and making software that changes with the times because technology changes fast. We don't want processes that don't allow us to change fast with technology, so we want to give again. We want a plan, but we want to allow change that plan. We won't allow us to be flexible to move the software this way. In that way, whenever we collaborate with the customer, we're gonna build working software so that the customer can see what is going on, and they can give us ideas so that we can respond to the change. We want to have these individuals and interaction with both the customer and with our engineers so that new ideas, better ideas are presented. We can change our tools around, we can build working software, we can show it to our customer, and we can respond to change. And so overall, that is the agile manifesto we're trying to create. This set of guidelines that allow us to change and move with the Times toe allow us to develop software in a more optimal way. And agile has done a great way of classifying that in the next lectures we're gonna begin actually talking about the models that are based off of agile, and you can see you will be able to see how these are quicker and faster ways of development than what we've previously talked about. 11. 2-3 Scrum: So the first agile model we're going to be talking about is the scrum model, so scrum you may have heard before because it is a very popular way of developing software and Scrum focuses on these 1 to 4 week different little intervals. So basically they're called sprints and scram. It's a scrum sprint and the sprint is this idea of quick development, adding in the highest priority features, then going to the client, the stakeholders, everyone who's involved, showing it off to them, taking feedback and redoing the cycle. It's his idea of plan, build, learn, repeat. So we're going to do all of our defined design, build and testing within this sort of scrum sprint here. And this is where the ideas of like back to back testing comes into play because weaken used back to back testing to make sure that between sprints, that we're not breaking something from the previous one and to ensure the new features are working properly as well. So with every sprint, we're going to be creating a product that is slightly better better than the previous sprint. It's to its idea of basically prototyping it out. So every single prototype is gonna be just a little bit better than the previous prototype and a lot of times maybe after the third or fourth sprint we have a product that we can actually release into the market and then we begin. We keep developing, it adds. It's released in the market so we can get a product out in, You know, three months, maybe four months that the client can begin making money from can begin taking in these ideas about how to fix it and make it better. And we can keep developing it based off of the user interaction. And so the scrum is very popular because of that, it's very quick to develop very quick for the client to start making money, and it also allows extreme flexibility in the development process. So they're a couple of different people involved in the scrum process. We have the product owner and they are basically the stakeholders, everyone who's involved in wanting this piece of software, so from them we get inputs from the executives, the team, the stakeholders, customers and users and then the product owner looks at all of this sort of input and they helped prioritize the list of the next steps, what we should do for our next sprint. So we need constant communication with the product owner and this is a sort of a disadvantage because maybe we have a product owner that doesn't like to spend the time prioritizing what's next. They just want us to do everything. And if that's the case, the court tenants of Scrum fall apart because we're supposed to be basically creating this flexible design that works with the product owner. If he steps out, he or she steps out. We do not have that input and we start developing in potentially wrong directions. The scrum master. They hold the team liable to scrum ideas and they facilitate meetings and do conflict resolution to a little bit of planning on the side. And so the scrum meeting is basically the lead person up for the scrum model there. Another might be a lead software engineer as well. That's, you know, working with more the code but the scrum master is holding the team liable toe, make sure that they're following all of the scrum tenants and they're doing everything in the proper manner and fashion because if we fall apart and we stop, you know, adhering to our sprints. And we don't, you know, hit our goals during our sprints. Then the whole process again is gonna fall apart because we aren't going to have finished products to show to our client. We aren't gonna get that feedback, and we aren't going to be very flexible. And then finally, we have the team, and that is the team actually building the software. And this isn't just software engineers. We might have engineers lead engineers. We might have designers. We might have just basic coders that don't know a lot about engineering, but they're pretty good in a single language, doing a single thing. Ah, lot of times this could be outside hired help for a specific task. Maybe we go look on a freelance Web site. We hire someone just for this sprint to build us a module, pay the person, and then he's off for the next sprint. As we get more and more people, so there's the team can sort of change. But there are core people in the team, and there are roles, and they all come together to create the in product. This is a typical sort of way that scrum works is we have this idea of the product backlog . This is a set of, ah, list basically up things that need to be done. So we have, you know, this list of ideas and things that need to be done, the problem. We don't know how to prioritize that list. So a lot of times we will bring in the stakeholders well for the sprint planning meeting. So we'll ask them. What do you guys want next in this process? What would help you or what Would you like to see? What's most important to getting this product out? Once we have that idea set up, we create a sprint backlog where this is essentially the set of ideas that we're going to be working on for this current sprint. We set a deadline. If we're gonna do it in three weeks, right in two weeks, we'll do it in 15 days. We saw some sort of deadline to it, have our list of objectives and then we begin the creation process. So we start having these daily scrum meetings, which is essentially they're typically under 20 minutes. The scrum team comes together they talk about what they did yesterday, what they plan to do today and what roadblocks they're dealing with and potentially what steps they're going to use to fix those roadblocks. And this communication is important because maybe a certain user or a certain engineer talks about how they're dealing with this this roadblock with the database integration or something like that. Well, another engineer, mind you like Well, actually, I've done that in the past. I know how to fix this. Let's get together today and I'll show you how to fix this and to get past that roadblock. So this communication allows for different engineers input on different projects or different parts of the project, and to help one another out. They complete all their work the next day. They have the daily scrum meeting, and they keep moving forward. This also allows everyone to keep track of how close they are to finishing their sprint and to maintain or to make sure that they're on schedule for their sprint. Once the sprint is done, it goes into Sprint Review. Typically bring the stakeholders back in demonstrate the Sprint takes some suggestions, they asked a stakeholder, Is this what you were talking about. They say yes. Except we were thinking that this area should do this and that. We mark that down, we make those notes, and typically, this would maybe then go back into the product backlog. While we have the stakeholders here. We asked them. Okay, What do you want on the next spring? They tell us what they're looking for in the next one. They prioritize our list. We start the process over. Now, the thing is, we also do a sprint retrospective. So after we've done the sprinter view with the stakeholders, the product owners, everyone who is, you know, basically hasn't seen this product in the last two are 1 to 4 weeks. Then we go into a Sprint retrospective, which is just the software team itself. We talk about the process about how the last 1 to 4 weeks have gone and we see if their ways to do it better what you know, held us up in a sort of a team environment. And what held us up individually are there ways that we can fix that after a Sprint retrospective, we begin the next Sprint planning. Get all those lists and we repeat the process over and over and over again until the product is complete. So scrum it's great for its flexibility because we have so much review, so much feedback from our stakeholders were constantly getting direction on what we should do next. We're not over committing to something where we, you know, create this giant project and by the time the product is developed, it's completely wrong. Were making sure that we're doing these tiny little sprints, walking forward, step by step and taking in feedback, So we create the product that the client is hiring us to create. 12. 2-4 Kanban: our next agile model is that of combine. So if you know anything about the Japanese language, this is a very Japanese word, and the reason for this is it was actually developed in Japan. Its origins could be traced back to the UK in Spitfire development. Those are really nice planes that they developed Back then, however, it was popularized, refined and really implemented into the consumer market with Toyota and Toyota is a Japanese company. They basically took a look at the current process of making cars, and they wanted to make it more situated. So everything was available that the car makers in the factory could get. It was all available like it wasn't a supermarket and you could go up and grab whatever you needed to complete your process. Basically, they wanted everything for a person, do their job to be within arm's reach, and they wanted a board to track off the progress, look at the current flow and to keep improving the flow so they could make more and more and more cars, and it became very popular. It made toilet a very, very successful convent has been since adapted into the software world and it's the same sort of technique we want to popular lie or you want to refine our flow. I want to take the flow of cards of bugs of features, and we want to find out where the bottlenecks are and keep continually improving on it. And here's a little example of it. Ah, lot of software companies use something like this, so you'll have cards. The backlog is use of the one that's filled up the most, so you have a bunch of cards in the backlog, and then when we want to start a project, we want to start one of the cards. We just move it over. So let's say we have a couple in the analyze phase one in the developed phase, and then maybe we have four in the test phase and then two in the release phase. Just from looking at this, we see two things we see. We have a lot of stuff to go. There's still a lot left in this project, and we see we have a little bottleneck in the testing phase. There's a problem here. Maybe we don't have enough engineers on testing. Maybe our current testing or our current methodologies with testing are slow or they're not working properly. Maybe there's a lot of bugs or errors that are happening within testing because of poor analysis. We know just from looking at this that there is a problem with the testing phase and that we want to improve the testing phase and we try to do this in a slow, incremental way. We make a little change. We go through it again and we see if we're improving this. We were trying to grab these big numbers here. We're looking at what percentages in the testing column. Maybe right now it's something like 25% of all cards are sitting in here, and so we try to make some changes. We take a look at it in two or three months, and we try to maybe get it down to 15% better sort of distribution instead of, you know, they're being this large lump and then down and in this large lump and then back down. We're trying to, you know, make it so that it's perfectly level across so that development is perfectly moving across , and with all of this, we have a couple of core tenants. Here we have the Con Bon Properties and the CONVEN principles, the properties air, just sort of ideas and things that we might want to follow. While the principles are pretty much locked in stone, these are things that every time you look up, combine principles. You're going to get this set over here, and so we'll go over these first. So number one is start with. What do you know? This is important because the Kon Bon system could be implemented over your current system . It's a way of tracking progress and improving the flow of that progress so you can technically put it onto anything and keep improving the flow. You could even attach this to like a waterfall method in the correct way and see what's holding you up during that method with Khan Bun the first again, Let's start with what do you know? We don't want to throw out everything and start completely from scratch. What we want to do is we want to put this over, implement a little change. Maybe our changes were implementing a board like this so that we can actually start tracking progress and then we move from there. From there, we agree to pursue incremental evolutionary change. What this means is we're not trying to change everything at once. We're not gonna look at this and go what testing is obviously where the bottleneck is. Let's hire five more testing engineers. That's a major change. And it might cause other problems down the road. Um, or maybe a better sort of change that we might do is we might say, Hey, whoever is working on development, maybe we can have one of those guys every two or three weeks, spend a couple weeks and testing and jump back and forth. It's a small change whenever engineers is just gonna move rolls just for a little wit back and forth for a couple of weeks every month. And that then we contest is that helping? Is that hurting and will make more changes based on that. So we want incremental evolutionary change, not giant jumps. We want to respect the current process, roles, responsibilities and titles, and this is important because we don't want to completely throw out a system just because we think it might be wrong. We want to again make those small changes so We want to respect the current process. We want to respect everything that's going on with our current set up. We wanted to take a very serious look at them and only make small changes. We don't want to begin firing people and moving people all around. It creates this fear of instability within the project that will slow us down even more so we want to look at the problem, see how we can make it better and make those small changes. And finally, this one is sometimes added, sometimes not. But I think it's important encourage acts of leadership at all levels. What this means is we want to encourage our lowest of workers the same amount as our highest of workers, the lowest of workers, meaning they're just coding. They're not doing a lot of the design process. They're just making changes. We want to make sure that there are being honest and they're being forthright in the way that they're coding. We want them to make really good decisions. While coatings would encourage those acts, and leadership here doesn't have to mean that were actually leading other people, it can mean simply that they are inspiring others because there working very hard and they're creating very solid and very bug free code. So what? I encourage that at all levels and in some of the properties, some of the ways that we can get to these principles is one. Visualize the work full. It's very important with combine. We want to put it up on a giant wall or on a website, or where everyone can access it so that we can look at the workflow. And what is the problem with this? We obviously see that we have the problem in testing and we need to work with it. Limit work in progress. This is one of the major major keys in this is we want to limit how much work we keep going through. We don't want toe have all of this work all in progress because at that point everyone has spread way too thin and we're not making a lot of progress. We're not being able to see the flow because there isn't any flow. Everyone just stopped and Onley making very, very tiny steps towards the final product. We're still trying to make this a little bit agile. We're still trying to speed up development process. So whenever we see something like this, we want to stop any inclusion of backlog and try to work through the current bugs before we introduce anymore into the process. Manage the flow again. We want to look at the flow and want to manage it. We want to see where the problems are and what the change Those problems wouldn't break. Process policies, Explicit meeting. We don't want to just sort of explain to someone, you know, that's how it's done. This is how we do it, sort of like that. We want to have a piece of paper with all of our policies, detail that we can give the people we want them to be easier access and explicitly written out. We don't want any gray area anymore. We want something that's very, very explicit, very easy to find and very easy to follow that again. It makes so that all of our engineers were following the process and if we know that they're all perfectly following the process, we know how to change the process because of all the engineers aren't following our policy , it doesn't matter how we make changes to the policy, there's still not going to follow it and no change will actually occur, so we need to make sure that they're following it. The only way to do that is to make it very explicit, making sure that they can read it and to enforce it. Then we can make changes based on it and finally improve collaborative collaboratively. What we mean by this is we want to improve as a group would improve collaboratively helps bad right there. We want to improve together. We don't want to make just small changes top down, meaning the leader looks at all. It says we're making this change. We want to improve as a group. So you wanna have group meetings, Wanna have issues brought up, we wanna have, maybe bringing the stakeholders as well. And we wanna have these little meetings thes collaborations about how we're going to improve. Everyone should be involved so that we can keep improving the process because maybe us as a let's say, us as a program manager, we don't understand the problems over here and testing. So we try to implement it, you know, changes in testing by what we think testing is well, that's not going to really help us, because if we brought some of the testing engineers in, they're going to better explain to us why there's a bottleneck there. Maybe they're saying we're sitting way too much down the pipeline and we're not having enough people to deal with it. Maybe there's processes is in the end of the analysis state, where you're actually coming up with the design. Maybe they're errors in development. The developers are just their pencil whipping everything, and they're not making good code. We want to talk to the testing engineers and we'll talk to all the engineers to figure out that problem. And so improving collaboratively is a very big part. But common is a really, really neat sort of way of developing code. And it's a fun wait till look at all the visuals and to keep improving every single day basically 13. 2-5 Lean Startup: Let's talk about the lean startup, which is another agile model. The lean startup is very, very interesting, and it's something that's relatively new and something that you can really only do with technology. The lean startup is this sort of experimental way of building products. By experimental, I mean that literally. You're making experiments to see if your product can actually make money on the market. So what we do is we go to this idea of learn, build measure. Take those measurements we learned build, etcetera, and we're trying to create a product as fast as possible and as minimum as possible to see if there's a market out there. So what we do is we make some sort of assumption. We make a hypothesis if you're into the scientific method, and we're trying to figure out if this hypothesis or assumption is true. So what we do is we build an experiment. We build a website, we build a service and we see if people are interested in it. We then uses that interest as a metric, and we adjust based on that metrics. A very, very popular example of this is of the company Zappos, Zappos was basically founded in 1999 back when the Internet was just beginning to start taking up some steam. A lot of online shopping still wasn't very popular. Back then, however, the Foundered went to a local mall trying to find some shoes, and he couldn't find the shoes that he wanted. And that was basically it. There was either he bought shoes at that mall or he didn't buy shoes. That's how it was back in the day. So he thought, Hey, let's build a website that we can put in shoes from all over the place so that we can always find the pair of shoes that we want. So we went to the mall graphic camera, took a bunch of pictures and posed to them all on the website. Now, instead of purchasing an inventory up front, what he did was he built the website, so he made the assumption that people would buy shoes online. He built the website and then he was just measuring how many people would get sales. And instead of buying the inventory and building out the whole product, what would do is if someone basically placed an order he would look at the order. Figure out what should they wanted? Drive to the local ball by that shoe, put it in a box and then send it to that person. So is this very manual process. There was no inventory keeping. There was nothing except him being the entire business logic himself. It became very, very, very popular. He realized that he had something really large on his hands. His metric was confirmed that this was gonna make a lot of money, and because of that, because of the interest he was then open to investments. He was open to changing up his process in making it an actual website to make money. And it ended up being one of most successful all line businesses starting in the early two thousands. So through this process, this lean startup process, he was able to invest minimum risk to see if a proposition or a business idea was viable. And that's why it's very popular, because we can use this lean startup to do exactly that is to figure out if our ideas are worthwhile and they'll make money. So that's the lean startup. There's basically nothing else with this one. The way that you build it is You would use another one like a scrum style. Or you could use some basically just coding and hack way of getting something started and then you just measure it. And after you figure out that it's ah, go. So we have this idea of of go and no go meaning Do we continue? Adoree, Stop! If it's ago, we develop the software. We're using one of the other methods. If it's a no go What? We just stopped the product there and hopefully come up with ideas later on. But lean startup really interesting to learn.