Project Management

Scrum Methodology will be used for managing the project.

Sprints

• We will have weekly sprints.
• Each sprint will start and end every Monday after class.
• After every class we will have small retrospective meeting (either from slack or face-to-face) in order to discuss what went good and bad at that sprint and what can we do in order to improve the next one.
• After retrospective, we will plan the next sprint based on the discussion at class.
• Sprints name should have the following format: Sprint{SprintNumber}-{MilestoneName}.

Board Management

• We will use "Projects" page in github to follow issues. We will have "ToDo", "InProgress", "CodeReview" and "Done" sections.
• Board should only contain items in that sprint
• ToDo: Items that are expected to be done in that sprint
• InProgress: Items that are in progress. Everyone should change to assignee to themselves before moving an issue to this section.
• CodeReview: Items that have been done and created a pull request. Someone other than the assignee of the issue should review and confirm the code. Everyone should create a pull request before moving an issue into this section. If no development needed for the issue, you can skip this item. Every issue which has "development" label should be moved to this section when the development is done.
• Done: Items that are done without development or issues with development which pull request was confirmed and merged.

Issue Management

• Each issue should have a brief description about what should be done
• Anyone in the team can create issues.
• Every development issue should also have at least one of the following related labels: "Api","FrontEnd","Mobile"

Development Management

Modules

• We will have 3 modules. "Api", "FrontEnd", "Mobile"
• Each module should be on seperated folder under repository

Branching

• We will follow git flow.
• Each commit description should start with related issue number. For example #issue{issuenumber}-{CommitDescription}
• If there is any conflict which developer is not sure how to merge, it is developer's responsibility to contact with other developers and merge correctly.
• Using a branching tool such as "SourceTree" is highly recommended in order to follow proper git flow.

Testing

• Time to time, we will have presentations to the product owner. When we are going to do a presentation we should create a release 2 days prior to the presentation from the development branch and do a regression test as a team. If a bug is found we should fix it on release branch.
• Every developer should test their code before sending it to code review.
• After presentation we should finish release which will merge it to both master and development.

Unit Tests

• We won't have any code coverage limits but every developer should write some unit tests about their code.