Agile Modeling and TDD Workshop, by Craig Larman (1)

The vision is to make a monopoly game, computer game. Monopoly is a board game which is named after the economic concept of monopoly, the domination of a market by a single entity. The board looks like below
Sample Monopoly Board
 
E-version computer game is the product we are going to develop.
 
First, find out use cases by drawing use case diagram. Use case is a description of a system’s behaviour as it responds to a request that originates from outside that system. The use case technique is used to capture a system’s behavioural requirements by detailing scenario-driven threads through the functional requirements. Which looks like below
Sample Use Case Diagram
 
In this workshop, our use case diagrams are very simple. One group has "Human Player", then "Play Monopoly" and "Handle Options"; another group has "Player", then "Play" and "Admin".
 
Then, start from one specific use case, identify top level user stories, which follows the "As a <role>, I want <feature>, so that <motivation>.". Top level user story is too big to implement, we need to split it into smaller user stories. User story is a software system requirement formulated as one or two sentences in the everyday or business language of the user. The sentences are really simple, for example :
  • As a customer representative, I can search for my customers by their first and last name.
  • As a non-administrative user, I can modify my own schedules but not the schedules of other users.
  • Starting Application
    The application begins by bringing up the last document the user was working with.
  • Closing Application
    Upon closing the application, the user is prompted to save (when ANYTHING has changed in data since the last save!).

The format sentence is normally written on index card, besides Card, other two important parts of the user story practice are Conversation and Confirmation. An reference article for more information on this.

We made several user stories, which are visible in same pictures above together with use cases. After split into several small enough stories, we picked one small user story to start implementing.

Now stop for a while, there are several user stories, sizing from epic, theme to finegrained, before start product development, we need the product backlog. Excel would be a simple tool for product backlog management, together with it, using wiki pages to record detail information of product backlog items.

We used google docs to quickly create our product backlog, with the product backlog items’ descriptions, links to wiki for more details, value, risk and effort. wiki site name is modified to remove confidential information.

Below is the picture captured of our main wiki page for the Monopoly game.

About Kaveri, Yi XU

Agile Coach & Consutlant
This entry was posted in Agile&Scrum&Testing&TA. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s