Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Happy sad evil_weird

528 visualizaciones

Publicado el

Happy, Sad, Evil, Weird: Driving Feature Development With Use Case Planning

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Happy sad evil_weird

  1. 1. Happy, Sad, Evil, Weird Driving Feature Development With Use Case Planning
  2. 2. Who Am I?
  3. 3. Ben Lewis Engineering Lead Blogger OS Contributor Mentor
  4. 4. What Am I Talking About?
  5. 5. Use Case Planning
  6. 6. Save Money
  7. 7. Look Ahead
  8. 8. Usually…
  9. 9. But there’s also…
  10. 10. Bad Data
  11. 11. Bad Data Hacker Attack
  12. 12. Bad Data Hacker Attack Chaos
  13. 13. What Is Use Case Planning?
  14. 14. Mark Shacklette University of Chicago CS Department Use Case Analysis: Purpose and Implementation http://people.cs.uchicago.edu/~mark/51023/Ucstyleg.html
  15. 15. What’s required to build it? How should it behave? Who’s involved? (People, systems and processes) We’re Building A System
  16. 16. Who’s Involved? Product Owner Designer Developer QA Technician
  17. 17. User Experience Driven Design for the user Talk about behavior in user’s terms Think through all of the behavior you can
  18. 18. Scenarios
  19. 19. Why Consider Use Cases? Everyone can understand plain language Agreements will stick better Fewer things fall through the cracks Prevents bugs Guides architectural decisions
  20. 20. It’s a Sketch
  21. 21. Use Case Story Use Case Diagram UX Diagram Wireframe Design Comp Development Code Production Easy to Change Hard to Change
  22. 22. How To Plan Use Cases
  23. 23. 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?
  24. 24. Who are the actors and what are their roles?
  25. 25. What’s the purpose of this feature?
  26. 26. What are the use cases?
  27. 27. How do the use cases relate to each other?
  28. 28. 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
  29. 29. Turn Use Cases Into Stories
  30. 30. An Example
  31. 31. 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
  32. 32. 2. What’s the purpose of this feature? Take money from the user Give it to the merchant and SaaS platform owner
  33. 33. 3. What are the use cases? Happy Paths Sad Paths Evil Paths Weird Paths
  34. 34. 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
  35. 35. 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
  36. 36. Weird Paths Stripe server goes down JavaScript is disabled, form gets submitted to SaaS server Connection to Stripe is interrupted
  37. 37. Happy Paths User fills out form with valid data and clicks submit Credit card charge is accepted
  38. 38. 4. How do the use cases relate to each other? SaaS Platform Stripe Credit Card Company 💣 💣 💣 💸
  39. 39. 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.
  40. 40. 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.
  41. 41. Conclusion
  42. 42. Use Case Planning
  43. 43. Goals Design with the user experience in mind Think about how the feature should behave Agree on the answer to “what are we building?”
  44. 44. Benefits Gives all the stakeholders a voice Uncovers edge cases early Low cost way of changing a feature
  45. 45. 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:
  46. 46. Results (Stories)
  47. 47. fin.
  48. 48. Ben Lewis blewis@quickleft.com @fluxusfrequency fluxusfrequency.github.io github.com/fluxusfrequency
  49. 49. Peanut Gallery

×