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

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.

发表评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据。