次の方法で共有

Scenarios in Practice

  • [アーティクル]

Scenarios are a practical way to organize and focus your product design, development and release.   (We use scenario-driven engineering in patterns & practices) 

Key Benefits

  • Business value.  You can  use scenarios to evaluate business value.   What pain does that scenario address? ... What opportunity does it create? ... etc.
  • Chunking and prioritizing.  You can use scenarios to chunk up and prioritize your product.  You can think of versioning in terms of releasing incremental value or scenarios.
  • Effective design.   Walking through a set of customers scenarios and "what ifs" will help you figure out your product's most effective design.  It's not a silver-bullet, but it does help make requirements more concrete, or at least put them in perspective.  It also opens the door to more precise questions about user experience or engineering challenges..
  • Focal point for perspectives.  You can use scenarios as a focal point for user experience, business and tech perspectives.
  • Requirements in context.  You can use scenarios to put requirements in context.  A requirement makes a lot more sense when you see it in action.
  • Architectural trade-offs.  You can use scenarios to evaluate and make architectural trade-offs.  You can't evaluate an architecture in a vacuum; you can evaluate against concrete scenarios.  There's several flavors of scenario-based evaluations you can leverage.
  • Customer value.  Your customers can appreciate how well you did (or didn't) address their scenario.
  • Tests for success.  You can use scenarios as tests for success.  By measuring customer effectiveness against specific scenarios, you have a way to focus your improvements.

Chunking Up a Project Using Scenarios
If you think of your product as helping a user accomplish a goal, it helps cut through the fog. You can think of your product in terms of a list of user goals, business goals and technical goals.  What's the minimum set of tasks your user needs to perform with your product?  That's your baseline release.  What's the incremental value from there?  That's how you start to shape your versions and releases.

User Experience, Business and Technical Perspectives
Using scenarios is a good forcing function to bring together the user experience, business, and technical perspectives.  For the sake of example, let's say your scenario is "User views the product catalog."  From the user experience perspective, you're thinking in terms of "show me a relevant list" and "don't make me wait,"  From a business perspective, you're thinking in terms of "support a given number of orders per hour" and "lower the total cost of ownership."  From a technical standpoint, you're thinking in terms of "requests per second," "minimize resource utilization," ... etc.  Well, no wonder getting software right is tough!  Luckily, scenarios help you bring together and rationalize the perspectives against a common frame of reference.

Constraints Make More Sense In Context
Constraints are boundaries to operate within, or what the solution must or must not do.  In software, I see a lot of generic constraints passed down as policies.  When policy meets scenario, you now have a way to evaluate the effectiveness of that constraint.  You can also measure whether that scenario is actually meeting the constraint.  You can perform scenario-based testing against a set of scenarios with specific constraints.

Walking the Scenarios
Have you ever been sold on a great set of features, only to fall flat when you try to actually do something useful?  Obviously, that's the extreme case, but it happens to me.  It happens less now because whenever I go to buy something, I walk my usage scenarios.  Doing a dry run against a scenario is very revealing.   This approach works great on the engineering side too.  It's one thing to have generic technical requirements for security or performance.  It's another to evaluate a scenario and make appropriate and relevant trade-offs from a user, business and technical perspective.  Suddenly, generic technical requirements no longer seem as helpful, do they?  They still have their place, but when you're engineering your job is to make the right trade-offs.

Scenarios and Solutions
Given part of my job is to improve customer effectiveness on our platform, I regularly use scenarios as a backdrop for evaluation.  As I've gotten more effective, I noticed shifting from features and components to scenarios and solutions is the key.

More Information

My Related Posts

Comments