Revised: 12 February 2014
This project consists of:
- Execution of (and reporting for) one sprint of the project planned in Lab 4.
- Sprint review
- Sprint retrospective
- Stand-up meeting at beginning of each period (class or lab) of team work.
- Each team member provides answers to the "three questions".
- Corrective action (e.g., plan update, task assignment changes, etc.) taken quickly, or scheduled for discussion.
Definition of "done"
- Design documentation updated and committed to repository (as needed)
- Code (including unit tests) completed/updated and committed to repository
- Peer review (with report in task comments) completed
- All tests passed (not just the ones directly related to the task in question)
- All related entries in Atlassian Agile (JIRA) completed.
This is a working list of things that will be graded in the SE-2800 Project:
- Time logged to project.
Review your logged times to make sure they correctly reflect the time you spent on the associated tasks. If there are significant discrepancies in the time spent by different team members, they should be explained in the team or individual sections of the project report. Be sure to update the estimated remaining time, and set that estimate to zero when a task is done. Also, be sure to include a description of what was worked on; in many cases, this can be the same comment as used during Bitbucket commits (see below).
- Bitbucket commits documented with value-added comments.
At a minimum, put the story tag (e.g., "SEESA-99") in the commits, but add a few words capturing what improvement you made. "Added file abc" or "modified abc" are not value-added comments; one can see that easily in the Bitbucket logs. It is expected that all group members will have a significant amount of Bitbucket activity.
- Javadoc or other code-level documentation.
Ensuring documentation is present is part of the task for code reviews.
- JUnit tests covering all code you wrote, or at least as much as feasible.
- Evidence you did hold reviews and correct issues.
This will probably be captured by a simple report you make at the end of the project.
- Project report written by each team briefly documenting the following:
- Results of daily scrum meetings
You don't need a detailed log, but you should have information about what sorts of things you discovered during daily scrum meetings, especially any issues that were revealed during the meetings or caused changes in how you executed your project work.
- What was accomplished by the group.
This should be more than a simple list of story identifiers or tasks. From the user's point of view, describe what is being delivered at the end of this sprint.
- A list of contributions by team member.
Again, this list should not be a simple list of tasks, but a more abstract description of how each team member contributed to the project.
- A table listing the reviews (story or task) that were conducted and a summary of the action items from each review.
Keep your summary brief; for instance, "missing documentation for half the methods", "fixed error in parsing dates", or "added test for empty file" would be adequate.
- Notes from your sprint review and retrospective.
- A list of the things that went well in this sprint.
- A list of the things the team would need to improve in future sprints.
- Lessons learned (one section for each team member)
- What was the most important thing you learned from the project exercise?
- Briefly discuss one thing you will do differently in future projects to improve your (and your team's) software development process.
- An assessment of the quality and quantity of your own work on the project.
- Other comments on your project experience.
- Additional items as identified by your instructor.
- Results of daily scrum meetings
- Project report submission
- The project report should be in a single PDF file named "SE2800-teamNN-Project.pdf", where "NN" is your team number (e.g., "03").
- Submit it in the top-level directory of your team's Bitbucket repository.
- The report is due Sunday evening, 23 February 2014.
Note that number of features implemented is not a critical issue. You are expected to implement a substantial portion of the system, but your grade will be based more on the process, documentation, and system robustness than the number of features you have implemented.