Team Organization

Task Delegation

Task delegation is usually a fairly fluid process on our team. Especially near the completion of a bike, when we are frequently under pressure to meet a deadline, task priorities are constantly in flux as we try to meet the immediate needs of the team. The firmware lead is responsible for keeping track of all the tasks under way and their priorities. In general, you should be able to look to them for guidance on what to work on. Right now, we primarily use Jira to keep track of tasks that need to be done, which you can read more about below. All that said, there is quite a bit of flexibility in what we are able to work on. Because firmware is a smaller subteam and we don't have much pressure on us between bike development cycles, we are able to explore and work on interesting side projects to benefit the team in new ways. For example, ideas about using a CAN bootloader for flashing the bike and converting the whole codebase to Rust have been thrown around in the past. If you have an idea for an interesting new project that you want to be sure, feel free to bring it up to the firmware lead. So long as there aren't any time-sensitive or pressing tasks, there should be no reason you can't work on that independently.

Using Jira

Jira is a project management tool that we use to keep track of everything we are working on as a team, so everyone on the firmware team has easy access to it. As the firmware team grows, the ability to organize becomes even more important because it gets exponentially easier to lose track of what the team is working on. Because the team is doing so much, there is a lot of information on Jira, but it has a lot of different ways of viewing that information that makes the most important information easy to find. This section breaks down different features of Jira and should give you a good understanding of how it works.

Issue Types

Feature - Most common issue type; tracks a feature being developed for one of our repos
Administrative - Tracks a task that doesn't require code development
Bug - Tracks the development of a fix for a bug in a repo
Epic - Tracks a broader goal that consists of multiple issues; frequently used to track entire PCBs' development; stores links to other issues

Creating Issues

From any page on the firmware team Jira project, press the "Create" button in the bar along the top.
Select the appropriate issue type from the dropdown.
New issues should be created with the "To Do" status, except for some rare cases.
The Summary should be a brief description of the issue that is easy to distinguish from other issues.
Fill out the description according to the issue type.
- For feature issues, fill out the description and user story.
- For admin issues, fill out the description and add tasks.
- For bug issues, fill out the problem and any other sections needed to fully describe the bug.
- For epic issues, write a thorough description.
Assign the issue an appropriate priority. If you aren't certain, be sure to consult the firmware lead.
Label the issue with the firmware team project it's associated with, such as EVT-core, or a specific PCB.
- In general, the tag should follow the format of BIKE-BRD. If the board is used on multiple vehicles, it may not have a bike name associated with it.
If work is going to start on the issue immediately, assign it to the person who will be working on it.
If work is going to start on the issue immediately, add it to the current sprint. Otherwise, don't assign a sprint, so that it goes into the Backlog.
If the issue is associated with an epic, add that epic as a parent issue.
If the firmware lead has specific deadlines for this issue, they can be entered here, although we don't expect many issues to need this.
If the issue blocks or duplicates another issue, be sure to link it at the bottom of the issue.

Using Issues

All issues can be viewed easily in the Backlog view of the project.
When we decide we should target completion of an issue, it is moved from the Backlog into the sprint that we plan to work on it from.
When an issue is in an active sprint, its progress can be seen most easily in the Board view.
When you start working on an issue, you should assign it to yourself and move it from "Sprint Backlog" to "In Progress".
For each issue type, there will be some information you need to add to the issue, like "Definition of Done" on feature issues.
As you work on the issue, be sure to update it at the end of each meeting with what you were able to complete.
If the issue is a feature or bug, when you put up a Pull Request (PR), you should move the issue to "Code Review".
- To ensure the PR links properly, be sure the PR title starts with "FWT-###".
When complete, move the issue to "Done".

Sprints

Sprints are a way of grouping tasks into specified timeframes, so we can make short-term goals and quantify our progress at regular intervals. A normal software development team would have sprints of 2-4 weeks. Our team instead uses semester-long sprints because it makes much more sense for our development process. We only really have the time to dedicate to planning between semesters. Everyone's availability is also normally set on a semester-basis, so we can expect relative stability over the course of a semester.

Before the start of each semester, the team will have a sprint planning meeting, in which we discuss the plans for the coming semester. We will organize issues from the backlog into the next semester's sprint. We can also use this time to tentatively put issues into future sprints, but that should not be a big focus of the meetings. In any disputes, the firmware lead has the final say, primarily because the sprint can be modified later, meaning any mistakes can be fixed. Because there are so many issues, we should not spend much time on any particular issue.

Cross-Team Coordination

Although the majority of a firmware member's time is spent at the firmware table, there are many times that we have to reach out an coordinate with the other subteams of EVT. The firmware lead will regularly be meeting with the other technical leads and team manager to make high level decisions and keep the overall project on track, but all members will work with members of other subteams at one point or another. Most frequently, this will be meetings with members of either the Electrical or Integration teams.

Electrical Subteam

The Electrical Subteam is primarily responsible for designing and populating all the boards for our bikes. Because they have full control over the hardware we have to work with, keeping close ties to this team is extremely important. We need to make sure we are aware of all the components they are putting onto the board and how they can be controlled by our code. We want as much notice as possible about new drivers that might need to be written or new chips that need to be supported. We also want to make sure they are including as many debug options for us as possible, so we can quickly and efficiently debug the hardware when it is finally built and in our hands. Lastly, we want to work with the hardware team on a state diagram for each, so we have as much understanding as possible about the functionality of the board. This also helps the Electrical team double-check their hardware design and reconfirm the validity of their design decisions.

Integration Subteam

After a board has been created and validated, the Integration Subteam is responsible for integrating it with the other boards and the bike as a whole. At this stage, little mistakes in the hardware and software of each individual board usually begin compounding on each other to the point that a whole team needs to be dedicated just to debugging. The integration team is made up of primarily electrical engineers, so they are able to debug a lot of the hardware and usually a bit of the software, but they need the help of the firmware team to fully understand the software. The exact number of firmware members working with them normally fluctuates as they are needed, but integration is the last step of the development process, so working with them is usually the highest priority task.

Page updated

Report abuse