O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Minimum viable product development

Carregando em…3

Confira estes a seguir

1 de 30 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (18)


Semelhante a Minimum viable product development (20)


Mais recentes (20)

Minimum viable product development

  2. 2. Why do we build products?  Delight customers with inspiring solutions  Solve a real problem and help people  Realize a big vision and change the world  Get a strong fan base and lots of revenue
  3. 3. Product development approach  Build a great product with lots of features  Time wasted in building something nobody wants OR  Build for fast releases and get customer feedback  Time wasted in getting the right customer requirements
  4. 4. MVP is  NOT The final version of the product  An experiment to validate the hypothesis  Usually discarded to build the real product  A minimalist user interface  Ok to share and receive feedback
  5. 5. Minimal Viable Product  The minimum set of features needed to learn from early adopters  Avoid features no one will use  Maximize the learning per dollar spent
  6. 6. Minimal Viable Product  Product needs to solve a real problem  Early adopters can bridge the gap with missing features  Can be developed incrementally  Requires a commitment to iteration
  7. 7. Simple landing page screenshots from your Value Prop Call to action graphic designer Web page title http://www.url.com “Register/Sign- up” MVP Dissected
  8. 8. Lean Startup & Extreme Programming
  9. 9. User Stories  Similar to use cases but, not the same  Used to build time estimates  Track what customers need the system to do  Drive the creation of acceptance test cases  Each story will get 1,2 or 3 weeks ideal development time  Focus on user needs and not technology
  10. 10. User Stories  The project velocity (or just velocity) is a measure of how much work is getting done on your project.  To measure the project velocity you simply add up the estimates of the user stories that were finished during the iteration.
  11. 11. Architectural Spike  Figure out answers to tough technical or design problems  A simple program to explore potential solutions  Expect this to be throw-away code  Reduce the risk of the problem
  12. 12. Release Planning  Approx. 60 – 100 user stories are sufficient to make a release plan  A release planning meeting is used to create a release plan  The goal of the release planning meeting is to estimate user stories in ideal programming weeks  Customers prioritize stories with developers via user story cards  Planning may be done by time or scope  Project may be quantified by four variables; scope, resources, time, and quality
  13. 13. Release Planning
  14. 14. Iteration
  15. 15. Iteration  Iterative Development adds agility to the development process.  Divide your development schedule into about a dozen iterations of 1 to 3 weeks in length.  One week is the best choice even though it seems very short.  Have an iteration planning meeting at the beginning of each iteration to plan out what will be done.  If it looks like you will not finish all of your tasks then call another iteration planning meeting, re-estimate, and remove some of the tasks.
  16. 16. Acceptance Tests  Acceptance tests are created from user stories  Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority  A user story is not considered complete until it has passed its acceptance tests  Quality assurance (QA) is an essential part of the XP process
  17. 17. Acceptance Tests  Acceptance tests should be automated so they can be run often  A bug in production requires an acceptance test be written to guard against it.  Given a failed acceptance test, developers then create unit tests to show the defect from a more source code specific point of view.  When the unit tests run at 100% then the failing acceptance test can be run again to validate the bug is fixed.
  18. 18. Testing Techniques  Smoke test via landing pages  SEM - $5 a day via Facebook etc.  In product split testing  Paper prototypes  Customer validation  Removing features  Mturk, Adwords
  19. 19. Small Releases  The development team needs to release iterative versions of the system to the customers often.  At the end of every iteration you will have tested, working, production ready software to demonstrate to your customers  This is critical to getting valuable feedback in time to have an impact on the system's development
  20. 20. User Stories Release Plan Prototype Acceptance tests & Bugs MVP Deliverables
  21. 21. Tools & Resources
  22. 22. MVP Backend • Cloud • Database Services/ Middle tier Frontend • User interface
  23. 23. Resources  User Stories  Download Team Foundation Server  Workflow items and workflow  Visual Studio 2012 Guide  Measuring velocity in VSFS  Power Mockup  Release Planning  Create a project plan in five steps  Planning using Project 2013  Scrum process template  Acceptance Tests  Tracking software quality  Bug Tracking using Visual Studio - Test Manager
  24. 24. Resources  Azure Portal  Windows 8 Store App Sample Code  BizSpark Site  List of products available through BizSpark

Notas do Editor

  • http://www.foundersspace.com/wp-content/uploads/2012/06/Minimum-Viable-Product.jpeg
  • Customer Development for Web Startupshttp://steveblank.com/2010/02/25/customer-development-for-web-startups/
  • Extreme Programming Projecthttp://www.extremeprogramming.org/map/project.html
  • http://www.extremeprogramming.org/rules/velocity.html
  • An ideal week is how long you imagine it would take to implement that story if you had absolutely nothing else to do. Include time for testing.
  • http://office.microsoft.com/en-us/project-help/what-s-new-in-project-2013-HA102749523.aspxhttp://office.microsoft.com/en-us/project-help/professional-project-management-desktop-software-project-professional-FX103797571.aspx
  • http://www.extremeprogramming.org/rules/iterative.html
  • http://www.extremeprogramming.org/rules/bugs.html