class: middle
.eight[CSET-115]
.eight[Technical Requirements & Data Structures]
# Agile --- # Morning Routine 1. Make a list of _everything_ you did from waking up to starting class. -- count: false 2. Label each activity according to priority, from 1-N where 1 is the highest and N is the lowest. ??? Exercise taken from: https://www.agilesparks.com/blog/wake-up-in-the-morning-game/ --- # Morning Routine Here's the problem: your alarm didn't go off. You need to figure out how to change your plan to make it to class in 15 minutes. ??? - Our goal is still to get full "value" out of getting ready. - Can't get too deep into a single goal, get good enough and move to next goal. - Maybe even drop a goal. It's still a story from end-to-end, though. - Prioritizing is easier with context. --- # If plans don't work, why plan? --- count: false # If plans don't work, why plan? - Reduce risk - Reduce uncertainty - Make better decisions - Establish trust - Convey information --- class: center, middle .eight["Planning is everything.] .eight[Plans are nothing."] ??? Field Marshall Helmuth Graf von Moltke Planning was important because even though we threw our plan out, we had to know what was important to keep on the new plan. --- # Hurricane Forecast .center[
] ??? This doesn't mean it's growing over time, although it could be. This just means there's more of a likelihood that the hurricane will be in some unexpected place as time goes on. --- # Cone of Uncertainty .center[![Cone of Uncertainty](http://ptgmedia.pearsoncmg.com/images/ch01_9780131479418/elementLinks/01fig01.jpg)] ??? Let's use our house example from yesterday. With blueprints in hand, it's more likely that our estimate of done is more inaccurate than if we're almost done and just have to install carpets, do some painting, and add the trim. --- class: center
??? The waterfall process has critical paths, one team is blocked until the other is finished. This is a Gantt chart. --- class: center
--- class: center, middle # [Agile Manifesto](http://agilemanifesto.org/) --- # In Practice - Work as one team - Work in short iterations - Deliver something each iteration - Focus on business priorities - Inspect and adapt --- class: center, middle # [Agile vs Waterfall](http://www.agilenutshell.com/agile_vs_waterfall) --- # Roles - .eight[Product Owner] - .eight[Team Lead] (Project Manager/Scrum Master) - .eight[Everyone Else] ??? PO: Focusing on larger vision, priorities PM: Focusing on tasks, estimation, completion --- # Iterations - .eight[Sprint] - Short period of time, usually consistent Instead of a six month project, it's a series of two-week sprints. --- class: center
??? Iteration is not incrementing --- class: center
--- class: center We iterate to **find the right solution**. We iterate to **improve a potential solution**. --- class: middle, center # [The Agile Bicycle](https://m.dotdev.co/the-agile-bicycle-829a83b18e7) --- # Deliver Often - *Potentially* shippable - Sometimes trashed - "Are we going in the right direction?" ??? Clients from yesterday, how would you feel if you weren't allowed to see the final project until it was done? hopefully it'd be right. What about seeing something in two weeks? --- # Business Priorities - Features delivered in order set by Product Owner - Features are created with User Stories - No mention of tasks or implementation details, just requirements --- # Terminology - [User Stories](http://www.agilenutshell.com/user_stories) - [Estimation](http://www.agilenutshell.com/estimation) - [Planning](http://www.agilenutshell.com/planning) - [Burndown](http://www.agilenutshell.com/burndown) --- # User Stories - Who? - What? - Why? As a .eight[{role}], I want to .eight[{action}] so that .eight[{benefit}]. --- # User Stories Examples for Tic-Tac-Toe: - As a player, I want to see the grid so I know the state of the game. - As a player, I want to click a space so I can add my symbol. - As a player, I want the game to determine the result so I know who won. --- # Estimation - For each story, label it according to effort - Avoid thinking about time - Focus on relative effort, not absolute units We'll use a fake unit called Story Points. --- # Practice Estimating Instead of Story Points, let's look at Dog Points: 1. Make a small list of dog breeds -- count: false 2. Pick a random breed and say it is 1 dog point. -- count: false 3. Now estimate the rest of the breeds by size. --- # Estimate Scales - S, M, L - 1, 2, 4, 8 - 1, 2, 3, 5, 8 --- # Planning Poker - Everyone gets a bunch of cards representing one of the values - For a user story, everyone draws a card at the same time - Compromise, if you can - If not, try drawing cards again --- # Sprint Planning and Burndown - Grab a few high priority User Stories - The team starts working in a Sprint - Compare the Points of completed stories with remaining stories Now our fake unit has real value. --- # Ideal Days How long is a game of football? -- count: false - Four 15 minute quarters - Around 3 hours --- # Ideal Days - Ideal time is not Elapsed time - Imagine all the things you do in a day that aren't developing the product --- # Inspect and Adapt - Retrospectives - New knowledge affects new plan - Not mid-sprint, but between sprints --- # More Resources - [Atlassian's Agile Coach](https://www.atlassian.com/agile) - [Agile Estimating and Planning (book)](https://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415)