0 00:00:08,090 --> 00:00:12,110 After watching this video, you'll be able to describe the Waterfall approach to software 1 00:00:12,110 --> 00:00:13,560 development. 2 00:00:13,560 --> 00:00:18,860 Explain the problems with the Waterfall approach, describe Extreme Programming approach, list 3 00:00:18,860 --> 00:00:22,430 of values of XP approach, define Kanban, 4 00:00:22,430 --> 00:00:25,310 and list its core principles. 5 00:00:25,310 --> 00:00:28,360 So, let's take a look at a traditional Waterfall development. 6 00:00:28,360 --> 00:00:32,820 It all starts out with a requirements phase. People are gathering requirements, seeing 7 00:00:32,820 --> 00:00:35,820 what the customer wants, making sure that we're going to deliver something that the 8 00:00:35,820 --> 00:00:38,780 customer wants. At least for that point in time. 9 00:00:38,780 --> 00:00:43,960 And so this is a phase where all you're doing is documenting all the requirements of the 10 00:00:43,960 --> 00:00:49,380 customer might want in the system. Then you move on to the design phase. 11 00:00:49,380 --> 00:00:51,329 Notice I'm using the term phases here. 12 00:00:51,329 --> 00:00:56,880 This is very important, because there was exit criteria and entrance criteria to move 13 00:00:56,880 --> 00:00:58,650 from one phase to the other. 14 00:00:58,650 --> 00:01:03,670 So once we've got all the requirements, we move on to the design, hoping that we have 15 00:01:03,670 --> 00:01:06,930 all the requirements that we actually need. 16 00:01:06,930 --> 00:01:10,840 So then in the design phase, the architects are designing. They're figuring out how do 17 00:01:10,840 --> 00:01:15,869 we take those requirements, turn them into working software, and so they design the entire 18 00:01:15,869 --> 00:01:16,869 system. 19 00:01:16,869 --> 00:01:20,270 And then once that phase is done, we move on to the coding phase. 20 00:01:20,270 --> 00:01:23,840 So this is where the developers are hackety hacking coding away. 21 00:01:23,840 --> 00:01:29,039 Now, you'll notice this is called Waterfall and those arrows are flowing down. 22 00:01:29,039 --> 00:01:32,599 because it's really hard to swim up a waterfall. 23 00:01:32,599 --> 00:01:34,649 This is an appropriate name. 24 00:01:34,649 --> 00:01:38,870 Because when you're in the coding phase, and you find out, this is a bad design, it doesn't 25 00:01:38,870 --> 00:01:42,930 work, it's real hard to go back up and redesign things. 26 00:01:42,930 --> 00:01:47,590 In fact, because we treat software development like civil engineering projects, sometimes 27 00:01:47,590 --> 00:01:52,310 some of those designers have moved on to the next project, and you've got to go find them. 28 00:01:52,310 --> 00:01:56,220 So very, very difficult to go back and swim with the waterfall. 29 00:01:56,220 --> 00:01:59,150 Then after coding, we finally get to integrate. 30 00:01:59,150 --> 00:02:04,470 So all along, we're coding in isolation, we're not integrating my module with the next person's 31 00:02:04,470 --> 00:02:07,820 module. You know, there's a time when all those modules come together. The first time 32 00:02:07,820 --> 00:02:11,849 we realized, do all these pieces of code even work together? 33 00:02:11,849 --> 00:02:15,459 And then we move on to the testing phase, because now we've got a system that people 34 00:02:15,459 --> 00:02:16,730 can test. 35 00:02:16,730 --> 00:02:21,760 And as they find bugs, they got to go back, swim up the waterfall, and open some bugs 36 00:02:21,760 --> 00:02:23,989 in the coding phase and do some recoding. 37 00:02:23,989 --> 00:02:28,370 And then if one of those bugs that they tested, turns out to be, you really need to change 38 00:02:28,370 --> 00:02:33,980 the design because these things aren't interacting well, way, way up the waterfall, very expensive 39 00:02:33,980 --> 00:02:36,569 to go back up to the design phase. 40 00:02:36,569 --> 00:02:41,580 And then finally, after all the testing is done, we deploy the software. 41 00:02:41,580 --> 00:02:43,879 So what's wrong with this approach? 42 00:02:43,879 --> 00:02:46,490 Well, there's no provision for change. 43 00:02:46,490 --> 00:02:48,840 Every phase has entrance and exit criteria. 44 00:02:48,840 --> 00:02:51,750 And when one ends, you know, the next one begins. 45 00:02:51,750 --> 00:02:55,640 And there's just no provision for going back and changing the design or changing the requirements 46 00:02:55,640 --> 00:02:57,840 or anything like that. 47 00:02:57,840 --> 00:03:01,940 So the other problem is, you don't know if it works to the end, right, there's no intermediate 48 00:03:01,940 --> 00:03:06,299 delivery. Nothing is delivered, until that last step, when we give it to the operations 49 00:03:06,299 --> 00:03:10,640 team and say, go deliver this thing into production. 50 00:03:10,640 --> 00:03:14,390 The other is that each step ends when the next one begins, that's where it got this 51 00:03:14,390 --> 00:03:17,590 waterfall name, where things are just passed down. 52 00:03:17,590 --> 00:03:22,689 And of course, every one of these is an opportunity to lose information, you know, and to have 53 00:03:22,689 --> 00:03:28,109 a mishap happen or to have people get blocked, because they can't accept, you know, the work 54 00:03:28,109 --> 00:03:29,400 from the previous phase. 55 00:03:29,400 --> 00:03:33,080 And now you're waiting to get that next phase going. 56 00:03:33,080 --> 00:03:38,060 The other is that mistakes are found later on are very, very costly, very costly to find 57 00:03:38,060 --> 00:03:42,439 something that's designed wrong and testing and go back and redesign it. 58 00:03:42,439 --> 00:03:46,579 And then finally, there's the long lead times, right between getting that software 59 00:03:46,579 --> 00:03:51,740 delivered. From the time you first want the software, and you design the software and 60 00:03:51,740 --> 00:03:52,760 code it and test it. 61 00:03:52,760 --> 00:03:56,569 And by the time you finally deliver it long, long, long lead times. 62 00:03:56,569 --> 00:04:01,620 So the problem here is teams are working separately, they're unaware of their impact to each other. 63 00:04:01,620 --> 00:04:05,579 Right, designers are unaware of the impact of the code, the coders are unaware of their 64 00:04:05,579 --> 00:04:07,720 impact to integrating all the code together. 65 00:04:07,720 --> 00:04:11,139 There everybody's working in their little silos for their little phase. 66 00:04:11,139 --> 00:04:13,609 And then this should be a scary thought. 67 00:04:13,609 --> 00:04:19,470 The people who are furthest away from a code, the poor operations team, have to run this 68 00:04:19,470 --> 00:04:21,700 and manage this in production, right? 69 00:04:21,700 --> 00:04:26,750 They know the least about the code, and they're the ones who are expected to run it. 70 00:04:26,750 --> 00:04:28,340 Not very efficient. 71 00:04:28,340 --> 00:04:31,600 Let's talk about another methodology, extreme programming. 72 00:04:31,600 --> 00:04:33,610 This was introduced back in 96. 73 00:04:33,610 --> 00:04:38,140 Kent Beck introduced this and if you look at the graphic on the right, you'll see that 74 00:04:38,140 --> 00:04:41,490 it is very iterative and talking about loops. 75 00:04:41,490 --> 00:04:44,680 You've got these major release plan on the outer loop. 76 00:04:44,680 --> 00:04:46,400 And then you've got an iteration plan. 77 00:04:46,400 --> 00:04:49,280 And so the release maybe months, the iterations maybe weeks, 78 00:04:49,280 --> 00:04:54,340 acceptance has maybe days, stand up meetings once a day, right, pair negotiation in hours, 79 00:04:54,340 --> 00:04:58,180 unit testing in minutes, pair prpgramming in seconds. 80 00:04:58,180 --> 00:05:04,690 You know, it's these tighter and tighter loops of doing work and then getting fast feedback. 81 00:05:04,690 --> 00:05:08,160 It's based on an iterative approach to software development. 82 00:05:08,160 --> 00:05:10,580 And in fact, this is where Agile got it from. 83 00:05:10,580 --> 00:05:15,131 And the intent here is to improve software quality, right? Be responsive to change, be 84 00:05:15,131 --> 00:05:18,930 responsive to customer requirements, do things in small increments. 85 00:05:18,930 --> 00:05:25,180 And so many people recognize Extreme Program as one of the first Agile methods. 86 00:05:25,180 --> 00:05:28,009 So let's talk about Extreme Programming values. 87 00:05:28,009 --> 00:05:29,620 First is simplicity, right? 88 00:05:29,620 --> 00:05:30,820 Do what you need 89 00:05:30,820 --> 00:05:36,050 and no more, don't over-engineer, don't over code, don't deliver more code than the customer 90 00:05:36,050 --> 00:05:37,050 asked for. 91 00:05:37,050 --> 00:05:39,069 Keep it simple, very important. 92 00:05:39,069 --> 00:05:41,020 The next one is communication. 93 00:05:41,020 --> 00:05:44,830 Everyone on the team should be communicating know what everyone else is doing, it fosters 94 00:05:44,830 --> 00:05:49,639 a lot, a lot of communication, and people interacting. Very important as well. 95 00:05:49,639 --> 00:05:53,830 And then feedback, you have no idea how you're doing unless you're getting feedback. 96 00:05:53,830 --> 00:05:58,540 So having those feedback loops are critical to extreme programming, and critical to Agile 97 00:05:58,540 --> 00:06:00,070 in general. 98 00:06:00,070 --> 00:06:04,580 And then respect, everyone feels that they are respected on the team, that they can offer 99 00:06:04,580 --> 00:06:09,440 advice that they can make suggestions, and that their suggestions are just as valuable 100 00:06:09,440 --> 00:06:11,270 as anybody else's suggestion on the team. 101 00:06:11,270 --> 00:06:16,520 There's no hierarchy, everybody has peers on the team, and respected for their ideas. 102 00:06:16,520 --> 00:06:21,020 And then finally, courage, right, we don't pad our estimates, we're just very honest 103 00:06:21,020 --> 00:06:22,690 about we think we could do this 104 00:06:22,690 --> 00:06:24,130 And we don't think we can do that. 105 00:06:24,130 --> 00:06:27,199 And we're not going to lie to you that we you know, we can get this, this done in this 106 00:06:27,199 --> 00:06:28,280 amount of time. 107 00:06:28,280 --> 00:06:32,750 We're very open and honest in Extreme Programming on, these are the estimates, this is what we'll commit 108 00:06:32,750 --> 00:06:33,750 to. 109 00:06:33,750 --> 00:06:35,639 Next, there's Kanban. 110 00:06:35,639 --> 00:06:38,520 This comes from the Japanese manufacturing systems. 111 00:06:38,520 --> 00:06:43,221 And kanban literally means billboard sign, and it's all about continuous flow on the 112 00:06:43,221 --> 00:06:48,569 manufacturing floor, where these cards or notes would flow with the product from station 113 00:06:48,569 --> 00:06:52,050 to station, going down the line. 114 00:06:52,050 --> 00:06:55,550 So the core principle with Kanban are visualize the workflow. 115 00:06:55,550 --> 00:06:58,450 If you can't see the work, you can't manage the work. 116 00:06:58,450 --> 00:07:02,080 And this is something we take into Agile too. You're going to find out we're going 117 00:07:02,080 --> 00:07:03,580 to use Kanban boards and Agile. 118 00:07:03,580 --> 00:07:08,039 And it's all about visualizing the work, very important that you can understand the work 119 00:07:08,039 --> 00:07:14,660 that needs to be done, and everything is accounted for. Kanban also stresses limit the work in 120 00:07:14,660 --> 00:07:19,300 progress. You don't want, when you're on a manufacturing floor, you don't want work to back up at one 121 00:07:19,300 --> 00:07:20,300 of the stations. 122 00:07:20,300 --> 00:07:23,470 But even when you're developing software, you don't want to have people working on too 123 00:07:23,470 --> 00:07:25,040 many things at once. 124 00:07:25,040 --> 00:07:29,080 Because, you know, you can only ship 100% of one thing that's working, you can't ship 125 00:07:29,080 --> 00:07:30,080 50% of two things. 126 00:07:30,080 --> 00:07:33,180 And so if you got one person working on two things, it's not good. 127 00:07:33,180 --> 00:07:37,300 And that comes from Kanban to limit the work in progress. 128 00:07:37,300 --> 00:07:41,860 Then there's managing and enhancing the flow. In Kanban, they're always looking to improve. 129 00:07:41,860 --> 00:07:46,479 They're always looking to change and understand how can we get a better flow, a quicker flow 130 00:07:46,479 --> 00:07:52,889 on the manufacturing floor, and then making policies explicit, so that everyone understands 131 00:07:52,889 --> 00:07:54,189 how things work. 132 00:07:54,189 --> 00:07:58,659 And everyone understands the definition of "done," what does it mean to have something be 133 00:07:58,659 --> 00:08:04,840 "done." We take that also from Kanban in our Agile planning to understand what the definition 134 00:08:04,840 --> 00:08:06,300 of"done" is. 135 00:08:06,300 --> 00:08:11,520 And then continuously improving, very, very important to get feedback and continuously 136 00:08:11,520 --> 00:08:12,520 improve on what you're doing. 137 00:08:12,520 --> 00:08:17,850 So Kanban is all about making the flows work better, understanding them, seeing them, 138 00:08:17,850 --> 00:08:22,530 being able to measure them, and then continuously improving on how we can flow faster. 139 00:08:22,530 --> 00:08:27,500 In this video, you learn that your traditional Waterfall approach to software development 140 00:08:27,500 --> 00:08:32,520 is a structured, step-by-step process that can lead to problems not surfaced until later 141 00:08:32,520 --> 00:08:33,980 in development. 142 00:08:33,980 --> 00:08:38,820 The extreme programming was developed to improve software quality and responsiveness to changing 143 00:08:38,820 --> 00:08:40,540 requirements. 144 00:08:40,540 --> 00:08:46,150 XP values include simplicity, communication, feedback, respect, and courage. 145 00:08:46,150 --> 00:08:52,270 Kanban is a system characterized by visualizing workflow, limiting work in progress, managing 146 00:08:52,270 --> 00:08:58,053 and enhancing the flow, making process policies explicit and continuously improving the process.