 |
|
|
In this phase of the project, you will prepare user stories for the project and enter them into an issue tracking system. These stories will help to organize your team’s work in the later phases.
Your reference materials for this phase include
Teams for this and the remaining phases will be selected by sign-up.
Go to the groups area in your recitation section on Blackboard. Each recitation section has been assigned an arbitrary color, and groups are available with names consisting of that color plus a number. Sign up for one of those groups.
All team members must be enrolled in the same recitation date/time.
You should only sign up as the 5th member of a team only if all other teams for that recitation have at least 4 members already.
After the sign-up due date I will arbitrarily assign students who are not signed up and will shift people out of 5-member teams to teams with 3 or fewer members. I may merge 2-person teams to create a 4-person team.
I will post an announcement when this has been done.
After signing up for your group, go to the CS350 Forge and log in to the RedMine issue tracker and to GitLab. * This establishes your credentials on each of those systems, which must be done before projects can be set up.
Within 24 hours of my announcement that the groups have been formed, post to your group’s discussion area:
Your name.
Your CS login name.
Your @odu.edu email address.
Once 24 hours have passed since my announcement of the groups being formed, the projects can be set up.
One team member should create a new project on the issue tracking system and add the other team members to that project (as “managers”).
Note that you cannot add people to a project until they have logged into the issues tracker for the first time. But they should have done this by now.
The project name should match the group name from Blackboard, dropping any blank spaces. For example, if your group is “Blue 2”, your project name should be “Blue2”.
On the New Project page for the project, make sure that the project is not public.
On the New Project page for the project, make sure that the “Agile” box is checked.
One team member should also create a new project on Gitlab and add the other team members to that project (as “developers”). The project name should be the same as on RedMine – your group name.
Again, this project should be private, not public.
Open a browser window to the two team project areas on Gitlab and on the Redmine issue tracker. On Gitlab, select the “Settings” for the project, then select “Services”, and then “RedMine”. Fill in the URLs from the issue tracker window (mainly, replacing “:issue_tracker_id” by the appropriate project string from Redmine.
Check the “active” box and save.
Your project area on Gitlab includes a Wiki. You will use this as the base for your project’s web page. In this phase, you will mainly be documenting your plans for the first two increments of development, corresponding to phases 3 and 4 of the project.
Set up the opening page of your group’s Wiki with three sections. The Membership section should contain a list of all members of the team.
The Reports section will, for now, be empty.
The Stories section should link to three pages titled “Roles”, “Increment 1”, and “Increment 2”. These pages can be empty for now.
Discuss within your team: What are the user roles relevant to this project?
In your Wiki, record your conclusions on the “Roles” page. List each user role and give a brief one or two sentence description.
Compose your stories. The sum total of your stories should span the required behaviors of the system.
Stories will be entered into the Redwine issue tracking (a.k.a. bug tracking) system.
In the later project phases, having these in the issue tracker will help in tracking who is working on what stories, which stories are completed, and which have not yet been started.
Each story should be entered as a “new issue” of type “User Story”.
Do not mark your stories as “assigned” to a team member. You will use that ability later when someone takes responsibility for implementing that story.
Ideally, a story should indicate a unit of work that a programmer can complete within a single increment of the iterative development process. For our purposes, that amounts to something that a student programmer could complete within a week or two. (That should take into account the fact that students are not assigned full-time to this project.)
For each story, enter the effort level expected in the “Estimated Time” field.
Important: Remember that each increment must add observable functionality to the system. That means that you must choose at least one story that generates visible output. Think in vertical slices!
At the top of each Increment page, add a paragraph or two of text describing what observable functionality will be available upon completion of that increment.
If you can’t do this easily, then you need to either redesign your stories or re-think your choice of stories for that increment.
Please remember that updating an internal data structure is not, in and of itself, observable.
And compiling your code and/or passing your unit tests does not count as functionality.
Then list the stories (one-line title/description each) that make up that increment. Each story should link directly to the issue page for that story.
After your work has been completed, each team member must individually take the peer evaluation survey. The purpose of this survey is to assess the relative contributions made by individual team members.
Evaluations will be a combination of what the group has accomplished and how much each individual contributed to that group’s effort.
This phase will be graded as
score = quality * indiv
where:
quality is an assessment of the completeness, correctness, and quality of the stories and Wiki pages prepared by the team.
indiv is a scaling factor for an individual’s effort. A normal effort level is 1.0. This factor will be raised or lowered by a combination of
As your stories are graded, I may make comments directly in your issue tracker (these will appear as comments in the story detail) or in the spreadsheet in which your overall evaluation is tallied.
Some shorthand annotations that I may use for common problems are:
Stories about getting the build to work or getting unit tests written are not of interest to the end users, only to the developers.
That’s not to say that there isn’t effort required to do this stuff. but the effort is generally considered to be factored in to the effort to implement “real” stories.
Almost any story that begins “As a programmer…” or “As a software developer…” will be ODC (unless the project is itself a library or tool for use by other programmers and developers who are not members of the system’s own development team).
Refers to stories that aren’t merely epics, but summarize the working of the entire system, or of major subsystems, in a single sentence. Such stories cannot be completed in a single increment and are unhelpful in breaking the development effort into practical units of work.
Examples would be “Evaluate all expressions in a spreadsheet loaded from a file.” or “Generate monthly sales reports broken down by customers.”
These epic stories need to be broken down. Ask yourself why you wanted to write this in the first place. Is this, for example, the only mention of a report? Then devise a story to generate that report from data already loaded and summarized in the system, so that the loading and summarization can be added as separate stories. Is this the only mention of reading data from a file? Then have a story (even if IB, see below) to load the data, and separate stories to work with it and to produce visible output after that work.
This describes stories that cannot be assigned as units of work during the development phase. Reasons might include that this is not done during development (e.g., system reliability and usability requirements must be measured after the development is completed), and/or is an over-arching concern (e.g., “maintain communication with end users”, “use pair-programming”, “satisfy all mandatory requirements”).
A special case of NUW, this describes stories that cannot be assigned as distinct units of work because they will never be finished until all development work is complete.
For example, you might have a requirement that the code must compile with the Java 8.0.1 compiler. But a story
As a developer, I want the code to compile with the
Java 8.0.1 compiler.
would be an NES story (_and_ an ODC story). You can’t assign it to someone as a unit of work and expect them to complete it, because as long as anyone else is contributing any code, they could contribute something that breaks the requirement.
Indicates a story that assumes a teammate will do a poor job on another, closely related story.
For example, suppose that you have a requirement stating that the system must keep sales data for a company’s customers and another requirement that the system must be capable of storing data on at least 500 customers.
If you wrote separate stories
As a ..., I would like to see sales data for customers.
As a ..., I would like to see that data for up to
500 customers.
the second story would be an MTAI story. It assumes that whoever implements the first story will not have read the requirements and so will choose an inappropriately small data structure to store the data.
A common special case of MTAI. People like to pad out their stories by focusing on error conditions and messages.
For example, you might have a requirement to read in and process a positive number, with a required error message if the number is zero or negative. That’s one story - it doesn’t naturally break down into a “read and process this number” and a separate “Print the error message if the number is not positive” story.
Anyone implementing the first story will naturally inject the logic required for the second story. Certainly it makes little sense to assign one person the error message story and someone else the read-and-process story (or even worse, to assign someone the error message story and defer the read-and-process story to a later increment). Yet, I’ve seen students who, after three increments of the project, have worked on nothing but printing error messages.
Be careful of stories like “As a …, I want the system to read a data file X.”
Reading data into an internal data structure is not an observable behavior. You might claim to have done this, but how does an end user know that you really have done it unless it directly affects the output somehow. (And, no, passing a unit test does not count because ODC.)
There’s two ways to deal with this kind of story.
1) Rewrite the story to establish a link to behavior, e.g., As a … I would like the customer listing to reflect only customers listed in the data file X."
2) Plan your increments so that an NVB story is paired with an output-generating story (e.g., As an …, I would like to see a report listing all customers.) and make sure that someone is assigned the output story before the input story, so that if you don’t finish all scheduled stories by the end of the increment, you still have a visible behavior to demonstrate to the end user.
Add comments in the tracker to your IB story indicating which out-producing stories it is intended to be paired with.
|
|