Using Trello and Github for Senior Design

Posted on August 7, 2017 by Gabe Parmer

When you’re working on a team, you’re no longer just hacking away at a project at your own pace. Instead, you must coordinate between team members, ensure that they synchronize their work at the right points, figure out who is working on which bug/feature, and generally work toward a larger goal without stepping on each other’s feat. To aid in this, you’ll be using both Github and Trello to orchestrate your project. This document details a set of conventions that we will use for senior design. These ensure that we’re all using these technologies in the same way, and they are similar to the constraints that your Project Manager (PM) would impose on you at a company.

Trello

Trello is a technology that helps with project management, scheduling, and time management. It provides a nicely visual means of tracking different actions, categorizing them, assigning people to them, providing deadlines, and orchestrating the flow of the tasks that must be completed over time. You can find many tutorials on how to use Trello.

First, you should have provided your Trello user-name/email to Prof. Parmer and he can add you to the “GWU Senior Design” Team. Second, you can access to the “SD Template” Board. Do not modify it. You can by finding “… More” in the Menu, and choosing “Copy Board”.

The template board is populated with a set of tasks (cards), and a set of lists we’ll be using to track monthly progress. It should look a little something like this:

Trello and Sprint Planning Meetings (SPM)

Your sprint planning meetings are essential for enabling your mentor to track your progress, to help you move your project forward, and to provide a basis for your grade. If you don’t take these seriously, and prepare well for them, it will have a negative impact on your progress and grade.

The SPM meeting. In the SPMs, you will have 8 minutes to

  1. Describe why any cards with a deadline of the current SPM in the TODO column have not been completed. You should simplify this process by providing comments in the corresponding cards detailing the difficulties you’ve had that prevented you from finishing in time.
  2. Describe the “story” for the coming sprint (month). You should set up the card in the “Month-Granularity Planning” list for the month to tell this story. Each of these cards should include a checklist. Each item in the checklist summarizes a high-level task, and include a set of references to the actual cards in the “Backlog” that constitute this higher-level task. See the card for Sept that we’ve populated with a subset of what you’ll want to accomplish for the month.
  3. Include all of the tasks that you believe constitute sufficient progress for the sprint/month in the “Backlog”. Each of these cards should have their deadline set to the next SPM date. They are what you’re promising to complete for the sprint. Given that these are part of the contract between you and your SD Mentor, you cannot modify them aside from adding to them. Once your SD Mentor approves the story for the sprint, and these constituent cards, you must move them into “TODO this Month”. If you still have cards that you haven’t completed in the previous sprint in “TODO this Month”, you must leave them there, cannot change their deadline, and must complete them in addition to the next month’s worth of tasks.

Your SD mentor will likely ask questions to understand your story and cards, so be prepared to walk them through your cards.

Preparation for the SPM meeting. You must prepare for the SPM meeting. Given the organization of the meeting, you must spend significant time creating your cards for the coming sprint in “Backlog”, and summarizing them in the “Month-Granularity Planning” card. The easiest way to get a bad grade in this class is to not take this preparation seriously.

During the sprint/month. If you are currently working on a card, you will move it from “TODO this Month” into the “In Progress” list. As you work through your tasks for the month and complete them, you will move them into the “August Sprint - Done” list (replace “August” with the current sprint’s month).

You might also realize that one of your cards should actually be more fine-grained, motivating you to add new cards. This might happen when you learn more information about the system, and find out that more work is necessary. For cards that you add during a sprint, they are not part of the contract of work for the month with your SD Mentor, so you should not put a deadline on them. Other than that, treat them as a normal card. You are expected to generate a steady stream of cards throughout the sprint as sprint planning is never perfect.

During the Project Update meetings. Your group meets weekly with your SD Mentor. These meetings are to discuss weekly progress, and to use your mentor and peers as resources. Please come prepared to speak for maximum 9 minutes, and summarize

  1. your group’s progress over the week through the cards you’re working on and have completed,
  2. how they relate to the overall story for the sprint, and
  3. any difficulties or questions you have.

In these meetings, your SD Mentor is there to help. Make use of them accordingly. Note that they will be unlikely to be able to help you with deeper technical issues in these meetings. If you need that, schedule a meeting with them. In the end, you’re responsible for your own technical progress.

Github

Github is based on git and is your means of collaborating with others when writing and modifying code. I’m not going to do a deep dive into using git here, and expect that you can figure out the main features online. Some quick git tips can be found at the bottom of software engineering guide.

Github provides a wonderful set of repository management features online. You can go through the github bootcamp if you don’t know how to use it.

You can use git to coordinate between team members in many different ways. You must use the feature branch workflow pattern of interaction for senior design. Please read about the details there. At the highest-level, this means that each team member will be working on their features on separate branches, and will integrate them into the mainline to coordinate with everyone else.

Issues

In addition to interacting with github with git and issuing Pull Requests (PRs), you’ll be using github’s issues to track bugs.

Commit/Pull Request Frequency

Part of your grade will depend on steady progress. We will partially be evaluating this progress based on the monthly sprint planning meetings and your Trello tasks, but also on your commit and PR frequencies. You should focus on issuing PRs for individual features (or, often, sub-features), and you generally don’t want your PRs to be more than 400 lines of code.

When you issue a PR, make sure that you @-mention your teammates that could benefit from seeing the new code, or from doing a code review. Part of doing a PR is to get feedback from your team-mates. You can also construct a PR of relevant code if you want to go through it with your mentor.

Style

Please document in your repository (e.g. in the README.md) which coding style you’re using. It is important, when you’re working on a team to use a consistent style. It is more important to choose one and stick with it, than to choose the “perfect style”. You can find many different styles online, including

Many modern languages have prescribed styles such as go, and Rust.

Project Webpage

You must use Github pages for your project (see the gh-pages branch on your repo). For the most part, you have visual freedom with it, though you must only avoid posting inappropriate material. See the class’s submission guidelines for some required content: you must post as pdfs all written assignments, and all presentations.