G6046 Software Engineering
Seminar session: User stories and task cards Summary
This exercise is designed to ensure that you understand:
Creating user stories
Copyright By PowCoder代写 加微信 powcoder
Generating task cards
This will help you to understand the workflow that you will need to adopt for the Agile process model for the group coursework. Once you have created user stories and task cards, you should look at generating system requirements (functional and non-functional) from them. We will cover system requirements in class and through a seminar exercise.
To give your team a head start, we shall draw upon the group coursework user requirements from Watson Games (published on Canvas). The user requirements are a statement from our customer in their words as to what they want your team to deliver. Note that the user requirements do not tell us how to do something, just what is wanted. There is an important distinction between:
User requirements: from the customer (in their words and on their terms) – the “what”
System requirements: produced by the development team to support the development
process model – the “how”.
Our development process model needs to define how we convert the statement of what the customer wants into a fully featured and tested codebase that delivers, hopefully on time and on budget. So we needs a set of rules (the process model) to guide us. This is where Agile comes in.
Remember that Agile development consists of a series of iterative development cycles (“sprints”) where each sprint:
Starts with a user story – some part of the overall problem that we want to solve.
This can then be further broken down into system requirements, and we can then engage in
some appropriate planning, risk planning and design as appropriate.
User stories are broken down into task cards. A task card represents a specific part of a user story. A single member of the development team would typically take lead responsibility for
a task card (although more than one person can actually work on it).
Task cards can (and really should) be prioritised.
A sprint results in a working prototype. That prototype can then be shown to the customer
to get feedback, or can be internally evaluated against the user requirements.
Unfinished task cards and user stories can be carried over to the next sprint. But the product of a sprint should be a working prototype. So an unfinished task is carried over in its entirety
to the next sprint.
First example
Let’s start by producing a simple user story. We are looking for something for a first sprint, so choose something straightforward and core:
The game is for 2-6 players. Each player is assigned one of the game tokens. The tokens are: boot, smartphone, goblet, hatstand, cat and spoon. Each player takes a turn by rolling two dice to determine how they move around the board. At the outset, all players start on the board space labelled Go and move clockwise around the board.
For each turn, the player rolls the two dice. They move the number of spaces shown on the dice and arrive at a board space. Players move clockwise around the board.
These are requirements taken directly from the original brief. But what do we really need to do here? To deliver this “story” we would need:
A set of tokens
A dice and means to roll it
The ability to move a token around the board
Remember that the customer may have provided further clarifications on their original requirements in response to questions from teams. These clarifications are published on Canvas. At the design level it is now clear that we shall need data structures for:
The board (array? Map? Linked list? … all implementation decisions).
The player tokens.
The dice
We might also consider some kind of game controller to co-ordinate game play. These are all team decisions for you to make. So now we can come up with some possible task cards:
Task card 1 Priority: 1 Value: 10
A square 10 x 10 board shall be generated. The board functionality needs to be split between a data model and a GUI representation. When the model is updated, a call to the corresponding GUI shall cause the GUI to update. For this task card, only the model needs to be produced. The model shall need to fetch data on the content of each board square from a configuration file. The configuration file shall be stored in a plain text coding style and loaded as the game first starts. The configuration file format needs to be developed and documented.
Each board square can be a property/utility, a pot luck or opportunity knocks square, jail, GO, free parking as needed. The model needs to provide a means of recording what tokens are on each square, and a means of moving a token either forwards or backwards a specific integer number of spaces to support the dice rolling action. Backward movement can result from an action from the pot luck and opportunity knocks cards. In either case, the board should also be able to signal whether a token has passed the GO square by means of forward movement.
This is just one possible example. This should be something that one member of your team can take a lead on. You may also opt to adopt the pair wise programming strategy (try it out – you may well be surprised). You will also need to consider for this task card:
What design do you need to do? For example, for an OO implementation, what classes, attributes and methods are required?
How will you test the code that you produce? How might it interact with other tasks?
We will cover testing in classes. Here there is an obvious potential interaction with another task card – to produce a part of the user interface that displays the board. That can be a job for another member or members of your team. But to do this you will need to agree on some kind of shared Application Programming Interface (API) between the underlying data model (the business logic) and the presentation component (the GUI).
A good task card should:
Be a distinct activity that one person can lead on.
Clearly contribute to, and link back with, the underlying user story (and is thus addressing a
real requirement from the customer rather than just being your perception of what might be
Be achievable in the duration of a sprint.
Have some measure of relative priority (here priority 1 means “essential”)
Have some measure of how hard it is to achieve (to assist in planning and risk
management”). Here value 10 means that successful completion adds “lots of valsue”.
Be testable.
You will develop a feeling as a team as how much you can take on for each sprint.
Each user story will generate multiple task cards. A sprint can address one or more use story, but this will depend upon your capacity for work, and your collective ability. You should review how well you did at the end of each sprint and use your experience to help you shape the next sprint. With time, you will get better at selecting stories, tasks and setting an appropriate team workload.
See what further task cards you can generate from this user story. Or choose another user story and then generate some task cards for that.
There is no single right answer. Ask your seminar leader for help if you find it hard to get the process started.
Dr Kingsley Sage Dr
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com