-
Notifications
You must be signed in to change notification settings - Fork 2
Sprint 1 Challenges
Most team members were unfamiliar with 'git' and 'GitLab' prior to this project, and building the repository required guidance on virtually all aspects of the platform. In particular:
Using the command line for basic actions like staging, committing and pushing to remote was new to most team members. Prior to this, we mostly used the built-in git integration of our IDEs. Though it was not difficult to learn the commands, we were tentative when using them due to the permanent record left on the repository in the case of a mistake or oversight.
Understanding how to correctly phrase issue descriptions was a challenge as there was conflicting information on the matter. Members were unclear on whether user stories should be the standard or if natural language descriptions were sufficient. Eventually it was clarified that user stories were to be the norm in all issues except where illogical, such as in tasks of purely technical nature like bug fixes. It was also agreed that elaborations using natural language were acceptable in each issue.
There was lack of clarity on the expectations regarding the definition of our Milestones. More specifically, we were unsure of whether our Sprints were to be composed of multiple Milestones, or just one Milestone to represent the whole Sprint. This caused confusion and delay in our planning for Sprint #1. It was eventually cleared up that the latter was the correct approach.
A considerable source of confusion came from ascertaining what information was to be included in the Readme as opposed to the Wiki (and vice versa). Once again, conflicting information on the matter led to us having content in one that was more appropriate in the other, such as lists of requirements/user stories being in the initial Readme. With the guidance of our teaching assistants, good practice was eventually clarified.
Discipline with regard to all processes on 'GitLab' needed to be cultivated as team members familiarized themselves with the platform. Details like forgetting to change status labels or including issue numbers in commit messages were commonplace, but expected. Eventually, as we learned our way around it, these oversights lessened. This challenge was solved definitively by producing our Code of Conduct, which codifies concrete contribution standards and even includes a checklist for team members to memorize. When in doubt, we can fall back on this.
All of these challenges were overcome in large part thanks to Michal, who had thorough prior experience and mentored us in its use. Through the oversight of his expertise and the additional guidance of our assigned teaching assistants, team members grasped the core concepts and learned the checklist of
Microcontrollers in general were new to several of our team members and required much learning of the software used in harnessing them (Arduino IDE) and its corresponding language (C++ and C). The Wio Terminal specifically, as a relatively new piece of hardware, lacks the kind of documentation available on the internet that other more well established microcontrollers have, making it more difficult for us to learn about it and troubleshoot issues. In particular:
Our project required the parallel use of 5 physical sensors. We expected to be able to connect them all to the Wio Terminal's 2 grove ports using port hubs. However, this proved to be impossible, as the first grove port only supports 1 connection, and the second is an I2C port that our sensors did not support. This challenge was solved by making use of the 40-pin GPIO on the back of the Wio Terminal and connecting 4 of the sensors to its pins (and 1 to the grove port).
Terminarium Wiki 2023, DIT113, University of Gothenburg | Chalmers University of Technology, Sweden