Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Here's an example Scenario Frame my team is creating to evaluate Source Control in VSTS 2005:
Scenario Frame Example
| Accessing Version Control |
| A developer uses Team Foundation Version Control from outside of Visual Studio 2005 |
| Administration |
| A development team manages user permissions |
| A development team manages roles |
| Branch/Label/Merge |
| A development team plans to isolate code to allow concurrent development |
| A development team produces a build that they plan to maintain going forward |
| A development team produces a build they do not plan to maintain going forward |
| A development team merges changes from one branch to another |
| Check-in |
| A development team sets check-in policies |
| Checkout |
| A developer prepares to make a code change |
| Distributed/Remote Development |
| A developer works from a remote ___location |
| A development team works from a remote ___location |
| Migration |
| A development team migrates existing source code into Team Foundation Version Control |
| Project/Workspace Management |
| A development team sets up a new project |
| A developer creates local workspace to isolate code changes from the main branch |
| A developer merges a local workspace into the main branch |
| Reporting |
| A developer reports on file level information |
| A development team reports on project level information |
| A developer customizes reporting |
| Shelving |
| A developer shares code with another team member |
| A developer backs up pending changes on the server |
Here's an example expanding the Branch/Label/Merge category above:
Branch/Label/Marge
| A development team plans to isolate code to allow concurrent development |
| A development team creates a branch to enable development on a high-risk, large-impact change |
| A development team creates a branch to enable development on multiple future versions |
| A development team creates a branch to isolate teams in a very large team |
| A development team produces a build that they plan to maintain going forward |
| A development team creates a branch that contains an interim (beta) release of their application |
| A development team creates a branch that contains a major version of their application |
| A development team produces a build they do not plan to maintain going forward |
| A development team labels a set of file versions that represents a continuous integration build |
| A development team labels a set of file versions that represents a daily build |
| A development team labels a set of file versions that represents an internal alpha build |
| A development team merges changes from one branch to another |
| A development team forward integrates a change from one branch to another |
| A development team reverse integrates a change from one branch to another |
| A development team wants to merge a change into a branch that is not a direct parent or child |
What's your favorite tool for framing out problem spaces?
Comments
Anonymous
February 21, 2007
When I tackle a problem ___domain, I first frame out the space. To do this, I list out scenarios and sub-scenarios.Anonymous
September 10, 2007
Our Scenario Frames for Team Foundation Server are available on CodePlex. We have Scenario Frames forAnonymous
October 15, 2007
Scenario-driven engineering means using scenarios to organize and focus your product design, developmentAnonymous
July 22, 2008
When I ramp new folks on the team, I find it helpful to whiteboard how I build prescriptive guidance.