Process - sheared-sasquatch/sparkclips GitHub Wiki

How will you communicate with teammates you depend on? Describe specific tools or settings.

  • We will Slack each other politely.
    • Why: We want to be polite because we want to promote good team dynamics. Slack has been our main method of communication since day one of the project and every member of the team has been consistently responsive.
  • We will also text each other for time sensitive or urgent things (we have already collected each other’s phone numbers)
    • Why: Some of our team members are much more accessible via text message than they are over Slack. To be cognizant of that, we have agreed to all be more responsive over SMS than Slack for urgent situations.Time sensitive tasks should also be discussed on Slack if applicable (if media needs to be exchanged for example)

What coordination and planning practices will you follow? Identify daily scrums, sprint planning meetings, ad hoc meetings, or other ways of coordinating work.

  • We have scheduled meeting times right after class Monday and Wednesday. This meeting only takes place if we need it, we decide this as a group on a day by day basis.
    • Why: Every team member is available after class on both Monday and Wednesday. We have used Slack as well as in class time to coordinate in the past and it has been very effective so we do not see a need to have regular weekly meetings scheduled.
  • We will be using Slack in order to coordinate work
    • Why: Using Slack to make sure everyone knows what functions of the application each person is working on which will help ensure we are not duplicating effort. Additionally, Slack will be used to keep everyone up to date on Git activity (merges and commits) in order to reduce merge conflicts.

Who will own each of the components in your architecture?

  • Server side Sam - Kyle
  • Client side Cody - Derry
  • Hairy Database - Nate
  • Blob Bob - Luis
    • Why: Each team member picked a component to work on based on their background and interest. They will be responsible for its completion. Everyone however is responsible for staying in the know about others work, as the team is small and this helps keep the code consistent.

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

  • May 15th is our first scheduled release candidate
    • Why: May 15th is a good release date for us as it avoids the final crunch time for two our members who are taking Capstone this quarter. We should be able to flush out most if not all requirements. May 15th is also a good day because we would technically be completing the project ahead of schedule, leaving us enough buffer time (2 weeks) to tune our project in case some of the requirements were not met. What practices will you use to know if you're making progress toward that release candidate? We will use Github Issues to keep track of our process towards our release candidate Why: We are using Github to host our code already, so it is easy for us to use their built in issue tracker and milestone functionality to track our progress towards our release candidate.

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

  • We will bring up issues as they come up during our weekly meetings and avoid bringing them up via Slack. We don’t want to talk about issues with our process over Slack because we can discuss disagreements more effectively in person.
    • Why: In person communication, while not abundant among busy college students like ourselves, is key for working over process changes and figuring out what isn’t working. Furthermore, asynchronous communication is not very conducive to process changes. Our meetings before, during and after class are opportunities for us to discuss the week ahead and plan further meetups if issues arise or extra work is needed. From there we can assign any tasks or work that needs to be done, and which can be done easily while not in meeting.