Process - HomeDivision/Choreless GitHub Wiki

How will you communicate with teammates you depend on?

  • Slack will be the primary communication tool to discuss technical details and to coordinate meeting times. This is a useful tool for us in this scenario because Slack performs well for group text-based talk as well as the notifications are good for notifying individuals or the team about issues.
  • Google Hangouts will be the primary point of contact for all remote meetings. Google Hangouts is an effective tool as it is easy to access, allows video and voice communication, and also supports screen sharing.
  • Facebook Messenger will be the final point of contact for informal online communication such as if a team member is running slightly late to a meeting or discussing homework that has just been graded. This is because we do not want to clutter the Slack channel with unnecessary messages that are not relevant to the overall project.

What coordination and planning practices will you follow?

  • Our team will perform weekly online or in-person meetings to discuss everything related to this class. At the start of each meeting Albert will give team members the opportunity to discuss roadblocks, project frustrations, or any other concerns. By providing this opportunity at the start of each meeting, it allows team members to have an opportunity to be honest about their thoughts on the project.
  • We will meet weekly every Thursday at 5pm. This meeting will be evaluated each week to ensure that the timing works for all members. In addition, we will have time to meet twice a week during each of the class periods on Monday and Wednesday. This allows us to always have a designated time to meet, but also gives us the flexibility to meet since we are a team of 5 students with various activities and workloads each week. By allowing the meeting times to be flexible, we can ensure that all team members have been able to make progress on the project and have topics to discuss for the meeting.

Who will own each of the components in your architecture?

  • Jeff is lead engineer and will oversee the interactions of each component, but we will individually own each component.
  • Navigation - Jeff
  • Login/Register Page - Albert
  • Join/Create Group Page - Isaac
  • Group Settings Page - Thomas
  • Weekly Calendar Page - Jimmy
  • Monthly Calendar Page - Jeff
  • User Settings Page - Albert
  • Firebase Admin - Thomas

By what date will you have a fully-built (but likely buggy) release candidate?

  • May 29th - Buggy release
    • The application will have all of the core functionality complete and all of the major requirements done
    • Bugs may exist within the software at this point
    • The chosen date gives us time to focus on fixing bugs before the final release on June 2nd. Also, since Jimmy will not be here for the release week of class, being able to dedicate time beforehand to fixing bugs will be useful for our team.
  • June 2nd - full release

What practices will you use to know if you're making progress toward that release candidate?

  • One form of communication will be at the weekly meetings about how the progress on each component is coming. Each team member will quickly describe what they are working on and what progress they have made. This will both allow us to see how far the project is coming, but will also incite team members to bring up any roadblocks they came across if their progress that week was low.
  • To confirm that a feature has been finished, the primary developer for that feature will go through the requirements checklist with two other team members to ensure that all of the core functionality was completed. By doing this sort of “peer review”, we hope to have less gaps in our code and confirmation that we are moving closer to our first buggy release.
  • To hold ourselves accountable for doing the peer reviews, we will always set aside time in class so that our team will always be required to dedicate time to do them. This does not mean members cannot do peer reviews outside of class (we encourage it!), rather this is just a block of time they we will dedicate to doing them. We will also keep other team members accountable by not allowing them to merge code to the master branch unless they have had a peer review.

What practices will you follow to improve your process if it's not working?

  • Our primary form of feedback will be during the weekly meetings when we perform retrospectives to see what is going wrong/what is going right. This works nicely for our schedules as it occurs during our meetings and allows other group members to contribute to and discuss any feedback.