CompSci 307
Fall 2021
Software Design and Implementation

OOGA Team Meeting

In your OOGA teams, complete the following activities today:

  1. Introduce yourselves by sharing:
    • where you are and how you are experiencing school this semester
    • your motivation/interest in this course
    • your knowledge/interest in games (or online shopping/rating experiences if games are not your thing)
    • areas of the project you interested or concerned about
  2. Discuss each person's team experiences and expectations
    • share good and bad past team experiences and what you learned from them
    • share social preferences and styles regarding expectations, communication, and debating issues
    • share technical preferences regarding internal project deadlines, general design goals, and a GIT workflow
    • choose a time for the next team meeting
  3. Discuss your project goals, ideas, and roles to come to consensus as a start to your planning:
    • what are your goals for the project?
    • what parts of the project do you want to spend more or less effort on (game complexity or variety, viewer, engine, etc.)?
    • what extensions to the project would be most interesting/useful?
    • what would mark good progress for each Sprint/week?
    • summarize the discussion in the file PLANNING.md using Gitlab's Markdown format
    • choose a specific game genre the team wants to work on
  4. Create a Team Contract
    • discuss the questions in this worksheet to get started
    • complete this example contract template using Gitlab's Markdown format
    • additionally, individually submit this form as your personal agreement to its content
    • 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 :)
  5. Complete this exercise to think about describing the design of a very flexible game without actually writing any code
  6. Clone the shared team repository to each person's machine and Open the project in IntelliJ to submit your work
  7. Team exercises with DUI!

Submission

By the end of lab, push your Team Contract and discussion summaries to the doc folder of the master branch of your team's provided Gitlab repository using the commit message "lab_plan - participating NETIDs".

Individually, submit the Team Contract form as your personal agreement to its content.

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 team mates about how the team will operate and has been adopted by many Open Source coding projects.

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.

As a reminder, here are the individual expectations for course team projects.

Planning

Like most complex software, OOGA 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 each Sprint should always be runnable (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 (or some other "technical" goal).

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.

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.