Establishing Group Norms and Project Design

Back to Futbol Home

Group Norms

Your group should plan and expect to spend at least the first full project day on iteration 1. We’ve provided some resources to guide this iteration, however you are encouraged to explore on your own and come up with a plan that works best for your team.

Git Workflow Expectations

You’ve already spent a lot of time this mod working with git and git workflow. Now, you will be collaborating with three or more people for the first time. Spend some time with your group reviewing git workflow and determine the workflow that will be best for your group. While you have flexibility as to what this means for you, it should include the use of branches and pull requests for merging changes. We never want to merge directly to main.

Communication and Collaboration

We have a lot of tools for facilitation good communication and collaboration in our group. Many of these tools you will use on the job as well: Slack, Github, giving and receiving feedback, pairing techniques, and performing a DTR before beginning work with a new team. Set expectations with your team about how and how often communication should be happening. Remember, communication doesn’t just mean live (or on Zoom). Communication can be asynchronous when we do a code review or leave messages in Slack that don’t require an immediate response. Good communication can mean letting your team know you’ll miss the morning check-in because you have a doctor’s appointment, or apologizing if you forgot a meeting and detailing your plan for getting caught up.

Project Organization, Planning, and Design

This topic will probably be the one with the most unknowns for the group. We’ve provided a lot of resources on code focused workflows and communication, but we haven’t talked much about how to organize projects. This is up to you!

Your group should research different methodologies and tools for project organization. You might choose to use an issue tracker like Trello or Github Projects. You might decide to use things like calendar events to plan meetings and check-ins. It’s also important to not overdo it. There are so many ways to organize projects. You don’t need to do EVERYTHING. Pick one or two things to try out and see how it goes. The expectation is not that you run a perfect project, but that you start practicing with some of the tools and get a feel for what works well when building software with a team.

Code Design

The following tools are helpful for collaborative design: Miro, Figma, and Draw.io.

There are a few things to consider when deciding how you want to organization your code:

• What classes do you need?
  • Classes should be compact.
  • Classes should have a single responsibility - you should be able to describe what a class is responsible for in one sentence.
• Use the tools we have learned recently when thinking about reorganization - Modules, Inheritance, Class Methods, and Plain Old Ruby Objects (POROs).
• What makes the most sense for how to break this out in to pieces that individuals or pairs can work on. Odds are, you won’t be mob programming the entire project.
• How will you determine when something is “good enough” to move on to the next thing (potential to refactor later)?

Deliverables

Your iteration deliverable is to create a README with the following. As you craft your answers, consider how you might talk about these same topics in a job interview after you graduate.

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

• 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.

• 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.

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

• 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.

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