Team Project (tP):
Week 9 [Fri, Oct 9th] - Project
tP: v1.2
- Deliver v1.2
- Wrap up v1.2
- Do an informal demo of v1.2 before the tutorial
tP: v1.2
1 Deliver v1.2
- The product must be working although the functionality is basic.
2 Wrap up v1.2
- Manage the milestone v1.2 as explained in the panel below.
Admin Appendix E(extract): Project schedule tracking
tP Project Schedule Tracking
In general, use the issue tracker (Milestones, Issues, PRs, Tags, Releases, and Labels) for assigning, scheduling, and tracking all noteworthy project tasks, including user stories. Update the issue tracker regularly to reflect the current status of the project. You can also use GitHub's Projects feature to manage the project, but keep it linked to the issue tracker as much as you can.
Using Issues:
- Record each of the user stories you plan to deliver as an issue in the issue tracker. e.g.,
You can break the user story into issue subject and description in this way:
| title | As a user I can add a deadline |
|---|---|
| Description | ... so that I can keep track of my deadlines |
Alternatively, you can put the entire user story in the description.
| title | Add deadline |
|---|---|
| Description | As a user I can so that I can keep track of my deadlines |
In both cases, apply the type.Story label.
-
Assign the
type.*andpriority.*labels to those issues. -
Formalize the project plan by assigning relevant issues to the corresponding milestone.
-
Define project tasks as issues. When you start implementing a user story (or a feature), break it down to smaller tasks if necessary. Define reasonable sized, standalone tasks. Create issues for each of those tasks so that they can be tracked.
-
A typical task should be small enough for one person to do in a few hours. eg.,
- Bad (reasons: not a one-person task, not small enough):
Write the Developer Guide - Good:
Update class diagram in the Developer Guide for v1.4
- Bad (reasons: not a one-person task, not small enough):
-
There is no need to break things into VERY small tasks. Keep them as big as possible, but they should be no bigger than what you are going to assign a single person to do within a week. eg.,
- Bad:
Implementing parser(reason: too big). - Good:
Implementing parser support for adding of floating tasks
- Bad:
-
Do not track things taken for granted. e.g.,
push code to reposhould not be a task to track. In the example given under the previous point, it is taken for granted that the owner will also (a) test the code and (b) push to the repo when it is ready. Those two need not be tracked as separate tasks. -
Write a descriptive title for the issue. e.g.
Add support for the 'undo' command to the parser- Omit redundant details. In some cases, the issue title is enough to describe the task. In that case, no need to repeat it in the issue description. There is no need for well-crafted and detailed descriptions for tasks. A minimal description is enough. Similarly, labels such as
prioritycan be omitted if you think they don't help you.
- Omit redundant details. In some cases, the issue title is enough to describe the task. In that case, no need to repeat it in the issue description. There is no need for well-crafted and detailed descriptions for tasks. A minimal description is enough. Similarly, labels such as
-
-
Assign tasks (i.e., issues) to the corresponding team members using the
assigneesfield. Normally, there should be some ongoing tasks and some pending tasks against each team member at any point.
Using Milestones:
Given below are the conditions to satisfy for a milestone to be considered properly managed:
Planning a Milestone (to do within the first week of the iteration):
-
Issues assigned to the milestone, team members assigned to issues: Used GitHub milestones to indicate which issues are to be handled for which milestone by assigning issues to suitable milestones. Ensured issues are assigned to team members. Note that you can change the milestone plan along the way as necessary.
-
Deadline set for the milestones (in the GitHub milestone). Your internal milestones can be set earlier than the deadlines we have set, to give you a buffer.
Wrapping up a Milestone:
-
A working product tagged with the correct tag (e.g.
v1.3) and is pushed to the main repo or a product release done on GitHub (example). -
CI passing for the version tagged/released.
-
Milestone updated to match the product i.e. all issues completed and PRs merged for the milestone should be assigned to the milestone. Incomplete issues/PRs should be moved to a future milestone.
-
Milestone closed.
- Wrap up the milestone using a git tag
v1.2. When the milestone deadline is near (e.g., 0.5 days before the deadline), if you think some of the ongoing work intended for the current milestone may not finish in time, reassign them to a future milestone.
- Do a release on GitHub. Uploading a JAR file to GitHub is optional.
3 Do an informal demo of v1.2 before the tutorial
- As we don't have in-class tutorials this semester, do the following in lieu of a live demo:
[one member] Run your app using the latest released versionv1.2(orv1.2b, if applicable). Take screenshots of each available feature in action. Add those screenshots to your collaborative project notes document with an appropriate heading e.g.,v1.2 features demo. Alternatively, you can screen-record a demo, upload it to somewhere, and post the link in the project notes document.