-
Notifications
You must be signed in to change notification settings - Fork 1
Product Preparation
PourDecisions is a website and mobile application that contains a database of adult beverages (i.e., cocktails and mocktails) and suggests recipes from the database based on inputted ingredients. Users may add their own custom recipes, view a catalog of recipes, save their favorite recipes, rate other user’s recipes, and visit previously viewed recipes through their account history. The application will work on iOS and Android devices.
The Proxy Product Owner is Emilia Sollaberrieta, and the Scrum Master is Julie Chen. The remaining members of the team are software developers.
Git will be used for source control and Github will be used for version control. Source code, unit tests, automated acceptance tests, and product documentation will be kept in source control. Any code written by a developer will be done on a separate branch, using the GitHub ‘pull request’ feature whenever the code is to be merged with the master branch.
npm will be used as the build tool for this project, and will launch automated story tests and acceptance tests as part of the build process. GitHub Actions will be used for Continuous Integration (CI).
The database that will be used is MongoDB. Mongoose.js will be used to facilitate the implementation of the persistence by providing schemas and reducing the amount of boilerplate code.
The backend services will be based on a UML class diagram created by the developers. RESTful APIs will also be implemented to link the business services to the frontend.
The frontend website will be implemented using React.js, and the frontend mobile application will be implemented using React Native.
An interactive user interface (UI) mockup will be created using Figma to ensure consistency across pages during development. RESTful API’s will be used to link the application buttons to the backend services.
The entire team will meet every week on Sunday at 3PM virtually on Discord. This meeting will be facilitated by the scrum master. A mid-week, relatively quick, check-in will also happen every Wednesday at 8PM. A planning meeting will be held on the first day of each sprint, and a retrospective and demo meeting will be held at the end of each sprint.
Google Drive and its various tools (i.e., Google Docs, Google Slides, Google Sheets) will be used for collaboration of documentation, meeting minutes, and file storage. Any major documentation necessary for future reference will be uploaded to GitHub Wiki. Discord will be used for key updates, with specific channels dedicated to the various topics of the project. It will also be used for debugging or collaboration meetings. Facebook Messenger will be used for quick updates or meeting requests and planning.
GitHub will be used to share and develop the code base within the group for project tracking and version control. GitHub’s issue tracker tool will be used to document any errors/bugs found within the code base, and to alert team members of any tasks that need to be completed. The scrum mask will maintain the issues and task list.
The Done Checklist will be verified after all tasks pertaining to a specific story are completed by the scrum master. If all items in the list are confirmed to be true, the user story will be marked as ‘done’ (completed) in the product and sprint backlog. Any issues will be brought to the team for discussion and debugging. This checklist was designed to be able to apply to each user story in the sprint 1 backlog.
- The code builds successfully.
- The code can be executed.
- All story related tasks in the Sprint Backlog have been completed.
- All of a story’s code is integrated into the main source code (i.e. merged into the master branch).
- Unit tests using the Gherkin feature files have been written, run, and succeed as part of the build process.
- All previously automated unit tests still succeed.
- All story specific acceptance tests succeed.
- All story normal and alternate flow story tests are automated and run as part of the build process.
- All of a story’s code has been peer reviewed and accepted.
- All known bugs have been reviewed and documented. Any bugs which block acceptance tests from passing have been corrected.
- The user story has at least one positive normal flow and one error flow in the Gherkin feature file.
- The user story has at least one unit test written for positive normal flow and another for error flow.
- All normal and alternate flows acceptance tests pass.
- The user story has a fully functioning page that persists with the database.