Lab Team Meeting: Preparing for OOGASalad

In this lab, you will practice planning the project's scope and priorities, explore flexibility in games, and develop a Team Contract.

In your OOGASalad teams, complete the following steps:

1. Discuss each person's team experiences and expectations:
   • share good and bad past team experiences and what you learned from them
   • share preferences and styles regarding expectations, communication, and debating/conflict
   • share technical preferences regarding internal project deadlines, general design goals, and the course GIT workflow
   • choose a time for the next team meeting
2. Discuss your project goals, ideas, and roles to come to consensus as a start to your planning:
• what game genre do you want to work on?
• what parts of the project do you want to spend more or less effort on?
• what extensions to the project would be most interesting/useful?
• what would mark good progress for each Sprint?
• summarize the discussion in the file doc/SCOPE_PLANNING.md using Gitlab's Markdown format
• choose a fun/interesting name for your team (this is an excellent team build exercise because, along with agreeing on the genre, it can sometimes be the hardest part of the project :)
3. Complete this exercise to think about describing the design of a very flexible game without actually writing any code
• summarize the discussion in the file doc/DESIGN_EXERCISE.md using Gitlab's Markdown format
4. Create a Team Contract
   • discuss the questions in this worksheet to get started
   • complete this example contract template using Gitlab's Markdown format
   • individually submit this form as your personal agreement to its content
5. Clone the shared team repository to each person's machine and Open the project in IntelliJ to submit your work
6. Team exercises with DUI!

For shared Markdown editing, you can work directly within IntelliJ using the Code With Me feature or it can be enabled directly within Google Docs.

The result of this lab will be a set of documents that captures the important points of your team's several directed discussions.

Discussion

In sub-groups complete this smaller exercise that asks you to try to think about the design of a very flexible game without worrying about exactly how it will be implemented. In other words, without writing any actual implementation code, try to explore trade-offs between several designs and describe the best one in enough detail that you can get a handle on how the different rules and goals could be defined using data files.

Team Contract

Now that you have some experience with teams in this course, create your own Team Contract for this project. This document serves as an agreement between all teammates on a set of conventions to abide by. When making your contract, consider the following resources:

• minimal contract used for previous projects
• Codes of Conduct examples for Open Source projects
• individual expectations for team projects in this course

It should be created collaboratively by thinking about good or bad aspects of team project experiences you have already had, your goals for the course, how the team should communicate, the quality of work everyone wishes to achieve, and the level of group participation and individual accountability everyone feels comfortable with. The process of generating a team contract usually helps jump start a group's efforts to become a team by immediately focusing everyone on a definite task that requires communication and negotiation.

Use the questions in this worksheet to guide your discussion. Make sure to address at least these topics:

• communication goals as well as meeting types and frequency
• identifying the quality of work everyone wishes to achieve
• level of group participation and individual accountability everyone feels comfortable with
• how to make the team a safe place for everyone to participate
• what to expect from GIT commits and how to use GIT branches

Before Moving On: Complete the file doc/TEAM_CONTRACT.md, then add, commit the file, and push it to your shared oogasalad_teamNN repository.

Planning

Like most complex software, this very large can be broken down into a set of somewhat self-contained components that are potentially usable on their own but need to work together flexibly to solve the total problem. Keep in mind when your team creates a schedule for the work to be done on various components that some components are more fundamental than others and some can simply be placeholders or have simplified implementations until they need to be fleshed out. Some components will represent the Model, while others will represent the View and/or Controller.

Within each Sprint, you may choose to start some components, make progress on others, and/or finalize the implementation of yet other components. No matter how you choose to distribute the work to be done among the sprints, there should always be something demonstrably improved over the last sprint, and the code at the end of the sprint should always run (i.e., without crashing). In industry, Sprints often end with a demo to stakeholders, and progress is measured by how many features (i.e., things a customer would see as a reason for buying your product) were completed in the Sprint, rather than how much of the data structure was set up.

Try to spend some time now clarifying the order in which the project's features will be completed and who will be taking the lead on each feature.

• There is much flexibility in the specifications and goals for this project so start by listing all features your team wants to complete (called the project's Backlog) and then begin to break those down into one or more tasks (issues) for each Use Case you feel confident could get down during a single Sprint.
• Then take responsibility to complete specific tasks during each Sprint during the rest of the semester. Based on the scope of the project and your design goals, you should be able to prioritize the order of specific tasks so your team has a working app to demo at the end of each Sprint. These tasks should include both a user interface component as well as backend support for each feature and be small enough to verify they can get done during a Sprint. Tasks may also be non-programming oriented, but it should be clear from looking at the distribution of tasks that everyone on the team is accepting responsibility for their fair share.

Discuss your plan by prioritizing the components each team member plans to take primary and secondary responsibility for and a high-level plan of how the team will spend its time to complete the program. Specifically, each person should take responsibility for specific features and use cases they intend to work on during each Sprint. This requires the team to agree on the feature priorities and set a goals for each week's work.

Submitting your Work

At the end of lab, you should have pushed your team's Markdown files to the doc folder of your provided, shared, oogasalad_teamNN repository to submit your notes about your teams' discussions:

• SCOPE_PLANNING.md
• DESIGN_EXERCISE.md (for each sub-group)
• TEAM_CONTRACT.md

Make sure the text of your final commit message is of the form "lab_oogasalad_design - NetIDs".