Happy sad evil_weird
•Download as PPTX, PDF•
1 like•784 views
Happy, Sad, Evil, Weird: Driving Feature Development With Use Case Planning
Recommended
More Related Content
Similar to Happy sad evil_weird
Similar to Happy sad evil_weird (20)
Recently uploaded
Recently uploaded (20)
Happy sad evil_weird
- 1. Happy, Sad, Evil, Weird Driving Feature Development With Use Case Planning
- 2. Who Am I?
- 3. Ben Lewis Engineering Lead Blogger OS Contributor Mentor
- 4. What Am I Talking About?
- 6. Save Money
- 7. Look Ahead
- 8. Usually…
- 11. Bad Data
- 15. What Is Use Case Planning?
- 16. Mark Shacklette University of Chicago CS Department Use Case Analysis: Purpose and Implementation http://people.cs.uchicago.edu/~mark/51023/Ucstyleg.html
- 17. What’s required to build it? How should it behave? Who’s involved? (People, systems and processes) We’re Building A System
- 18. Who’s Involved? Product Owner Designer Developer QA Technician
- 19. User Experience Driven Design for the user Talk about behavior in user’s terms Think through all of the behavior you can
- 20. Scenarios
- 21. Why Consider Use Cases? Everyone can understand plain language Agreements will stick better Fewer things fall through the cracks Prevents bugs Guides architectural decisions
- 22. It’s a Sketch
- 23. Use Case Story Use Case Diagram UX Diagram Wireframe Design Comp Development Code Production Easy to Change Hard to Change
- 25. How To Plan Use Cases
- 26. Answer Four Questions 1. Who are the actors and what are their roles? 2. What’s the purpose of this feature? 3. What are the use cases? 4. How do the use cases relate to each other?
- 27. Who are the actors and what are their roles?
- 28. What’s the purpose of this feature?
- 29. What are the use cases?
- 30. How do the use cases relate to each other?
- 31. A Use Case Diagram "Use case restaurant model" by Kishorekumar 62. Licensed under CC BY-SA 3.0 via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Use_case_restaurant_model.svg#/media/File:Use_case_restaurant_model.svg
- 33. An Example
- 35. 1. Who are the actors and what are their roles? User - exchange money for services Merchant - exchange services for money Platform Owner - provide the platform for money SaaS Platform (The App) - make the exchange possible CC Service (Stripe) - Verify and charge card, store data Credit Card Company - Transfer funds if available
- 36. 2. What’s the purpose of this feature? Take money from the user Give it to the merchant and SaaS platform owner
- 37. 3. What are the use cases? Happy Paths Sad Paths Evil Paths Weird Paths
- 38. Sad Paths User fills out the credit card form with invalid information Credit card is rejected Stripe accepts card on client but server charge fails
- 39. Evil Paths Hacker breaks into server and steals data and system logs User figures out how to change price in hidden form field Hacker launches CSRF attack and creates bogus charges
- 40. Weird Paths Stripe server goes down JavaScript is disabled, form gets submitted to SaaS server Connection to Stripe is interrupted
- 41. Happy Paths User fills out form with valid data and clicks submit Credit card charge is accepted
- 42. 4. How do the use cases relate to each other? SaaS Platform Stripe Credit Card Company 💣 💣 💣 💸
- 43. Stories! As a user, when I complete the form with invalid information and click submit, I should see the invalid inputs become highlighted, and I should see validation errors telling me what went wrong so that I can correct my error and successfully buy products.
- 44. Stories! …and 11 others As a user, when I complete the form with invalid information and click submit, I should see the invalid inputs become highlighted, and I should see validation errors telling me what went wrong so that I can correct my error and successfully buy products.
- 45. Conclusion
- 47. Goals Design with the user experience in mind Think about how the feature should behave Agree on the answer to “what are we building?”
- 48. Benefits Gives all the stakeholders a voice Uncovers edge cases early Low cost way of changing a feature
- 49. Process 1. Who are the actors and what are their roles? 2. What’s the purpose of this feature? 3. What are the use cases? 4. How do the use cases relate to each other? Answer these four questions:
- 51. fin.
- 52. Ben Lewis blewis@quickleft.com @fluxusfrequency fluxusfrequency.github.io github.com/fluxusfrequency
- 53. Peanut Gallery
Editor's Notes
- Warning: there will be memes
- Eng Lead at Quick Left Blogging - EY, QL, personal, Ruby + JS Weekly, Pointer.io Exercism contrib, exercises and nitpicking gSchool / Turing background => mentoring
- Agile software dev => Iterative process => planning features early & often Many stakeholders w/ different POVs => can conflict Easy to overlook behaviors => if not thorough
- A way to solve these problems A term I made up Based on Use Case Analysis
- Time is Money Use Case planning => flexible early => cheaper to make changes
- Easy to go blindly forward => building it the way we think should happen => overlook edge cases Teams should think ahead and plan for alternative scenarios Cuz
- What we usually do is
- Golden path esp Dev & POs
- Sad
- Evil
- Weird
- It comes down to money Save with good planning
- My ripoff of Use case analysis
- Summarizing / reworking the process in this paper Comes from Object Oriented Analysis (academic) a way of thinking about building systems of any kind Modelling people & processes involved as objects Like OOP
- In this case the system => feature in an app Use case planning will help us: ID Requirements functional description of behavior ID actors (Sets the foundation)
- Who’s involved in planning a feature Draw on the perspective each of each of these roles This will help us plan =>
- We want to build software with UX in mind (read) How can we do these three things?
- This is the game plan Goal: break feature down into as many use cases (scenarios) as the team can Weave a story of interactions b/w people of various roles and the computer systems
- Common language Contract Foresee less common behaviors Plan what and what not to build
- Most valuable benefit “high level”, abstract & cheap to change (it’s just a post it note)
- Feature gets harder to change over time Will cost more In order to achieve this =>
- Four steps == answer four questions who’s involved why are we building it what are the scenarios put all together
- Everything that interacts with the system Users, admins, clientside app, API, external APIs, cloud services, hardware Relationship & responsibilities of each
- High level. Why do we want this feature to be built?
- Use and “misuse” cases Think of “packages” Today’s package: Happy, Sad, Evil, Weird Noun (actor), verb (actions), description (what should happen) for each scenario Specific purpose can also be added for each
- Each UC has a name, actor, and behavioral breakdown How do they relate?
- Actors get shapes Actions get lines Extending other UCs For example, login In our case, might make more sense to do as a UX flow diagram or whiteboarding wireframes
- Tracking tool 1. Everything gets built 2. Can estimate when work will be complete
- Multi-tenant SaaS platform like Etsy Merchants run stores, users buy them, platform takes a cut We’re part of a team doing sprint planning — PO, Dev, Design, QA present
- Credit Card form common to all tenants Imagine it will be hand-build (not Stripe checkout) But still using Stripe JS
- Going through the four steps actors & their roles
- Each stakeholder contributes to discovering use cases ID bundles as we go
- Alternatives paths first => can uncover things we should omit => e.g. thinking about spam on a blog => no comment form SAD PATHS Designer => form should display feedback for good UX PO => Should take as few steps as possible to make $ Dev => Use Stripe to make things easier QA => ironclad validations (special characters dont break)
- PO => Make sure company not liable / must be PCI compliant w/ users CC info Dev => never log CC info / don’t set price in form field QA => What happens when CSRF token / session is altered?
- Dev => dont submit form with CC # in it! PO => Resend request if Stripe is down Designer => feedback if server is down Netflix => Chaos Monkey service
- Finally, after exploring all the alternative paths Designer => Success message for good UX PO => analytics
- Draw and label something like this We did all that work, what did we get out of it? (besides this awesome diagram)
- From our first use case we can create this story point out ACTOR, ACTION, RESULT, REASON Can translate the use cases directly into stories
- This process should yield small stories Which are best for predict when feature will be done Put them in tracking software (like sprint.ly)
- Did use case planning Our tracker is full of stories We agree on what we’re building Everyone’s happy How did we get here again?
- Before you start building a feature You should break down the use cases As a team
- Why did we do it again?
- What did we get out of doing it this way?
- How did we do it again? 1 (nouns in our stories) 2 (value) 3 Golden path and alternative paths (verbs) 4 (diagram)
- What did we get in the end?
- Hope you enjoyed talking about Use Case Planning
- Questions? Comments?