Trex Cross Pol DTR

Trex-DTR

### Template for DTR Memo

Project: Trex

Group Member Names: Alyssa, Brianna, Emily, Stella, & Will

* What are each of our learning goals for this project? What drives us in this project?

Alyssa: Inight into the backend (languages/frameworks)/React Native

Brianna: Inight into the backend (languages/frameworks)/React Native

Emily: Inight into the backend (languages/frameworks)/React Native

Stella: Inight into the front end (languages/frameworks)/GraphQL

Will: Inight into the front end (languages/frameworks)/GraphQL

* What is your collaboration style? How do you feel about pair programming vs. divide-and-conquer approaches?

Alyssa: New stuff so more collaborative. Divide in conquere on things we're familiar with

Brianna: New stuff so more collaborative. Divide in conquere on things we're familiar with

Emily: New stuff so more collaborative. Divide in conquere on things we're familiar with

Stella: New stuff so more collaborative. Divide in conquere on things we're familiar with

Will: New stuff so more collaborative. Divide in conquere on things we're familiar with

* How do you communicate best? How do you appreciate receiving communication from others?

Alyssa: Be kind, communicate often, & in person/in PR's

Brianna: Proactive and honest communication

Emily: Honest and often. Slack

Stella: Kind, specific, actionable, and timely. Slack(group chat)

Will: Honest and direct, communicate struggles 

* How would you describe your work style?

Alyssa: Collaborative, communicative, cool. Group decides on big decisions and work on smaller parts alone

Brianna: Don't interup when working alone, others explain code that is a little fuzzy, realistic expectations

Emily: Go with the flow, work on whatever. I prefer paired programming to start then breaking off when stuff is locked down. 

Stella: Pre-planning, organization, same page, acurate reflection of project board at every step. Remote paired programming, driver navigator

Will: Go with the flow, code in large chunks of time. Up late. 

* What are each of our strengths? How can our strengths complement each other?

Alyssa: TEAM, good teammate

Brianna: Stay calm, no freakouts. Emotional pulse, encouragement to take care of yourself

Emily: Stay calm, good Navigator

Stella: Asking for help and timeboxing struggles

Will: sticking with tough problems. try try try. Google Fu

* What’s gone well or poorly in your previous projects?

Alyssa: Well: Identifying issues and addressing them Poor: Broken code being pushed up(tests)

Brianna: Well: Good planning, checking in, communication Poor: Perfectionist or overworker resenting people on the team

Emily: Well: Good planning, just start! Poor: Time management, not moving on

Stella: Well: Clear expectations, prioritize team dynamic over perfection Poor: Lack of communication, merging large code blocks and breaking shit

Will: Well: Clear direction, everyone has a part. Poor: Taking irrelevant advice, too much rigidity

* How will we set direction and make decisions as a team?

Plan plan plan, as a team! Every other day standup (can be altered depending)

* How will we overcome obstacles?

Communication, planning, story board, reach out, meet human needs

* What do you need (resources, environment, communication) to do your best work?

Alyssa: Clear expectations, same page, row with the flow(of the project)

Brianna: Agreement on codebase (formatting, style, testing), be respectful of people speaking

Emily: Clear Expectations

Stella: Direct and clear communication, meet wherever is most convienient for team

Will: not all days at Turing

* What scheduling restraints do you have? What are your scheduling preferences?

Alyssa: Meeting in Boulder @ 9AM so late to school that day.

Brianna: 10/22 DeverScript meetup @ 6-9

Emily: 10/23 coffee meeting at 12
       10/22 DeverScript meetup @ 6-9

Stella: N/A as of now

Will: Leave most days at 5pm from school

* What is your style for giving feedback? Does anything ever hold you back from giving feedback?

Alyssa: Wrapped in kindness, give feedback often. Hold back: defensiveness

Brianna: Lead with inquiry Hold back: combative(but not really)

Emily: Calmy try to discuss things Hold back: crying

Stella: Kind, specific, actionable, and timely

Will: Informal, conversational 

* What do you identify as being your biggest strength(s) technically, as they relate to this project? Where do you feel you could use improvement in your technical skills, as they relate to this project? How can our team help support you in improving these skills?

Alyssa: React/Redux

Brianna: Testing

Emily: React/Google Fu

Stella: Ruby on Rails/TDD

Will: API's/using&building

* What tools do you want to use to manage the project?

Github Pages: Story Board

* How do you want the group to solve problems when members run into issues with features of the project?

Reach Out, don't struggle fo too long.

* How do you know if a project is successful? How can we achieve that as a group?

Win demo comt(lol). Meet MVP, we all still like each other at the end. User test with non-turing people. Accessible

* How will we recognize each other's successes and celebrate them?

High fives, celebrating small success, alloance to take breaks

Any additional questions that you would like to add:


Day 1 Agenda: 

DTR
* Initialize your repositories (don’t write any code just yet!)
* Set up your scrum board with Github projects. You’ll be requireed to use a single board for all repos. This will make it easier to see what everyone is working on during the project.
* Each student create your goal for something you would like to learn about the other stack (BE student creates learning goal for something about the FE, and vice versa)
* Normalize on git workflow (we recommend using a “rebase” workflow, as opposed to “merge”, as it is most common on the job) - use a PR template
* Determine MVP (knowing it could change as the project continues)
* Create user stories
* Create wireframes
* Construct schema design
* Decide on rough tech stack

Additional Notes:

Git Workflow:
-DO NOT MERGE YOUR OWN PR's
-At least 1 person must (actually) review a PR
-1 branch 1 piece of functionality
-1 commit per method
-Deal with git merge conflicts locally
-Always comminicate when a PR has been posted or merged
-Communication via github 
-Don't merge straight to master
-Pull master before pushing up
-Set up CI
-ALWAYS KEEP PROJECT BOARD UP TO DATE!