Alla ricerca della user story perduta

679 views
617 views

Published on

Edoardo Schepis

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
679
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Alla ricerca della user story perduta

  1. 1. Ogni riferimento a fatti realmente accaduti e/o a persone realmente esistenti è da ritenersi puramente casuale. Any resemblance to actual persons is purely coincidental
  2. 2. As a user I want to search the Internet so that I find the information I need
  3. 3. • Software Engineer • Scrum Master in Funambol – 6 teams – 30 engineers schepis@funambol.com • 2,5 years = 50 iterations  3000 user stories • Links: – http://www.funambol.com – http://www.edschepis.net – http://pragmaticagile.wordpress.com edschepis
  4. 4. • Introduction to User Stories – Epic/Theme/User Story/Task – INVEST – Estimation – DONE! • Gugol User Stories • Critics • Conclusions
  5. 5. • In general or for your particular product/service/company, what would you rather have your customers talk about? – A. “Their is awesome” – B. “Their is awesome” – C. “Their is awesome” – D. “ ” • First-person language... reverse engineer • It's not about the tools we build, it's what our tools let them do • better is... better Thanks to Kathy Sierra - Talk at Business of Software 2009 [http://www.blip.tv/file/3346148]
  6. 6. • What's that? Kent Beck coined the term user stories in Extreme • 3C Programming Explained 1 st Edition, 1999 – Card – Conversation – Confirmation • Limitations – It's not just “As a ... I want to... so that...” – Without acceptance tests are open to interpretation – They require close customer contact throughout the project which in some cases may be difficult or may be unnecessary overhead – Can have difficulty scaling to large projects – Conversation starters... fail to serve as a form of reliable documentation of the system
  7. 7. • User stories provide a small-scale and easy-to-use presentation of information – generally formulated in the everyday language of the user – contain little detail, thus remaining open to interpretation – should help the reader understand what it is the software should accomplish – • Use cases in contrast describe a process and its steps in detail, and may be worded in terms of a formal model. – is intended to provide sufficient detail for it to be understood on its own – a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system –
  8. 8. • Theme – a top-level objective that may span projects and products – a collection (group) of user stories • Epic – a large user story: break up epic to several user stories • User Story • Task
  9. 9. • Independent – User Stories should be as independent as possible. • Negotiable – User Stories are not a contract. • Valuable – User Stories should be valuable to the user. • Estimable – User Stories need to be possible to estimate. • Small – User Stories should be small. Not too small. But not too big. • Testable – User Stories need to be worded in a way that is testable
  10. 10. • Who (As a...) – User – Roles – Systems?!? • What (I want to...) – Action • Why (so that...) – Needs
  11. 11. • Search engine follow links on the web to request pages that are either not yet indexed or have been updated since they were last indexed • These pages are crawled and are added to the search engine . Searching a slightly outdated index of content which roughly represents the content of the web • – Accept the user query, checking to match any advanced syntax and checking to see if the query is misspelled – Check to see if the query is relevant to other vertical search databases (such as news search or product search) and place relevant links to a few items from that type of search query near the regular search results. – Gather a list of relevant pages for the organic search results. These results are ranked based on page content, usage data, and link citation data.
  12. 12. As a user I want to search the Internet so that I find the information I need
  13. 13. • Why splitting is essential? – a user story should be split when it is too large to fit within a single iteration – split a large user story if a more accurate estimate is necessary • How to split? – Data Boundaries (the information, the results) • along the boundaries of the data supported by the story – Operational Boundaries (search) • separate CRUD operations – Orthogonal Features (security, logging) • creating two versions of the story: one with and one without support – Performance Constraints (find quickly, millions of users) • separating the functional and nonfunctional aspects into separate stories – Mixed Priorities (error paths) • the priorities of the smaller stories are different. • Don’t split a large story into tasks • Watch out the User Stories split f re n z y (“details are not needed now”)
  14. 14. As a user I want to search the Internet so that I find the information I need
  15. 15. As a user I want to search the Internet so that I find the information I need
  16. 16. As a user I want to search the Internet so that I find the information I need
  17. 17. As a user I want to search the Internet so that I find the information I need
  18. 18. As a user I want to search the Internet so that I find the information I need
  19. 19. • Data boundaries: search contents, input and results • Operational Boundaries: searching... “I'm Feeling Lucky” • Performances and scalability • Mixed Priorities: – Ranking – Advanced Search – Web Services – Localized searches
  20. 20. • Web Search – Simple input – “I'm Feeling Lucky” – No Ranking – IP-local searches – Subset of results • Data boundaries: – News Search – Image Search – Code Search Advertising – Maps Search – ... • Advanced Search • Web Services • Support millions of users
  21. 21. • Story Points are units of size used in estimating software requirements as an alternative to units of time • Measurement of complexity vs. man-day • Advantages: – cheaper to arrive at – collaborative estimation - it's not just developers who can or do estimate, it is a product team including analyst, tester and developers – the estimates of size are more transparent and universally agreed upon • Planning Poker and other techniques • Fibonacci sequence
  22. 22. • DoD is a checklist of valuable activities required to produce software – a simple list of activities (writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.) that add verifiable/demonstrable value to the product • DoD is the primary reporting mechanism for team members – “This feature is done.” • DoD is equivalent to “potentially shippable” • DoD is not static
  23. 23. 1 2 8 13 2 2 ?
  24. 24. • Web Search – Simple input – “I'm Feeling Lucky” – No Ranking – IP-local searches – Subset of results • Data boundaries: – News Search – Image Search – Code Search Advertising – Maps Search – ... • Advanced Search • Web Services • Support millions of users
  25. 25. • Scaling: more than 4 billion of pages and 10Kb/page = tens of terabytes – Performances – Hardware requirements – Handling Failures – PageRank and Shards • Documenting Gugol with a list of “As a user..”? • Prototypes and Spikes
  26. 26. • http://www.mountaingoatsoftware.com • http://en.wikipedia.org/wiki/History_of_Google • http://xprogramming.com • http://www.searchenginehistory.com/ • http://headrush.typepad.com/ • http://pragmaticagile.wordpress.com
  27. 27. Focus on what user does, not what you do Don't build a better [x], build a better [user of x] Thanks to Kathy Sierra - Talk at Business of Software 2009 [http://www.blip.tv/file/3346148]

×