Starter repository for the Turing School Futbol project.
-
PLAN FOR CHECK-INS
- Stand ups tentatively scheduled at 8:15 daily. To include:
- Review and update project board
- Plan next steps
- Assigning methods
- Announce (not solve) bug/code problems and plan on next steps to troubleshoot
- If relevant, address any personal or team conflicts
- Stand ups tentatively scheduled at 8:15 daily. To include:
-
PROJECT ORGANIZATION AND WORKFLOW
- We will use Trello to assign tasks and monitor progress on those tasks. We will use our daily stand ups to update our Trello board and make changes as needed.
- Git workflow
- Try to create branches by feature and do a pull request when a feature is completed
- Send a message in Slack after you make a pull request (mark urgent as appropriate)
- Respond in Slack if you are able to review
- Segment off sections for each method to try to avoid merge conflicts
- Try to create branches by feature and do a pull request when a feature is completed
- https://trello.com/b/G0pyWoBa/futbol
-
PROJECT ORGANIZATION TOOLS
- We decided to use Trello because it was a new tool that we were interested in exploring. Devlin also had limited experience using Trello and found it user friendly and simple to use.
-
CODE DESIGN APPROACH
- Attempt to create compact classes with single responsibilities
- Try to group methods together in logical chunks
- Create sample data from larger CSV files to facilitate testing
- Identify opportunities to streamline code and refactor as appropriate
-
DTR DOCUMENTS
-
CONTRIBUTORS
- Alora Riley
- Danielle Cardona
- Devlin Lynch
- Natasha Vasquez
-
RETRO
- Tools used for our retro
- How to Run an Effective Project Retrospective Meeting:
- We chose to complete our retro using Jamboard because it is a tool that we are all comfortable with. We also agreed that Jamboard would allow us to easily document our thoughts.
- Top 3 things that went well during our project
- We communicated well and were responsive to each other's requests
- We had compatible working preferences and were all comfortable working independently
- We learned a lot from reading other team member's code
- Top things we would do differently next time
- implement a system to avoid merge conflicts, such as segmenting off sections of files for each team member to work on
- diagram/pseudocode to analyze difficulty level of methods
- Tools used for our retro