Skip to content

Sprint 2 Retrospective

loucadufault edited this page Nov 1, 2019 · 2 revisions

What worked well

Management

  • 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

Version-control

  • a dev branch was made to protect master
  • the gitignore were finalized

Codebase

  • javadocs are made for almost all methods

What didn't work well

Management

Version-control

Codebase

What can be improved

Management

Version-control

  • 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

Codebase

Conventions to adopt for Sprint 3

Management

Version-control

  • 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)

Codebase

  • 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