The Waterfall Model3:40 with Matt Anthes-Washburn
A time-honored tradition in software development is to use a consistent sequence of stages to design, build, and test software. This sequential model is often called, “waterfall” because, like water flowing downstream, it is characterized by a process of irreversible flow from stage to stage from start to finish.
Waterfall Model: A model for software development that follows a sequential and irreversible series of steps, like water flowing downstream.
[MUSIC] 0:02 Hi, my name is Matt and I'm a SCRUM product owner. 0:04 In this course, we're going tp take a look at some of the practices that teams use 0:08 to efficiently develop software. 0:12 We'll study a group of practices with an emphasis on delivering a high value to 0:14 the customer in the face of changing needs and requirements. 0:18 These practices are commonly referred to as agile software development. 0:23 In this stage, we will discuss the meaning of the term agile and 0:27 where the concept originates. 0:30 To start, let's look at the landscape of software development 0:32 before agile methods were introduced. 0:35 The Waterfall Model. 0:38 A time honored tradition in software development, 0:40 is to use a consistent sequence of stages to design, build, and test software. 0:42 This sequential model is often called waterfall, 0:48 because like water flowing downstream, it is characterized by a process of 0:51 irreversible flow from stage to stage from start to finish. 0:56 For the purposes of understanding it here, 1:00 we are going to simplify these stages into design, build, and test. 1:03 At each step in the Waterfall Model, a specialized group of people, or 1:08 a department, is tasked with the work of that stage. 1:12 After completing the work, they hand it off to the next group. 1:16 Typically this handoff involves some form of formal documentation 1:20 that describes to the next group what the software is supposed to do. 1:24 Critics of the Waterfall Model sometimes refer to this kind of handoff as 1:28 throwing it over the wall. 1:33 Because the groups hand over the work without a lot of contact, 1:34 and then they never see it again. 1:37 There are few problems that plague the waterfall model for software development. 1:39 For one thing, it's said that the handoffs in this process can result in something 1:44 like the childhood game of telephone [SOUND] where each person makes their own 1:48 interpretation of a message and then passes it on. 1:52 By the end of the process, 1:55 the product may not look at all like what the client had in mind. 1:56 Time and resources are wasted building a product that isn't a good fit for 2:00 the customer. 2:04 Another big issue with Waterfall development is that there's not a lot of 2:05 opportunity during the process to respond to changing priorities or 2:09 outside influences. 2:13 Let's say you are two months into a six month 2:14 process of bringing your groundbreaking product 2:17 to market when a competitor introduces a new product in the same space. 2:19 You may want to respond by differentiating your product from this new offering. 2:24 However, in the Waterfall Model, you may be finished with design of a product and 2:28 find yourself in the middle of the build phase. 2:33 You're left with a tough choice, scrap the work that's been done so 2:35 far, and start over, or finish the project 2:38 even though the product might not be a great fit for the market anymore. 2:41 So we've covered three key problems people find with Waterfall development. 2:45 First, time and resources are wasted in the handoff between stages. 2:49 Second, the product doesn't always fit the original intent 2:53 due to imperfect communication. 2:57 And finally, it's difficult in Waterfall development to respond to change. 2:59 In this course, we'll learn more about alternate models meant to address some of 3:04 these concerns with the Waterfall Model. 3:08 You won't likely find companies boasting about being a Waterfall shop these days. 3:11 But, it is nonetheless easy to identify points in many team's processes 3:16 where a handoff is expected from one group to another. 3:20 A wonderful piece of advice I've heard about handoffs 3:23 is to be on the look out for them as opportunities for collaboration. 3:26 When you a identify a handoff point in your process, 3:30 try to figure out what can be done to bring the two parties involved 3:33 closer together to share a richer understanding of each others work 3:36
You need to sign up for Treehouse in order to download course files.Sign up