shawndcarpenter / futbol

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Futbol

Starter repository for the Turing School Futbol project.

A 1-2 summary or bullet points outlining your plan for check-ins throughout the duration of the project

  • Specified/scheduled times to work on the project often async and in-sync when necessary
  • Every call to begin with referencing the Trello for us to update in accuracy
  • Slack for more casual check-ins that are less formal

A 2-4 sentence summary of your plan for project organization and workflow. This can include bullet points. If you plan to use a project management tool, please include a link to your project board.

  • As previously mentioned before, the team will be using Trello for our general organization especially to ensure that methods or rubric points are not overlooked

Example of Trello

  • Project is divided into Iterations as well as check-lists that will be updated as the team progresses through, due to the large number of methods required we plan to begin this project in-sync for the first few methods then divide the workload (~5-6 methods) for Iteration II
  • For Iteration III, we will refactor with one another,!

A 2-3 sentence summary describing the different approaches your group discussed for project organization and how you collectively made a decision on which to use.

We started off with researching each recommended method (Github Projects or Trello) and decided we liked the aesthetic and user interface of Trello because it felt easier to navigate. All of us in our previous paired projects had a more relaxed approach without the use of a workspace template and felt that this was a better approach to stay on-task and to continue efficient workflow with an expanded team.

A 2-3 sentence summary describing your approach to the code design.

The project will be separated into 4 conceptual classes including stat_tracker, game_statistics, league_statistics, and season_statistics in addition to the spec_helper, rspec, and runner files. Based on the Iteration II tables under Statistics, the methods will be divided as suggested. Additionally, each method is to have its own respective RSpec section of its class_spec file.

In regards to reorganization/refactoring, we plan to do this in Iteration III once the code is fully functional with use of inheritance, modules, and potentially clas methods.

Include link to your initial DTR document and the date it was completed. If you do additional DTRs later in the project, you should link the revised versions here as well with the date. New versions should be listed alongside older versions. Do not delete old DTRs.

DTR Document Completed by Team on September 18, Updated September 21 for 1 Week Check-In

Create a section in your README called “Contributors”. List each group member’s name and link to their LinkedIn and Github profiles.

Contributer LinkedIn Github
Anthea Yur antheayur chisPmama
Nurudeen Sulaimon nurudeen-sulaimon nurudeensulaimon
Samuel Tran sam-t-tran Sykogst
Shawn Carpenter shawndcarpenter shawndcarpenter

Retro

The name of and links (if applicable) to any tools you used for retro

We used a jamboard linked here. We found that it was the easiest way for us to add all of our thoughts individually with some level of anonymity if necessary.

Top 3 things that went well during your project

  • We reviewed each other’s code, so we’d have a decent idea as to how others approached methods, which helped us understand our own methods.
  • We for the most part stuck to our plans and got almost everything done by EOD Friday.
  • We returned to the DTR and discussed changes to be implemented based on what was and wasn’t working for communication.

Top 3 things your team would do differently next time

  • Set up due dates on Google Calendar. We realized about halfway through the week that not all of the work was getting done with self-assignments on Trello alone. We had discussed deadlines on call, but these were not adhered to (and group members had no reference to check on this matter).
  • Create a flow chart depicting how all the methods work with each other. We realized that there was probably a fair amount of overlap in method functionality.
  • Do project check-in times on a Slack thread similar to what the instructors set up in Mod 0. We were checking in and calling on Slack daily, but without a structure and physical messages, it was not seen as necessary and some concerns were not voiced in the moment.

About


Languages

Language:Ruby 90.7%Language:HTML 9.3%