Project Plan

• What tools will you use for your task board?
  We will be using Jira to maintain our task board.
  It can be found at https://scarb-dining-team-work.atlassian.net/jira/software/projects/SD/boards/1/backlog

• What tools will you use for your burn-down chart?
  We will be mainitaining the burn-down chart manually through Excel.

• Who will maintain the burn-down chart?
  We will be rotating the responsibility of maintaining the burn-down chart on a weekly basis, so that each member gets sufficient practice working with burn-down charts. Below is our schedule:
  

  Week Number	Dates	Member
  Week 1	June 23 - June 29	Harshit
  Week 2	June 30 - July 06	Jenisha
  Week 3	July 07 - July 13	Chandra
  Week 4	July 14 - July 20	Sumuhash
  Week 5	July 21 - July 27	Aaditya
  Week 6	July 28 - August 03	Harshit
  Week 7	August 04 - August 09	Jenisha

  The developer responsible for handling the burndown chart for the week will maintain it by:
  • Observing the task board daily and reviewing the progress for the day
  • Updating the information on the spreadsheet with the information for the day
  • Plotting the new burndown chart for the progress that was made so far

• What is every team member’s role?
  Developmental Roles
  Every member of our team will be a Full Stack Developer. As we mentioned in the first deliverable, we would like take this project as a good learning opportunity to learn everything we can from the type of development we are doing. In this role, each member will get the opportunity to develop using front-end and back-end technologies. I.e. a developer may be assigned a task that could be either front-end utilizing React JS, or a back-end task utilizing Node JS.
  Non-Developmental Roles
  The team will rotate on a weekly basis of who will attend meetings and take notes. On some weeks, 2 members of the team will attend the client meeting, and 2 different team members will attend the Friday meeting. Members who are attending will be chosen by the team based on availablity. During this meeting, the two members attendig must take notes and share with the other team members to keep them up to date.

• What tools, if any, will you use for communication?
  Our main method of communication will be Facebook Messenger. Our secondary option will be Microsoft Teams. In the case of emergency we will be using phone or text.

• When do you plan to meet in person?
  Due to the current situation with Covid-19, we will not be holding any in-person meetings. Instead we will hold virtual meeting through Facebook Messenger's video call functionailty.
  These meetings will be Mondays 1-3 pm and Wednesdays 3-6 pm.
  We will also be having daily stand-ups at 12pm everyday
  

• How will you use your repository on GitHub?
  

  The branching structure of our GitHub repo will consist of four main types of branches

  

  1. Master Branch: This branch contains production ready code.
  2. Dev Branch: This branch contains the code using dev environment variables.
  3. Feature X Branch: This branch contains the code specific to a user story/task and is branched from the Dev branch.
     It will follow the naming convetion: feature_<user_story_id>_<taskNumber>
  4. Hotfix X Branch: This branch contains fix for the bug corresponding to bug_id. For every bug discovered a card willbe added to our Jira board which will contain the bug_id of that bug. This branch also branches of the Dev branch
     The hotfix branch will follow the name convention: hotfix_<bug_id>
  5. Commits and Merges: When a developer commits any portion of code, the commits must be coherent and logically grouped. For example, 2 changes that are not related should not be grouped into a single commit and should be separated, however 2 changes that are part of the same change should be put into a single commit. Commits must also be small and logical, large commits tend to be difficult to read and follow and hence we will refrain from making such changes. Commit messages must succintly summarize what changes were made for other developers to understand the code at any point as well assist in debugging for any developer. Commit messages do not need to have any specific format as long as they allow other developers to understand changes that were made.
  6. Documentation and Style: Code style must follow React best practices and must be readable by other developers. Any code that is pushed onto the main remote repository must come with comments that describe the code and be properly documented for other developers to use.

  The folder structure of our GitHub Repo will be the following:

  • deliverables: This folder will contain directories for each of the 5 deliverables, following the naming convention: deliverable-<deliverable_num>. Each directory will have the files corresponding the that deliverable.
  • feedback: This folder is used by the TA and Professor to provide feedback on the deliverables.
  • codebase: This folder will contain all code files for the project organized into the following:
    • client: Contains all the files required for the client side of the system, such as component files and redux.
    • middleware: Contains all the code needed for the backend middleware used to control the access to protected routes
    • models: Contains all the schemas used to read and store information in the database
    • routes: Contains all the route code files used by the router
  • README.md: The README will contain all information about the project and will be updated regularly so instructors as well as developers can be updated on the status of the project.

• Which machines will be used for development by each team member?
  Chandra: Windows OS
  Jenisha: Windows OS
  Aaditya: Windows OS
  Harshit: Windows OS
  Sumuhash: Mac OS
  

• What is your DoD (definition of done)?
  We have agreed upon the following criteria to determine whether a task is done:
  

  • The feature from a user story has been developed and tested.
  • The feature has met all required acceptance tests.
  • The code has been reviewed by at least 2 members.
  • The code has passed the Style checks.

Updated Product Backlog

After getting through some of our sprint, we realized that our current point estimates and priorities needed to be revised, as we discovered that we need a bit more time to adjust to the learning curve. Hence we modified our backlog, to accommodate for the extra time required to get familiarized with the tools and technologies being used.

The full updated product backlog can be found in excel format on our Github

Our sprints will last for 2 weeks or 10 business days. We choose this duration as it gives us sufficient time to make significant changes to the the project and its features. This choice of sprint length was chosen to accommodate for the different levels of difficulty for different tasks, as well accommodate for the learning curve a developer may need to go through to get some task done.This 2 week length also allows the developers to have enough time to complete as many tasks as they can in the period as opposed to a 1 week sprint which gives too little time and 3 weeks which gives too much time to developers. The 2 week sprint seems to give the right balance of time to develop and test.

Sprint Number	Dates
Sprint 1	June 23 - July 06
Sprint 2	June 07 - July 20
Sprint 3	July 21 - August 03
Sprint 4 (shortened)	August 03 - August 09

• Sprint 1 Backlog Snapshot:

  

  Each story has its associated subtasks as children as well as the associated acceptance criterion:

  

  To view the rest of the stories/tasks please vist the board at: https://scarb-dining-team-work.atlassian.net/
  The sprint backlog can also be found in excel format on our Github
  

• Rough Plan of who will do what:

  Member	Assigned Tasks
  Harshit	SD-99, SD-90, SD-89, SD-88, SD-82, SD-81, SD-80, SD-43
  Jenisha	SD-95, SD-93, SD-84, SD-83, SD-6, SD-3
  Chandra	SD-100, SD-97, SD-92, SD-91, SD-71, SD-56, SD-5, SD-4
  Sumuhash	SD-98, SD-86, SD-85, SD-79, SD-50, SD-49
  Aaditya	SD-96, SD-78, SD-77, SD-76, SD-75, SD-72

• Inital Jira snapshot (Sprint 1):

  

• Initial burn-down snapshot
  

  

• Updated burn-down snapshot. As you can see, the progress of the application is slow, but has begun to pick up as the sprint progressed
  

  

Component Descriptions

User Interface

Navigation Bar

Component responsible for the navigation throughout the website. Provides links to the Home, Login, User registration and restaurant registration pages. It is present on all 4 of these pages and redirects to the corresponding pages when clicked.

Landing Home Page

The first page the user will see when accessing the site. Provides information on the benefits of the site for both users and restaurants. Also provides a button to navigate to the "About Us" for more information.

Login Page

This page prompts users to enter their credentials to login to their account. This information is retrieved through the login form component. This page needs to communicate to API for verification.

User Registration Page

This page is for new customer users to sign up on the site. The information is collected through the user registration form. This component needs to communicate with the API to store user’s information into the database.

Restaurant Registration Page

This page is for new restaurant owners to sign up their restaurants on the site, where the required information is collected through the restaurant registration form. This component needs to communicate with the API to store restaurant’s information into the database.

User Dashboard

This page is the view the customer user sees after logging in on the site. This page shows users a list of restaurants and lets them filter and search for restaurants. This component needs to communicate to API to get the restaurant suggestions list for the user.

Restaurant Dashboard

This page is the view the user sees after logging in as a restaurant. Here the most recent restaurant analytics are displayed. Alongside this there is a button that allows the user to navigate to the edit restaurant view to modify their restaurant info.

Edit Restaurant Info Form

This form is for restaurant owners to edit information about their restaurant. This component needs to communicate to API to change the information in the database.

Order Cart

This is a list of items from a restaurant’s menu, which contains the items a customer user is trying to order. It should have checkout button and cancel order/item button. This component needs to communicate to API once an order is placed.

Order Cart

This is a list of items from a restaurant’s menu, which contains the items a customer user is trying to order. It should have checkout button and cancel order/item button. This component needs to communicate to API once an order is placed.

Restaurant Page (User View)

This is the page that the user sees when they select a restaurant from their search results. It includes the menu which is generated by the API reading the restaurants items from the database. In this page, the user can also view the chef’s pages.

Order History

This page shows the history of the orders a customer user has placed in the past. This component needs to communicate to the database inorder to get the order history.

Payment Form

This page is shown to the customer user once an order has been checked out. This lets the user select an option to either pay by cash or pay by card. This component needs to communicate to API in order to verify and process payment.

Chef Page

This page shows a list of chefs in the database. This component needs to communicate in order to read chef data from the database.

Edit chef page form

This form is for chef users to edit information about themselves and add more dishes. This component needs to communicate to API to change the information in the database.

Upload videos/pictures form

This form is for chef users to add pictures and videos to their profile. This component needs to communicate to API to edit information in the database.

Menu Page

This page is shown once a customer user selects a restaurant to order food from. This component is dependent on API to get menu items from.

Edit item form

This form is shown once a restaurant user selects to edit information in the menu of their restaurant. This component is dependent on API to change information in the database.

Add item form

This form is shown once a new restaurant user selects to add information in the menu of their restaurant. This component is dependent on API to change information in the database.

API

User Authentication

This authentication is for verifying user credentials (username, password). This is dependent on the database to verify information.

CRUD Functions for Items

This component is responsible to create,update and remove menu items for a restaurant. This component makes changes in the database.

CRUD Functions for Restaurant info

This component is responsible to edit restaurant’s information. This component makes changes in the database.

CRUD Functions for User info

This component is responsible to edit user’s information. This component makes changes in the database.

Database

User Collection

This collection is for storing user’s information. The fields stored are determined by the role of the user (customer or restaurant).

Menu Items Collection

This collection is for storing restaurant menus.

NOTE: Although a complete sprint has not completed for this group, we will attempt to answer the following questions to the best of our abilities. As mentioned above, our sprint ends on July 6th, 2020 and we will attempt to update the following as soon as possible.

Project Velocity

With nearly half the sprint completed, we feel that the project is moving at a good pace. Although the burndown chart may show that the rate at which tasks are completed are slow this is largely due to the learning curve that came with learning the technology required to build the project. With the daily talks that the team has, we are beginning to understand how develop effectively using the technology we have, and are picking up the pace of development. We believe that by the end of the sprint, we will be able to accomplish what we had set out initially.

Below is the burndown chart that depicts the progress of the team from estimated to actual.

Sprint Reflection

The plans set out by the team were initially thrown off track a little bit by the set up process that was involved for the project. However, after overcoming the inital set up that was required to run the project, the team got right back on track and began completing tasks as they were planned. In the end, it seems that we have balanced out the initial pace set out and the current pace of development.

Luckily for our project, we have not needed to use our contingency plan. Developers have been following their tasks fairly well and have not needed to resort to any other methods for completing tasks.