Metodología Agil: User Stories

Hola, Siguiendo con la línea sobre metodologías ágiles, los siguientes links exploran el tema de "User Stories", la definición, utilidad, composición, sus diferencias con los Casos de Uso y varias reflexiones muy interesantes! Definición de Wikipedia: In software development and product management, a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. User stories are used with agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for the business user as that user's primary way to influence the functionality of the system being developed. User stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.), though primarily it is the task of a product manager to ensure user stories are captured. https://en.wikipedia.org/wiki/User_story Martin Fowler (Guru en Metodologías Agiles) User Stories are chunks of desired behavior of a software system. They are widely used in agile software approaches to divide up a large amount of functionality into smaller pieces for planning purposes. You also hear the same concept referred to as a feature, but the term "story" or "user story" has become prevalent in agile circles these days. Kent Beck first introduced the term as part of Extreme Programming to encourage a more informal and conversational style of requirements elicitation than long written specifications. The essence of a story can be written on a single note card (Kent and I prefer 3" by 5" ). Stories are deliberately not fleshed out in detail until they are ready to be developed, you only need enough understanding to allow prioritization with other stories. Bill Wake came up with the INVEST mnemonic to describe the characteristics of good stories: - Independent: the stories can be delivered in any order - Negotiable: the details of what's in the story are co-created by the programmers and customer during development. - Valuable: the functionality is seen as valuable by the customers or users of the software. - Estimable: the programmers can come up with a reasonable estimate for building the story - Small: stories should be built in a small amount of time, usually a matter of person-days. Certainly you should be able to build several stories within one iteration. - Testable: you should be able to write tests to verify the software for this story works correctly. A common way to formulate stories is the "As a … I want … So that …" form. The "As a" clause refers to who wants the story, "I want" describes what the functionality is, "so that" describes why they want this functionality. The "so that" part provides important context to understand to help get from what the customer think they want to providing what they actually need. Mike Cohn wrote what is now the standard book on writing user stories. To understand the roots of user stories in XP consider the white book, or the tasteful green book. In an earlier bliki entry I discuss why UseCasesAndStories are different. http://agile.dzone.com/articles/martin-fowler-user-stories What is the difference between a UseCase and XP's UserStory? This is a common question, and not one that has a generally agreed on answer. Many people in the XP community consider stories to be a simplified form of use cases, but although I used to hold this view I see things differently now. Use cases and stories are similar in that they are both ways to organize requirements. They are different in that they organize for different purposes. Use cases organize requirements to form a narrative of how users relate to and use a system. Hence they focus on user goals and how interacting with a system satisfies the goals. XP stories (and similar things, often called features) break requirements into chunks for planning purposes. Stories are explicitly broken down until they can be estimated as part of XP's release planning process. Because these uses of requirements are different, heuristics for good use cases and stories will differ. The two have a complex correlation. Stories are usually more fine-grained because they have to be entirely buildable within an iteration (one or two weeks for XP). A small use case may correspond entirely to a story; however a story might be one or more scenarios in a use case, or one or more steps in a use case. A story may not even show up in a use case narrative, such as adding a new asset depreciation method to a pop up list. Do you need to do both? As in many things, in theory you do but in practice you don't. Some teams might use use cases early on to build a narrative picture, and then break down into stories for planning. Others go direct to stories. Others might just do use cases and annotate the use case text to show what features get done when. http://martinfowler.com/bliki/UseCasesAndStories.html http://martinfowler.com Stories about users and User Stories http://under10consulting.com/2013/02/28/stories-about-users-and-user-stories/