CompSci 308
Spring 2024
Advanced Software Design and Implementation

Lab Team Meeting: Preparing for OOGASalad

In this lab, you will practice planning the project's scope and priorities. 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 a 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 are your goals for the project?
    • 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/ 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. Create a Team Contract as a team, and:
    • individually, submit this form as your personal agreement to its content
  4. Practice Agile Project Planning
  5. Design your project APIs
  6. Team exercises with DUI!

For shared Markdown editing, you can work

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

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:

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:

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

Agile Project Planning

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.

Though this project is large and complex, it can be broken down into a set of manageable APIs that work together flexibly. Some APIs will be more fundamental than others and some can simply be placeholders or have simplified implementations until they need to be fleshed out. Within each Sprint, you may choose to start some components, make progress on others, and/or finalize the implementation of yet other components. Use features to prioritize the work among different Sprints, so there is always running, demonstrable, improvement from the previous Sprint.

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. Keeping your code clean, and refactoring as you go, should allow you to move faster as the project goes rather than having to spend an entire Sprint cleaning up from past issues.

Spend time now prioritizing project's features to complete and who will be taking the lead on each feature:

  1. list all Feature Requirements your team wants to complete (called the project's Backlog)
  2. break each feature down into one or more Use Cases (Gitlab Issues)
  3. prioritize the tasks to ensure your team has a working project to demo at the end of each Sprint and a complete project by the end of four Sprints
  4. assign each person to take responsibility to complete specific tasks each Sprint

Tasks should include both user interaction as well as backend support for each feature. Tasks may also include 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.

Note this Backlog will be updated throughout the project as new possible features and Use Cases are discussed and this process will be repeated at the start of each Sprint based on your actual progress.

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

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, slogo_teamNN repository to submit your notes about your teams' discussions:

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


Depending on how your team classifies your APIs and

  • Sprint 1: Simplest Game
    • Simplest Game Engine
    • Data Files to represent it
    • Authoring Environment that can build it
    • Player that can load and run it
  • Sprint 2: Basic Functional and MOD Variation
    • Basic Game Engine
    • Data Files to represent them
    • Authoring Environment that can build them
    • Player can have themes and preferences
  • Sprint 3: Major Variations
    • Complete Game Engine
    • Complete Data Files
    • Authoring Environment is dynamic with more game design interactions
    • Player can manage and run multiple games
  • Sprint 4: Extensions
    • Integrate team chosen Basic and Challenging Extensions
    • Complete Authoring Environment and Player
  • Sprint 1: Simplest Game
    • Basic Game Engine
    • Data Files to represent it
    • Authoring Environment that can build it
  • Sprint 2: Basic Game and Functional Variation
    • Complete Game Engine
    • Complete Data Files
    • Authoring Environment has variety of game design interactions
    • Player can run games
  • Sprint 3: Complete Game and Basic Extensions
    • Complete Complex Game Functionality
    • Integrate team chosen Basic Extensions
    • Authoring Environment is dynamic with preferences
  • Sprint 4: Complete Player
    • Integrate team chosen Challenging Extensions
    • Complete Authoring Environment and Player