对话：在敏捷中，是否可以仍然用需求来替代用户故事？

问题的提出

For Agile, could we still use Requirements instead of user stories, or could we combined both ?

Nicolas PangaudVP, Head Of Embedded Security at NagraVisionTop Contributor

Niels Malotaux：User Stories are not requirements. They are design elements to eventually fulfill requirements.

Michael DeKort：Get all the info you can but do not put it in text.

Use diagrams - Activity, UML, Use Case or a hybrid.

The reason for this is
- Text leads to miscommunication and defects
- Text does not build well towards an overall doc set. All you get is a pile of text that is hard to link and visualize no one will read
- Text does not handle multiple paths well
- Text does not afford seeing all the places you need to identify exceptions
- Diagrams solve all of this and virtually create system tests and training aids.

Alan S Koch：When we link Agile to traditional frameworks like CMMI, we tend to talk about User Stories as being equivalent to Requirements. But as Niels points out, they are not.

Kent Beck (author of Extreme Programming Explained) describes User Stories as, "a promise to have a conversation later". In other words, they are merely a place-holder, and the real details and information will be filled in later. In my training, I tell people to visualize the table of contents for the Requirements Spec the write on traditional projects -- *that* is what User Stories are.

Later, when we *do* have that conversation and work out the details, the Agile methods don't talk about writing a Requirements document. But they do not intend that nothing is captured in durable form. Michael's point is in line with Agile thinking -- let's capture these details in some visual form like Use Case diagrams or business process flows.

What gets written down and in what form it is recorded must always be driven by value and usage. Capture all valuable information in a form that will be useful later. To do this, you must carefully identify what information will be useful for later reference, and what you (or someone else) will need it for.

Luc Nys：User stories are used to plan the sprint. If needed for implementation, requirements can be derived during the sprint to further detail the user needs. Some user stories can be implemented without detailing requirements, others will need more detailed requirements.

Niels Malotaux：If I see requirements I usually ask "Where are the pictures?"

Be careful: we see a lot of design (solutions) in typical requirements (needs). The business specifies the requirements (e.g. "time to do something now is 4 hr, can you help us to do it in 30 min"). The rest is design how to achieve that. Sometimes IT may be helpful to achieve it.

Using the term "Writing Requirements" doesn't imply just "write text".
Still, there is a great way of writing requirements textually: Tom Gilb's "Planguage".
I'll post a simple example of Planguage on my website soon.
You can find the example in slide 108 ofhttp://www.malotaux.nl/doc.php?id=86
Here you can see it's concise, clear (except for what's still between <fuzzy brackets>) and can be read and understaood quickly by anyone, even the CEO or the customer.
It's not specifically an IT specification, however, a business requirement is also not an IT specification. If a business requirement calls for IT support, it's easy to derive designs that support the business requirement. Use cases (or scenarios) merely help us to find the real requirements (what's really necessary). How to achive that is design.

Murali Nambiar：My experience is with having Requirements as against User stories is that the former brings out the contractual nature in every team member.. The level of granularity makes document sacrosanct and then every one from the developer to the tester uses this document as base rather than focusing on understanding what business value needs to be delivered.
The "as a... i want to ...so that" sections in the story template addresses this short coming very well and gets the team to be creative on how to achieve the business goals.

Scott W. Ambler：There is a very wide range of requirements options available to you, user stories is just one of many. Unfortunately there has been a lot of messaging around user stories over the past decade or so that has drowned out a lot of the coherent discussions around agile requirements strategies. You might findhttp://www.agilemodeling.com/essays/agileRequirements.htm#Artifactsto be an interesting resource. It's not a complete list but it's certainly much longer than "1. User stories"

From a disciplined agile point of view, you have choices. Athttp://disciplinedagiledelivery.wordpress.com/2013/07/17/exploring-initial-scope-on-disciplined-agile-teams/we discuss the options that you face when initially exploring requirements on an agile team. One thing you need to consider is which views you want to consider, a usage view being one of them. User stories, along with use cases, usage scenarios, and several others techniques, are valid options to do so. You may also need to explore the domain view (via data models or class diagrams perhaps), explore the user interface view (via sketches or prototypes perhaps), and so on.

Of course, view types is just one factor you need to consider. The amount of initial detail to capture, how to explore requirements, how you're going to manage change later in the lifecycle, and address non-functional requirements are also important decisions.

Ahmad Abuhamda, MBA, PMP：Nicholas, I think you're confusing requirements with use cases. Every project has requirements (functional specs or customer wants/needs). User stories is the Agile equivalent of use cases. You use the functional specs/requirements to develop use cases (or user stories for Agile/Scrum/etc.)

Scott W. Ambler：@Ahmad, although there is a lot of focus on user stories in the agile community fact is that user stories are just one way that you can choose to capture usage requirements.

Also, an artifact isn't automatically agile or not agile. Just because you're writing user stories it doesn't imply that you're agile, it implies that you're writing user stories. Similarly, if you're doing use cases (or scenarios, or data models, or process models, or mind maps, or ...) it doesn't mean you're (not) agile.

讨论太火爆，不摘录了

请前往 http://www.linkedin.com/groupItem?trk=eml-b2_anet_digest_weekly-null-5-null&gid=1516987&view=&ut=2wcbfSKq04x6c1&item=5859931505509302274&type=member&fromEmail=fromEmail