-
Notifications
You must be signed in to change notification settings - Fork 2
Sprint 2 Retrospective
loucadufault edited this page Nov 1, 2019
·
2 revisions
- Sprint planning was adequate, tickets were assigned and followed their lifecycle on the Kanban board. Not much room for improvement in the Kanban board
- Team meetings were very productive and all members were present each time (outside of extenuating circumstances)
- Planned meetings with mentors or TA often fell through
- FB messenger was used more than slack
- a dev branch was made to protect master
- the gitignore were finalized
- javadocs are made for almost all methods
- limit branching
- commit often to avoid conflicts
- work on delimited parts of the codebase
- only make small patches (for instance minor comment changes to a dozen different files across all packages) as a single commit when no one else has any pending work to avoid conflicts
- branches are only used for major new features or epics, can be worked on by several devs
- branches should not be used to make a most recent copy of the work when conflicts
- branches should be merged onto dev first
- master should always be fully functional (no travis errors)
- fix the file names for the service methods
- fix the model names for the review models
- standardize the service method names, have a general service interface that all services implement
- standardize the service method parameters, some methods act on the object passed as argument, som on the object whose id is passed as argument (see https://github.com/McGill-ECSE321-Fall2019/project-group-21/issues/50)
- add multiple constructors for most services, one with all parameters and one with the parameters that will be provided by the user in the general use case