The primary goal of SE2800 is to help you learn the fundamental elements of a software process that will help you develop the skills you need to create good software. By "good", we mean:
You haven't been exposed to all of these topics in your coursework yet, but
SE10x1, CS2852, SE2811, SE2832, and SE2030 have covered at least some of these
concerns.
At any rate, following a decent software process provides you with
a framework for meeting these goals.
Since software process is so central to SE2800, you'll be assessed (graded) on your demonstration of following the process as well as the resulting software you'll be creating.
There are multiple aspects of the process that you need to follow in every sprint:
While you will not be graded on how well your estimates are (for either Story Points or total Task Hours), you will be assessed on how consistent your effort is during the course of a sprint. This is because working steadily makes it easier to detect problems earlier, and make better forecasts for the remaining effort needed to complete the sprint. If you wait until the end to do the work, you won't know until the end that you have problems - and then it's too late to do anything about it. You'll be expected to log your work time in substantial portions for each week of the project. The work you perform should be clearly evident, based on substantial work artifacts (use cases, UI mockups, UML diagrams, test files, test code, implementation code) appearing steadily in your team's repository. It is not meaningful to log work without producing evidence of that work.
Rule: log your work at the end of each day you actually do work - the longer you wait, the more uncertain you'll be of the time you spent. Don't worry about precision; aim for accuracy. If you work for 73 minutes, logging 70, 80, or even 90 minutes is good enough.
Rule: when logging your work, re-estimate the remaining time left on your task(s). You'll acquire a lot of insight into the task as soon as you put time into it, and likely realize your original estimate was off (either high or low). That original estimate doesn't matter (and, again, doesn't affect your grade) - what's more important is that you keep the time for the remaining work to be done up to date, so that you and your team (and I) know your status and the entire project's status.
The PBIs and their subtasks that appear on a team's Scrum board provide another overview of the status of the sprint. Each subtask shows the remaining time needed to complete it, and also indicates whether a task is lingering in a particular state for a long time.
Rule: Any task actively being worked on must be in the IN PROGRESS (or BLOCKED) state, and have a finite (non-zero) amount of time remaining.
Rule: Any task with no time remaining is, by definition, complete. When tasks are complete, they should be moved to the REVIEW READY state, indicating that the result of the task (usually code, but also design diagrams or test files) can be peer-reviewed and integrated into the dev branch (see Repository Usage below).
Rule: Any task in the REVIEW READY (or DONE) states should have 0 time remaining.
Scrum teams typically conduct a 10-15 minute "stand-up"meeting at the beginning of each day. In a full-time environment, a lot of work can get accomplished each day, and it's vital to keep everyone on the team informed of progress and/or problems. In that environment, it's of course assumed you (and other team members) worked for 8 hours the previous day and split the time among the various tasks, but the amount of progress made is more important. It's also assumed that everyone has re-estimated their ongoing tasks, so that the team can use the Burndown and Scrum board to forecast remaining hours to completion and to identify potential problems in sprint execution.
Rule: In SE2800, you and your team will conduct a 10-minute "stand-up" meeting every Tuesday and Thursday to identify progress or problems, and to verify that the remaining times are accurate.
Rule: By the end of class on Thursday, you and your team will create a Status Report and publish it to Confluence (based on the SE2800 Status Report you can find in Confluence, which contains instructions for the content you are to provide).
While you may have committed directly to the dev branch of your team's repository in SE2030, this is prohibited (except in extraordinary circumstances) in SE2800 (and in professional practice in most cases). Keep in mind that the dev branch should always have some version of code that works - it certainly compiles and executes, although it may contain code that hasn't yet been thoroughly tested. As an individual developer, you should ALWAYS be working on a feature or defect branch. More than one team member may work with you on one of these branches, but the more isolated you are, the less chance you'll have of running into merge conflicts.
Rule: Feature and defect branches will contain the ID of the User Story, Internal Improvement, Knowledge Acquisition, or Defect in the Jira sprint backlog. This makes the purpose of the branch very clear. The branch name may include a short description as well as the ID. Example: "MHP1-14_GoogleMapsOverlay"
Rule: You will commit directly only to feature or defect branches.
Rule: You will push your commits to the remote consistently, as both a backup and as evidence of progress.
Rule: You will never commit directly to the dev branch (or master/production branch - if you even have such a branch).
When working on a feature or defect branch, you create or
modify the code base to implement the feature or fix the defect you're working
on. As you finish a subtask involved, it should be moved to the REVIEW READY
state (see Scrum board usage above). When all subtasks are in REVIEW READY, it
implies that you have finished the work AND TESTED IT and COMMENTED IT to the
best of your abilities - you are confident that it is good to go. This means
that your code can be integrated back into the dev branch - however, you must
first integrate the dev branch into your feature branch first to make sure that
other people's changes don't break the work you just completed. You do this
using the following commands (assume you are on the branch
"MHP1-14_GoogleMapsOverlay", and all changes have been committed and pushed on
that branch):
git checkout dev && git pull
#this switches to the dev branch gets the latest version of the dev branch on
the remote to your laptop. This ensures you have the latest code of the dev
branch on your laptop.
git checkout MHP1-14_GoogleMapsOverlay #this switches back to your feature branch
git merge dev #this merges the code from dev into your MHP1-14_GoogleMapsOverlay branch.
Usually, Git will be able to auto-merge the dev code into your branch. If your branch is ahead of dev, there will be no code to merge and Git does a "fast-forward". If code on the dev branch was updated after you had created your MHP1-14_GoogleMapsOverlay branch, Git will attempt to auto-merge the dev code into your branch. If you are working in separate areas of the application, this should happen automatically without conflicts. However, you may encounter merge conflicts here if you modified code in your branch that was also modified by someone else on their feature or defect branch which was then merged into dev. You will have to fix the merge conflicts manually in your branch and make sure the code in your branch still works, which possibly may require further code changes on your part, but at the very least requires re-running your tests. When done, commit and push your code to your branch. Next, issue the above 3 Git commands again - just to make sure that nobody else has merged their code into dev while you were fixing your merge conflicts. You may have to repeat the whole process again (and again)!
Once you have merged dev into your branch, use the Bitbucket web interface to issue a Pull Request to alert your teammates that you want to merge your branch into dev. The Pull Request gives your teammates a chance to review your changes and approve (or reject) them.
Rule: Use Pull Requests to merge your feature or defect branch into the dev branch, but only AFTER you first merge dev into your branch.
Rule: After your Pull Request has been approved, move your subtasks to the DONE state. Then move the parent PBI into the WAITING FOR VALIDATION state.
Ideally, all subtasks should be in the DONE state by the end of a sprint, and all PBIs should be in the WAITING FOR VALIDATION state. Your Instructor/Product Owner will validate your PBIs with you and your team, even though this may not happen until after the sprint end date. It is possible that your PBIs will not be validated if defects or other issues are discovered during validation. The status of the PBIs not meeting validation will be determined at that time, and then you will close your sprint.
Rule: At the end of a sprint, do not close the sprint until your Instructor/Product Owner validates your PBIs.
Production code that is distributed to customers is often merged into a master or production branch - the name of the branches varies with an organization, but BItbucket (unfortunately) creates a master branch whenever a repository is created. Only tested, release-ready code is put into the master branch.
Rule: Never merge dev into your team's master branch unless your Instructor/Product Owner asks you to do so.
Once your sprint is closed, you and your team will create a Sprint Report and publish it to Confluence (based on the SE2800 Sprint Report you can find in Confluence, which contains instructions for the content you are to provide).
The sprint is worth 400 points, assigned as follows: