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. Practice Agile Project Planning
2. Design your project APIs

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.

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/AGILE_PLANNING.md, then add, commit the file, and push it to your shared oogasalad_teamNN repository.

Designing your Project APIs

APIs are contracts with developers (now clients), that helps them innovate by acting as a reliable service even if your underlying implementation changes. Although the concept is inherently subjective, most developers seem to agree that APIs should have the following characteristics and need to be revised before getting them right:

• Easy to learn
• Hard to misuse
• Provide for extension

When designing a set of services to be used by other developers (current and future team members), consider the following:

• Goal: how to encapsulate the implementation details while encouraging changes (extensions for as many different kinds of features as possible)
  • Such as: between the backend and frontend (e.g., between programmers in a project's other sub-groups to allow them to develop independently and in parallel)
  • Such as: between a platform and completely external developers (e.g., between iOS and app developers or between Unity and game developers)
• Contract: what services can you provide to encourage other programmers to build their own new functionality?
  • How do you plan to encapsulate them from implementation changes?
  • What objects will be used for communication, making clear:
    • how needed information will be delivered to where it is needed
    • what will be abstractions
    • what errors may be thrown
    • what things will be immutable
    • how to make the process as active as possible (not just giving out raw data)

When designing the each API service for your project, note that Design-18 requires the API consists of only abstractions (Java interfaces or abstract classes), purely immutable classes, or Exceptions.

After creating a "one-page" design for each API (with the most significant methods), test it against your Use Cases, providing English and Java descriptions for each:

• English: how do you want programmers to think of the process of using the API to accomplish this task using metaphors or analogies (e.g., event-response paradigm), or standard programming ideas (e.g., step by step or substitution via polymorphism) beyond simply restating the procedural steps
• Java: list the actual Java methods you expect to use from the API to accomplish this task with a comment about how they would be used (e.g., call, implement, or change)
  Note, include any Exceptions you plan to throw because of errors that might occur within your methods.

Before Moving On: Add the following to the file doc/API_PLANNING.md, and add, commit the file, and push it to your project 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:

• AGILE_PLANNING.md
• API_PLANNING.md

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