Planning the MVP4:54 with Craig Dennis
In this video we will set up the Minimal Viable Product, or MVP for the project we will build during this course. I will introduce several key Agile concepts that we will refer to during the remainder of the course.
[MUSIC] 0:00 We are now armed with enough information to build out the project for this course, 0:04 and I feel extremely confident that we can knock out a game of hangman pretty quick. 0:09 Now, I'd like to use this fun project to introduce you to a couple of 0:14 agile software development practices. 0:16 The agile methodology is a set of practices to use when 0:19 programming that help you maintain focused on your project and 0:22 stay organized, both personally and within your team. 0:25 While not specifically related to Java these practices 0:28 are quite common amongst most software development teams. 0:31 Owing to more info in the teachers notes 0:34 if you're interested in delving deeper into agile. 0:36 All right, so let's review how the classic hangman game works. 0:37 So the game is usually played by two people first one person 0:43 will call them the Prompter comes up with the word that the other person 0:47 will call the Guesser is going to try and guess a letter at a time. 0:50 The guesser is showing blank spaces for each letter. 0:55 The proper keeps track of how many times the player has had an incorrect guess. 0:57 There is a fixed number of incorrect guesses that can be made. 1:02 If the guesser guesses all the letters they win. 1:06 If they don't well, they lose. 1:08 One strategy that is used by some agile software development teams is to define 1:11 a minimum viable product or MVP. 1:14 What this helps us to do is to define the minimum requirements to prove 1:18 that our product is working as we hypothesized it would. 1:22 This helps us keep our scope to only the required tasks and nothing more. 1:25 Now for example in our project we might be tempted to add a scoring system or 1:30 ask the guessers name. 1:34 But that doesn't really help us get the software out the door any quicker. 1:36 This is sort of along the same lines as YAGNI, or 1:40 ya ain't gonna need it, that I mentioned earlier. 1:42 The idea here is to get your product out as soon as possible and 1:45 then change it based on how users are actually using your software, or 1:48 even better, what is actually being requested by them. 1:52 A common way of handling scope is to build a prioritized backlog of user stories. 1:56 Now, I setup a board that we can use to track our progress. 2:01 Let's go check it out. 2:04 So, this is Trello. 2:05 It's a free web application and it's primarily used for 2:07 keeping track of things. 2:10 Now, I've used it for several gigs and I think it's awesome for 2:11 doing software development through user stories. 2:14 User stories are another agile practice, but 2:17 basically there are development requests that are written in a certain form. 2:20 Now writing a good user story is a skill and definitely its own art form and 2:23 its way out of the scope of this course. 2:27 So please check the teacher's notes for more. 2:29 Now the main idea though is to communicate on a high level that everyone, 2:31 both the people requesting the product. 2:36 And the people developing it can understand. 2:38 It shows what will be delivered and for what reason 2:41 it does not expose the how that's our job as developers to figure that out. 2:45 So I've written a few stories that will run through here together 2:49 as a guess I should be able to submit a guess so that I can play the game. 2:52 So I'm going to do this I'm going to click it and 2:57 I'm a drag it over to the to do column. 2:59 Now as you'll notice this is a common format for users stories. 3:01 As a persona, I should whatever the feature request is. 3:06 So that and then the reason of why. 3:10 So that really helps convey the message of what it is we're doing and why. 3:13 So the next story up, as a guesser I should be presented with my 3:18 current progress so that I can make an educated guess. 3:21 That makes sense, hangman's hard without knowing the current progress. 3:24 As a guesser, I should know how many tries I have left, so 3:28 that I'm encouraged to be cautious. 3:32 Okay, next step, we have as a guesser, I should be stopped from making 3:35 a guess that has all ready been made so that I do not waste turns. 3:40 As a guesser I should be able to know that the game is won or lost so 3:45 that I can acknowledge completion with celebration or tears. 3:49 Okay, and I'm gonna stop right here, awesome. 3:53 So we've got the stories that we're planning to do all set up for us. 3:56 The amount of stories you choose is sometimes based on an estimate of 4:00 effort that you agree upon as a team. 4:03 Now I estimate that together we can finish these stories by the end of the course. 4:05 In most agile practices, the word sprint is used to find a set period of time 4:10 during which specific work will be completed and made ready to review. 4:15 So in that case this to do column here is going to represent our sprint and 4:19 this backlog is going to be stuff that we're going to not, 4:24 say we're not going to do this right. 4:27 This is where we we're talking about doing things like 4:28 know the name of the guesser or know the high score we're not gonna do that. 4:30 We're gonna keep that out of the MVP because we think that we can prove our 4:33 hypothesis of fun hanging. 4:36 I think if we complete all those stories that should give us our MVP or 4:39 again minimum viable product. 4:43 That is to say as long as we can deliver on these stories 4:45 we should have a working product that we can get out the door and iterate on. 4:49 Let's get building. 4:53
You need to sign up for Treehouse in order to download course files.Sign up