Skip to content

Team-EKG/project-prep

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
 
 
 
 

Repository files navigation

Team Agreement

  • Guy Farley
  • Katharine Swilley
  • Elizabeth Hammes

Guy

Key strengths:

  • Handling ambiguity
  • Integrity
  • Project execution

Professional competencies that Guy wants to develop greater strength in:

  • Pair programming
  • Craft: How to use tools in my toolbelt to solve problems

Elizabeth

Key strengths: Organization Collaboration Detail Oriented

Professional competencies to further develop: Explore tools Creativity

Katharine

Key strengths:

  • Collaboration
  • Inclusivity
  • Process

Professional competencies that Katharine wants to develop greater strength in:

  • Technical
  • Confidence

Conflict Plan

What is the team's process for resolving conflict?

If a team member has a conflict with one member, that member will first try to resolve the issue with the other member directly. If the issue is not resolved, the two members will discuss with the whole team. If the whole team is still not able to reach a solution, the team will seek guidance from an instructor or TA.

Issues of one member "taking over" the group

Similar to a general conflict, if a person feels that one member is taking the group over, they will discuss with that person, and escalate to the group, and then an instructor/TA as necessary.

Issues dealing with differing skill levels and understanding

The sanctity of learning will be preserved, and if a group member is struggling with a concept, it will be used as an opportunity to learn from another group member who is more comfortable with a concept.

If a member(s) is/are not contributing to the group

During morning stand-up, if a member is feeling that another is not contributing, they can voice that concern; the first question to be asked after that is if the person who is not contributing has something going on, whether it is an issue with the group or a personal issue, and the other group members can help in any way or what can be changed to help the person be more involved with the group

Communication plan

Communication hours

The members have agreed that messages can essentially be sent at any time, as everybody has personal settings on their personal devices so as to not receive notifications during desired time windows. The bigger issue is when messages are expected to be responded to. Team members are expected to respond within 30 minutes to an hour within the normal business hours (start at morning stand-up, end at 6pm Pacific). Outside of that time window, communication is not expected until the next morning or specified meeting time.

Breaks

We will strive for a general rhythm of 50 minutes of work and 10 minutes of rest. Lunch breaks will be an hour long.

Falling Behind

If the group begins to fall behind schedule, work hours can be extended as needed, but no later than 8pm Pacific. Loop in a TA or Ryan for additional help in an extreme case.

After Hours

Addressed in Communication Hours

Ensuring everyone is heard and the group is psychologically safe

Every morning after the stand-up with the instructor, the team will have its own stand-up where the previous day's work will be reviewed, the current day's work will be addressed and assigned, and members will be given the opportunity to address any concerns they have.

Work plan

  • Trello board to be higher level, and will flesh out detailed tasks first thing in the morning
  • First thing in the AM: Discuss features to be completed for the day
  • Work on small pieces individually (or as pairs if needed) and come back together frequently to merge

Git process

  • All aspects of the project will be contained on GitHub and members' local machines.
  • Repos will be shared and accessed on GitHub.
  • All work will be done on feature branches, then pushed to dev upon team agreement. Pushing to main will be reviewed by 2 other team members.
  • After cloning to local machine - from main: git checkout -b [newBranch].
  • Do not return to main until time for adding final product.
  • Each day's work will be a branch off of the dev branch.
  • From dev: git checkout -b <that day's feature>.
  • Merges to dev will, in general, be performed around lunch time every day and before logging off for the night.

Project Planning

Project Summary Project Planning

Wireframe

Invision

wireframe 1 wireframe 2 wireframe 3 wireframe 4

Database Schema

db-schema

UML

UML

About

Planning and documentation for the Binge App

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 2

  •  
  •