Stand-Up
What have you done, what are you doing, what are you yet to do?
Adam and Moad
- Allow to use middle mouse click to open from viewlets pinned #14453 [3]
James, Myoran
- Ctrl-Up and Ctrl-Down don’t advance cursor when hits page limit #2091 [5]
Retrospective
The board at the end of the first sprint.
Points to note: A ‘Rejected by Admin’ category was added to board. It is important to consider that the work completed may well not be accepted by the VSCode team.
The group decided to run their retrospectives using a traffic light system.
Green – Things that went well, the types of things we want to replicate
Amber – Things that went okay, but definitely need improving. Also, things that we learned that we must remember for the next sprint.
Red – Things that went badly. Issues that occurred that we must ensure are never repeated again.
Green
– Pair programming within a formal environment produced a high work output.
– Idea communication was good. The discussion of potential problems and the way in which we assigned those problems was good. Group discussion!
– The setup and use of the Trello board was good.
– Keeping the Trello cards up-to-date was fantastic. The use of check-lists to monitor workflow was highly effectively. The useof the comments section to engage in a discussion regarding the issue at hand was also excellent.
– The use of Discord for James and Myoran to work was good. No issues and when remote working is recommended over Skype and Slack.
Amber
– Trello board was good, but adaptions needed to be made. A rejection category needed to be added as well as adaptions to ‘current sprint’ category to aid workflow for the following sprints.
– Pair programming for exploration and discussion around resolving an issue, but actual programming/implementation could be done singularly, as in, by ourselves.
– GitHub hasn’t particularly been used well, it has been used to pull down the code but nothing else (see GitHub point in red section)
– Points scaling needs re-thinking. Need a way that contextualises workflow within a student schedule. This means lower points, and more accurately reflecting the hours of put into the work. Developers put in around a normal days work (6-7 hours) on a 3 pointer. We need to consider accurately predicting the tasks.
– Getting an actual debug instance running for the project can be an issue. Moving from machine to machine can become time consuming. This can only be resolved by using the same machine, or developers become to familiar with the process they can resolve the issue(s) straight away.
Red
– Lack of pizza/free stuff from SCRUM master
– Create branch and actually utilise GitHub. We need a commit/push history going to accompany our workflow. This is key for the assessment.
– Actual pair programming seemed ineffective. The actual resolution of bug fixes is better resourced by a single developer, the scale of the problem does not give itself to pair programming practices.
– Pair programming logs, seemed totally useless. Comments on Trello card were used instead.
– UML, seemed pointless due to scaling of problem again. The problems are already well defined, and we’re mainly completing bug fixes/side features. These do not require UML diagrams.
Kicking off Sprint 2
The new Trello board:
Burndown Chart – Sprint Cycle 1
Sprint 1 Review
Sprint 2 Predictions
